c#编码规范

　做为软件开发者，咱们能够开发低等级的软件，但不能开发低质量的软件。因此，如何实施质量保证，是咱们关注的主要问题之一，而编码规范则是实施质量保证的第一步。

　　编码规范已经成为一个老生常谈的问题，几乎每一个项目，每家公司都会定义本身的编码规范。但在真正实施时，却在有意或无心地违背编码规范。程序员，不喜欢改变本身的编程习惯。加之，管理者对质量控制不足，致使编码规范每每形同虚设。有些人会认为：遵照编码规范不能给项目带来利益，也不能让客户看到咱们为此付出的努力，其彻底是团队自发的行为，没有必要作硬性的要求。还有些人有更好的理由：编码规范会破坏创造性和程序质量。我认为，编码规范，在软件构件以及项目管理中，甚至是我的成长方面，都发挥着重要的做用，好的编码规范是提升咱们代码质量的最有效的工具之一。

一 编码规范的做用

• 提升可读性 “任何一个傻瓜都能写出计算机能够理解的代码，惟有写出人类容易理解的代码，才是优先的程序员。”编码规范，帮助咱们写出人类容易理解的代码，它为咱们提供了最基本的模板，良好的编码风格，使代码具备必定的描述性，能够经过名字来获取一些须要IDE才能获得的提示，如可访问性、继承基类等。
• 统一全局，促进团队协做 开发软件是一个团队活动，而不是我的的英雄主义。编码规范，要求团队成员遵照这一统一的全局决策，这样成员之间能够轻松地阅读对方的代码，全部成员正以一种清晰而一致的风格进行编码。并且，开发人员也能够集中精力关注他们真正应该关注的问题——自身代码的业务逻辑，与需求的契合度等局部问题。
• 有助于知识传递，加快工做交接 风格的类似性，能让开发人员更迅速，更容易理解一些陌生的代码，更快速地理解别人的代码。由于，他和你的代码风格是同样的，你没有必要对他的一些个性化风格进行揣测。这样的好处是开发人员能够很快的接手项目组其余成员的工做，快速完成工做交接。
• 减小名字增生，下降维护成本 在没有规范的状况下，和容易为同一类型的实例起不一样的名字。对于之后维护这些代码程序员来讲会产生疑惑。
• 强调变量之间的关系，下降缺陷引人的机会 命名能够表示必定的逻辑关系，是开发人员在使用时保持警戒，从而必定程度上减小缺陷被引人的机会。
• 提升程序员的我的能力 不能否认，每一个程序员都应该养成良好的编码习惯，而编码规范无疑是教材之一。从一个程序员的代码自己能看出不少东西。因此，即使是为了自身发展，做为程序员也没有理由抵制这种规则的存在。你可能没有认识到，咱们正默默地得益于编码规范。

二 编码规范不是“物神”

　　在高质量的软件中，你能够看到“架构的概念完整性”与“底层实现”之间的关系。“实现”与“架构”必须是清晰一致的，这种内在的、固有的一致性，须要编码规范来维系。若是没有这种统一的约定，那么咱们作出的东西可能会充斥着各类不一样的风格，显得混乱且难以理解。团队成员之间可能很不理解彼此之间的想法，甚至是相互抨击。各类编码风格上的差别会不断扩大，而代码质量则不断降低。并且，团队成员会花费时间在理解不一样编程风格之间的差别，而没有专一于真正应该解决的问题。这样的时间消耗是难以接受的。因此，在每个高质量代码的背后，必定存在着一份优秀的编码规范。

　　然而，也必须认识到编码规范不是“物神”。编码规范仅仅是一个全局性质的规范，它只不过是一种编程约定，不能解决更深层次的问题。就像一篇格式漂亮但内容糟糕的论文不能被发表同样，你不能仅靠一个规范来摆脱软件做坊。并且，在编码规范中不宜包含那些冗长的开发技巧。我认为，对于代码是最佳实践应该是代码审查所要解决的，应该避免将编码规范写成一部关于重构的教科书。

三 编写编码规范的一些建议

　　如下是我对定义编码规范的一些建议：

• 求同存异 不要妄图改变组织的编码习惯，除非有绝对合理的理由，不然仍是以民主为主，毕竟你没有权利要求全部人都沿用你的编码习惯。
• 定义编码规范越早越好 也早使用编码规范，也早享受其带来的好处。
• 将规范分为强制部分和推荐部分 求同存异的具体实现。将最基本的规范列放在强制部分，全部成员必须遵照；将好的但不重要的习惯列在推荐部分，开发人员能够根据本身习惯选择是否使用。
• 编码规范不要太长 太长的文档没人看，全部人都同样，除了礼品单和工资单没人愿意看长的东西，因此编码规范必须精炼，最好是只有2~3页，让开发人员能够打印出来随时查看。
• 必须是约定俗成的 规范必须是行业中约定俗成的，不要有什么个性化发挥。

