整洁代码

1 好的规范

• 有意义的命名

  • 变量，函数，参数，类
  • 名符其实
  • 避免误导，最小惊诧
  • 准则，不用看定义就能确当该调用哪个两数或类。
  • 影响代码可读性的 90%

• 函数

  • 短小
  • 只做一件事情
  • 每个函数一个抽象层级
  • 函数参数，最多三个

• 没有整洁代码，何谈面向对象

• 类

  • 短小
  • 单一职责
  • 高内聚
  • 为了修改而组织，一个类只有一个变化原因

• 使用异常代替错误码

• 使用解释性变量

match = re.match(pattern, text)
if match:
	ip_list[match.group(1)] = match.group(2)

# this is better
match = re.match(pattern, text)
if match:
	interface = [match.group(1)]
	ip_address = [match.group(2)]
	ip_list[interface] = ip_address

2 坏的习惯(bad smell)

• 重复代码，霰弹式修改，维护成本增加，bug 增多；根源，拷贝黏贴。

• 过大类的类，和其他类的耦合度必然增加。

• 内聚性差，不相干的功能放到了一起，外部依赖复杂

• 过长的函数

  • 缺点
    • 陷入细节中，无法在不同的抽象层次上审视代码
    • 不利于复用
    • 滚动鼠标
  • 重构，抽取函数(性能，编译器优化)

• 过多的参数，不要超过三个参数。

• 数据泥团

• 纯数据类

• 缺乏封装

  • 基本类型偏执，电话号码，提取区号，合法性检查(固定电话/移动电话/国际电话)，格式化，
  • 直接使用/暴露容器类(字典/列表，map/list)
  • server = {‘name‘：‘build server， tip： 192.168.0.2‘}

• 发散式变化，不同原因引起不同变化/修改。

• 霰弹式修改，一个原因引起多处变化/修改

• 对象之间紧耦合(依恋情节/)，对象职责划分不清(专家模式)

• 太多的条件分支(switch， if/else)

• 预先设计,未来性 vs YAGNI (you aren’t going to need it)

• 魔术字,包括数字和字符

  • 霰弹式修改,#define MARRY_AGE 21
  • 出错后编译期检查不出来, 常量用const, 尽量不用#define
  • 表现力差