为了提升自己的基础能力以及代码风格，稳扎稳打，计划阅读代码整洁之道这本书。
目录
第一章 整洁代码
说明了本书的重要性，整洁代码的重要性，想要code review少挨骂，那就来读这本书吧。
第二章 有意义的命名
1.做有意义的命名，采用驼峰式的命名。
2.避免误导，比如0和O，l和1，还有在linux等其他系统中的hp等特殊用语。
3.做有意义的区分，不要以结尾的1和2等数字进行区分，不要以类似的英文进行区分，count和countData是没有太大区别的。
4.命名的发音开会的时候读不出来那将会是十分尴尬的，鄙人不才，发生在身上一次，场面一度十分尴尬。
5.使用便于搜索的名称，而不是用很多次出现在单词组成中的名称，比如sum。
6.就算是循环内部，有时候也尽量用有意义的名称，比如高级for循环，少用i，j什么的。
剩下的其它条个人觉得没有什么意思
第三章 函数
1.短小。
2.只做一件事。
3.别害怕长名字，长而具有描述性的名称，要比短而令人费解的名称好。
4.传入标识参数true或false，大声宣布此函数不是做一件事情，一般都可将其分为两个函数。
5.当三个或者三个以上的参数的时候，有必要将多个参数封装在一个对象当中。
6.尽量做到函数无副作用，以后工作中慢慢体会。
7.函数要么做什么事，要么回答什么事情，比如set和is什么要分开。
8.使用异常替代返回错误码。
9.最好把try和catch代码块中主体部分抽离出来，另外形成函数。
10.如果一部分代码重复了很多次，可以考虑使用函数来解决。
第四章 注释
1.注释可能在代码长期维护的过程中逐渐变得不准确，不准确的注释比没有注释糟糕的多，尽量用代码表示意思。
2.注释可以用来描述意图。
3.用来警示的注释有时也是有用的，告诉你做某件事的后果。
4.todo注释可以用来在编程的时候表示自己要求做的事，但是做完之后，要定期清理这些没用的todo。
5.注释不要喃喃自语，要让别人也可以看得懂，但也不要废话练习。
6.循规式的注释，所谓每个函数或者变量都要有注释是愚蠢可笑的，这类废话只会搞乱代码。
7.日志式注释可以有，但不要有太多无用的注释。
8.注释掉的代码一定要在最后进行删除，否则后续的人也会认为它是有用的，不会随意去修改，从而越积越多。
9.假如你一定要写注释，请确保它描述了离它最近的代码。
第五章 格式
1.适当加一些空行，表示不同的代码区域，会看起来更加清晰。联系紧密的代码也要在一起，不要分隔。
2.每一行尽量不要超过120个字符。
3.在赋值运算符左右加空格，函数名后不加空格，函数参数的逗号后加空格等等。
4.不要特意将变量的类型和名字逐个对齐。
5.如果你所在的团队有自己的格式风格的话，建议不要独树一帜。
第六章 对象和数据结构
这一章内容不多，由于翻译的原因感觉不是特别好理解，赞略。
第七章 错误处理
1.使用异常而不是返回错误码。
2.给出异常发生的环境说明。
3.别返回null值，别传递空值，很容易发生NPE空指针异常。
第八章 边界
1.建议我们去使用第三方代码，有时候会变得十分方面，但是在使用我们控制不了的代码的时候，我们就要深入了解它，加倍小心的投资与整合，确保未来修改的成本没有那么大。
第九章 单元测试
1.测试代码和生产代码一样重要，否则，随着时间的推移，生产代码的修改，会使得测试代码无法通过，越来越乱，最后变得无法使用，从而使得生产代码没有了测试的保障，所以，测试代码也要好好写。
2.测试应该可以快速运行。
3.测试应该保证独立性。
4.测试应该可重复，在任何环境下重复通过。
5.测试应该自足验证。
6.测试应该及时编写。
第十章 类
1.短小，单一职责。
2.类应该只有少量实体变量，类的每一个方法都应该操作一个或者多个这种变量，方法操作的变量越多，类就越内聚。
3.保持内聚性就会得到许多短小的类。
4.我们应该对类加以组织，降低修改的风险。（在以后工作中慢慢体会）
第十一章 系统
较难理解，目前暂略。
第十二章 迭进
1.运行所有的测试，不可验证的系统，绝不应部署。
2.递增式的重构代码，添加了几行代码就要停下来思考一下，测试一下，测试消除了对清理代码就会破坏代码的恐惧。
3.不可重复，不要有重复的代码。
4.增加表达性，取好名字，大函数切小函数，大类变成小类，用心。
第十三章 并发编程
1.分离并发相关代码与其它代码。
2.谨记数据封装，严格限制可能被共享的数据。
3.尝试将数据分解到可被独立线程操作的独立子集上。
第十四章 逐步改进
本书的核心部分
这后面好大一段代码，理解它的前后结构较为复杂，也花费时间，真的有人会耐心读完吗。。。。。。。。再积累点经验以后再读吧
第十五章 junit内幕
第十六章 重构serialdate
第十七章 味道与启发
扫一扫
336
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
