C#代码规范
命名惯例和规范
注记 :
Pascal 大小写形式－所有单词第一个字母大写，其他字母小写。
Camel 大小写形式－除了第一个单词，所有单词第一个字母大写，其他字母小写。
· 类名使用Pascal 大小写形式
public class HelloWorld{ ...}
· 方法使用Pascal 大小写形式
public class HelloWorld{ void SayHello(string name) { ... }}
· 变量和方法参数使用Camel 大小写形式
public class HelloWorld{ int totalCount = 0; void SayHello(string name) { string fullMessage = "Hello " + name; ... }}
· 不要使用匈牙利方法来命名变量
以前，多数程序员喜欢它－把数据类型作为变量名的前缀而m_作为成员变量的前缀。例如：
string m_sName;int nAge;
然而，这种方式在.NET编码规范中是不推荐的。所有变量都用camel 大小写形式，而不是用数据类型和m_来作前缀。
· 用有意义的，描述性的词语来命名变量
- 别用缩写。用name, address, salary等代替 nam, addr, sal
- 别使用单个字母的变量象i, n, x 等. 使用 index, temp等
用于循环迭代的变量例外：
for ( int i = 0; i < count; i++ ){ ...}
如果变量只用于迭代计数，没有在循环的其他地方出现，许多人还是喜欢用单个字母的变量(i) ，而不是另外取名。
- 变量名中不使用下划线 (_) 。
- 命名空间需按照标准的模式命名
...
· 文件名要和类名匹配
例如，对于类HelloWorld, 相应的文件名应为 helloworld.cs (或, helloworld.vb)
缩进和间隔
· 缩进用 TAB . 不用 SPACES.。
· 注释需和代码对齐.。
· 花括弧 ( {} ) 需和括号外的代码对齐.。
· 用一个空行来分开代码的逻辑分组。.
bool SayHello (string name) { string fullMessage = "Hello " + name; DateTime currentTime = DateTime.Now; string message = fullMessage + ", the time is : " + currentTime.ToShortTimeString(); MessageBox.Show ( message ); if ( ... ) { // Do something // ... return false; } return true; }
这段代码看起来比上面的好：:
bool SayHello ( string name ) { string fullMessage = "Hello " + name; DateTime currentTime = DateTime.Now;
string message = fullMessage + ", the time is : " + currentTime.ToShortTimeString();
MessageBox.Show ( message );
if ( ... ) { // Do something // ...
return false; }
return true; }
· 在一个类中，各个方法需用一空行，也只能是一行分开。
· 花括弧需独立一行，而不象if, for 等可以跟括号在同一行。.
好：
if ( ... ) { // Do something }
不好：
if ( ... ) { // Do something }
· 在每个运算符和括号的前后都空一格。.
好：
if ( showResult == true ) { for ( int i = 0; i < 10; i++ ) { // } }
不好：
if(showResult==true) { for(int i= 0;i<10;i++) { // } }
良好的编程习惯
遵从以下良好的习惯以写出好程序
· 避免使用大文件。如果一个文件里的代码超过300～400行，必须考虑将代码分开到不同类中。
· 避免写太长的方法。一个典型的方法代码在1～25行之间。如果一个方法发代码超过25行，应该考虑将其分解为不同的方法。
· 方法名需能看出它作什么。别使用会引起误解的名字。如果名字一目了然，就无需用文档来解释方法的功能了。
好：
void SavePhoneNumber ( string phoneNumber ) { // Save the phone number. }
不好：
// This method will save the phone number. void SaveData ( string phoneNumber ) { // Save the phone number. }
· 一个方法只完成一个任务。不要把多个任务组合到一个方法中，即使那些任务非常小。
好：
// Save the address. SaveAddress ( address ); // Send an email to the supervisor to inform that the address is updated. SendEmail ( address, email ); void SaveAddress ( string address ) { // Save the address. // ... } void SendEmail ( string address, string email ) { // Send an email to inform the supervisor that the address is changed. // ... }
不好：
// Save address and send an email to the supervisor to inform that the address is updated. SaveAddress ( address, email ); void SaveAddress ( string address, string email ) { // Job 1. // Save the address. // ... // Job 2. // Send an email to inform the supervisor that the address is changed. // ... }
· 使用C# 或 VB.NET的特有类型，而不是System命名空间中定义的别名类型。
好：
int age; string name; object contactInfo;
不好：
Int16 age; String name; Object contactInfo;
· 别在程序中使用固定数值，用常量代替。
· 别用字符串常数。用资源文件。
· 避免使用很多成员变量。声明局部变量，并传递给方法。不要在方法间共享成员变量。如果在几个方法间共享一个成员变量，那就很难知道是哪个方法在什么时候修改了它的值。
· 必要时使用enum 。别用数字或字符串来指示离散值。
好：
enum MailType { Html, PlainText, Attachment } void SendMail (string message, MailType mailType) { switch ( mailType ) { case MailType.Html: // Do something break; case MailType.PlainText: // Do something break; case MailType.Attachment: // Do something break; default: // Do something break; } }
不好：
void SendMail (string message, string mailType) { switch ( mailType ) { case "Html": // Do something break; case "PlainText": // Do something break; case "Attachment": // Do something break; default: // Do something break; } }
· 别把成员变量声明为 public 或 protected。都声明为 private 而使用 public/protected 的Properties.
· 不在代码中使用具体的路径和驱动器名。 使用相对路径，并使路径可编程。
· 永远别设想你的代码是在“C:”盘运行。你不会知道，一些用户在网络或“Z:”盘运行程序。
· 应用程序启动时作些“自检”并确保所需文件和附件在指定的位置。必要时检查数据库连接。出现任何问题给用户一个友好的提示。
· 如果需要的配置文件找不到，应用程序需能自己创建使用默认值的一份。
· 如果在配置文件中发现错误值，应用程序要抛出错误，给出提示消息告诉用户正确值。
· 错误消息需能帮助用户解决问题。永远别用象"应用程序出错", "发现一个错误" 等错误消息。而应给出象 "更新数据库失败。请确保登陆id和密码正确。" 的具体消息。
· 显示错误消息时，除了说哪里错了，还应提示用户如何解决问题。不要用 象 "更新数据库失败。"这样的，要提示用户怎么做："更新数据库失败。请确保登陆id和密码正确。"
· 显示给用户的消息要简短而友好。但要把所有可能的信息都记录下来，以助诊断问题。
注释
· 别每行代码，每个声明的变量都做注释。
· 在需要的地方注释。可读性强的代码需要很少的注释。如果所有的变量和方法的命名都很有意义，会使代码可读性很强并无需太多注释。
· 行数不多的注释会使代码看起来优雅。但如果代码不清晰，可读性差，那就糟糕。
· 如果应为某种原因使用了复杂艰涩的原理，为程序配备良好的文档和重分的注释。
· 对一个数值变量采用不是0,-1等的数值初始化，给出选择该值的理由。
· 简言之，要写清晰，可读的代码以致无须什么注释就能理解。
· 对注释做拼写检查，保证语法和标点符号的正确使用。
异常处理
· 不要“捕捉了异常却什么也不做“。如果隐藏了一个异常，你将永远不知道异常到底发生了没有。
· 发生异常时，给出友好的消息给用户，但要精确记录错误的所有可能细节，包括发生的时间，和相关方法，类名等。
· 只捕捉特定的异常，而不是一般的异常。
好：
void ReadFromFile ( string fileName ) { try { // read from file. } catch (FileIOException ex) { // log error. // re-throw exception depending on your case. throw; } }
不好：
void ReadFromFile ( string fileName ) { try { // read from file. } catch (Exception ex) { // Catching general exception is bad... we will never know whether it // was a file error or some other error. // Here you are hiding an exception. // In this case no one will ever know that an exception happened. return ""; } }
· 不必在所有方法中捕捉一般异常。不管它，让程序崩溃。这将帮助你在开发周期发现大多数的错误。
· 你可以用应用程序级（线程级）错误处理器处理所有一般的异常。遇到”以外的一般性错误“时，此错误处理器应该捕捉异常，给用户提示消息，在应用程序关闭或 用户选择”忽略并继续“之前记录错误信息。
· 不必每个方法都用try-catch。当特定的异常可能发生时才使用。比如，当你写文件时，处理异常FileIOException.
· 别写太大的 try-catch 模块。如果需要，为每个执行的任务编写单独的 try-catch 模块。 这将帮你找出哪一段代码产生异常，并给用户发出特定的错误消息
· 显示给用户的消息要简短而友好。但要把所有可能的信息都记录下来，以助诊断问题。
注释
· 别每行代码，每个声明的变量都做注释。
· 在需要的地方注释。可读性强的代码需要很少的注释。如果所有的变量和方法的命名都很有意义，会使代码可读性很强并无需太多注释。
· 行数不多的注释会使代码看起来优雅。但如果代码不清晰，可读性差，那就糟糕。
· 如果应为某种原因使用了复杂艰涩的原理，为程序配备良好的文档和重分的注释。
· 对一个数值变量采用不是0,-1等的数值初始化，给出选择该值的理由。
· 简言之，要写清晰，可读的代码以致无须什么注释就能理解。
· 对注释做拼写检查，保证语法和标点符号的正确使用。
异常处理
· 不要“捕捉了异常却什么也不做“。如果隐藏了一个异常，你将永远不知道异常到底发生了没有。
· 发生异常时，给出友好的消息给用户，但要精确记录错误的所有可能细节，包括发生的时间，和相关方法，类名等。
· 只捕捉特定的异常，而不是一般的异常。
好：
void ReadFromFile ( string fileName ) { try { // read from file. } catch (FileIOException ex) { // log error. // re-throw exception depending on your case. throw; } }
不好：
void ReadFromFile ( string fileName ) { try { // read from file. } catch (Exception ex) { // Catching general exception is bad... we will never know whether it // was a file error or some other error. // Here you are hiding an exception. // In this case no one will ever know that an exception happened. return ""; } }
· 不必在所有方法中捕捉一般异常。不管它，让程序崩溃。这将帮助你在开发周期发现大多数的错误。
· 你可以用应用程序级（线程级）错误处理器处理所有一般的异常。遇到”以外的一般性错误“时，此错误处理器应该捕捉异常，给用户提示消息，在应用程序关闭或 用户选择”忽略并继续“之前记录错误信息。
· 不必每个方法都用try-catch。当特定的异常可能发生时才使用。比如，当你写文件时，处理异常FileIOException.
· 别写太大的 try-catch 模块。如果需要，为每个执行的任务编写单独的 try-catch 模块。 这将帮你找出哪一段代码产生异常，并给用户发出特定的错误消息
· 如果应用程序需要，可以编写自己的异常类。自定义异常不应从基类SystemException派生，而要继承于. IApplicationException。
#1楼[楼主] 2006-09-15 14:27 仰天一笑
评论
编 写 人: kkding
日 期: 2003-12-22
当前版本: V 0.5
版本号
作者
日期
批准日期
标志
备注
0.5
kkding
2003-12-22
C
注:C－创建; M－修改; D－删除; A－添加
目录
1 目的.... 3
2 范围.... 3
3 规范内容.... 3
3.1 文件规范... 3
3.1.1 文件命名... 3
3.1.2 文件内容格式... 3
3.2 代码格式... 4
3.3 注释（Comment）规范... 5
3.3.1 模块（类）注释规范... 5
3.3.2 类属性注释规范... 6
3.3.3 方法注释规范... 6
3.3.4 代码间注释规范... 6
3.4 变量（Variable）命名规范... 6
3.4.1 程序文件(*.cs)中的变量命名规则... 6
3.4.2 控件命名规则... 8
3.4.3 常量命名规范... 9
3.4.4 类（Class）命名规范... 9
3.4.5 接口（Interface）命名规范... 10
3.4.6 方法（Method）命名规范... 10
3.4.7 命名空间（NameSpace）命名规范... 10
4 实施建议.... 10
1 目的
为了保证企业编写出的程序都符合相同的规范，保证一致性、统一性而建立的程序编码规范。
编码规范对于程序员而言尤为重要，有以下几个原因：
- 一个软件的生命周期中，80%的花费在于维护
- 几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护
- 编码规范可以改善软件的可读性，可以让程序员尽快而彻底地理解新的代码
- 如果你将源码作为产品发布，就需要确任它是否被很好的打包并且清晰无误，一如你已构建的其它任何产品
为了执行规范，每个软件开发人员必须一致遵守编码规范。每个人。
2 范围
适用于企业所有基于C#.NET平台的软件开发工作。
3 规范内容
3.1 文件规范
3.1.1 文件命名
与类名名称相同
3.1.2 文件内容格式
开头注释
引用
命名空间
类体
变量(代理事件)：用#region 变量………#endregion包括
属性：用#region属性………#endregion包括
构造：
方法(事件的实现)：用#region方法………#endregion包括
3.2 代码格式
u 所有的缩进为4个空格，以空格代替Tab 。选中”插入空格(P)”
u 在代码中垂直对齐左括号和右括号。
if(x==0)
{
Response.Write("用户编号必须输入！");
}
不允许以下情况：
if(x==0) {
Response.Write("用户编号必须输入！");
}
或者：
if(x==0){ Response.Write("用户编号必须输入！");}
u 为了防止在阅读代码时不得不滚动源代码编辑器，每行代码或注释在1024*800的显示频率下不得超过一显示屏
u 当一行被分为几行时，通过将串联运算符放在每一行的末尾而不是开头，清楚地表示没有后面的行是不完整的。
u 每一行上放置的语句避免超过一条。
u 在大多数运算符之前和之后使用空格，这样做时不会改变代码的意图却可以使代码容易阅读。
例：
int j = i + k;
而不应写为
int j=i+k;
u 将大的复杂代码节分为较小的、易于理解的模块。
u 编写 SQL 语句时，对于关键字使用全部大写，对于数据库元素（如表、列和视图）使用大小写混合。
u 将每个主要的 SQL 子句放在不同的行上，这样更容易阅读和编辑语句，例如： SELECT FirstName, LastName
FROM Customers
WHERE State = 'WA'
3.3 注释（Comment）规范
注释规范包括：模块（类）注释规范、类的属性、方法注释规范、代码间注释
3.3.1 模块（类）注释规范
模块开始必须以以下形式书写模块注释：
///
///定义某某类的方法
///
///
///
///
如果模块有修改，则每次修改必须添加以下注释：
///
3.3.2 类属性注释规范
在类的属性必须以以下格式编写属性注释：
///
///属性说明
///
3.3.3 方法注释规范
在类的方法声明前必须以以下格式编写注释
///
/// 说明：<对该方法的说明>
///
/// <参数说明>
///
///
3.3.4 代码间注释规范
代码间注释分为单行注释和多行注释：
单行注释：
//<单行注释>
多行注释：
/*多行注释1
多行注释2
多行注释3*/
代码中遇到语句块时必须添加注释（if,for,foreach,……）,添加的注释必须能够说明此语句块的作用和实现手段（所用算法等等）。
3.4 变量（Variable）命名规范
3.4.1 程序文件(*.cs)中的变量命名规则
程序中变量名称 = 变量的前缀 +代表变量含意的英文单词或单词缩写。
1． 类模块级的变量类型的缩写作前缀
public class hello
{
private string s_Name;
private DateTime dt_Date;
}
2． 类的属性所对应的变量，采用属性名前加类型的缩写作前缀前缀的形式
public class hello
{
private string s_Name;
public string Name
{
get
{
return m_Name;
}
}
}
3． 过程级的变量不使用前缀
public class hello
{
void say()
{
string SayWord;
}
}
4． 过程的参数使用“p_”作为参数
public class hello
{
void say(string p_SayWord)
{
}
}
补充说明：
针对异常捕获过程中的Exception变量命名，在没有冲突的情况下，统一命名为e；
如果有冲突的情况下，可以重复e，比如：ee。
Try
{
//your code
try
{
//code
}
catch(Exception ee)
{
//your code
}
}
catch(Exception e)
{
//your code
}
补充：如果捕获异常不需要作任何处理，则不需要定义Exception实例
例：
try
{
//your code
}
catch( Exception )
{
}
5． 鉴于大多数名称都是通过连接若干单词构造的，请使用大小写混合的格式以简化它们的阅读。每个单词的第一个字母都是大写.
6． 即使对于可能仅出现在几个代码行中的生存期很短的变量，仍然使用有意义的名称。仅对于短循环索引使用单字母变量名，如 i 或 j。
7． 在变量名中使用互补对，如 min/max、begin/end 和 open/close。
8． 不要使用原义数字或原义字符串，如 for( i = 1,i< 7;i++)。而是使用命名常数，如 for( i = 1,i< NUM_DAYS_IN_WEEK ; i++) 以便于维护和理解。
3.4.2 控件命名规则
控件命名=Web控件缩写前缀 + “_” +变量名
控件
缩写
Label
lbl
TextBox
txt
CheckBox
chk
Button
cmd
ListBox
lst
DropDownList
drp
等等
3.4.3 常量命名规范
常量名也应当有一定的意义，格式为 NOUN 或 NOUN_VERB。常量名均为大写，字之间用下划线分隔。
例：
private const bool WEB_ENABLEPAGECACHE_DEFAULT = true;
private const int WEB_PAGECACHEEXPIRESINSECONDS_DEFAULT = 3600;
private const bool WEB_ENABLESSL_DEFAULT = false;
注：
变量名和常量名最多可以包含 255 个字符，但是，超过 25 到 30 个字符的名称比较笨拙。此外，要想取一个有实际意义的名称，清楚地表达变量或常量的用途，25 或 30 个字符应当足够了。
3.4.4 类（Class）命名规范
1． 名字应该能够标识事物的特性。
2． 名字尽量不使用缩写，除非它是众所周知的。
3． 名字可以有两个或三个单词组成，但通常不应多于三个。
4． 在名字中，所有单词第一个字母大写，缩写都要大写。
例如 IsSuperUser，包含ID的，ID全部大写，如CustomerID。
5． 使用名词或名词短语命名类。
6． 少用缩写。
7． 不要使用下划线字符 (_)。
例：
public class FileStream
public class Button
public class String
3.4.5 接口（Interface）命名规范
和类命名规范相同，唯一区别是 接口在名字前加上“I”前缀
例：
interface IDBCommand;
interface IButton;
3.4.6 方法（Method）命名规范
和类命名规范相同。
另：方法开头尽量使用e文动词表示，
如：GetMoney , SetMoney
3.4.7 命名空间（NameSpace）命名规范
和类命名规范相同。
4 实施建议
l 先对编码人员进行“专题”培训，让他们掌握此编码规则。
l 系统设计人员、编码人员、测试人员可以较好的建议，适当地修改完善《C#编码规范》
l 对本文档修改要做出记录，变更版本号。
回复 引用 查看
1.用pascal规则来命名方法和类型.
public class TextBox
{
public void DataBind()
{
}
}
2.用camel规则来命名局部变量和方法的参数.
string userName;
public AddUser(string userId, byte[] password);
3.所有的成员变量前加前缀 m_
public class Database
{
public string m_connectionString;
}
4.接口的名称加前缀 I.
interface ICompare
{
int compare();
}
5.自定义的属性以Attribute结尾
public class AuthorAttribute : Attribute
{
}
6.自定义的异常以Exception结尾
public class AppException : Exception
{
}
7.方法的命名.一般将其命名为动宾短语.
ShowDialog()
CreateFile()
GetPath()
8.代码的缩进.要用Tab，而不要用space.
9.局部变量的名称要有意义.不要用x，y，z等等.
string userName
10.所有的成员变量声明在类的顶端，用一个换行把它和方法分开.
11.用有意义的名字命名namespace，如：产品名、公司名.
12.建议局部变量在最接近使用它时再声明.
13.使用某个控件的值时，尽量命名局部变量.
14.把引用的系统的namespace和自定义或第三方的分开.
15.文件名要能反应类的内容，最好是和类同名，一个文件中一个类.
16.目录结构中要反应出namespace的层次.
17.大括号"{"要新起一行.
public class AuthorAttribute : Attribute
{
}
二、编码习惯.
1.用C#预定义的类名，而不要用别名.
string userName; 而不是 System.String userName;
int number; 而不是 System.Int32;
2.一行不要超过80个字符.
3.尽量不要手工更改机器生成的代码，若必须更改，一定要改成和机器生成的代码风格一样.
4.关键的语句(包括声明关键的变量)必须要写注释.
5.文字常量和数字常量不要硬编码，应该用常量类或枚举代替.
6.不要用goto系列语句.
7.不要声明public和protected的成员变量，应用property.
8.不要声明public的event，应用事件访问器.
public class Source
{
private EventHandler m_NumberChangeEvent;
public event EventHandler NumberChangeEvent
{
add
{
m_NumberChangeEvent += value;
}
remove
{
m_NumberChangeEvent -= value;
}
}
}
9.类型转换的使用规则.
Animal animal = new Dog();
Dog dog = animal as Dog;
if (dog != null)
{
}
10.生成和构建一个长的字符串时，一定要使用StringBuilder，而不用string.
11.始终使用"{ }"包含if下的语句，即使只有一条语句.
12.switch语句一定要有default来处理意外情况.
13.尽量不要使用三目运算符 ? : ，而要使用if语句.
14.尽量不用使用this引用，除非是要调用类中的另一个Constructor.
public class Person
{
public Person(string name)
{
}
public Person() : this("Jim")
{
}
}