💠

💠 2024-09-06 11:36:43

写出优秀的代码

代码整洁之道

Clean Code Notes

  • 《7 QUESTIONS TO ASK YOURSELF ABOUT YOUR CODE》 – Bozhidar Bozhanov

  1. 代码是正确的吗？

    • 是不是实现了规格说明书中的需求？如果没有的规格说明书，你自己是不是付出了足够的努力来找出软件期待的行为， 并且把它测试了一遍？ — 最好是自动的，至少也得有手工的测试。

  2. 代码是完整的吗？

    • 不管你的需求文档中写没写， 你的代码是不是仔细考虑了边界条件？ 很多边界条件都是技术相关的：连接断开，内存不足，硬盘已满等等。

  3. 代码是安全的吗？

    • 它是不是遵循了安全的最佳实践，是否验证了输入数据，防止了数据注入？ 它是否经过了对已知攻击的安全测试？ 安全当然不仅仅是代码， 但是代码的确可以引入不少安全漏洞。

  4. 代码是可读、可维护的吗？

    • 其他人是不是可以轻松地理解你写的代码？ 有没有适当的注释来描述一小部分代码在一个大场景中的位置？有没有把代码拆分成小的，可以读的单元。

  5. 代码是可以扩展的吗？

    • 代码是否允许添加新的功能而不破坏老的代码？ 是不是参数化的，或者可以配置的？ 有没有使用恰当的设计模式来支持扩展？

  6. 代码是不是高效的？

    • 在高负荷下能否工作正常？ 是否避免了一次性读入大量数据到内存中，是否适当地使用了异步的处理？

  7. 有没有一些让你可以自豪的地方？

    • 你觉得你的代码会让你很自豪，还是说你想把它藏起来不让别人看到？
    • 大部分的代码都是平凡的，不是光芒四射的，但是你的代码是不是展示了一些比较好的实践？你是否愿意把他放到GitHub上去？

其实这些问题不仅仅要在提交代码之前思考，在Code Review的时候也完全可以借鉴。 高质量的软件依赖很多因素，程序员可以说是最重要的一环。我觉得经常问问自己这些问题并且采取行动，你最终会变得与众不同。

代码的坏味道

如果在代码中，存在下面的情况之一者，则说明代码需要清除腐败。

  1. 代码中存在许多大型的类和复杂的函数
  2. 函数的名称很晦涩或者会误导人。如果函数名称没有良好地反应函数的用途，那么会造成惊人的副作用。
  3. 没有任何结构：应该在哪里找某个功能非常不清晰。
  4. 内容重复：有许多相互独立的代码在做着同一件事情。
  5. 高耦合性：复杂的模块相互连接和依赖关系，将意味着某个地方的小小改动就会影响整个代码，甚至会影响看起来不相关的模块。
  6. 当数据流过系统时，它将在各个表示方法之间转化。
  7. API变得模糊不清。由于考虑不周，增加了新功能，曾经整洁的接口现在在范围上变得宽泛。
  8. API在不同代码版本中快速地变换。
  9. 公共API中泄露了部分私有实现，以便可以进行别的快速的修改。
  10. 代码中到处都是权宜之计：治标不治本的修改。它们隐藏了真正的问题。系统的外围尽是这种修改，结果导致缺陷隐藏在系统的核心。
  11. 有些函数的参数太多。这些函数有许多并不使用的参数，而只是将他们传递给下一级函数调用。
  12. 你发现代码太可怕了，以至于你都不想去修改它。你不知道它是会改善的，还是会轻微地破坏它，或是它更糟糕。
  13. 添加新功能时没有提供任何支持文档：现有的文档过时了。
  14. 你发现有的注释说：“不要动这段代码……”

《代码整洁之道》

命名

  • 有意义，短而精悍
  • 类用名词，方法用动词，还要特别注意语境
  • 普通变量：首单词小写，其后使用驼峰法命名
  • 常量：全部大写
  • 命名有意义，简单直接明了就不需要注释了

函数

  • 短小，只做一件事，if while for try catch中只写一句话（调用一个函数），并且减少嵌套
  • 如果非要用 switch 语句就要尽量简化他
  • 函数参数越少越好，最好没有
  • 函数参数最好不要使用输出类型
  • 分隔指令（动作，会改变数据）与查询（只做一件事）
  • 使用异常代替返回特定的错误码
  • 把try catch 抽离封装到函数内
  • 避免重复

注释

  • 注释越少越好，注释往往得不到维护，代码变动了，注释却没有变，这时候的注释就是错误的引导了（坏注释）
  • 注释都是程序猿的自言自语，不要说废话
  • 避免 坏注释，多余的注释

格式

  • 赋值，一般的类、方法的缩进格式我已经了解
  • 注意：函数的参数，最好是这种格式 fun(int a, int b, ){} 逗号后要加空格
    • 一行字符在20-120之间，不过我一般是达到不使用滑动条看代码即可
  • 函数的排布，最好是越底层越在下面的行数上

异常

  • 避免null：避免函数返回值是null以及函数入参是null
  • 尽量避免可控异常（throws）的出现，因为破坏了封装

编写可读代码的艺术