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

[Mohanson]

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

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

[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 有道理，先规划，在动手

[yannxia]

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

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