代码整洁之道-阅读笔记
一段时间的项目忙碌之后，对工作和业务都有了一定层次的了解。经过自己的思考与别人的指导，也能够区分出什么样的代码是好代码和垃圾代码，是时候看些理论书籍来巩固下自己的这些理解。当然这样经典的书，读一遍肯定是不够的，期待以后具备更佳的能力和见识的再读此书，能有另一番思考与体会。
导语
个人觉得代码的整洁程度是非常能够体现一个人的做事态度的特征之一。毕竟闻道有先后，初入职场或者初入编程行业的人，没有老司机那么有架构、模块、设计模式之类的经验。而写出干净、简洁、明了的函数和类，就应当成为一开始写代码的人追求的目标。我们写出良好的代码，第一为了自己之后能够方便回溯，第二为了给别人减少麻烦。–下面即开始我的阅读《代码整洁之道》的第一次笔记。
有意义的命名
这一章节比较简单。总结出来就是无论是变量名称、方法名称、类名称、包名称都应该命名的有意义，不要过度追求简短，从而胡乱缩写。如果你的英文不够好，建议必备有道词典。坚决不要用拼音，不要装可爱，每一个单词都应该是有意义的。另外要重视 IDE 的单词提示，不要漏掉或者乱序字母。
函数
函数最紧要追求的就是短小和只做一件事。短小这一点大家都应该了解。往往我们为了让函数复用，传入 Boolean 参数使其具备两种功能，其实这种写法是不建议的，当然也要见机行事。我们一直在强调少用 If-else 多用 Switch。但是 Switch 语句也会造成滥用的情况。即 Switch 语句，前面说了函数最好只做一件事，但是 Switch 语句天生就要做很多事，这不是违背了之前的理论吗？另外 Switch 语句违背了单一职权原则和开发闭合原则。另外书中阐述 Switch 语句可能多次与同一个对象事件关联，从这个角度来说，书中建议将 Switch 语句隐藏到抽象工厂中去。
函数的名称不要怕长，一定要清晰，个人见过项目中的代码这种简单的不得了的函数命名：share()/delete()/download()，说真的这种命名真的无力吐槽了。函数应该无副作用，要非常小心你的函数会不会对一些全局变量造成修改。输出的参数，对全局的影响。函数最完美的参数应该是零参数、其次是一个。如果参数有三个以及三个以上，就要考虑封装参数对象了。使用异常代码错误码。这一点很有用，错误码如果过多会导致多层次的 If-else 语句。异常的话，可以将可能出错的代码都包裹在 Try-Catch 里面，统一返回异常。另外一点就是 Try-Catch 会影响代码的排版，美观性收到很大影响，此时建议将 Try-Catch 中的代码抽离成函数。避免 Try-Catch 搞乱了代码排版和结构。
另外最后两点就是函数不要重复自己和结构化编程。重复不必多说，一个尴尬的局面就是需要修改时，要多处修改。结构化编程，意思是说代码应该只有一个出口和入口。尽量少一些 Break、Return、Continue 等。这一点仁者见仁，持保留意见。
类
将类这一节放在函数下面讲好像更合适。对于类来说，很多要注意的地方跟函数其实差不多。但是还是单独强调下较好。
第一：类应该短小。书中有说：系统应该由许多短小的类而不是少量巨大的类组成。另外一点就是保持内聚，说实话对这一点我的体会还不怎么深刻。在业务代码中，我的理解可能就是能写局部变量就写局部变量(本质上是作用域的概念)，另外一种理解就是模块(函数或者类)应该尽可能的独立完成自己的任务，减少对其他模块的依赖。
另外一点就是设计类时候应该考虑到日后的修改，因为毕竟后面可能会一直持续维护。术语即对扩展开发，对修改关闭。当然，做到这一点很难。
注释
这一节一开始就强调注释不能美化糟糕的代码。另外很多人都说好的代码是不要注释的。不过我觉得注释肯定是要的，不过应该简短清晰。很多地方是要注释 Why 而不是 How 和 What.另外从注释的角度我们回溯一下命名，从这里可见好的命名、可读性强的命名是可以减少不必要的注释的。另外个人觉得最基本的是一个类的开头一点要有注释，起码应该有日期、作者信息，负责一点最好写一下类的作用，否则很坑后面的代码维护者。
不要废话注释、不要让注释搞乱代码的排版结构。不要的大规模的代码，也不要用注释，可以用版本控制，写好 Commit 信息处理好。
格式
格式这一点，个人追求的也是论文类格式。不过书中倡导的是向报纸的排版学习。不要多余空格，代码格式统一化，括号放的位置统一化。这些都是要平常注意的。不过最好团队能够统一。记住常用格式化快捷键。
错误处理
这个章节首先还是强调的是使用异常而不是错误码，特别针对 Java 这类支持异常的语言。另外在代码编写过程中，不要轻易或者坚决不要返回 Null 值，这是坑人的做法。同时，更不要传递 Null 值给其他人。如果你必须要返回 Null 值得话，请用空列表或者空集合替代，注意复用本身已有的即可，不要重新 New 一个。
