cleancode

命名
  • 使用读的出来的名字
  • 成员前缀m_,把类和函数做小些,消除对成员前缀的需要
  • 接口前缀也不要了
函数,函数月短小,功能越集中,越容易取得好名字
  • 函数第一要择:短小
  • 单一行为:拆解行为
  • 单一权责,开放闭合原则:工厂
  • 函数参数尽可能少,最好能降至0参:对多参进行封装
  • 无副作用:有副作用的函数在做自己的功能时却偷偷修改了其他于己无关的数据,具有破坏性导致古怪的时序耦合及顺序依赖,令人迷惑
  • 分隔指令与查询:函数要么做什么事,要么回答什么事,两者都做常常会导致混乱
  • 异常/返回错误码:返回错误码要求调用者立刻处理错误,异常处理代码能从主路径代码分离出来得到简化
    • 抽离try/catch代码块,它搞乱了代码结构,将其封装为函数
    • 错误处理就是一件事,意味着若try在某个函数中存在,那它就该是函数代码块中的第一个单词,在catch/finally代码块后面也不该有其他内容
  • 不要想着一开始就能按规矩写好函数,初稿冗长粗陋无序没关系,完成功能,在来重构分解函数,修改代码
注释
  • 注释的是用来弥补在用代码表达意图时遭遇的失败!
  • 注释会撒谎!程序员不能坚持维护注释,而代码在变动演化,时间越久,注释离其代码功能就越远
  • 与其花时间编写解释编写的糟糕代码,不如花时间清洁那堆糟糕代码
  • 必要的注释:
    • 版权信息:copyright
    • 特殊意图的解释:为啥要这样做
    • 警示:线程安全…
    • 注释用来放大某种看起来不合理之处的重要性
  • 坏注释 = 程序员的喃喃自语,及时清理那些没用的注释
格式
  • 文件代码行数:…
  • 垂直方向区隔:每个空白行都是一条线索,表示出新的独立概念,往下读代码时,目光总会停留于空白行之后那一行
  • 垂直方向上靠近:靠近的代码暗示它们之间的紧密关系
  • 水平方向上的区隔和靠近:空格字符加强分离效果,(x*y) + z; 乘号两边不加空格,因为它具有较高的优先级,加号两边加空格强调其为运算符
  • 水平对齐…233,没用,但格式相一致的部分对齐也是极好的
类和对象
  • 数据抽象:以最好的方式来呈现某个对象包含的数据,随意get/set实乃不明智之举
  • 过程式代码难以添加新的数据结构,因为必须修改所有函数;面向对象代码难以添加新函数,因为必须修改所有类……
类,设计模式
  • 类应该短小
  • 类的名称应当描述其权责:可以拿出25个字母来描述!
  • 单一权责原则:只有一条修改的理由…,鉴别权责…
  • 内聚性:类应该只有少量实体变量,类中的每个方法都应该操纵一个或多个这样的变量,并且操纵的变量越多,就越黏聚到类上
    • 拆解!
  • 对扩展开放,对修改关闭
  • 依赖倒置原则