这是一个创建于 1364 天前的主题，其中的信息可能已经有所发展或是发生改变。
提示：代码越少越好（劳尔定律） 程序员倾向于吹嘘自己使用大量的代码实现某功能。这样做本质上是不对的。我们应该吹嘘以很少的代码实现给定的任务。简洁的代码更易懂，缺陷更少。正如 Hugh Lauer 在讨论构建一个飞行员操作系统时说：“如果给同样这些人两倍的时间，他们可以只用一半的代码来实现”[L81]。我们称之为劳尔定律（ Lauer's Law ），很值得记住。下次你吹嘘写了多少代码来完成作业时，三思而后行，或者更好的做法是，回去重写，让代码更清晰、精简。
来自操作系统导论。我记得我工作的第一个月的月报是统计了这个月写了多少行代码。。。溜了
 |
1
Mohanson OP 我想反思下许多开源项目都存在的没有设计和过度设计这两个方面，都会让代码又臭又长。
|
 |
2
imdong 2020-07-23 16:58:39 +08:00 via iPhone  1
有一段时间，会特别刻意追求代码临江越短越好。
后来就想开了，去 T 喵 D 优雅，为了短而短时没意义的。 舒舒服服的把问题解决了，不就坑就行。 1 行代码和 10 代码没区别，自己写的舒坦就好，顺便让后人看着舒坦就更好了。 |
 |
3
kop1989 2020-07-23 16:59:20 +08:00 1
其实程序设计是取舍的艺术，每个人都能说出他这么设计的理由。
代码少是好的没错，但是代码少就意味着耦合性必然高。 所以没有最优解而言。 只要程序设计方案和项目的需求匹配，就是好设计。 |
 |
4
raaaaaar 2020-07-23 17:03:26 +08:00 via Android
过于追求代码的长度都是不合理的，过长肯定是规划不合理，过短是追求炫技也不行，规划设计好是第一步，然后合理的规范，以易读为准则才是正确的。
当然这是工程的原则，我有时看到 一些人在 c 或 python 中，把一大段融合在一行中，光是看都要理清半天，那这个代码从工程上来说肯定是不合理的。 |
 |
5
Hoye 2020-07-23 17:03:28 +08:00
只要不是为了短而短就好了，代码是写给人看的，附带能让机器运行 - layui
|
 |
6
w568w 2020-07-23 17:05:10 +08:00
于是 Robustness 通常就会很低，尤其是对于业务代码而言（摊手）
|
 |
7
encro 2020-07-23 17:06:59 +08:00
想起了 知识产权。。。的代码
|
 |
8
sonxzjw 2020-07-23 17:09:35 +08:00
对于“简洁的代码更易懂”我不认同，这没有必然关系。
我看过不少简洁的代码（多种语言），内里的逻辑更为复杂。 |
 |
9
Leonard 2020-07-23 17:17:51 +08:00
有时过于简化的代码可读性会非常差。。凡事注意个度
|
 |
10
hengstchon 2020-07-23 17:18:10 +08:00
现在人评论时，都不先检查一遍错别字漏字啥的吗？
自己写的舒服了，人家看着真累。 观 2 楼老哥留言有感。 |
 |
11
jswh 2020-07-23 17:20:49 +08:00
到目前为之，我觉得最有用的规则是，一个函数不允许超过 xx 行。我自己定的是 20 行，正常情况下。
|
|
12
encro 2020-07-23 17:23:25 +08:00 1
应该吹嘘的是用最少的代码产生了多大的价值。
比如我用几行行代码实现了按订单金额筛选客户，然后客户说这功能太有用了。 |
 |
13
luckyliu1926 2020-07-23 17:25:18 +08:00
必须是这个样子
|
 |
14
zaima 2020-07-23 17:29:11 +08:00
衡量写的项目好坏的有代码量、完成的时间、可读性、可扩展性等等等等方面，个人认为，单用代码多或少去判断好或不好都是扯淡！
|
 |
15
coderluan 2020-07-23 17:30:51 +08:00
不完全是, 给楼主推荐本书, 叫<<短码之美>>, 你会感觉这代码卧槽好牛逼, 但是你同事这么写你肯定只想抽死他, 所以比起短, 更准确的说法是整洁, 再推荐本书, 叫<<代码整洁之道>>, 个人认为是程序员必读书籍.
|
 |
16
Keeper 2020-07-23 17:39:20 +08:00
能管理好复杂度就行
|
 |
