代码整洁之道

最近读了代码整洁之道这本书，还是挺有感触的。。。

有意义的命名

• 命名的时候应该已经答复了所有的大问题，正确的命名应该让看代码的人知道，为什么存在，做什么事情，应该怎么用。
• 好的命名是不需要注释来进行补充的。 写代码的人应该避免留下掩藏代码本意的错误的信息，不应该使用和本意相违背的词语。
  在同一作用范围内命名的时候要做出有意义的区分，不可进行随意的区分。
• 要使用读得出来的词语进行命名，否则在进行解释命名的时候就会显得异常的愚蠢。
• 要使用可搜索到的词语进行命名，名称的长短应该与其作用域的大小相对应。 不要使用自己的固定思维去进行命名，要进行慎重的选择。
• class 的命名应该是名词或者名词短语，不应该是动词。 方法名应该是动词或者动词短语。 别用你自己所认为的幽默来进行命名，懂得你幽默的人其实并不多。
  同一个团队中要约定好每个概念对应的是哪个词，这样就不会产生歧义，不会造成代码的混乱。
• 命名的时候要避免将同一个单词用于不同的目的，这样的双关语容易造成语义不对，要找到能够区分的词语重新命名。
• 可以使用计算机科学术语、算法名、模式名、数学术语进行命名，只有程序员才会看你的代码，所以他们是能够读懂的。
• 要添加有意义的语境来进行命名，这样比单独的一个单词更有说服力，在某些特定的情境下，合适的前缀可以让读者明白这是结构中的哪一个部分。
• 别害怕重新命名的工作，名称变得更好之后，代码也就向着整洁代码更近一步。

函数

• 函数应该是短小的，函数不应该大到足以容纳嵌套结构，函数的缩进层级不应该多于一层或者两层，这样的函数才是利于阅读和理解的。
• 函数只应该做一件事，把一件事做好，而且只由这个函数来做这一件事。
• 函数中不要混杂不同的抽象层级，不同的抽象层级步骤应该封装在不同的函数里面，每个函数的后面都应该跟着位于下一抽象层级的函数。
• 利用多态来代替 switch 语句。
• 要使用描述性的名称来给函数命名，别害怕长名称，长而具有描述性的名称，要比短而令人费解的名称好。
  函数最理想的状态是没有参数，然后是一和二，应尽量避免超过三个参数，除非有足够特殊的理由。
• 应该避免将参数作为输出，这样会造成阅读上的困惑，还会导致函数的副作用，函数的副作用就是函数会偷偷的做了预料之外的事情。
  函数应该修改某对象的状态或者返回该对象的有关信息，两者都干的时候会导致混乱。
• 使用异常代替返回错误码，错误处理本身就是一件事，而函数只应该做好一件事情，若 try 出现在函数中，它就应该是函数中的第一个单词。
• 不要重复自己的代码。
• 函数中只该有一个 return 语句，循环中不能有 break 和 continue 语句，不能有任何的 goto 语句。
• 一开始写不出最佳的函数很正常，重要的是好的代码需要不断的打磨，分解函数、修改名称、消除重复，第一遍就能写出最佳代码的人大概是不存在的。
• 好的程序员是把系统当做故事来讲的，而不是当做程序来写；当你编写的函数可以干净利落的拼装到一起，形成了一种精确而清晰的语言的时候，它就可以帮助你更好的讲诉你的故事了。

类

• 类应该从一组变量列表开始，如果有公共静态常量，应该先出现，然后是私有静态变量，以及私有实体变量，很少会有公共变量；公共函数应该跟在变量列表的后面，把某个公共函数调用的私有工具函数紧随在改公共函数后面。
• 类应该是短小的，系统应该由许多短小的类而不是少量巨大的类组成，每个小类封装一个权责，只有一个修改的原因，并与少数其他类一起协同达成期望的系统行为。
• 类应该只有少量实体变量，类中的每个方法都应该操作一个或者多个这种变量，方法操作的变量越多，就越黏聚到类上。
• 将大函数拆分为许多小函数，往往也是将类拆分为多个小类的时机，程序会更加的有组织，也会拥有更加透明的结构。
• 整洁的类，可以让修改的代码的人更容易的看懂结构，在修改的时候也不会顾虑太多，某种意义上也是节约了在修改上时间的成本。
  部件之间的解耦代表着系统中的元素互相隔离的很好，隔离也让系统每个元素的理解变得更加容易。