←
读书笔记:代码整洁之道
书籍名称：
代码整洁之道
会挑选一些自己感觉用处比较大的章节来看。
序
对于软件而言，百分之八十或更多的工作量集中在我们美其名曰“维护”的事情上，其实就是修修补补。
目录
整洁代码
将需求明确到机器可以执行的细节程度，就是编程要做的事情，而这种规约就是代码。
勒布朗法则：稍后等于永不。
1.3 混乱的代价
项目初期进展迅速 -> 随着时间增加代码难以维护 -> 团队生产力下降 -> 增加新人手 -> 制造更多混乱的代码 -> 小部分人组建新团队重构，大部分人维护现有系统 -> 新老系统竞赛，新系统需要完全实现老系统功能，还要拓展新功能 -> 新团队开发周期很长，成员离职 -> 完成时所谓“新系统”变成难以维护的老系统。
整洁的代码只做好一件事……糟糕的代码想做太多事情，它意图混乱、目的含混。整洁的代码力求集中。每个函数、每个类和每个模块都全神贯注于一件事，完全不受四周细节的干扰和污染。
简单代码，依其重要顺序：
- 能通过所有测试
- 没有重复代码
- 体现系统中的全部设计的理念
- 包含尽量少的实体，比如类、方法、函数等等。
有意义的命名
原文中主要是针对 Java 提出的建议。
前端的相关命名实践我找到这篇博客写的挺不错：
另外我自己按照词性为常用词列了一个表：
函数
函数的第一规则是要短小，第二条规则还是要短小。
If 语句、else 语句、while 语句等等，其中的代码块应该只有一行，该行大抵是一个函数调用语句
函数应该做一件事，做好这件事，只做这一件事。
最理想的参数数量是零，其次是一，再其次是二，应尽量避免三。
面向对象语言中对输出参数的大部分需求已经消失了，因为 this 也有输出函数的意味在内。
函数要么做什么事，要么回答什么事，但二者不可得兼。
总结
这本书和 Java 耦合程度太高了，看不下去去看别的书了，如果有一天我去写后端代码了，我再回来看看。