代码风格

方法命名要见名知意 方法内容不模糊

 

整洁代码

• 优雅和高效

• 分层结构

• 完善错误处理代码

• 可读、像散文一样、令人愉快

• 干净利落的抽象 和 直截了当的控制语句

• 整洁的代码总是看起来像是某位特别在意它的人写的

• 能通过所有测试

• 没有重复代码

• 体现系统中的全部设计理念

• 包括尽量少的实体，比如类、方法、函数等

有意义的命名

• 名副其实 --- 让代码更明确

• 避免误导 --- 避免提供错误的信息

• 做有意义的区分 --- 不要用a1 a2 这种

• 使用读得出来的名称 --- 不要自己造单词，读不出来影响讨论

• 使用可搜索的名称 --- 如 把一个有意义的数字定义成常量，数字不好搜，但是常量的名字就很好搜

• 类名 --- 类名和对象应该是名词或名词短语，不应该是动词

• 方法名 --- 方法名应该是动词或名词短语

• 每个概念对应一个词 --- 不要同时拥有 manager controller 令人困惑

• 别用双关语 --- 用append insert 而不是 add

• 使用解决方案领域名称 --- 尽管用CS术语 取个技术性的名称

• 添加有意义的语境，不要添加没用的语境

函数（也叫 方法 提高程序的复用性 和 可读性）

• 函数的第一规则是要短小，提第二条规则还是更短小

• 函数应该只做一件事，并做好这件事。----如何判断做了多少事？（如果函数只是做了该函数名下统一抽象层上的步骤，则函数还是只做了一件事。 方法2 看是否还能拆出一个函数）

• 每个函数一个抽象层级 --- 让代码拥有自上而下的阅读顺序

• switch 语句缺点 （天生要做N件事，通常代码很多，难于维护，违反SRP 和 OCP（对于扩展开放 对于修改封闭）） 使用多态

• 使用描述性的名称 --- 名字要较好的描述函数所在做的事情 函数越小，功能越集中，就越便于取个好名字；不要害怕长名称。长而具有描述性的名字要比短而令人费解的名称号，比长注释好

• 函数参数 --- 最理想的参数数量是零，其次是1，在此是2，尽量避免3；向函数传入布尔值是骇人听闻的做法，使函数签名变得复杂，大声宣布本函数不止做一件事。；如果函数需要多个参数，可能可以考虑将参数封装成对象了

• 分隔指令与询问 --- 函数要么做什么事，要么回答什么事，两者不可兼得；函数应该修改某个对象的状态，或是返回该对象的有关信息。两样都干会导致混乱。

• 使用异常替代返回错误码 --- 可以将错误处理的代码从主路径分离

• 抽离try/catch 代码块 --- try/catch 丑陋不堪，扰乱了代码结构，把错误处理与正常流程混为一谈，最好抽离成单独的函数。；错误处理就是一件事 --- 处理错误的函数不该做其他事