Skip to content

Latest commit

 

History

History
112 lines (87 loc) · 5.6 KB

代码整洁之道.md

File metadata and controls

112 lines (87 loc) · 5.6 KB

  1. 关于注释有哪五条规则？ C1. 不恰当的信息 C2. 废弃的注释 C3. 冗余注释 C4. 糟糕的注释 C5. 注释掉的代码

  2. 什么是注释的不恰当的信息？ 比如源代码控制信息，问题追踪等信息，这些应该在提交时标注为提交信息。比如作者、最后修改时间、Jira Ticket 信息等。

  3. 有哪些糟糕的注释？ 使用正常的标注，要更认真地对待注释。

  4. 关于函数有哪四条规则？ F1. 过多的参数 F2. 输出参数 F3. 标识参数 F4. 死函数

  5. 什么是标识参数？ 是指的用来控制函数流程的单独参数，按照作者的说法，这种参数应该用两个不同的参数函数来控制参数

  6. 什么是输出参数？ 是指的用来接收返回值的参数，比如说某个 list，来接收错误的返回信 息。

  7. G2，明显的行为未被实现是指的什么？要怎么注意？ 即函数或类应该实现其他程序员有理由期待的行为。比如 DayDate.StringToDay() 就应该忽略大小写，缩写形式等等都能被处理。

  8. 有哪些难以理解的规则？ G3：不正确的边界行为 G6: 在错误的抽象层级上的代码。 —— 怎么样来判定一段代码的抽象层级，怎么划分抽象层级？ G14： 特性依恋。—— 似乎好理解，但是实际操作里似乎很复杂？有的时候需要多个类来组合一起完成功能？就例子里举出的 caculator 来说，如果将 Employee 看做是一个 POJO 类，那用一个辅助的计算类来进行辅助计算不也是很正当的事情吗？ G26: 准确，这里的要求感觉有点太抽象了，具体实践意义不明，是指的是要有逻辑清晰的因果关系吗？还是说逻辑应该要完整呢？ G27: 结构甚于约定。这里指的是什么啊，举的例子也难以看懂。

  9. 一般性原则中比较重要的几条： G2. 明显的行为未被处理 G5. 重复，DRY 法则 G7. 基类依赖于派生类 G8. 信息过多 G11. 前后不一致 G12. 混淆视听 G15. 算子函数 G16. 晦涩的意图 G18. 不恰当的静态方法 G21. 理解算法 G23. 用多态代替 if/switch G28. 封装条件 G29. 避免否定性条件 G31. 遮蔽时序耦合 G32. 别随意 G36. 避免传递浏览 G30. 函数只该做一件事

  10. 怎么消除重复？ a. 每次看到重复代码，都代表遗漏了抽象。重复的代码可能成为子程序或干脆是另一个类。 b. 较隐蔽的形态是在不同模块中不断重复出现，检测同一组条件的 switch/case 或 if/else 链，可以用多态来代替。 c. 更隐蔽的形态是采用类似算法但具体代码行不同的模块，可以使用模板方法或策略模式来修正。

  11. G7，基类依赖于派生类是指的什么 即基类不应对任何派生类有依赖。基类也应该依赖于基类——如果有需要的话

  12. G8，信息过多要求怎么做？ 设计良好的模块有着非常小的接口，让你能事半功倍。 设计良好的接口并不提供许多需要依靠的函数，所以耦合度也比较低。 隐藏你的数据，隐藏你的工具函数，隐藏你的常量和你的临时变量。 不要为子类创建大量受保护变量和函数

  13. G11，前后不一致的要求是什么？ 即保持代码的一致性，比如前后代码的风格，代码的名字和实际的功能。

  14. G12，混淆视听的要求是什么？ 移除无用的代码，保持代码的整洁

  15. G15, 算子函数的要求是什么？ 不能用 true 和 false 来做为函数参数控制函数的走向，而应该创建不同的函数来实现

  16. G16，晦涩的意图是什么？ 代码要尽可能具有表达力。不应该追求形式上的短小精悍。

  17. G16, 晦涩的意图的要求什么？ 不能使用联排表达式、匈牙利标记法和魔术数。

  18. G18，不恰当的静态方法要求什么？ 通常应该倾向于选用非静态方法。 如果有疑问，就是用非静态函数。 如果的确需要静态函数，确保没机会打算让它有多态行为。

  19. G21， 什么是理解算法？ 在你认为自己完成某个函数之前，确认自己理解了它是怎么工作的。通过全部测试还不够好。你必须知道解决方案是正确的。

  20. G23： 用多态替代 IF/ELSE 或 Switch/Case 即在 switch 的 case 下，用多态来进行逻辑的转化会更好。因为类是可以扩展的，也可将函数抽取出来扩展。

  21. 什么是魔术数？ 它不仅仅指数字，它泛指任何不能自我描述的符号。

  22. G28: 封装条件。 即把一个 if 语句中的判断条件用函数抽离出来，这样可以增加代码的可读性。展示代码的意图。

  23. G29, 避免否定性条件是指的什么？ 条件应避免加! 来加一层否定，宁愿在抽取函数里加否定，这样可读性更好。

  24. G31，掩蔽时序耦合。 当函数中存在时序性耦合时，不要掩盖它，具体的做法是使上一个操作的结果成为下一个操作的参数。—— 这在一定程度上会增加函数的参数，所以也要进行权衡的。

  25. G32，别随意 构建代码结构时，也应该要有充足的理由，而不是随心所欲

  26. G36，避免传递浏览 即应该确保模块只了解其直接写作者，不应该中间结果的协作者。 例如 a.getB().getC() 这样就是不对的。应该要在 getB() 时即可得到想要的结果。