一般规则：
避免在构造函数中做大量工作。这通常会限制构建和初始化类的灵活性，通常会导致难以测试。
谨防过度类似的条件。它们可能是缺失或不合适的抽象的标志，或者是改进设计的一般需求。
处理边缘情况。请注意仅考虑最常见的情况。示例包括无数据，无效数据，边界条件，错误和空值（如果适用）。
避免运行不必要的代码 如果工作完成且返回值已准备就绪，则返回。运行额外的代码会浪费时间，并模糊阅读它的意图。
方法
一般来说，方法应该是独立的。避免在调用之前/之后总是需要调用一个“伴随方法”的方法，例如检查前提条件或检索结果/错误。
从外部防范预期的无效呼叫。在预期的情况下，调用方法没有意义，避免调用它 - 而不是实现它来处理无效/无意义的情况。例如，一个小数位数的输入形式验证器不会期望用数字以外的任何东西调用。
避免不恰当的违约。使用默认值的机会包括本地/成员变量，方法参数和配置值。在创建默认值之前，请考虑它是否有用，并根据其隐藏错误或在意外和不知不觉中使用它的可能性进行权衡。
在加载数据时，避免将默认集合设为空。这样做会删除/隐藏加载状态和无数据状态之间的区别，这通常会导致处理不当/丢失。
检查
避免不必要的空检查。技术和业务逻辑域中有一些我们可以相当自信地依赖的东西永远不会为空。为它们添加显式检查可以隐藏问题，并且它们会使代码膨胀。
避免对基础问题进行修补的不适当的空/状态检查（或位于不适当位置的检查）。这些通常是在无效或边缘情况下跳过/分支逻辑的检查，在一个地方完成以避免/隐藏源自其他地方的问题。相反，更愿意解决/修复根本原因问题。还要注意调用者者中的检查，反之亦然。
处理不愉快的路径情况
尽早和大声失败，而不是后来/安静地失败。尽早发现问题，并使其可见，例如通过抛出错误。避免通过跳过某些代码或使用默认值来静默检测并隐藏问题。示例包括初始化检查，有效性检查，方法前提条件和API响应状态检查。函数 >快速失败。
防守代码与严格的期望。编写防御性代码以适应周围问题是一种可用于使应用程序更加健壮的方法 - 解决问题而不是让它们导致失败。然而，一个主要的缺点是它使这些问题变得不那么明显 - 反过来使它们不太可能被注意到并被解决。它还使代码复杂化，可能不必要的“以防万一”处理。对于您应用的特定区域，权衡成本和收益，以帮助确定防御性或严格方法是否最合适。例如，在应用程序与其控制之外的外部交互的系统边界处，防御的情况更可能是引人注目的。