您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iProcess 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
     
   
 订阅
  捐助
C#项目代码规范
 
144 次浏览     评价:  
 2019-8-22
 
编辑推荐:
本文来自于tencent, 本文主要是作者总结C#代码规范中的要注意的21点,希望对您能有所帮助。

前言

小菜就是小菜,几个人搞出来的项目,让公司大牛稍微看了下,最后送出了惨不忍睹四个字。命名各种各样,五花八门,大写英文、小写英文、大写拼音、小写拼音、英文和拼音组合、字母和特殊字符(下划线等)组合。这样的项目代码要是让人来维护或者添加功能、查找bug会头痛欲裂。也没办法谁叫咱们是小菜呢?而且程序员最头疼的事,最终的结果居然是命名。所以……

于是结合现有项目,通过查看各种博客文章,进行了一下总结。当然这样做肯定是有不少好处的。

1.方便代码的交流和维护。

2.不影响编码的效率,不与大众习惯冲突。

3.使代码更美观、阅读更方便。

4.使代码的逻辑更清晰、更易于理解。

在C#中通常使用的两种编码方式如下

Camel(驼峰式): 大小写形式-除了第一个单词,所有单词第一个字母大写,其他字母小写。

Pascal(帕斯卡): 大小写形式-所有单词第一个字母大写,其他字母小写。

本文的C#代码规范主要参考的是大神的规范,当然还有其他的,在此就不一一进行列举了。

C#代码规范

1、 类型(类、结构、委托、接口)、字段、属性、方法、事件的命名

优先考虑使用英文(尽量使用英文),如果实在没有合适的英文进行描述,可以使用拼音,使用中文是不符合要求的。

2、不使用缩写

所有类型、字段、属性、方法、事件尽量不使用缩写,包括大家熟知的缩写,例如msg。

3、不使用单个字母的变量

不使用单个字母的变量, 像 i、m、n,使用index等来替换,用于循环迭代的变量除外。

4、用Tab作为缩进,并设置缩进大小为4

5、 注释

类型、属性、事件、方法、方法参数,根据需要添加注释。

如果类型、属性、事件、方法、方法参数的名称已经是自解释了,不需要加注释;

否则需要添加注释。

6、类型名称和源文件名称一致

当类型命名为Product时,其源文件命名只能是Product.cs。

7、所有命名空间、类型名称使用Pascal风格

8、本地变量、方法参数名使用Camel风格(不使用下划线)

红色标记的为使用Camel风格的变量或者方法参数

9、在一个类中,各个方法需用一空行(最好是一个空行)

10、避免使用大文件。如果一个文件里的代码超过300-400行,必须考虑将代码分开到不同的类中。同时避免写太长的方法,如果一个方法代码过长(暂时没有明确指出方法的行数),应该考虑将其分解为不同的方法

11、一个方法只完成一个任务。不要把多个任务组合到一个方法中,即使那些任务非常小

12、调用类型成员内部其他成员,需加this,调用父类成员需加base

13、不在代码中使用具体的路径和驱动器名。 使用相对路径,并使路径可复用

14、不要“捕捉了异常却什么也不做“。如果隐藏了一个异常,你将永远不知道异常到底发生了没有

15、如果if语句块的内容只有一行,可以不加花括号,并且最好和if语句位于同一行

16、类型内部的私有字段和受保护字段,使用Camel风格命名,但加“_”前缀

17、类型成员的排列顺序

类型成员的排列顺序自上而下依次为:

字段:私有字段、受保护字段

属性:私有属性、受保护属性、公有属性

事件:私有事件、受保护事件、公有事件

构造函数:参数数量最多的构造函数,参数数量中等的构造函数,参数数量最少的构造函数

方法:重载方法的排列顺序与构造函数相同,从参数数量最多往下至参数最少

18、委托和事件的命名

委托以EventHandler作为后缀命名,例如 SalesOutEventHandler。

事件以其对应的委托类型,去掉EventHandler后缀,并加上On前缀构成。

示例代码如下:

19、返回bool类型的方法、属性的命名

如果方法返回的类型是bool类型,则其前缀为Is,例如:IsHidden。

如果某个属性的类型为bool类型,则其前缀为Can,例如:CanHidden。

20、常见集合后缀类型命名

凡符合下表所列的集合类型,应添加相应的后缀。

21、常见字段、属性命名

字段、属性种类比较繁杂,因此仅列出最常用的几项

总结

本文的规范,将会在接下来的新项目中进行参考使用,使用过程中遇到的问题或者意见,将会反馈到本文,也恭请各位客官前来参阅,共同优化。

   
144 次浏览  评价: 差  订阅 捐助
相关文章

深度解析:清理烂代码
如何编写出拥抱变化的代码
重构-使代码更简洁优美
团队项目开发"编码规范"系列文章
相关文档

重构-改善既有代码的设计
软件重构v2
代码整洁之道
高质量编程规范
相关课程

基于HTML5客户端、Web端的应用开发
HTML 5+CSS 开发
嵌入式C高质量编程
C++高级编程
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号