<<代码整洁之道>> 读书笔记(1-2)-JZTXT

整洁代码

人工智能永远不能完全取代程序员, 因为客户的需求总是模糊的, 程序员不只是写代码, 也会去讨论/设计需求和架构
糟糕的代码会杀死项目, 通常会在项目中后期体现出来, 此时项目的生产力快速下降, 影响正常迭代和问题修复
对一个成熟的项目进行重新设计和编写, 往往会分散人力, 同时新版的项目要想替换老项目也会耗时很久, 可能因为中间的人力变更导致烂尾
程序员要积极的拥抱项目发展中的各种需求变更, 不要总是抱怨太多杂事和需求变更导致开发时间紧迫, 事实上应该和PM沟通, 说明时间的用处和压缩时间的坏处, PM也希望可以给多的时间来产出优秀的代码.
整洁的代码是能让其他读者觉得, 这个代码是编写者用心写的, 几乎没有可以改进的地方, 其他人没有办法让这段代码变得更好了.
在编写代码的时间里, 实际上我们需要一直读之前的代码. 因此, 提高代码可读性是非常重要的.
时刻的记住保持代码的整洁, 从细微处做起.

有意义的命名(变量名/函数名/类名/文件名/文件夹名...)

选一个好名字需要花时间思考, 但是这是绝对值得的, 可以大大提高可读性
名字应该直观的体现出它存在的意义(为什么存在/做了什么事/怎么使用)
任何时候, 如果名字需要添加注释才能明白其意义, 那么就不是有意义的命名
名字要避免误导, 尤其是将变量名缩写(比如 userName->un)
list一般代表列表, 不要给不是列表的变量名添加list
多个命名如果相似度很高也会让人不小心看错
小写字母I和大写字母O很可能会被看错成小写字母i和数字0
命名只以其中的数字做差异区分, 是错误的做法(比如 a1, a2, a3, ...)
相似意思的命名也是错误的(比如 userInfo 和 userData 都是用户数据的意思)
命名中不要出现废话, 给命名加上类型一定要慎重(比如 nameString, name 难道还能不是 string 类型吗?)
命名要保证可读性, 不要违背命名的正常使用(比如 userName 比 nameForUser 更加符合常识)
命名要易于搜索, 方便在修改名字时搜索到(比如 err相比于e, e可能是某个名字的其中一个字母, 在搜索时可能有很多结果, 易混淆)
短命名只适用于短方法中的本地变量, 名称的长短应该与其作用域的大小正相关
对于强类型语言, 不需要在命名中体现出来这个命名的值的类型是什么(强类型语言的phone能代表phoneNumber)
不必给成员的变量添加 m_ 前缀, 应该让命名更有意义
不必给接口命名统一加上前缀 I
减少使用短命名, 不要让读者猜测和适应你的命名规则(比如把 url 命名为 r)
类名和对象名应该是名词或者名词短语, 而不是动词, 同时名词也应该有具体的意义(比如 Info/Data/Set)
方法名应该是动词或者动词短语
命名不要参杂一些搞笑的/耍宝的词
给每一个抽象的概念起一个独有的名字, 并且在命名中体现, 保持每个命名都是独一无二的, 这样才能快速的找到对应的命名(比如每个抽象都有get, 我们很难知道这个get是对应哪个)
不要使用双关语, 即一个命名在多个抽象中代表不同意思, 不要为了整齐而忽视了代码整洁的目的, 提高可读性(比如 add在a抽象是添加的意思, 在b抽象是追加, 那么b应该是append而不是add, 不能因为保持一致强行命名)
读代码的人始终是程序员, 因此命名应该紧贴程序员的涉及领域, 而专有领域的专用词汇, 只有普通命名真的无法定义这个意义, 才考虑使用专用词
如果命名无法准确的自我说明, 就需要添加前缀了, 可以给命名添加对应的语境, 来更好的说明命名的意义(比如 firstName lastName city, 如果都是地址中的某一个部分, 可以统一加上 address 的前缀), 当然更好的方法是将其归为一个类的多个属性, 此时就不需要前缀了(例如将address 变成一个类, firstName lastName city 都是其中的属性, 那么就更加的易懂了)
不要添加无用的语境, 命名如果有大量的统一前缀, 说明代码结构出现了问题