四 编码规范参考

　　我本人不太推荐制定过细的编码规范。制定编码规范是为了加强代码的可读性，毕竟代码的结构才是主要关注问题，因此个人编码规范仍是比较简短的。里面只是对可能会破坏编码风格的行为进行约束，而没有细化到“空行”甚至“空格”的级别。　

编码规范

一 命名空间

　　<公司名称>.(<产品名称>|<相关技术>)[.<用途>] [.<子命名空间>]

二 代码风格

• 花括号“{}”不容许省略，即便只有一段代码。
• 不容许省略访问修饰符。
• 类型默认是密封的。
• 不容许公开字段。
• 使用括号“()”来强调运算符优先级。

三 命名规范

（一） 类、结构和接口的命名

• 使用名词或名词短语。
• 使用Pascal方式。
• 在接口名称前加上前缀“I”。
• 考虑在派生类末尾使用基类的名字。
• 若是该类仅仅为了实现某个接口，那么请保持其与接口命名的统一。
• 若是从.NET 框架中存在的类型派生的类型，应该遵循如下规范：

基类	派生类
System.Attribute	要给自定义的特性添加“Attribute”后缀
System.Delegate	要给用于事件处理的委托添加“EventHandler”后缀  要给用于事件处理以外的那些委托添加“Callback”后缀   不要给委托添加“Delegate”后缀
System.EventArgs	要添加“EventArgs”后缀
System.Exception	要添加“Exception”后缀
IDictionary，IDictionary<T,V>	要添加“Dictionary”后缀
IEnumerable，ICollection，IList，  IEnumerable<T>，ICollection<T>，IList<T>	添加“Collection”后缀
System.IO.Stream	添加“Stream”后缀
CodeAccessPermission，IPermission	添加“Permission”后缀

（二） 成员的命名

成员	大小写	规范
方法	Pascal（公开）、Camel（私有）	用动词或动词短语命名
属性	Pascal	用名词、名词短语或形容词来命名   集合属性应该使用复数形式，而不是添加后缀   用“Is”、“Can”、“Has”等表示布尔属性  能够用属性的类型名来命名属性
事件	Pascal	使用动词或动词短语来命名事件  用如今时和过去时来区分前置和后置事件
字段	Camel（私有）	要用名词、名词短语或形容词来命名  不要加任何前缀

（三） 参数的命名

• Camel风格。
• 要使用left和right来命名重载的二元操做符的参数——若是参数没有具体的含义。
• 要使用value来命名重载的一元操做符的参数——若是参数没有具体的含义。
• 不要在参数中使用数字编号。
• 尽可能使用描述性的名字命名泛型类型参数，并在前面使用“T”前缀。

（四） 常量、变量的命名

• 常量——全部单词大写并用“_”分隔。
• 局部变量——Camel风格。

（五） 枚举的命名

• Pascal风格。
• 使用名词的复数形式来命名标记枚举。
• 不要添加“Enum”或“Flag”后缀。
• 不要给枚举类型值的名字加前缀。

（六） 资源的命名

• Pascal风格。
• 仅使用字母、数字和下划线。
• 在命名异常消息的资源时，资源标识符应该是异常类型名加上简短的异常标识符。

（七） 数据库命名

• 表——“模块名_表名”。
• 字段——bool类型用“Is”、“Can”、“Has”等表示；日期类型命名必须包含“Date”；时间类型必须包含“Time”。
• 存储过程——使用“proc_”前缀。
• 视图——使用“view_”前缀。
• 触发器——使用“trig_”前缀。

（八） XML命名

　　节点名称使用Pascal风格，属性名称使用Camel风格。

四 注释

• 对接口和复杂代码块必须进行注释。
• 修改代码时保持注释同步。
• 未完成的功能使用TODO标记。
• 修改他人代码时要先注释对方代码，并写明修改缘由，不容许随便删除他人代码。
• 发布前移除无用注释。

五 异常处理

• 原则上只容许显示抛出InvalidOperationException、ArgumentException、ArgumentNullException和ArgumentOutOfRangeException四种异常类型。
• 在自定义异常时，必须使用VS提供的代码模板来建立自定义异常。

 转自：http://www.cnblogs.com/MeteorSeed/archive/2012/03/21/2404656.html