新学习到一条写代码的定律，分享大家

[Mohanson]

提示：代码越少越好（劳尔定律） 程序员倾向于吹嘘自己使用大量的代码实现某功能。这样做本质上是不对的。我们应该吹嘘以很少的代码实现给定的任务。简洁的代码更易懂，缺陷更少。正如 Hugh Lauer 在讨论构建一个飞行员操作系统时说：“如果给同样这些人两倍的时间，他们可以只用一半的代码来实现”[L81]。我们称之为劳尔定律（ Lauer's Law ），很值得记住。下次你吹嘘写了多少代码来完成作业时，三思而后行，或者更好的做法是，回去重写，让代码更清晰、精简。

来自操作系统导论。我记得我工作的第一个月的月报是统计了这个月写了多少行代码。。。溜了

[Mohanson]

我想反思下许多开源项目都存在的没有设计和过度设计这两个方面，都会让代码又臭又长。

[imdong]

有一段时间，会特别刻意追求代码临江越短越好。

后来就想开了，去 T 喵 D 优雅，为了短而短时没意义的。

舒舒服服的把问题解决了，不就坑就行。

1 行代码和 10 代码没区别，自己写的舒坦就好，顺便让后人看着舒坦就更好了。

[kop1989]

其实程序设计是取舍的艺术，每个人都能说出他这么设计的理由。
代码少是好的没错，但是代码少就意味着耦合性必然高。
所以没有最优解而言。
只要程序设计方案和项目的需求匹配，就是好设计。

[raaaaaar]

过于追求代码的长度都是不合理的，过长肯定是规划不合理，过短是追求炫技也不行，规划设计好是第一步，然后合理的规范，以易读为准则才是正确的。
当然这是工程的原则，我有时看到 一些人在 c 或 python 中，把一大段融合在一行中，光是看都要理清半天，那这个代码从工程上来说肯定是不合理的。

[Hoye]

只要不是为了短而短就好了，代码是写给人看的，附带能让机器运行 - layui

[w568w]

于是 Robustness 通常就会很低，尤其是对于业务代码而言（摊手）

[encro]

想起了 知识产权。。。的代码

[sonxzjw]

对于“简洁的代码更易懂”我不认同，这没有必然关系。
我看过不少简洁的代码（多种语言），内里的逻辑更为复杂。

[Leonard]

有时过于简化的代码可读性会非常差。。凡事注意个度

[hengstchon]

现在人评论时，都不先检查一遍错别字漏字啥的吗？
自己写的舒服了，人家看着真累。
观 2 楼老哥留言有感。

[jswh]

到目前为之，我觉得最有用的规则是，一个函数不允许超过 xx 行。我自己定的是 20 行，正常情况下。

[encro]

应该吹嘘的是用最少的代码产生了多大的价值。
比如我用几行行代码实现了按订单金额筛选客户，然后客户说这功能太有用了。

[luckyliu1926]

必须是这个样子

[zaima]

衡量写的项目好坏的有代码量、完成的时间、可读性、可扩展性等等等等方面，个人认为，单用代码多或少去判断好或不好都是扯淡！

[coderluan]

不完全是, 给楼主推荐本书, 叫<<短码之美>>, 你会感觉这代码卧槽好牛逼, 但是你同事这么写你肯定只想抽死他, 所以比起短, 更准确的说法是整洁, 再推荐本书, 叫<<代码整洁之道>>, 个人认为是程序员必读书籍.

[Keeper]

能管理好复杂度就行

[mitu9527]

代码“整洁”不等于代码“少”，代码要整洁到什么程度也不是一成不变的，要视情况决定。

建议大家去读读《程序员修炼之道》，相信会有一些不一样的收获。

[skymei]

目前接手的代码就有种感觉，过度抽象了，为了抽象而抽象，搞的业务代码跳来跳去，有些隐藏的 bug 不好查。

[aydd2004]

然后重构的时候 使劲抽自己嘴巴

[miv]

我有个建议就是想清楚、设计好在写，写的过程中，发现有优化的及时优化，因为可能考虑不是很周全。
这样，后面的代码因为有了前面的设计和铺垫，会写起来很舒服，而且“牛逼”二字也慢慢显露出来（可能自己还没意识到，当搞好了，回过头，你就有这样子的体会）
如果一开始写垃圾代码，后面加需求或者功能变动，改起来很吃屎一样难受。
特别是改别人代码的时候。

[zdnyp]

不谈剂量讲毒性，都是耍流氓

华丽花哨的一大堆语法糖有 p 用，兼容性差，难读

[xcstream]

程序员应该学习如何拒绝不合理需求

[guo8345345]

java 的 lambda 表达式，可以把以前 N 行的代码写在一行。但你确定这个玩意儿可读性好么？

[CEBBCAT]

@encro #12 风马牛不相及，业务是业务，工程是工程。这个帖子讨论的是怎么让代码变得更好，代码写得稀烂也可以 work，但当改需求的时候就傻眼了

[guo8345345]

@guo8345345 不小心敲到回车了。简单常用的还好，一些罕见的、复杂的，真心读起来难受。

[Mohanson]

哈, 帖子下的许多人都被某些楼带歪了, 当我们谈论代码越少越好时, 不是极端的--用 lambda 把所有功能写到一行, 或者刻意的用花里胡哨的方式.

[x66]

只有我一个人觉得 lambda 比一大段的循环+if 更好阅读？

[InkStone]

@Mohanson 是的，其实并不是越短越好，而是越简单越好

[hoyixi]

大多数人在 堆 代码，不是在写

[LennieChoi]

这就是代码老手和代码新手的区别。新手觉得面向对象设计模式是铁律，左一层右一层糊墙一样封装，最后自己都蒙了。成了老手会发现，代码即 bug，代码越少，bug 越少，有时候不需要封装对象 做复杂的操作，直接操作数组、map 对象一样好用，还减少 bug，毕竟这些东西最终是变成冰冷冷的数据存到数据库的，对数据过多封装 没用

[atonku]

从头到尾一个 map 或者 json,鬼知道你里面放的什么东西，还是对象好用

[encro]

@CEBBCAT

实现同样功能，在容易理解的前提下，一般是代码越少越好，这个基本没错的，所以我认为没有什么好讨论的。

才提出程序员不仅关注功能，还可以关注需求，在实现同样需求前提下，（方案）代码越少越好，其实也是成立的，因为上面很多楼歪了，所以跟着歪了一下，比较玩笑，见谅。

以下为我理解：

1，一本书完成时，不是不可以加任何东西，而是不能再减任何东西（莎士比亚，同样适合项目和代码）；
2，代码越少，出错可能性越少；
3，代码少，往往意味对需求理解透彻
4，代码少，往往意味重用性好

以上代码大全一书中就有相关解说。

[encro]

写代码的三个好习惯，可以帮助你比 90%的程序员写出更好的代码：

1，写之前先在脑子里面过一遍逻辑，尽量做到胸有成竹，如果不行还可先画画流程图；

2，使用伪代码编写注释，将写代码变成填空；

3，写完代码之后优化下，尝试使代码更少，更易读。

[better]

@encro 有道理，先规划，在动手

[Yanickkk]

这事情我觉得还分 2 部分：

1. 新手可能会堆代码，生搬硬套。
2. 老手要防止过早优化（或者说预留扩展）