- 编码原则
- SOLID原则
- 单一职责原则(Single Respon-sibility Principle)
- 类和方法应当仅具备单一职责。所有组合为单一职责的元素应当组合在一起并进行封装。
- 开闭原则(Open-Closed Principle)
- 类和方法应当对扩展开放,对修改封闭。
- 里氏替换原则(Liskov Substitution)
- 若函数接收一个基类的指针,那么该指针应当可以替换为任何从基类派生的类(的指针)而无须事先知晓具体类信息。
- 接口隔离原则(Interface Segregation Principle)
- 与其设计一个大而全的接口不如拆分为若干小型接口,而类可以选择实现需要的接口中的方法。
- 依赖倒置原则(Dependency Inversion Principle)
- 高层次的模块不应当依赖低层次的模块。
- 低层次的模块的替换不应当影响高层次模块的使用。
- 不论是高层次的模块还是低层次的模块都应当依赖于抽象。
- 抽象不应当依赖于细节,但是细节应当依赖于抽象。
- 单一职责原则(Single Respon-sibility Principle)
- YAGNI原则
- “你不会需要它”(You Ain't Gonna Need It)
- 确保类、方法和整体代码行数保持绝对最小水平。
- KISS原则
- “保持软件简单易懂”(Keep It Simple,Stupid)
- 务必要保持代码整洁易读,确保即使是新手程序员也能够理解其含义。
- DRY原则
- “避免重复的代码”(Don't Repeat Yourself)
- 当遇到重复代码时应当尽早将其移除
- 奥卡姆剃刀法则
- Occam's Razor, Ockham's Razor
- “如无必要,勿增实体”,即“简单有效原理”。
- 最简单的方案也最可能是正确的那个方案
- 假设越多,设计方案包含缺陷的可能性就越大
- 项目的构成组件越少,出问题的可能性就越少
- SOLID原则
- 编码方法
- 测试驱动开发(Test-Driven Development,TDD)
- 行为驱动开发(Behavioral-Driven Development,BDD)
- SpecFlow
- 面向方面编程(Aspect-Oriented Programming,AOP)
- PostSharp
- 良好代码
- 合理的缩进
- 工具实现
- 有意义的注释
- API文档注释
- 文档越易用,开发人员使用API的意愿就越强
- 使用命名空间合理组织代码
- 使用命名空间合理组织代码
- 合理的命名规则
- Pascal命名法
- 命名空间、类、接口、枚举和方法
- 驼峰命名法
- 变量名称、参数名称
- 在成员变量上必须加上前缀下划线
- Pascal命名法
- 一个类执行一种任务
- 一个方法做一件事情
- 方法的代码少于10行,最好不超过4行
- 代码格式化、链式函数算1行?
- 方法的参数不多于两个
- 方法最好没有参数
- 有两个以上的参数时就需要考虑类和方法的职责是不是太多了
- 方法的确需要两个以上的参数,那么最好将其合并为一个对象参数
- 合理使用异常
- 代码可读性强
- 代码耦合程度低
- 高内聚的代码
- 将公共的功能正确地分组的代码具有高度的内聚性
- 对象会被恰当销毁
- 请务必调用Dispose()方法明确地销毁使用中的资源
- 将对象(引用)设置为null以使其超出作用范围
- using语句
- 避免使用Finalize()方法
- 最好在更加可靠的Dispose()方法中来销毁非托管资源
- 合理地进行抽象
- 当设计只向更高的级别开放,并仅开放必需的内容时,它就处在正确的抽象层次上
- 在大型类中使用#region进行区域划分
- 合理的缩进
读C#代码整洁之道笔记01_C#的编码标准和原则
最新推荐文章于 2024-07-08 10:36:41 发布