VB.net 2010 视频教程 VB.net 2010 视频教程 python基础视频教程
SQL Server 2008 视频教程 c#入门经典教程 Visual Basic从门到精通视频教程
当前位置:
首页 > temp > C#教程 >
  • 读C#代码整洁之道笔记01_C#的编码标准和原则

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进行区域划分

出处:https://www.cnblogs.com/lying7/p/17232202.html

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进行区域划分


相关教程