Clean Code 读书笔记

最近开始跟着程序员练级攻略重新读书，第一本翻起的就是Clean Code这本书，记得刚毕业的时候草草读过，当时心里想的这些不都是废话么，真正看了写了几年代码后再看，又有一些新的体验，对于有些看似废话的东西也就心有戚戚焉了。

为命名添加有意义的语境
我个人比较推崇Verbose的命名方式，因为单看代码就能理解类或者函数干了什么，所以比如类A的方法B，有时候我会用AB这种命名方式，当类A名字很长而且有很多命名差不多的方法时，这样命名就会产生一些差别非常细微的方法，类似SuperLongNameClassGetFirstSuperImportantValue和SuperLongNameClassGetLastSuperImportantValue。其实真正有区分度的就是First和Last这两个单词，但是之前无意义的前缀导致很难区分这两个方法，即便使用了IDE的自动补全有时也会手抖写错。这种情况以后确实不应该再加上没有意义的前缀A。

函数应该无副作用
曾经踩过这个问题的大坑，我记得我在公司的代码库里见过这样的代码。
当时我还奇怪为什么每次调用总能得到值，后来看到实现简直吐血了。这种get函数就是明显的有副作用的代码，一般人的理解get就是有就返回，没有返回null值，但是上面的函数没有时额外帮你创建了一个并且放到了map里。这种难以估计的副作用会令调用者的debug过程异常痛苦。

public @Nullable AwesomeClass get(Object key) {
    AwesomeClass awesomeClass = map.get(key);
    if (awesomeClass == null) {
      awesomeClass = new AwesomeClass();
      map.put(key, awesomeClass);
    }
    return awesomeClass;
}

注释
我非常非常赞同作者对于注释的看法，注释并不能美化糟糕的代码。我在公司的代码库里见到过很多超长的注释，它详细解释了一些令人一头雾水的操作的来龙去脉，乍一看你可能会觉得作者非常负责任，但注释最大的问题就是很多情况下注释并不会随着代码一直更新。当这种超长的注释解释的代码经过几次移动和更新后，即便作者本人也并不能确定的说明注释所说的情况是不是还是有效的。久而久之，这种超长注释和它所对应的代码就变成了代码库中的magic code，没人能解释也没人敢修改。下次当我发现我需要写很长的注释才能解释一些代码的时候，也许直接重构代码是一个更好的选择。

未完待续