1 概述
1.1 规范制定原则
1) 方便代码的交流和维护。
2) 不影响编码的效率，不与大众习惯冲突。
3) 使代码更美观、阅读更方便。
4) 使代码的逻辑更清晰、更易于理解。
1.2 术语定义
1) Pascal 大小写
将标识符的首字母和后面连接的每个单词的首字母都大写。可以对三字符或更多字符的标识符使用Pascal 大小写。例
BackColor
2) Camel 大小写
标识符的首字母小写，而每个后面连接的单词的首字母都大写。例如：
backColor
1.3 文件命名组织
1.3.1 文件命名
1) 文件名遵从Pascal命名法，无特殊情况，扩展名小写。
2) 使用统一而又通用的文件扩展名： C# 类 .cs
1.3.2 文件注释
1) 在每个文件头必须包含以下注释说明
/*----------------------------------------------------------------
// Copyright (C) 公司名称
// 版权所有。
//
// 文件名：
// 文件功能描述：
//
//
// 创建标识：
//
// 修改标识：
// 修改描述：
//
// 修改标识：
// 修改描述：
//----------------------------------------------------------------*/
2) 文件功能描述只需简述，具体详情在类的注释中描述。
3) 创建标识和修改标识由创建或修改人员的拼音或英文名加日期组成。如：
姚明20040408
4) 一天内有多个修改的只需做一个在注释说明中做一个修改标识就够了。
5) 在所有的代码修改处加上修改标识的注释。
2 代码外观
2.1 列宽
代码列宽控制在110字符左右，原则上不超过屏宽。
2.2 换行
当表达式超出或即将超出规定的列宽，遵循以下规则进行换行：
1、在逗号，括号后换行。
2、 在操作符前换行。
3、规则1优先于规则2。
当以上规则会导致代码混乱的时候自己采取更灵活的换行规则。
2.3 缩进
缩进应该是每行一个Tab(4个空格)，不要在代码中使用Tab字符。
Visual Studio.Net设置：工具->选项->文本编辑器->C#->制表符->插入空格
2.4 空行
空行是为了将逻辑上相关联的代码分块，以便提高代码的可阅读性。
在以下情况下使用两个空行：
1、接口和类的定义之间。
2、枚举和类的定义之间。
3、类与类的定义之间。
在以下情况下使用一个空行：
1、方法与方法、属性与属性之间。
2、方法中变量声明与语句之间。
3、方法与方法之间。
4、方法中不同的逻辑块之间。
5、方法中的返回语句与其他的语句之间。
6、属性与方法、属性与字段、方法与字段之间。
7、注释与它注释的语句间不空行，但与其他的语句间空一行。
8、文件之中不得存在无规则的空行，比如说连续十个空行。空行是为了将逻辑上相关联的代码分块，以便提高代码的可阅读性。
2.5 空格
在以下情况中要使用到空格：
1、 关键字和左括符 “(” 应该用空格隔开。如
while (true)
注意在方法名和左括符 “(” 之间不要使用空格，这样有助于辨认代码中的方法调用与关键字。
2、 多个参数用逗号隔开，每个逗号后都应加一个空格。
3、 除了 . 之外，所有的二元操作符都应用空格与它们的操作数隔开。一元操作符、++及--与操作 数间不需要空格。如
a += c + d;
a = (a + b) / (c * d);
while (d++ = s++)
{
n++;
}
PrintSize(“size is “ + size + “\n”);
4、 语句中的表达式之间用空格隔开。如
for (expr1; expr2; expr3)
2.6 花括号 - {}
1、 左花括号 “{” 放于关键字或方法名的下一行并与之对齐。如
if (condition)
{
}
public int Add(int x, int y)
{
}
2、左花括号 “{” 要与相应的右花括号 “}”对齐。
3、 通常情况下左花括号 “{”单独成行，不与任何语句并列一行。
4、 if、while、do语句后一定要使用{}，即使{}号中为空或只有一条语句。如
if (somevalue == 1)
{
somevalue = 2;
}
5、 右花括号 “}” 后建议加一个注释以便于方便的找到与之相应的 {。如
while (1)
{
if (valid)
{
} // if valid
else
{
} // not valid
} // end forever
3 程序注释
3.1 注释概述
1) 修改代码时，总是使代码周围的注释保持最新。
2) 在每个例程的开始，提供标准的注释样本以指示例程的用途、假设和限制很有帮助。注释样本应该是解释它为什么存在和可以做什么的简短介绍.
3) 避免在代码行的末尾添加注释；行尾注释使代码更难阅读。不过在批注变量声明时，行尾注释是合适的；在这种情况下，将所有行尾注释在公共制表位处对齐。
4) 避免杂乱的注释，如一整行星号。而是应该使用空白将注释同代码分开。
5) 在部署发布之前，移除所有临时或无关的注释，以避免在日后的维护工作中产生混乱。
6) 如果需要用注释来解释复杂的代码节，请检查此代码以确定是否应该重写它。尽一切可能不注释难以理解的代码，而应该重写它。尽管一般不应该为了使代码更简单以便于人们使用而牺牲性能，但必须保持性能和可维护性之间的平衡。
7) 在编写注释时使用完整的句子。注释应该阐明代码，而不应该增加多义性。
8) 在编写代码时就注释，因为以后很可能没有时间这样做。另外，如果有机会复查已编写的代码，在今天看来很明显的东西六周以后或许就不明显了。
9) 避免多余的或不适当的注释，如幽默的不主要的备注。
10) 使用注释来解释代码的意图。它们不应作为代码的联机翻译。
11) 注释代码中不十分明显的任何内容。
12) 为了防止问题反复出现，对错误修复和解决方法代码总是使用注释。
13) 对由循环和逻辑分支组成的代码使用注释。这些是帮助源代码读者的主要方面。
14) 在整个应用程序中，使用具有一致的标点和结构的统一样式来构造注释。
15) 在所有的代码修改处加上修改标示的注释。
16) 为了是层次清晰，在闭合的右花括号后注释该闭合所对应的起点。
namespace Langchao.Procument.Web
{
} // namespace Langchao.Procument.Web
3.2 文档型注释
该类注释采用.Net已定义好的Xml标签来标记，在声明接口、类、方法、属性、字段都应该使用该类注释，以便代码完成后直接生成代码文档，让别人更好的了解代码的实现和接口。如
///<summary>MyMethod is a method in the MyClass class.
///<para>Here's how you could make a second paragraph in a description.
///<see cref="System.Console.WriteLine"/>
///for information about output statements.
///</para>
///<seealso cref="MyClass.Main"/>
///</summary>
public static void MyMethod(int Int1)
{
}
3.3 类c注释
该类注释用于
1) 不再使用的代码。
2) 临时测试屏蔽某些代码。
用法
/*
[修改标识]
[修改原因]
. . . (the source code )
*/
3.4 单行注释
该类注释用于
1) 方法内的代码注释。如变量的声明、代码或代码段的解释。注释示例：
//
// 注释语句
//
private int number;
或
// 注释语句
private int number;
2) 方法内变量的声明或花括号后的注释, 注释示例：
if ( 1 == 1) // always true
{
statement;
} // always true
4 申明
4.1 每行声明数
一行只建议作一个声明，并按字母顺序排列。如：
int level; //推荐
int size; //推荐
int x, y; //不推荐
4.2 初始化
建议在变量声明时就对其做初始化。
4.3 位置
变量建议置于块的开始处，不要总是在第一次使用它们的地方做声明。如：
void MyMethod()
{
int int1 = 0; // beginning of method block
if (condition)
{
int int2 = 0; // beginning of "if" block
...
}
}
不过也有一个例外：
for (int i = 0; i < maxLoops; i++)
{
...
}
应避免不同层次间的变量重名，如：
int count;
...
void MyMethod()
{
if (condition)
{
int count = 0; // 避免
...
}
...
}
4.4 类和接口的声明
1） 在方法名与其后的左括号间没有任何空格。
2） 左花括号 “{” 出现在声明的下行并与之对齐，单独成行。
3） 方法间用一个空行隔开。
4.5 字段的声明
不要使用是 public 或 protected 的实例字段。如果避免将字段直接公开给开发人员，可以更轻松地对类进行版本控制，原因是在维护二进制兼容性时字段不能被更改为属性。考虑为字段提供 get 和set 属性访问器，而不是使它们成为公共的。 get 和 set 属性访问器中可执行代码的存在使得可以进行后续改进，如在使用属性或者得到属性更改通知时根据需要创建对象。下面的代码示例阐释带有get 和 set 属性访问器的私有实例字段的正确使用。示例：
public class Control: Component
{
private int handle;
public int Handle
{
get
{
return handle;
}
}
}
5 第五章 命名规范
5.1 命名概述
名称应该说明“什么”而不是“如何”。通过避免使用公开基础实现（它们会发生改变）的名称，可以保留简化复杂性的抽象层。例如，可以使用 GetNextStudent()，而不是 GetNextArrayElement()。
命名原则是：
选择正确名称时的困难可能表明需要进一步分析或定义项的目的。使名称足够长以便有一定的意义，并且足够短以避免冗长。唯一名称在编程上仅用于将各项区分开。表现力强的名称是为了帮助人们阅读；因此，提供人们可以理解的名称是有意义的。其实从长变量名的负面作用三，因为Ctrl+C和Ctrl+V加上在VS中的智能感知，其负面追用已经很小。最优秀的代码它本身就是注释。作为一流的程序员。并不仅仅实现功能，而是要让我们的代码更加优美，具备让他人维护或今后扩充的能力。作为现在的业务系统，其门槛的准入水平已大大降低，实现功能上的需求已没有什么难度，但是高手和菜鸟的区别在于，高手的代码通俗易懂，在整个编码的过程中，不仅能考虑到性能、还会考虑代码可读性和维护性。不过，请确保选择的名称符合适用语言的规则和标准。
以下几点是推荐的命名方法。
1） 避免容易被主观解释的难懂的名称，如命名 AnalyzeThis()，或者属性名 xxK8。这样的名称会导致多义性。
2） 在类属性的名称中包含类名是多余的，如 Book.BookTitle。而是应该使用 Book.Title。
3） 只要合适，在变量名的末尾或开头加计算限定符（Avg、Sum、Min、Max、Index）。
4） 在变量名中使用互补对，如 min/max、begin/end 和 open/close。
5） 布尔变量名应该包含 Is，这意味着 Yes/No 或 True/False 值，如 fileIsFound。
6） 在命名状态变量时，避免使用诸如 Flag 的术语。状态变量不同于布尔变量的地方是它可以具有两个以上的可能值。不是使用 documentFlag，而是使用更具描述性的名称，如 documentFormatType。 （此项只供参考）
7） 即使对于可能仅出现在几个代码行中的生存期很短的变量，仍然使用有意义的名称。仅对于短循环索引使用单字母变量名，如 i 或 j。 可能的情况下，尽量不要使用原义数字或原义字符串，如
For i = 1 To 7。而是使用命名常数，如 For i = 1 To NUM_DAYS_IN_WEEK 以便于维护和理解。
8） 文件名要和类名相同，一般情况下一个类一个文件。
5.2 大小写规则
下表汇总了大写规则，并提供了不同类型的标识符的示例。
|
标识符 |
大小写 |
示例 |
|
类 |
Pascal |
AppDomain |
|
枚举类型 |
Pascal |
ErrorLevel |
|
枚举值 |
Pascal |
FatalError |
|
事件 |
Pascal |
ValueChange |
|
异常类 |
Pascal |
WebException 注意 总是以 Exception 后缀结尾。 |
|
只读的静态字段 |
Pascal |
RedValue |
|
接口 |
Pascal |
IDisposable 注意 总是以 I 前缀开始。 |
|
方法 |
Pascal |
ToString |
|
命名空间 |
Pascal |
System.Drawing |
|
属性 |
Pascal |
BackColor |
|
公共实例字段 |
Pascal |
RedValue 注意 很少使用。属性优于使用公共实例字段。 |
|
受保护的实例字段 |
Camel |
redValue 注意 很少使用。属性优于使用受保护的实例字段。 |
|
私有的实例字段 |
Camel |
redValue |
|
参数 |
Camel |
typeName |
|
方法内的变量 |
Camel |
backColor |
5.3 缩写
为了避免混淆和保证跨语言交互操作，请遵循有关区缩写的使用的下列规则：
1） 不要将缩写或缩略形式用作标识符名称的组成部分。例如，使用 GetWindow，而不要使用 GetWin。
2） 不要使用计算机领域中未被普遍接受的缩写。
3） 在适当的时候，使用众所周知的缩写替换冗长的词组名称。例如，用 UI 作为 User Interface 缩写，用 OLAP 作为 On-line Analytical Processing 的缩写。
4） 在使用缩写时，对于超过两个字符长度的缩写请使用 Pascal 大小写或 Camel 大小写。例如，使用 HtmlButton 或 HTMLButton。但是，应当大写仅有两个字符的缩写，如，System.IO，而不是 System.Io。
5.4 命名空间
1） 命名命名空间时的一般性规则是使用公司名称，后跟技术名称和可选的功能与设计，如下所示。
CompanyName.TechnologyName[.Feature][.Design]
例如：
namespace Langchao.Procurement //浪潮公司的采购单管理系统
namespace Langchao.Procurement.DataRules //浪潮公司的采购单管理系统的业务规则模块
2） 命名空间使用Pascal大小写，用逗号分隔开。
3） TechnologyName 指的是该项目的英文缩写，或软件名。
4） 命名空间和类不能使用同样的名字。例如，有一个类被命名为Debug后，就不要再使用Debug作为一个名称空间名。
5.5 类
1） 使用 Pascal 大小写。
2） 用名词或名词短语命名类。
3） 使用全称避免缩写，除非缩写已是一种公认的约定，如URL、HTML
4） 不要使用类型前缀，如在类名称上对类使用 C 前缀。例如，使用类名称 FileStream，而不是
CFileStream。
5） 不要使用下划线字符 (_)。
6 、有时候需要提供以字母 I 开始的类名称，虽然该类不是接口。只要 I 是作为类名称组成部分的整个单词的第一个字母，这便是适当的。例如，类名称 IdentityStore 是适当的。在适当的地方，使用复合单词命名派生的类。派生类名称的第二个部分应当是基类的名称。例如，ApplicationException 对于从名为 Exception 的类派生的类是适当的名称，原因ApplicationException 是一种Exception。请在应用该规则时进行合理的判断。例如，Button 对于从 Control 派生的类是适当的名称。尽管按钮是一种控件，但是将 Control 作为类名称的一部分将使名称不必要地加长。
public class FileStream
public class Button
public class String
5.6 接口
以下规则概述接口的命名指南：
1） 用名词或名词短语，或者描述行为的形容词命名接口。例如，接口名称 IComponent 使用描述性名词。接口名称 ICustomAttributeProvider 使用名词短语。名称 IPersistable 使用形容词。
2） 使用 Pascal 大小写。
3） 少用缩写。
4） 给接口名称加上字母 I 前缀，以指示该类型为接口。在定义类/接口对（其中类是接口的标准实现）时使用相似的名称。两个名称的区别应该只是接口名称上有字母 I 前缀。
5） 不要使用下划线字符 (_)。
6） 当类是接口的标准执行时，定义这一对类/接口组合就要使用相似的名称。两个名称的不同之处只是接口名前有一个I前缀。
以下是正确命名的接口的示例。
public interface IServiceProvider
public interface IFormatable
以下代码示例阐释如何定义 IComponent 接口及其标准实现 Component 类。
public interface IComponent
{
// Implementation code goes here.
}
public class Component: IComponent
{
// Implementation code goes here.
}
5.7 属性 (Attribute)
应该总是将后缀 Attribute 添加到自定义属性类。以下是正确命名的属性类的示例。
public class ObsoleteAttribute
{
}
5.8 枚举 (Enum)
枚举 (Enum) 值类型从 Enum 类继承。以下规则概述枚举的命名指南：
1） 对于 Enum 类型和值名称使用 Pascal 大小写。
2） 少用缩写。
3） 不要在 Enum 类型名称上使用 Enum 后缀。
4） 避免显式指定枚举的值
|
//正确 public enum Color { Red,Green,Blue }
//避免 public enum Color { Red=1,Green=2,Blue=3 } |
5） 避免为枚举指定一个类型
|
//避免 public enum Color:long { Red,Green,Blue } |
5.9 参数
以下规则概述参数的命名指南：
1） 使用描述性参数名称。参数名称应当具有足够的描述性，以便参数的名称及其类型可用于在大多数情况下确定它的含义。
2） 对参数名称使用 Camel 大小写。
3） 使用描述参数的含义的名称，而不要使用描述参数的类型的名称。开发工具将提供有关参数的类型的有意义的信息。因此， 通过描述意义，可以更好地使用参数的名称。少用基于类型的参数名称，仅在适合使用它们的地方使用它们。
4） 不要给参数名称加匈牙利语类型表示法的前缀。
以下是正确命名的参数的示例。
Type GetType(string typeName)
string Format(string format, args() As object)
5.10 方法
以下规则概述方法的命名指南：
1） 使用动词或动词短语命名方法。
2） 使用 Pascal 大小写。
3） 以下是正确命名的方法的实例。
RemoveAll()
GetCharArray()
Invoke()
5.11 属性 (property)
以下规则概述属性的命名指南：
1） 使用名词或名词短语命名属性。
2） 使用 Pascal 大小写。
3） 不要使用匈牙利语表示法。
4） 考虑用与属性的基础类型相同的名称创建属性。例如，如果声明名为 Color 的属性，则属性的类型同样应该是 Color。请参阅本主题中后面的示例。
以下代码示例阐释正确的属性命名。
public class SampleClass
{
public Color BackColor
{
// Code for Get and Set accessors goes here.
}
}
以下代码示例阐释提供其名称与类型相同的属性。
public enum Color
{
// Insert code for Enum here.
}
public class Control
{
public Color Color
{
get
{
// Insert code here.
}
set
{
// Insert code here.
}
}
}
5.12 事件
以下规则概述事件的命名指南：
1） 对事件处理程序名称使用 EventHandler 后缀。
2） 指定两个名为 sender 和 e 的参数。sender 参数表示引发事件的对象。sender 参数始终是object 类型的，即使在可以使用更为特定的类型时也如此。与事件相关联的状态封装在名为 e 的事件类的实例中。对 e 参数类型使用适当而特定的事件类。
3） 用 EventArgs 后缀命名事件参数类。
4） 考虑用动词命名事件。
5） 使用动名词（动词的“ing”形式）创建表示事件前的概念的事件名称，用过去式表示事件后。例如，可以取消的 Close 事件应当具有 Closing 事件和 Closed 事件。不要使用BeforeXxx/AfterXxx 命名模式。
6） 不要在类型的事件声明上使用前缀或者后缀。例如，使用 Close，而不要使用 OnClose。
7） 通常情况下，对于可以在派生类中重写的事件，应在类型上提供一个受保护的方法（称为 OnXxx）。此方法只应具有事件参数 e，因为发送方总是类型的实例。
以下示例阐释具有适当名称和参数的事件处理程序。
public delegate void MouseEventHandler(object sender, MouseEventArgs e);
以下示例阐释正确命名的事件参数类。
public class MouseEventArgs : EventArgs
{
int x;
int y;
public MouseEventArgs(int x, int y)
{
this.x = x;
this.y = y;
}
public int X
{
get
{
return x;
}
}
public int Y
{
get
{
return y;
}
}
}
5.13 常量 (const)
使用Pascal命名
5.14 字段
以下规则概述字段的命名指南：
1） private、protected 使用 Camel 大小写。
2） public 使用 Pascal 大小写。
3） 拼写出字段名称中使用的所有单词。仅在开发人员一般都能理解时使用缩写。字段名称不要使用大写字母。下面是正确命名的字段的示例。
class SampleClass
{
string url;
string destinationUrl;
}
4） 不要对字段名使用匈牙利语表示法。好的名称描述语义，而非类型。
5） 不要对字段名或静态字段名应用前缀。具体说来，不要对字段名称应用前缀来区分静态和非静态字段。例如，应用 g_ 或 s_ 前缀是不正确的。
5.15 静态字段
以下规则概述静态字段的命名指南：
1） 使用名词、名词短语或者名词的缩写命名静态字段。
2） 使用 Pascal 大小写。
3） 对静态字段名称使用匈牙利语表示法前缀。
4） 建议尽可能使用静态属性而不是公共静态字段。
5.16 集合
集合是一组组合在一起的类似的类型化对象，如哈希表、查询、堆栈、字典和列表，集合的命名建议用复数。
5.17 范型
如果你对类型参数没有其他的跟上下文有关的信息（additional contextual information），你应该使用字母T：
5.18 措词
避免使用与常用的 .NET 框架命名空间重复的类名称。例如，不要将以下任何名称用作类名称：
System、Collections、Forms 或 UI。有关 .NET 框架命名空间的列表，请参阅类库。
另外，避免使用和以下关键字冲突的标识符。
|
AddHandler |
AddressOf |
Alias |
And |
Ansi |
|
As |
Assembly |
Auto |
Base |
Boolean |
|
ByRef |
Byte |
ByVal |
Call |
Case |
|
Catch |
CBool |
CByte |
Cchar |
CDate |
|
CDec |
CDbl |
Char |
Cint |
Class |
|
CLng |
CObj |
Const |
Cshort |
CSng |
|
CStr |
CType |
Date |
Decimal |
Declare |
|
Default |
Delegate |
Dim |
Do |
Double |
|
Each |
Else |
ElseIf |
End |
Enum |
|
Erase |
Error |
Event |
Exit |
ExternalSource |
|
False |
Finalize |
Finally |
Float |
For |
|
Friend |
Function |
Get |
GetType |
Goto |
|
Handles |
If |
Implements |
Imports |
In |
|
Inherits |
Integer |
Interface |
Is |
Let |
|
Lib |
Like |
Long |
Loop |
Me |
|
Mod |
Module |
MustInherit |
MustOverride |
MyBase |
|
MyClass |
Namespace |
New |
Next |
Not |
|
Nothing |
NotInheritable |
NotOverridable |
Object |
On |
|
Option |
Optional |
Or |
Overloads |
Overridable |
|
Overrides |
ParamArray |
Preserve |
Private |
Property |
|
Protected |
Public |
RaiseEvent |
ReadOnly |
ReDim |
|
Region |
REM |
RemoveHandler |
Resume |
Return |
|
Select |
Set |
Shadows |
Shared |
Short |
|
Single |
Static |
Step |
Stop |
String |
|
Structure |
Sub |
SyncLock |
Then |
Throw |
|
To |
True |
Try |
TypeOf |
Unicode |
|
Until |
volatile |
When |
While |
With |
|
WithEvents |
WriteOnly |
Xor |
Eval |
extends |
|
instanceof |
package |
var |
|
|
6 第六章 语句
6.1 每行一个语句
每行最多包含一个语句。如
a++; //推荐
b--; //推荐
a++; b--; //不推荐
6.2 复合语句
复合语句是指包含"父语句{子语句;子语句;}"的语句，使用复合语句应遵循以下几点：
1） 子语句要缩进。
2） 左花括号“{” 在复合语句父语句的下一行并与之对齐，单独成行。
3） 即使只有一条子语句也不要省略花括号“ {}”。 如
while (d + = s++)
{
n++;
}
6.3 return 语句
return语句中不使用括号，除非它能使返回值更加清晰。如：
return;
return myDisk.size();
return (size ? size : defaultSize);
6.4 if、 if-else、if else-if 语句
if、 if-else、if else-if 语句使用格式
if (condition)
{
statements;
}
if (condition)
{
statements;
}
else
{
statements;
}
if (condition)
{
statements;
}
else if (condition)
{
statements;
}
else
{
statements;
}
6.5 for、foreach 语句
for 语句使用格式
for (initialization; condition; update)
{
statements;
}
空的 for 语句（所有的操作都在initialization、condition 或 update中实现）使用格式
for (initialization; condition; update); // update user id
foreach 语句使用格式
foreach (object obj in array)
{
statements;
}
注意 1在循环过程中不要修改循环计数器。
2对每个空循环体给出确认性注释。
6.6 while 语句
while 语句使用格式
while (condition)
{
statements;
}
空的 while 语句使用格式
while (condition);
6.7 do - while 语句
do - while 语句使用格式
do
{
statements;
} while (condition);
6.8 switch - case 语句
switch - case 语句使用格式
switch (condition)
{
case 1:
statements;
break;
case 2:
statements;
break;
default:
statements;
break;
}
注意：
1） 语句switch中的每个case各占一行。
2） 语句switch中的case按字母顺序排列。
3） 为所有switch语句提供default分支。
4） 所有的非空 case 语句必须用 break; 语句结束。
6.9 try - catch 语句
try - catch 语句使用格式
try
{
statements;
}
catch (ExceptionClass e)
{
statements;
}
finally
{
statements;
}
6.10 using 块语句
using 块语句使用格式
using (object)
{
statements;
}
7 控件命名规则
7.1 命名方法
控件名简写+英文描述，英文描述首字母大写。
7.2 主要控件名简写对照表
|
控件名 |
简写 |
控件名 |
简写 |
|
Label |
lbl |
TextBox |
txt |
|
Button |
btn |
LinkButton |
lnkbtn |
|
ImageButton |
imgbtn |
DropDownList |
ddl |
|
ListBox |
lst |
DataGrid |
dg |
|
DataList |
dl |
CheckBox |
chk |
|
CheckBoxList |
chkls |
RadioButton |
rdo |
|
RadioButtonList |
rdolt |
Image |
img |
|
Panel |
pnl |
Calender |
cld |
|
AdRotator |
ar |
Table |
tbl |
|
RequiredFieldValidator |
rfv |
CompareValidator |
cv |
|
RangeValidator |
rv |
RegularExpressionValidator |
rev |
|
ValidatorSummary |
vs |
CrystalReportViewer |
rptvew |
8 程序结构
8.1 程序结构规范
1） 程序结构清晰，简单易懂，单个函数的程序行数不得超过100行。避免使用大文件。如果一个文件里的代码超过300～400行，必须考虑将代码分开到不同类中。 避免写太长的方法。一个典型的方法代码在1～25行之间。如果一个方法发代码超过25行，应该考虑将其分解为不同的方法。一个文件应避免超过2000行。
2） 打算干什么，要简单，直截了当，代码精简，避免垃圾程序。
3） 尽量使用.NET库函数和公共函数(无特殊情况不要使用外部方法调用windows的核心动态链接库API)。
4） 不要随意定义全局变量，尽量使用局部变量。
5） 方法名需能看出它作什么。别使用会引起误解的名字。如果名字一目了然，就无需用文档来解释方法的功能了。
好：
不好：
6） 程序编码力求简洁，结构清晰，避免太多的分支结构及太过于技巧性的程序。
7） 避免采用过于复杂的条件测试，避免过多的循环嵌套和条件嵌套。
8） 尽量使用.NET库函数和公共函数(无特殊情况不要使用外部方法调用windows的核心动态链接库API)。
9） 不要随意定义全局变量，声明局部变量，并传递给方法。不要在方法间共享成员变量。如果在几个方法间共享一个成员变量，那就很难知道是哪个方法在什么时候修改了它的值。
10） 别在程序中使用固定数值，用常量代替。
8.2 结构书写规范
1） 把所有系统框架提供的名称空间组织到一起，把第三方提供的名称空间放到系统名称空间的下面
|
void SavePhoneNumber ( string phoneNumber ) |
|
// This method will save the phone number. |
2） 所有的类成员变量应该被声明在类的顶部，并用一个空行把它们和方法以及属性的声明区分开
|
using System; using System.Collection.Generic; using System.ComponentModel; using System.Data; using MyCompany; using MyControls; |
|
public class MyClass { int m_Number; string m_Name; public void SomeMethod1(); public void SomeMethod2(); } |
|
|
3） 避免采用多赋值语句，如x = y = z;。
4） 必要时使用enum 。别用数字或字符串来指示离散值。
好：
不好：
5） 一个方法只完成一个任务。不要把多个任务组合到一个方法中，即使那些任务非常小。
好：
|
enum MailType |
|
void SendMail (string message, string mailType) |
|
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. // ... } |
不好：
6） 使用括号清晰地表达算术表达式和逻辑表达式的运算顺序。如将 x=a*b/c*d 写成 x=(a*b/c)*d可避免阅读者误解为x=(a*b)/(c*d)。
7） 总是使用以零为基数的数组。
8） 把引用的系统的namespace和自定义或第三方的用一个换行把它们分开.
9） 目录结构中要反应出namespace的层次.
9 异常处理
9.1 异常处理
1） 不要“捕捉了异常却什么也不做”。如果隐藏了一个异常，你将永远不知道异常到底发生了没有。
2） 发生异常时，给出友好的消息给用户，但要精确记录错误的所有可能细节，包括发生的时间，和相关方法，类名等。
3） 不必每个方法都用try-catch。当特定的异常可能发生时才使用。比如，当你写文件时，处理异常FileIOException.
4） 别写太大的 try-catch 模块。如果需要，为每个执行的任务编写单独的 try-catch 模块。 这将帮你找出哪一段代码产生异常，并给用户发出特定的错误消息。
5） 只捕捉特定的异常，而不是一般的异常。
好：
不好：
|
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. // ... } |
不必在所有方法中捕捉一般异常。不管它，让程序崩溃。这将帮助你在开发周期发现大多数的错误。
6） 避免利用返回值作为函数的错误代码，应该在程序中使用异常来处理错误。
10 其他
10.1 类型转换
1） 尽量避免强制类型转换。
2） 如果不得不做类型转换，尽量使用as关键字安全的转换到另一个类型。
10.2 正确性与容错性要求
1） 程序首先是正确，其次是优美
2） 无法证明你的程序没有错误，因此在编写完一段程序后，应先回头检查。
3） 改一个错误时可能产生新的错误，因此在修改前首先考虑对其它程序的影响。
4） 对所有的用户输入，必须进行合法性检查。
5） 尽量不要比较浮点数的相等，如： 10.0 * 0.1 == 1.0 ， 不可靠
6） 程序与环境或状态发生关系时，必须主动去处理发生的意外事件，如文件能否逻辑锁定、打印机是否联机等,对于明确的错误,要有明确的容错代码提示用户，在这样不确定的场合都使用Try Throw Catch。
7） 单元测试也是编程的一部份，提交联调测试的程序必须通过单元测试。
10.3 可重用性要求
1） 重复使用的完成相对独立功能的算法或代码应抽象为asp.net服务或类。
2） asp.net服务或类应考虑OO思想，减少外界联系，考虑独立性或封装性。
3） 避免让你的代码依赖于运行在某个特定地方的程序集。
10.4 其他
1） 不要手动去修改任何机器生成的代码
a) 如果修改了机器生成的代码，修改你的编码方式来适应这个编码标准
b) 尽可能使用partial classes特性，以提高可维护性。(C#2.0新特性)
2） 避免在一个程序集中(assembly)中定义多个Main()方法。
3） 只把那些绝对需要的方法定义成public,而其它的方法定义成internal。
4） 避免使用三元条件操作符。
5） 除非为了和其它语言进行互动，否则绝不要使用不安（unsafe）的代码。
6） 接口和类中方法和属性的比应该在2:1左右。
7） 努力保证一个接口有3~5个成员。
8） 避免在结构中提供方法
a) 参数化的构造函数是鼓励使用的
b) 可以重载运行符
9） 当早绑定(early-binding)可能的时候就尽量不要使用迟绑定（late-binding）。
10） 除了在一个构造函数中调用其它的构造函数之外，不要使用this关键字。
|
void ReadFromFile ( string fileName ) |
|
void ReadFromFile ( string fileName ) |
11） 不要使用base关键字访问基类的成员，除非你在调用一个基类构造函数的时候要解决一个子类的名称冲突
|
Dog dog=new GermanShepherd(); GermanShepherd shepherd=dog as GermanShepherd; if (shepherd!=null) {…} |
|
//Example of proper use of ‘this’ public class MyClass { public MyClass(string message) { } public MyClass():this(“Hello”) { } } |
|
//Example of proper use of ‘base’ public class Dog { public Dog(string name) { } virtual public void Bark(int howlong) { } } public class GermanShepherd:Dog { public GermanShepherd(string name):base(name) { } override public void Bark(int howLong) { base.Bark(howLong) } } |
12） 生成和构建一个长的字符串时，一定要使用StringBuilder，而不用string。