** 一、良好的代码：**
- 合理的缩进
- 有意义的注释
- API文档注释
- 使用命名空间合理组织代码
- 合理的命名规则
- 一个类执行一种任务
- 一个方法做一件事情
- 方法的代码少于10行，通常小于4行
- 方法的参数不多于两个
- 合理使用异常
- 代码的可读性强
- 代码的耦合度低
- 高内聚的代码
- 对象会被恰当的销毁
- 避免使用Finalize()方法
- 合理的进行抽象
- 在大型类中使用#region进行区域划分
- 封装和隐藏信息
- 面相对象的代码
- 设计模式
** 二、编码的原则：**
1、. SOLID原则：单一职责原则，开闭原则，里氏替换原则，接口隔离原则，依赖倒置原则
2、YANGNI原则：你不会需要它
3、KISS原则：保持软件简单易懂
4、DRY原则：避免重复代码
** 三、编码的方法：**
1、测试驱动开发（TDD）
2、行为驱动开发（BDD）
3、面向方面编程（AOP）
** 四、编码的规则：**
1、模块化
2、KISS原则
3、YANGNI原则
4、DRY原则
5、SOLID原则
6、奥卡姆剃刀法则：如无必要勿增实体。
** 五、组织类的准则：**
1、 遵循Pascal命名方法并按照公司名称，产品名称，技术名称以及分割到各个命名空间的组件的复数名称的顺序进行命名。
2、 将可复用的代码放在独立的程序集中
3、 命名空间和类型避免使用相同的名称
4、 公司名称，产品名称和缩写词汇无需使用复数形式
** 六、为变化而设计：**
1、面向接口编程
2、依赖注入和控制反转
** 七、整洁函数：** ：短小的不含重复代码的函数
1、保持方法短小：10行以内，最佳长度是4行
2、代码的缩进
3、避免重复代码：DRY,WET
4、避免多个参数
5、单一职责
** 八、创建线程池的方法：**
1、使用TPL:Parallel类
2、使用ThreadPool.QueueUserWorkItem()
3、使用异步委托
4、使用BackgroundWorker
** 九、多线程编程领域的建议：**
1、不要使用Thread.Abort()中止其他线程
2、使用Mutex,ManualResetEvent,AutoResetEvent及Monitor类同步多个线程的活动
3、如需要，请使用线程池来管理线程工作
4、如果任何工作线程处于阻塞状态，则可以使用Monitor.PulseAll将当前工作线程状态的更改通知所有线程
5、不要使用this，类型实例以及字符串实例作为锁对象，不要将类型作为锁对象
6、实例锁可能造成死锁，因此使用它请慎重
7、在线程进入监视区域时使用try/finally代码块，并确保在finally代码块中调用Monitor.Exit()令线程退出监视区域
8、对不同的资源使用不同的线程
9、不要为相同的资源分配多个线程
10、由于I/O任务执行时会阻塞，因此I/O任务应当拥有其自身线程。这样其他线程可以继续执行。
11、应当使用专门的线程处理用户输入。
12、对于简单的状态修改可以使用System.Threading.Interlocked类而无须使用Lock语句以改善性能
13、不要对频繁使用的代码使用同步功能，以避免死锁和竞态条件
14、确保静态数据在默认情况下是线程安全的
15、实例数据默认情况下不应当是线程安全的，否则不但影响性能，加剧死锁争用，还有可能发生死锁和竞态。
17、不要使用会更改状态的静态方法。因为可能导致线程相关的BUG.
** 十、编写REST服务时六项约定：**
1、统一接口：接口用于识别资源，并使用表述来操作资源
2、客户端-服务器：通过封装进行信息隐藏
3、无状态：没有会话也没有历史，如果客户端需要会话和历史支持，客户端必须在请求时提供相关信息。
4、可缓存：资源必须声明其缓存性，这样可以快速访问资源
5、分层系统：分层系统约定即每一层仅仅具备一种职责
6、可选的可执行代码：可执行代码是可选的，规定服务器可以通过传输可执行代码临时扩展或者自行定义客户端的功能。
** 十一、应用程序代码坏味道：**
1、布尔盲点：函数使用布尔值导致的信息缺少。
2、组合爆炸：由不同的代码使用不同参数组合来执行同一事情的产物。
3、人为复杂性
4、数据泥团：相同的字段同时出现的不同的类和参数列表时
5、粉饰注释：注释中使用优美的词句掩盖代码的确定
6、重复代码
7、意图不明
8、可变的变量：在不同的操作之间多次更改的变量
9、怪异的解决方案：代码中解决同样问题的方案多种多样。
10、霰弹式修改：一种改动需要在多个类型进行修改。
11、解决方案蔓延：一种职责在不同的方法，类甚至库中均被实现
12、不可控的副作用：在从中由于无法被质量保证过程发现而引起的问题
** 十一、类级别代码坏味道：**
1、过高的圈复杂度：工厂模式代替switch
2、发散式变化：一处更改，必须更改许多不相关的方法
3、向下类型转换：将基类转换为它的一个子类。
4、过度的字面量的使用
5、依恋情结：大量时间在处理类中的代码而非自身的代码
6、狎昵关系：一个类依赖另一个类的实现细节
7、不恰当的暴露：暴漏的累不细节
8、巨大的类：包含的系统中的方方面面，变成一个庞大，笨拙，什么都做的类
9、冗赘类：并不包含什么有效操作的类
10、中间人类：仅仅将功能委托给其他对象
11、孤立变量和常量类：使用一个独立的类来定义系统中不同部分使用的变量和常量
12、基本类型偏执：对某些任务（信用卡，邮政编码等）使用基本数据类型而非使用对象。
13、被拒绝的遗赠：一个类继承自另一个类，但没有使用其所有方法时
14、夸夸其谈未来性：一个类的功能现在不需要，但将来可能用到。
15、命令而非询问：应当将数据和操作数据的方法绑定在一起，不应该请求并操作数据
16、临时字段：不需要在对象的整个生命周期内存在的成员变量。
** 十二、方法级别代码坏味道：**
1、不合群的方法：一个类中和其他方法截然不同的方法
2、过高的圈复杂度
3、人为复杂性
4、无用的代码：现在的方法无人使用
5、过多的返回数据
6、依恋情结：
7、过长或过短的标识符
8、狎昵关系：
9、过长的代码行
10、冗赘方法
11、过长的方法
12、参数过多
13、过度耦合的消息链：迪米特法则
14、中间人方法
15、怪异的解决方案：多个方法使用不同的方式做同一件事情
16、夸夸其他未来性
** 十二、设计模式：**
1、单例设计模式：
2、工厂方法设计模式
3、抽象工厂设计模式
4、原型设计模式
5、建造者设计模式
6、适配器模式
7、桥接模式
8、组合模式
9、装饰器模式
10、外观模式
11、享元模式
12、代理模式
13、职责链模式
14、命令模式
15、解释器模式
16、迭代器模式
17、中介者模式
18、备忘录模式
19、观察者模式
20、状态模式
21、策略模式
22、模版方法
23、访问者模式