IDesign C#命名规范（翻译2.32）

1. Naming Conventions and Style 命名规范和代码风格

1. Use Pascal casing for type and method names and constants: 类型、方法和常量命名用Pascal风格，即首字母大写

public class SomeClass

{

const int DefaultSize = 100;

public void SomeMethod()

{ }

}

2. Use camel casing for local variable names and method arguments.局部变量和方法参数使用Camel风格。即首字母小写，后出现的单词首字母大写。

void MyMethod(int someNumber)

{

int number;

}

3. Prefix interface names with I 接口使用I前缀

interface IMyInterface

{...}

4. Prefix private member variables with m_. Use Pascal casing for the rest of a member

variable name following the m_.

私有变量使用m_前缀，其后单词用Pascal风格。

public class SomeClass

{

private int m_Number;

}

5. Suffix custom attribute classes with Attribute.自定义的属性类名使用Attribute后缀

6. Suffix custom exception classes with Exception.自定义的异常类名使用Exception后缀

7. Name methods using verb-object pair, such as ShowDialog().方法命名采用动宾式。如ShowDialog()。

8. Methods with return values should have a name describing the value returned, such

as GetObjectState().对于有返回值的方法，应该使用描述方法返回值的方法名，如GetObjectState()。

9. Use descriptive variable names. 使用有意义的变量名。

a) Avoid single character variable names, such as i or t. Use index or temp instead.

不要使用单个字符的变量名，如i或t。应使用index或temp

b) Avoid using Hungarian notation for public or protected members. 公共和保护的成员不要使用匈牙利命名法，即不要加数据类型前缀，如strName。

c) Do not abbreviate words (such as num instead of number). 不要缩写单词，比如number缩写成num

10. Always use C# predefined types rather than the aliases in the System namespace.

总是使用C#预定义的类型，而不是System命名空间中的别名。如：

用 object 不用Object

用string 不用String

用int 不用Int32

11. With generics, use capital letters for types. Reserve suffixing Type when dealing

with the .NET type Type. 当使用泛型时，使用大写字母作为类型。不要加Type后缀

//正确:

public class LinkedList

{...}

//避免:

public class LinkedList

{...}

12. Use meaningful namespaces such as the product name or the company name. 使用有意义的命名空间，比如产品名或公司名

13. Avoid fully qualified type names. Use the using statement instead. 不要直接使用带命名空间的完整类型名称。使用using语句引用。

14. Avoid putting a using statement inside a namespace. 不要将using语句放到命名空间里面

15. Group all framework namespaces together and put custom or third-party namespaces underneath. 将引用的framework的命名空间组合排放，自定义的和第三方的命名空间放到最下面

16. Use delegate inference instead of explicit delegate instantiation使用委托定义而不是直接的委托实例。

delegate void SomeDelegate();

public void SomeMethod()

{...}

SomeDelegate someDelegate = SomeMethod;

17. Maintain strict indentation. Do not use tabs or nonstandard indentation, such as one space. Recommended values are three or four spaces, and the value should be uniform across. 严格使用缩进。不要使用tabs或非标准缩进，如单个空格。推荐使用3个或4个空格，这个值应该统一。

18. Indent comments at the same level of indentation as the code you are documenting. 注释与代码缩进相等。

19. All comments should pass spell checking. Misspelled comments indicate sloppy development. 所有的注释应该通过拼写检查。错误的拼写意味着垃圾的开发。

20. All member variables should be declared at the top, with one line separating them from the properties or methods. 所有的成员变量应该在顶部定义，与属性和方法使用一个空行隔开。

public class MyClass

{

int m_Number;

string m_Name;

public void SomeMethod1()

{ }

public void SomeMethod2()

{ }

}

21. Declare a local variable as close as possible to its first use. 局部变量的定义尽量靠近第一次被使用的地方。

22. A file name should reflect the class it contains. 文件名应该体现它包含的类(即类名与文件名统一)。

23. When using partial types and allocating a part per file, name each file after the logical part that part plays. For example: 当使用partial类时，包含每个部分的文件名应包含这个部分的逻辑含义。

