1.编码原则

1.1.SOLID原则

1.1.1.单一职责原则（Single Respon-sibility Principle）

1.1.1.1.类和方法应当仅具备单一职责。所有组合为单一职责的元素应当组合在一起并进行封装。

1.1.2.开闭原则（Open-Closed Principle）

1.1.2.1.类和方法应当对扩展开放，对修改封闭。

1.1.3.里氏替换原则（Liskov Substitution）

1.1.3.1.若函数接收一个基类的指针，那么该指针应当可以替换为任何从基类派生的类（的指针）而无须事先知晓具体类信息。

1.1.4.接口隔离原则（Interface Segregation Principle）

1.1.4.1.与其设计一个大而全的接口不如拆分为若干小型接口，而类可以选择实现需要的接口中的方法。

1.1.5.依赖倒置原则（Dependency Inversion Principle）

1.1.5.1.高层次的模块不应当依赖低层次的模块。

1.1.5.2.低层次的模块的替换不应当影响高层次模块的使用。

1.1.5.3.不论是高层次的模块还是低层次的模块都应当依赖于抽象。

1.1.5.4.抽象不应当依赖于细节，但是细节应当依赖于抽象。

1.2.YAGNI原则

1.2.1.“你不会需要它”（You Ain't Gonna Need It）

1.2.2.确保类、方法和整体代码行数保持绝对最小水平。

1.3.KISS原则

1.3.1.“保持软件简单易懂”（Keep It Simple，Stupid）

1.3.2.务必要保持代码整洁易读，确保即使是新手程序员也能够理解其含义。

1.4.DRY原则

1.4.1.“避免重复的代码”（Don't Repeat Yourself）

1.4.2.当遇到重复代码时应当尽早将其移除

1.5.奥卡姆剃刀法则

1.5.1.Occam's Razor, Ockham's Razor

1.5.2.“如无必要，勿增实体”，即“简单有效原理”。

1.5.2.1.最简单的方案也最可能是正确的那个方案

1.5.2.2.假设越多，设计方案包含缺陷的可能性就越大

1.5.2.3.项目的构成组件越少，出问题的可能性就越少

2.编码方法

2.1.测试驱动开发（Test-Driven Development，TDD）

2.2.行为驱动开发（Behavioral-Driven Development，BDD）

2.2.1.SpecFlow

2.3.面向方面编程（Aspect-Oriented Programming，AOP）

2.3.1.PostSharp

3.良好代码

3.1.合理的缩进

3.1.1.工具实现

3.2.有意义的注释

3.3.API文档注释

3.3.1.文档越易用，开发人员使用API的意愿就越强

3.4.使用命名空间合理组织代码

3.4.1.使用命名空间合理组织代码

3.5.合理的命名规则

3.5.1.Pascal命名法

3.5.1.1.命名空间、类、接口、枚举和方法

3.5.2.驼峰命名法

3.5.2.1.变量名称、参数名称

3.5.3.在成员变量上必须加上前缀下划线

3.6.一个类执行一种任务

3.7.一个方法做一件事情

3.8.方法的代码少于10行，最好不超过4行

3.8.1.代码格式化、链式函数算1行？

3.9.方法的参数不多于两个

3.9.1.方法最好没有参数

3.9.2.有两个以上的参数时就需要考虑类和方法的职责是不是太多了

3.9.3.方法的确需要两个以上的参数，那么最好将其合并为一个对象参数

3.10.合理使用异常

3.11.代码可读性强

3.12.代码耦合程度低

3.13.高内聚的代码

3.13.1.将公共的功能正确地分组的代码具有高度的内聚性

3.14.对象会被恰当销毁

3.14.1.请务必调用Dispose()方法明确地销毁使用中的资源

3.14.2.将对象（引用）设置为null以使其超出作用范围

3.14.3.using语句

3.15.避免使用Finalize()方法

3.15.1.最好在更加可靠的Dispose()方法中来销毁非托管资源

3.16.合理地进行抽象

3.16.1.当设计只向更高的级别开放，并仅开放必需的内容时，它就处在正确的抽象层次上

3.17.在大型类中使用#region进行区域划分