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

[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]

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