代码整洁vs代码肮脏

写出整洁的代码，是每个程序员的追求。《clean code》指出，要想写出好的代码，首先得知道什么是肮脏代码、什么是整洁代码；然后通过大量的刻意练习，才能真正写出整洁的代码。

WTF/min是衡量代码质量的唯一标准，Uncle Bob在书中称糟糕的代码为沼泽（wading），这只突出了我们是糟糕代码的受害者。国内有一个更适合的词汇：屎山，虽然不是很文雅但是更加客观，程序员既是受害者也是加害者。

对于什么是整洁的代码，书中给出了大师们的总结：

Bjarne Stroustrup：优雅且高效；直截了当；减少依赖；只做好一件事
Grady booch：简单直接
Dave thomas：可读，可维护，单元测试
Ron Jeffries：不要重复、单一职责，表达力（Expressiveness）
其中，我最喜欢的是表达力（Expressiveness）这个描述，这个词似乎道出了好代码的真谛：用简单直接的方式描绘出代码的功能，不多也不少。
一、命名的艺术
坦白的说，命名是一件困难的事情，要想出一个恰到好处的命名需要一番功夫，尤其我们的母语还不是编程语言所通用的英语。不过这一切都是值得了，好的命名让你的代码更直观，更有表达力。

好的命名应该有下面的特征：

1.1 名副其实
好的变量名告诉你：是什么东西，为什么存在，该怎么使用

如果需要通过注释来解释变量，那么就先得不那么名副其实了。

1.2 避免误导
不要挂羊头卖狗肉
不要覆盖惯用缩略语
这里不得不吐槽前两天才看到的一份代码，居然使用了 l 作为变量名；而且，user居然是一个list（单复数都没学好！！）

1.3 有意义的区分
代码是写给机器执行，也是给人阅读的，所以概念一定要有区分度。

1.4 使用读的出来的单词
如果名称读不出来，那么讨论的时候就会像个傻鸟

1.5 使用方便搜索的命名
名字长短应与其作用域大小相对应

1.6 避免思维映射
比如在代码中写一个temp，那么读者就得每次看到这个单词的时候翻译成其真正的意义

二、注释
有表达力的代码是无需注释的：The proper use of comments is to compensate for our failure to express ourself in code.

注释的适当作用在于弥补我们用代码表达意图时遇到的失败，这听起来让人沮丧，但事实确实如此。The truth is in the code, 注释只是二手信息，二者的不同步或者不等价是注释的最大问题。

因此，当想要添加注释的时候，可以想想是否可以通过修改命名，或者修改函数（代码）的抽象层级来展示代码的意图。

当然，也不能因噎废食，书中指出了以下一些情况属于好的注释

法务信息
对意图的注释，为什么要这么做
警示
TODO注释
放大看似不合理之物的重要性
其中个人最赞同的是第2点和第5点，做什么很容易通过命名表达，但为什么要这么做则并不直观，特别涉及到专业知识、算法的时候。另外，有些第一感觉“不那么优雅”的代码，也许有其特殊愿意，那么这样的代码就应该加上注释，说明为什么要这样，比如为了提升关键路径的性能，可能会牺牲部分代码的可读性。

最坏的注释就是过时或者错误的注释，这对于代码的维护者（也许就是几个月后的自己）是巨大的伤害，可惜除了code review，并没有简单易行的方法来保证代码与注释的同步。