把系统当作故事来写

有意义的命名

  1. 尽量避免误导，即使用类似命名表达完全不一样的意思。避免双关语，即同一个名称表达两种意思。
  2. 不需要使用a，the等前缀，使用单复数区分即可，对应数据结构使用数据结构后缀，比如List->UserList
  3. 常量优于魔法值
  4. 添加有意义的语境，通过语境帮助解释功能作用；不要添加没用的语境，短名称足够清楚就可以了。

函数

  1. 函数内容尽可能短，一个函数完成一个功能
  2. 函数名尽可能描述清楚所完成的功能
  3. 函数入参越少越好
  4. 不要使用标记参数，比如向函数中传入布尔值，Assert()
  5. 【动词+名词】(名词)比【动词】(名称)更好理解
  6. 函数不要做多余的事情，避免产生副作用
  7. 函数要么做什么事，要么回答什么事，但二者不可兼得
  8. 编写函数初稿可以粗陋无序，冗长而复杂。可以通过分解函数，修改名称，消除重复，重新组装函数进行优化，并配合单元测试，确保程序的正确性。
  9. 永不被调用的方法应该丢弃。别害怕删除函数。

注释

  1. 对比注释，用代码来阐述系统才是更正确的事，因为程序员总是在维护代码，却不会同步维护注释。一些老的、坏的注释反而会误导程序员。
  2. TODO注释是一种程序员认为要做，但是目前因为某些原因还没有做到的事情，但他们不是系统中留下糟糕的代码的借口。需要定期查看并清理TODO注释。
  3. 注释可以放大某些看起来不合理代码的重要性
  4. 公共api中的javadoc十分重要，但是他们也可能会提供错误信息，误导程序员。代码更新时，同步更新javadoc十分重要。
  5. 在当前VCS(版本控制系统)中，注释归属和署名的注释是没有必要的，因为VCS会记住所有改动。
  6. 直接把代码注释掉是很糟糕的做法，仔细思考被注释的代码，为什么要注释掉？他们重要吗？是为了给未来的修改做提示吗？或者只是某人多年以前懒得清理的过时代码？如果代码可以被注释掉，那么他就可以被删除掉，在VCS中，他们丢不了。
  7. 不要使用HTML注释，如果注释将由工具（比如javaDoc）抽取出来，呈现到网页上，那么应该有该工具而不是程序员负责加上合适的HTML标签。

尽可能避免使用注释，好的注释应该可以帮助其他人更好地理解系统，提高其他人读系统的时间，而不是花费更多的时间。糟糕的注释示例

格式

  1. 完整逻辑之间的空白行可以提高可读性。
  2. 关系紧密的代码应该在垂直距离上靠近
  3. 按照函数的前后调用逻辑自上向下编写函数
  4. 水平方向上的代码紧密代码逻辑关联性强，而空格代表互相隔离的逻辑
  5. 团队规则：遵循团队规则，绝对不要用各种不同的风格来编写源代码

对象与数据结构

  1. 得墨忒耳律：模块不应了解他所操作对象得内部情形。类C的方法f只应该调用一下对象的方法：C；由f创造的对象；作为参数传递给f的对象；由C的实体变量持有的对象。
  2. 小结：对象暴露行为，隐藏数据。数据结构暴露数据，没有明显的行为。

异常处理

  1. 使用异常而不是返回码
  2. 在大型系统的调用层级中，最底层函数添加throws时，所有上层函数都需要添加控制异常。不推荐！
  3. 不返回null，避免参数传入null

边界

Map有着广阔的接口和丰富的功能，十分灵活，但是这种灵活也是要付出代价的，过多的暴露细节，可以考虑对Map接口进行隐藏，比如

class Sensors{
	private Map sensors = new HashMap();
    public Sensor getById(String id){
    	returen (Sensor)sensors.get(id);
    }
}

使用adapter模式转换接口，也可以清晰的确定边界