//In MyClass.cs

public partial class MyClass

{...}

//In MyClass.Designer.cs

public partial class MyClass

{...}

24. Always place an open curly brace ({) in a new line. 总是将大括号({)放到新的一行里。

25. With anonymous methods, mimic the code layout of a regular method, aligned with the delegate declaration. (complies with placing an open curly brace in a new line): 使用匿名方法时，代码风格应该和普通方法一样，与委托声明对齐。（大括号应该放到新的一行里）：

delegate void SomeDelegate(string someString);

//正确:

void InvokeMethod()

{

SomeDelegate someDelegate = delegate(string name)

{

MessageBox.Show(name);

};

someDelegate("Juval");

}

//避免

void InvokeMethod()

{

SomeDelegate someDelegate = delegate(string name){MessageBox.Show(name);};

someDelegate("Juval");

}

26. Use empty parentheses on parameter-less anonymous methods. Omit the parentheses only if the anonymous method could have been used on any delegate: 没有参数的匿名方法加上空的圆括号。除非这个匿名方法可能被用到任何类型的委托上。

delegate void SomeDelegate();

//正确

SomeDelegate someDelegate1 = delegate()

{

MessageBox.Show("Hello");

};

//避免

SomeDelegate someDelegate1 = delegate

{

MessageBox.Show("Hello");

};

27. With Lambda expressions, mimic the code layout of a regular method, aligned with the delegate declaration. Omit the variable type and rely on type inference, yet use parentheses: 使用Lambda表达式时，代码风格应该和普通方法一样，与委托声明对齐。省略变量类型，使用圆括号：

delegate void SomeDelegate(string someString);

SomeDelegate someDelegate = (name)=>

{

Trace.WriteLine(name);

MessageBox.Show(name);

};

28. Only use in-line Lambda expressions when they contain a single simple statement. Avoid multiple statements that require a curly brace or a return statement with inline expressions. Omit parentheses: 仅当Lambda表达式只包含一行简单语句的时候使用内嵌的风格。当包含多个语句和return语句的时候，不要使用内嵌的风格。省略圆括号：

delegate void SomeDelegate(string someString);

void MyMethod(SomeDelegate someDelegate)

{...}

//Correct:

MyMethod(name=>MessageBox.Show(name));

//Avoid

MyMethod((name)=>{Trace.WriteLine(name);MessageBox.Show(name);});

2. Coding Practices 编码实践

1. Avoid putting multiple classes in a single file. 不要将多个类放到一个文件中。

2. A single file should contribute types to only a single namespace. Avoid having multiple namespaces in the same file. 一个文件中应该只包含一个命名空间，不要同一文件包含多个命名空间。

3. Avoid files with more than 500 lines (excluding machine-generated code). 避免文件大小超过500行，除非是机器生成的代码。

4. Avoid methods with more than 200 lines. 避免方法超过200行。

5. Avoid methods with more than 5 arguments. Use structures for passing multiple arguments. 避免方法有超过5个参数，否者使用结构来传递多个参数。

6. Lines should not exceed 120 characters. 每行应该不超过120个字符。

7. Do not manually edit any machine-generated code. 不要手工修改机器生成的代码。

a) If modifying machine generated code, modify the format and style to match this coding standard. 如果修改机器生成的代码，那代码风格应该遵从代码规范。

b) Use partial classes whenever possible to factor out the maintained portions. 尽量使用 partial 类来维护修改的代码。

8. Avoid comments that explain the obvious. Code should be self-explanatory. Good code with readable variable and method names should not require comments. 不要对显而易见的逻辑增加注释。代码应该是自解释的。好的代码使用好的变量名和方法名而不需要注释。

9. Document only operational assumptions, algorithm insights and so on. 仅对算法、假设等进行文档化。

10. Avoid method-level documentation. 避免方法级的文档。

a) Use extensive external documentation for API documentation. 对API文档使用外部文件。

b) Use method-level comments only as tool tips for other developers. 方法级上的注释只用作给其他开发人员的提示。

11. With the exception of zero and one, never hard-code a numeri