有很多人说作为一个程序员，必须看看《代码整洁之道》(clean code)，虽然自己也阅读了并实践了一些公司总结的前后端代码规范，但总觉得缺少点什么，这个书与一般的代码规范的区别在于，代码规范记录的是死的条目，拿来直接照着用就可以了，而这本书从一个更深层的角度剖析了如何写出高质量代码的问题。
代码的质量与整洁都成正比，这是整本书的中心，我主要阅读了第一、二、三、四、五章，这些章节的内容与目前的工作内容紧密相关，将以下较为重要的点整理摘录如下。
整洁代码
项目经常在初期进展迅速，但在后期却慢如蜗牛，因为每次的修改都会影响到其他地方的两三处代码，混乱的增加，团队的生产力持续下降，管理层只好增加更多的人手到项目中，但事与愿违，新人并不熟悉系统。
进度和代码质量可能互相矛盾，项目经理护卫项目的进度和需求，开发人员则抱怨需求脱离了最初的设计，哀叹进度太紧张，没法好好干活，制造混乱无助于赶上期限，赶上期限唯一的方法——始终尽可能的保持代码整洁。
写出整洁的代码，需要遵循大量的小技巧，不断去实践以获得“整洁感”。
“破窗理论”也适用于软件项目开发，开到别人不规整的代码，放任自己也参与了破坏活动。
有意义的命名
- 名副其实。如果命名需要注释来说明，就不叫名副其实。
- 避免误导。hp、aix、sco不应该作为变量名，应为它们是某些平台的专有名称。提防使用不同之处较小的名称，比如XYZContorllerForEfficientHandlingOfStrings和XYZControllerForEffientStorageOfStrings。避免大写O和小写L作为变量名，可能会被看作阿拉伯数字0和1。
- 做有意义的区分。不能仅仅为满足编译器的的需要而写代码，代码更重要的是给人来阅读的。
- 使用读得出来的名称。
- 使用便于搜索的名称。
- 使用解决方案领域的名称。只有程序员才会读你的代码。
- 不要添加没用的语境。比如说在一个Item类中，不必将主键设置为ItemId.
函数
- 尽量避免长函数，函数的第一规则是要短小。if语句 else语句 while语句其中的函数应该只有一行。
- "函数应该只做一件事。做好这件事。只做一件事"，判断一个函数是否只做了一件事，就是看是否能再拆出一个函数。
- 要确保函数只做一件事，要确保函数中的语句都要在同意抽象层级上。
- 使用描述性的名称，描述函数做的事。别害怕长名称，长而具有描述性的名称，要比描述性的长注释好。
- 最理想的参数数量是零，其次是一，再次是二， 尽量避免三参数函数，有足够多的理由才能用三个以上参数，如果需要多个参数，就说明其中一些参数应该封装为类了。
- 使用异常替代返回错误码
- 别重复自己。重复可能是软件中一切邪恶的根源，许多原则与实践规则都是为控制和消除重复而创建的。
注释
- 注释的恰当用法是弥补我们在用代码表达意图时的遭遇的失败。
- 注释存在的时间越久，就离其所描述的代码越远，越来越变得全然错误。
- 注释不能美化糟糕的代码。
- 最好用代码而不是注释说明来阐述行为
- 避免循规式注释 例如 要求每个函数都要有javadoc注释，这样的注释只会搞乱代码，有可能误导读者，javadoc注释额外的形式要求等同于八股文章
垂直格式
- 每个空白行都是一条线索，标识出新的独立概念，空白行隔离开了概念，靠近的代码行则暗示了他们之间的紧密联系。
- 变量声明应尽可能的靠近其使用位置。
- 如果某个函数调用了另外一个，就应该把它们放到一起，而且调用者应该尽可能放在被调用者上面。
- 每个每个程序员都有自己喜欢的格式规则，但如果在一个团队中工作，就是团队说了算。
