C#编码标准
当前位置：点晴教程→知识管理交流
→『 技术文档交流 』
命名规范
1.利用Pascal的方式定义类型、方法名和常量 public class SomeClass 2. 对于局部变量和方法的参数使用骆驼命名法{ const int DefaultSize = 100; public SomeMethod() { } } int number; 3. 接口的名称前面加上Ivoid MyMethod(int someNumber) {} interface IMyInterface 4. 在私有成员变量前面加上m_。对于m_后面的变量名使用骆驼命名法{  }public class SomeClass 5. 对自定义的属性类加上后缀Attribute{ private int m_Number; } 6. 对自定义的异常类加上后缀Exception 7. 方法的命名使用动词——对象对。例如ShowDialog() 8. 有返回值的方法的命名中要有对返回值的描述。例如GetObjectState() 9. 使用带有说明性的变量名 a)避免单字符的变量名。例如i或t。使用类似于index或temp这样有意义的名字。 b)对于public或protected类型的变量避免使用匈牙利表示法 c)不要所写单词（例如用num取代number） 10. 总是使用c＃预定义的类型而不是使用在System命名空间中的别名。例如： 使用object而不是Object 使用string 而不是String 使用int而不是Int32 11. 在使用泛型的时候，类型的首字母要大写。当处理.NET中的Type类型的时候，保留Type后缀。  //正确public class LinkList<K,T> {}//避免public class LinkList<KeyType,DataType>{}13. 避免通过全限定方式使用类型名称，使用using关键字。 14. 避免在一个命名空间中使用using关键字 15. 把所有系统框架提供的命名空间组织到一起，把第三方提供的命名空间放到系统命名空间的下面 16. 使用代理推导而不要显示的实例化一个代理 17. 维护严格的代码缩进。不要使用tabs或非标准的缩进，例如一个空格。推荐的缩进市3到4个空格。 18. 在和你的代码缩进处于同一个级别处为该代码添加注释 19. 所有的注释都应该通过拼写检查。注释中的错误拼写意味着开发进度的延缓 20. 所有类成员变量应该被声明在类的顶部，并用一个空行把他们和方法以及属性的声明区分开 21. 在最靠近一个局部变量被使用的地方声明该局部变量 22. 一个文件名应该能够反映它所对应的类名 23. 当使用一个部分类并把该类分布到不同的文件中时，在每一个文件名末尾都加上该文件实现的部分在类整体中扮演的作用。 24. 总是要把“{”放在新的一行。 编码实践 1. 避免在同一个文件中放置多个类 2. 一个文件应该只向在一个命名空间内定义类型。避免在一个文件中使用多个命名空间 3. 避免在一个文件内些多余500行的代码 4. 避免写超过25行代码的方法 5. 避免写超过5个参数的方法。如果要传递多个参数，使用结构 6. 一行不要超过80字符 7. 不要手动去修改任何机器生成的代码 a)如果修改了机器生成的代码，修改你的编码方式来死适应这个编码标准 b)尽可能使用partial classes特性，以提高可维护性 8. 避免对那些直观的内容作注释。代码本身应该能够解释其自身的含义。由可读的变量名和方法名构成的优质代码应该不需要注释。 9. 注释应该只说明操作的一些前提假设、算法的内部信息等内容。 10. 避免对方法进行注释 a)使用充足的外部文档对API进行说明 b)只有对那些其他开发者的提示信息才有必要放到方法级的注释中来 11. 除了0和1，绝对不要对数值进行硬编码，通过声明一个常量来代替该数值 12. 只对那些亘古不变的数值使用const关键字，例如一周的天数 13. 避免对只读（read－only）的变量使用const关键字。 14. 对每一个假设进行断言。平均起来，每5行应有一个断言。 15. 每一行代码都应该以白盒测试的方式进行审读。 16. 只捕捉那些你自己能够显示处理的异常 17. 如果在catch语句块中需要抛出异常，则只抛出该catch所捕捉到的异常（或基于该异常而创建的其他异常），这样可以维护原始错误所在的堆栈位置。 catch(Exception exception) 18. 避免利用返回值作为函数的错误代码{ MessageBox.Show(exception.Message); throw;//或throw exception; } 19. 避免自定义异常类 20. 当自定义异常类的时候 a)让你自定义的异常类从Exception类继承 b)提供自定义的串行化机制 21. 避免在一个程序集中定义多个Main（）方法 22. 只把那些绝对需要的方法定义成public，而其他的方法定义成internal 23. 避免friend assermblies，因为这回增加程序集之间的耦合性 24. 避免让你的代码依赖于运行在某个特定地方的程序集 25. 在application assembly中最小化代码量。使用类库来包含业务逻辑 26. 避免显示指定枚举的值 //正确 27. 避免为枚举指定一个类型public enum Color { Red,Green,Blue } //错误 public enum Color { Red=1,Green=2,Blue=3 } //避免 28. 对于if语句，总使用一对{}把下面的语句块包含起来，哪怕只有一条语句也是如此public enum Color:long { Red,Green,Blue } 29. 避免使用三元条件操作符 30. 避免利用函数返回的Boolean值作为条件语句。把返回值赋给一个局部变量，然后再检测 31. 总是使用以零为基数的数组 32. 总是使用一个for循环显示的初始化一个引用成员的数组 33. 使用属性来替代public或protected类型的成员变量 34. 不要使用继承下来的new操作符，使用override关键字覆写new的实现 35. 在一个非密封（non－sealed）类中，总是把那些public和protected的方法定义为virtual 36. 除非为了和其他语音进行互动，否则绝对不要使用不安全的代码 37. 避免显示类型转换。使用as关键字安全的转换到另一个类型 Dog dog = new GermanShepherd() 38. 在调用一个代理前，总是检查它是否为nullGermanShepherd shepherd = dog as GermanShepherd; if(shepherd != null) { }39. 不要提供public的事件成员变量。改用Event Accessor 40. 总是使用接口 41. 接口和类中方法和属性的比应该在2：1左右 42. 避免只有一个成员的接口 43. 努力保证一个接口有3～5个成员 44. 不要让一个接口中成员的数量超过20，而12则是更为实际的限制。 45. 避免在接口中包含事件 46. 当使用抽象类的时候，提供一个接口 47. 在类继承结构中暴露接口 48. 推荐使用显示接口实现 49. 从来不要假设一个类型支持某个接口。在使用前总是要询问一下。 SomeType obj1;IMyInterface obj2;//Some code to initialize,then:obj2 = obj1 as IMyInterface;if(obj2 != null){ obj2.Method(); }else{ //handle error in expected interface}50.不要硬编码向用户显示的字符串。要使用资源 int number = SomeMethod()switch(number){ case 1: Trace.WriteLine("case 1:"); break; case 2: Trace.WriteLine("case 2:"); break; default: Debug.Assert(false) break;}60. 除了在一个构造函数中调用其他的构造函数之外，不要使用this关键字 该文章在 2017/2/7 18:53:52 编辑过 |
关键字查询
相关文章
正在查询... 
|
400 186 1886