17
mitu9527 2020-07-23 17:40:11 +08:00
代码“整洁”不等于代码“少”，代码要整洁到什么程度也不是一成不变的，要视情况决定。
建议大家去读读《程序员修炼之道》，相信会有一些不一样的收获。 |
 |
18
skymei 2020-07-23 17:41:15 +08:00
目前接手的代码就有种感觉，过度抽象了，为了抽象而抽象，搞的业务代码跳来跳去，有些隐藏的 bug 不好查。
|
 |
19
aydd2004 2020-07-23 17:42:58 +08:00
然后重构的时候 使劲抽自己嘴巴
|
 |
20
miv 2020-07-23 17:45:56 +08:00
我有个建议就是想清楚、设计好在写，写的过程中，发现有优化的及时优化，因为可能考虑不是很周全。
这样，后面的代码因为有了前面的设计和铺垫，会写起来很舒服，而且“牛逼”二字也慢慢显露出来（可能自己还没意识到，当搞好了，回过头，你就有这样子的体会） 如果一开始写垃圾代码，后面加需求或者功能变动，改起来很吃屎一样难受。 特别是改别人代码的时候。 |
 |
21
zdnyp 2020-07-23 17:48:08 +08:00
不谈剂量讲毒性，都是耍流氓
华丽花哨的一大堆语法糖有 p 用，兼容性差，难读 |
 |
22
xcstream 2020-07-23 17:53:35 +08:00
程序员应该学习如何拒绝不合理需求
|
 |
23
guo8345345 2020-07-23 18:01:27 +08:00
java 的 lambda 表达式，可以把以前 N 行的代码写在一行。但你确定这个玩意儿可读性好么？
|
 |
24
CEBBCAT 2020-07-23 18:02:17 +08:00
@encro #12 风马牛不相及，业务是业务，工程是工程。这个帖子讨论的是怎么让代码变得更好，代码写得稀烂也可以 work，但当改需求的时候就傻眼了
|
|
25
guo8345345 2020-07-23 18:02:19 +08:00
@guo8345345 不小心敲到回车了。简单常用的还好，一些罕见的、复杂的，真心读起来难受。
|
|
26
Mohanson OP 哈, 帖子下的许多人都被某些楼带歪了, 当我们谈论代码越少越好时, 不是极端的--用 lambda 把所有功能写到一行, 或者刻意的用花里胡哨的方式.
|
 |
27
x66 2020-07-23 18:23:52 +08:00
只有我一个人觉得 lambda 比一大段的循环+if 更好阅读？
|
 |
29
hoyixi 2020-07-23 19:00:21 +08:00
大多数人在 堆 代码，不是在写
|
 |
30
LennieChoi 2020-07-23 19:13:44 +08:00
这就是代码老手和代码新手的区别。新手觉得面向对象设计模式是铁律，左一层右一层糊墙一样封装，最后自己都蒙了。成了老手会发现，代码即 bug，代码越少，bug 越少，有时候不需要封装对象 做复杂的操作，直接操作数组、map 对象一样好用，还减少 bug，毕竟这些东西最终是变成冰冷冷的数据存到数据库的，对数据过多封装 没用
|
 |
31
atonku 2020-07-24 11:16:48 +08:00
从头到尾一个 map 或者 json,鬼知道你里面放的什么东西，还是对象好用
|
|
32
encro 2020-07-24 11:39:47 +08:00
@CEBBCAT
实现同样功能，在容易理解的前提下，一般是代码越少越好，这个基本没错的，所以我认为没有什么好讨论的。 才提出程序员不仅关注功能，还可以关注需求，在实现同样需求前提下，（方案）代码越少越好，其实也是成立的，因为上面很多楼歪了，所以跟着歪了一下，比较玩笑，见谅。 以下为我理解： 1，一本书完成时，不是不可以加任何东西，而是不能再减任何东西（莎士比亚，同样适合项目和代码）； 2，代码越少，出错可能性越少； 3，代码少，往往意味对需求理解透彻 4，代码少，往往意味重用性好 以上代码大全一书中就有相关解说。 |
|
33
encro 2020-07-24 11:45:07 +08:00
写代码的三个好习惯，可以帮助你比 90%的程序员写出更好的代码：
1，写之前先在脑子里面过一遍逻辑，尽量做到胸有成竹，如果不行还可先画画流程图； 2，使用伪代码编写注释，将写代码变成填空； 3，写完代码之后优化下，尝试使代码更少，更易读。 |
 |
35
yannxia 2020-07-24 15:22:38 +08:00
这事情我觉得还分 2 部分：
1. 新手可能会堆代码，生搬硬套。 2. 老手要防止过早优化（或者说预留扩展） |
Select Language