C#编程风格约定

约定着眼于以下这些目标：

• 约定是实际开发人员使用的约定。
• 约定应该尽可能地合理、简洁。
•  约定要简单。

1. 通用风格约定

花括号的使用

• 要使所有花括号单独放在一行，除do...while外

 

• 考虑把只有一条语句的代码块和左右花括号写在同一行中。属性经常使用这种风格

 

• 避免省略花括号，即使编程语言允许这样做。不应该认为花括号是可以省略的。即使对只有一条语句的代码块，仍应该使用花括号。这样可以增强代码的可读性和可维护性。

 A.2 命名约定
总的来说，我们建议遵循《框架设计准则》中的命名规范。但是，在命名内部标识符和私有标识符时，存在一些例外，需要另外一些约定。
√ 要在命名标识符时遵循《框架设计准则》中的命名规范，除非是内部字段和私有字段。

√ 要在命名名字空间、类型及成员时采用PascalCasing大小写风格，除非是内部字段和私有字段。

√ 要用camelCasing大小写风格来命名内部字段和私有字段。

√ 要用camelCasing大小写风格来命名局部变量。

√ 要用camelCasing大小写风格来命名方法的形式参数。

× 不要使用匈牙利命名法（也就是说，不要载变量名中包含变量的类型）。

× 避免给局部变量加前缀。

√ 要使用C#语言中对应的别名，不要使用.NET框架中的类型名。
例如：要使用int而不是Int32，要使用object而不是Object。
A.3  注释
应该用注释来描述代码的用意、大治的算法以及逻辑流程。最好的情况是，代码编写者之外的人能够通过独自阅读注释来理解函数的行为和目的。虽然注释并不存在一个最低标准，而且一些非常短小的函数根本不需要注释，但对大多数函数来说，通过注释来放映程序员的意图和所采用的方法仍然是值得的。

× 不要用注释来描述一些对任何人都显而易见的事。

× 避免使用块注释（/*…*/）。即使注释会有多行，也最好是使用单行注释语法(//…)。

// Implements a variable-size list that uses an array of objects
// to store the elements. A List has a capacity, which is the
// allocated length of the internal array. As elements are added
// to a List, the capacity of the List is automatically increased
// as required by reallocating the internal array.
//
public class List<T>:IList<T>,IList{
  …
}

× 不要把注释放在行尾，除非注释非常短。
  //Avoid
  public class ArrayList{
      private int count; // -1 indicates uninitialized array
}
A.4文件的组织
× 不要在一个源文件中包含一个以上的共用类型，除非有嵌套类，或各类型之间的不同之处仅在于泛型参数的数量。
一个文件中有多个内部类型是允许的。

√ 要用相同的名字来命名源文件及其包含的公用类型。
例如,String类应该在String.cs文件中，而List<T>类则应该在List.cs文件中。

√ 要用相同的层次结构来组织文件目录和名字空间。
例如，应该把System.Collections.Generic.List<T>的源文件放在System/Collections/Generic目录中。

√ 考虑根据下面给出的顺序和组别来对成员进行分组：
所有字段.
所有构造函数.
公有属性及受保护的属性.
方法.
事件.
所有显式实现的借口成员.
内部成员.
私有成员.
所有嵌套类型.

√ 要把不能公开访问的成员和显式实现的接口成员分别放在自己的#region块中。
#region internal members
…
#endregion
#region private members
…
#endregion

√ 考虑在每个组别内根据字母顺序来组织成员。

√ 考虑根据由简单到复杂的顺序来组织重载成员。

√ 要把using指令放在名字空间的声明之外。
   using System;
   namespace System.Collections{
…
}