Clean Code

Clean Code

命名

  • 使用读的出来的名字.
  • 难看的成员前缀m_: 把类和函数做小些, 消除对成员前缀的需要.
  • 也不推荐使用接口前缀.

写函数

  • 函数第一要择:短小, 越短小, 功能越集中, 越容易取得好名字.
  • 单一行为:一个函数只做一件事, 对于复杂函数进行行为拆解.
  • 单一权责, 开放闭合原则:工厂模式.
  • 函数参数尽可能少, 最好能降至0参:对多参进行封装, 如x, y坐标封装为class Point.
  • 无副作用:有副作用的函数在做自己的功能时却偷偷修改了其他于己无关的数据, 具有破坏性导致古怪的时序耦合及顺序依赖, 令人迷惑.
  • 分隔指令与查询:函数要么做什么事, 要么回答什么事, 两者都做常常会导致混乱.
  • 异常
    • 将丑陋的异常处理代码从主路径代码(try…catch)分离出来, 它搞乱了代码结构, 尝试将其封装为函数.
    • 错误处理就是一件事, 意味着若try在某个函数中存在, 那它就该是函数代码块中的第一个单词, 在catch…finally代码块后面也不该有其他内容.
  • 不要想着一开始就能按规矩写好函数, 初稿冗长粗陋无序没关系, 完成功能, 在来重构分解函数, 修改代码.

设计类

  • 同函数一样, 类也应该尽量短小.
  • 类的名称应当描述其权责:可以拿出25个字母来描述!
  • 单一权责原则:只有一条修改的理由, 鉴别权责是个经验活…
  • 内聚性:类应该只有少量实体变量, 类中的每个方法都应该操纵一个或多个这样的变量, 并且操纵的变量越多, 就越黏聚到类上, 对内聚性低的函数进行拆解!
  • 开闭原则: 对扩展开放, 对修改关闭.
  • 依赖倒置原则: 程序要依赖于抽象接口,不要依赖于具体实现.

写注释

  • 注释的是用来弥补在用代码表达意图时遭遇的失败!
  • 注释会撒谎!程序员不能坚持维护注释, 而代码在变动演化, 时间越久, 注释离其代码功能就越远.
  • 与其花时间编写解释编写的糟糕代码, 不如花时间清洁那堆糟糕代码.
  • 必要的注释:
    • 版权信息:copyright.
    • 警示:线程安全…
    • 特殊意图的解释.
    • 放大某种看起来不合理之处的重要性.
  • 坏注释 = 程序员的喃喃自语, 及时清理那些没用的注释.

注意格式

  • 文件代码行数:一个文件中不宜写过长的代码, 理由与写函数相似.
  • 垂直方向区隔:每个空白行都是一条线索, 表示出新的独立概念, 往下读代码时, 目光总会停留于空白行之后那一行.
  • 垂直方向上靠近:靠近的代码暗示它们之间的紧密关系.
  • 水平方向上的区隔和靠近:空格字符加强分离效果, 如(x*y) + z, 乘号两边不加空格, 因为它具有较高的优先级, 加号两边加空格强调其为运算符.
  • 水平对齐: …, 没用, 但格式相一致的部分对齐也是极好的.