《代码整洁之道》

前言
代码之于程序员，就如工艺品之于工匠。 两者都需要技艺（craftmanship)。技艺需要打磨，需要“刻苦习得”。怎样打磨，如何习得，这未必是每个程序员都会认真思考的。《代码整洁之道》提出了“整洁感”，程序不一定要有“艺术感”，但“整洁”是判断程序优劣的标准，“整洁感”是将程序化劣为优的攻略。作者在写代码的各处细节中总结经验，得出一套最佳实践。

第一章 整洁代码

将需求明确到机器可以执行的细节程度，就是编程要做的事，而这种规约正是代码。
抛弃代码等于抛弃精确性，所以代码永远存在。

糟糕的代码可以毁了这家公司。

我们都曾经瞟一眼自己亲手造成的混乱，决定弃之不顾，走向新的一天。我们都曾经看到自己的烂程序居然能运行，然后断言能运行的烂程序总比什么都没有强。我们都曾经说过有朝一日再回头清理。当然，在那些日子里，我们都没听过勒布朗法则：
稍后等于永不（Later equals never) 。


随着代码混乱的增加，团队的生产力也持续下降，甚至趋于零。当生产力下降时，管理层就只有一件事可做了：增加更多的人手到项目中。但新手往往一时间搞不清楚什么样的修改符合设计意图，什么样的修改违背设计意图；同时，所有人背负着提升生产力的可怕压力。于是更多的混乱产生了。。。

也许可以组建新团队，搭建新系统。但在新系统足以抗衡就系统之前，管理层不会扔掉旧系统。这样的以新替旧的过程会延续极长的时间。可能到新系统做成之时，新团队的老成员早已不知去向，而新成员则要求重新设计一套系统，因为这套系统太烂了。

多数经理想要知道实情，即便他们看起来不喜欢实情。多数经理想要好代码，即便他们总是痴缠于进度。他们会奋力卫护进度和需求；那是他们该干的。你则当以同等的热情卫护代码。
  同理，程序员遵从从不了解混乱风险的经理的一员，也是不专业的做法。

赶上期限的唯一方法——做得快的唯一方法——就是始终尽可能保持代码整洁。

能分辨整洁代码和肮脏代码，不意味着会写整洁代码。 写整洁代码，需要遵循大量的小技巧，贯彻刻苦习得的“整洁感”。

第二章 有意义的命名

 

2.2 名副其实

变量，函数或类得名称应该表明了一段程序中的所有大问题：为什么存在，做什么事，应该怎么用。

坏的命名会让程序的意图模糊甚至不可测。

 

2.3 避免误导

缩写会造成误导。

在名字前后加上诸如List这样的类型名也会造成误导。

不用字母“o"和"l"作为变量名。

 

2.4 做有意义的区分

不用无意义的或没必要的词

 

2.5 使用读得出来的名称

genymdhms是个好名字吗？

 

2.6 使用可搜索的名称

 

2.7 避免使用编码

 

2.8 避免使用思维映射

 

2.9 类名

类名和对象名应该是名词或名词短语。

 

2.10 方法名

方法名应该是动词或动词短语。

 

2.11 别扮可爱

 

2.12 每个概念对应一个词

以一贯之

 

2.13 别用双关语

 

2.14 使用解决方案领域名称

 

2.15 使用源自所涉问题领域的名称

使用解决方案领域名称不能时

 

2.16 添加有意义的语境

 

2.17 不要添加有没用的语境