C#编码规范
第一章 概述
1.1 规范制定原则
- 方便代码的交流和维护。
- 不影响编码的效率,不与大众习惯冲突。
- 使代码更美观、阅读更方便。
- 使代码的逻辑更清晰、更易于理解。
1.2 术语定义
1.2.1 Pascal 大小写
将标识符的首字母和后面连接的每个单词的首字母都大写。可以对三字符或更多字符的标识符使用Pascal 大小写。例如:
`BackColor`
1.2.2 Camel 大小写
标识符的首字母小写,而每个后面连接的单词的首字母都大写。例如:
`backColor`
1.2.3 匈牙利命名法
匈牙利命名法是一名匈牙利程序员发明的,而且他在微软工作了多年。此命名法就是通过微软的各种产品和文档传出来的。多数有经验的程序员,不管他们用的是哪门儿语言,都或多或少在使用它。
这种命名法的基本原则是:
变量名=属性+类型+对象描述
即一个变量名是由三部分信息组成,这样,程序员很容易理解变量的类型、用途,而且便于记忆。
第二章 代码外观
提示:可以借助VisualStudio提供的代码格式化工具Ctrl+K+F格式化你所选中的代码。
2.1 列宽
代码列宽控制在210字符左右。
2.2 换行
当表达式超出或即将超出规定的列宽,遵循以下规则进行换行
- 在逗号后换行;
- 在操作符前换行;
- 规则1优先于规则2。
2.3 缩进
缩进应该是每行一个Tab(4个空格),不要在代码中使用Tab字符。
2.4 空行
空行是为了将逻辑上相关联的代码分块,以便提高代码的可阅读性。在代码中,不能包含多个空行。
在以下情况下使用一个空行
- 方法与方法、属性与属性之间。
- 方法中变量声明与语句之间。
- 方法与方法之间。
- 方法中不同的逻辑块之间。
- 方法中的返回语句与其他的语句之间。
- 属性与方法、属性与字段、方法与字段之间。
- 注释与它注释的语句间不空行,但与其他的语句间空一行。
2.5 空格
在以下情况中要使用到空格
-
关键字和左括符 “(” 应该用空格隔开。如:
while (true)
注意:在方法名和左括符 “(” 之间不要使用空格,这样有助于辨认代码中的方法调用与关键字。
-
多个参数用逗号隔开,每个逗号后都应加一个空格。
-
除了 . 之外,所有的二元操作符都应用空格与它们的操作数隔开。一元操作符、++及–与操作数间不需要空格。如:
a += c + d;
a = (a + b)/(c*d);
while (d++ == s++)
{
n++;
}
PrintSize($"size is " {size} "\n");
-
语句中的表达式之间用空格隔开。如:
` for (expr1; expr2; expr3) `
2.6 括号 - ()
- 左括号“(” 不要紧靠关键字,中间用一个空格隔开。
- 左括号“(” 与方法名之间不要添加任何空格。
- 没有必要的话不要在返回语句中使用()。如
if (true)
{
Array.Remove(1);
return 1;
}
2.7 花括号 - {}
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.1 注释概述
-
修改代码时,总是使代码周围的注释保持最新。
- 在每个例程的开始,提供标准的注释样本以指示例程的用途、假设和限制很有帮助。注释样本应该是解释它为什么存在和可以做什么的简短介绍.
- 避免在代码行的末尾添加注释;行尾注释使代码更难阅读。不过在批注变量声明时,行尾注释是合适的;在这种情况下,将所有行尾注释在公共制表位处对齐。
- 避免杂乱的注释,如一整行星号。而是应该使用空白将注释同代码分开。
- 避免在块注释的周围加上印刷框。这样看起来可能很漂亮,但是难于维护。
- 在部署发布之前,移除所有临时或无关的注释,以避免在日后的维护工作中产生混乱。
- 如果需要用注释来解释复杂的代码节,请检查此代码以确定是否应该重写它。尽一切可能不注释难以理解的代码,而应该重写它。尽管一般不应该为了使代码更简单以便于人们使用而牺牲性能,但必须保持性能和可维护性之间的平衡。
- 在编写注释时使用完整的句子。注释应该阐明代码,而不应该增加多义性。
- 在编写代码时就注释,因为以后很可能没有时间这样做。另外,如果有机会复查已编写的代码,在今天看来很明显的东西,六周以后或许就不明显了。
- 避免多余的或不适当的注释,如幽默的不主要的备注。
- 使用注释来解释代码的意图。它们不应作为代码的联机翻译。
- 注释代码中不十分明显的任何内容。
- 为了防止问题反复出现,对错误修复和解决方法代码总是使用注释,尤其是在团队环境中。
- 对由循环和逻辑分支组成的代码使用注释。这些是帮助源代码读者的主要方面。
- 在整个应用程序中,使用具有一致的标点和结构的统一样式来构造注释。
- 用空白将注释同注释分隔符分开。在没有颜色提示的情况下查看注释时,这样做会使注释很明显且容易被找到。
- 在所有的代码修改处加上修改标识的注释。
- 为了使层次清晰,在闭合的右花括号后注释该闭合所对应的起点。
namespace Mango.Procument.Web
{
} // namespace Mango.Procument.Web
3.2 文件注释
在每个文件头必须包含以下注释说明:
// <copyright file="文件名.cs" company="Mango">
// Copyright (c) Mango. All rights reserved.
// </copyright>
// <author>×××</author>
// <date> yyyy-mm-dd </date>
// <summary>文件功能描述</summary>
// <modify>
// 修改人:×××
// 修改时间:yyyy-mm-dd
// 修改描述:×××
// 版本:1.0
//</modify>
注意:文件功能描述只需简述,具体详情在类的注释中描述。创建标识和修改标识由创建或修改人员的拼音或英文名。如:Zhangsan。一天内有多个修改的只需做一个在注释说明中做一个修改标识就够了。在所有的代码修改处加上修改标识的注释。
为了方便起见,可以使用Visual Studio 自动生成注释的功能,找到VS安装目录的Class.cs文件,具体路径:
#vs2019
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\ItemTemplates\CSharp\Code\2052\Class
这里根据你的vs版本可能路径要做适当的调整,
Community、Professional、Enterprise
上面的路径中 Code 文件夹下有两个目录 1033 和 2052,这两个文件夹为 LCID(Locale ID,区域性标识符) 其中,2052、1033 分别为 默认中文简体(中华人民共和国)、英语(美国)的Microsoft语言环境ID值。如果你的开发工具为中文版,就去2052文件夹下修改,英文版去1033下修改。
打开文件,在顶部添加注释
#region << 版 本 注 释 >>
/*----------------------------------------------------------------
* 项目名称 :$rootnamespace$
* 项目描述 :
* 类 名 称 :$safeitemname$
* 类 描 述 :
* 所在的域 :$userdomain$
* 命名空间 :$rootnamespace$
* 机器名称 :$machinename$
* CLR 版本 :$clrversion$
* 作 者 :$username$
* 创建时间 :$time$
* 修 改 :
* 修改人:$username$
* 修改时间:$time$
* 修改描述:
* 版本:v1.0.0.0
* 版 本 号 :v1.0.0.0
*******************************************************************
* Copyright @ $username$ $year$. All rights reserved.
*******************************************************************
//----------------------------------------------------------------*/
#endregion
using System;
using System.Collections.Generic;
$if$ ($targetframeworkversion$ >= 3.5)using System.Linq;
$endif$using System.Text;
$if$ ($targetframeworkversion$ >= 4.5)using System.Threading.Tasks;
$endif$
namespace $rootnamespace$
{
class $safeitemrootname$
{
}
}
3.3 文档型注释
该类注释采用.Net已定义好的Xml标签来标记,在声明接口、类、方法、属性、字段都应该使用该类注释,以便代码完成后直接生成代码文档,让别人更好的了解代码的实现和接口。如:
- 类、接口注释
/// <summary>
/// 类功能的说明
/// </summary>
/// <see cref=""></see>
/// <remarks>
/// 创建人:Zhangsan
/// 创建日期:yyyy-mm-dd
/// 修改人:Lisi
/// 修改日期:yyyy-mm-dd
/// 修改备注:无
/// 版本:1.0
/// </remarks>
public class CountersModuleInitializer : ModuleInitializer
{
}
注意:<see cref=""></see>标签根据具体情况选择有无
- 方法、事件注释
/// <summary>
/// 根据员工编号获得员工信息
/// </summary>
/// <param name="employeeId">员工编号</param>
/// <exception cref="System.Exception">系统异常</exception>
/// <returns>员工姓名</returns>
/// <remarks>
/// 创建人:Zhangsan
/// 创建日期:yyyy-mm-dd
/// 修改人:Lisi
/// 修改日期:yyyy-mm-dd
/// 修改备注:无
/// 版本:1.1
/// </remarks>
public string GetEmployeeNameById(int employeeId)
{
try
{
return "ddd";
}
catch (System.Exception)
{
throw;
}
}
注意:该方法注释中的<param></param>、<exception cref=" "></exception>、<returns></returns>等标签根据具体情况选择有无,方法初始版本为1.0,每次改动增加0.1。
- 属性、常量注释
/// <summary>
/// session id
/// </summary>
public const int SESSION_ID = 500;
- 单行注释
该类注释用于:
1) 方法内的代码注释。如变量的声明、代码或代码段的解释。注释示例:
/// <summary>
/// 编号
/// </summary>
private int number;
或
// 编号
private int number;
2) 方法内变量的声明或花括号后的注释, 注释示例:
if ( 1 == 1) // always true
{
statement;
}
else // always false
{
}
第四章 声明
4.1 每行声明数
一行只建议作一个声明,并按字母顺序排列。如:
int level; // 推荐
int size; // 推荐
int x, y; // 不推荐
4.2 初始化
建议在变量声明时就对其做初始化。
4.3 位置
变量建议置于块的开始处,不要总是在第一次使用它们的地方做声明。如:
void MyMethod()
{
int int1 = 0;
if (condition)
{
int int2 = 0;
...
}
}
例外情况
for (int i = 0; i < maxLoops; i++)
{
...
}
应避免不同层次间的变量重名,如:
int count;
...
void MyMethod()
{
if (condition)
{
int count = 0; // 避免
...
}
...
}
4.4 类和接口的声明
- 在方法名与其后的左括号间没有任何空格。
- 左花括号 “{” 出现在声明的下行并与之对齐,单独成行。
- 方法间用一个空行隔开。
4.5 字段的声明
不要使用是 public 或 protected 的实例字段。如果避免将字段直接公开给开发人员,可以更轻松地对类进行版本控制,原因是在维护二进制兼容性时字段不能被更改为属性。考虑为字段提供 get 和set 属性访问器,而不是使它们成为公共的。 get 和 set 属性访问器中可执行代码的存在使得可以进行后续改进,如在使用属性或者得到属性更改通知时根据需要创建对象。下面的代码示例阐释带有 get 和 set 属性访问器的私有实例字段的正确使用。例:
public class Control: Component
{
private int handle;
public int Handle
{
get
{
return handle;
}
}
}
第五章 命名规范
5.1 命名概述
名称应该说明“什么”而不是“如何”。通过避免使用公开基础实现(它们会发生改变)的名称,可以保留简化复杂性的抽象层。例如,可以使用
GetNextStudent()
,而不是GetNextArrayElement
()。
命名原则是:
选择正确名称时的困难可能表明需要进一步分析或定义项的目的。使名称足够长以便有一定的意义,并且足够短以避免冗长。唯一名称在编程上仅用于将各项区分开。表现力强的名称是为了帮助人们阅读;因此,提供人们可以理解的名称是有意义的。不过,请确保选择的名称符合适用语言的规则和标准。
以下几点是推荐的命名方法:
- 避免容易被主观解释的难懂的名称,如方面名
AnalyzeThis()
,或者属性名xxK8
。这样的名称会导致多义性。 - 在类属性的名称中包含类名是多余的,如
Book.BookTitle
。而是应该使用Book.Title
。 - 只要合适,在变量名的末尾或开头加计算限定符
(Avg、Sum、Min、Max、Index)
。 - 在变量名中使用互补对,如
min/max、begin/end
和open/close
。 - 布尔变量名应该包含
Is
,这意味着Yes/No
或True/False
值,如fileIsFound
。 - 在命名状态变量时,避免使用诸如
Flag
的术语。状态变量不同于布尔变量的地方是它可以具有两个以上的可能值。不是使用documentFlag
,而是使用更具描述性的名称,如documentFormatType
。 - 即使对于可能仅出现在几个代码行中的生存期很短的变量,仍然使用有意义的名称。仅对于短循环索引使用单字母变量名,如 i 或 j。 可能的情况下,尽量不要使用原义数字(幻数)或原义字符串,如
for (int i = 1; i < 7; i++)
。而是使用命名常数,如for (int i = 1; i < NUM_DAYS_IN_WEEK; i++)
以便于维护和理解。 - 用于事件处理的委托添加 EventHandler 后缀
- 用于事件处理之外的那些委托添加 Callback 后缀
- 不要给委托添加 Delegate 后缀
- 用名词或名词词组来给类型命名,在少数情况下也可以用形容词词组来给类型命名
- 用动词或动词词组来命名方法
- 用名词、名词词组或形容词来命名属性
- 要用动词或动词短语来命名事件
- 要用名词或名词短语来命名字段
5.2 大小写规则
大写
- 组织名缩写使用大写
- 两个或者更少字母组成的标识符使用大写。例:
System.IO
System.Web.UI
SCB.Framework.UI
下表汇总了大写规则,并提供了不同类型的标识符的示例。
标识符 | 大小写 | 示例 |
---|---|---|
类 | 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 缩写
为了避免混淆和保证跨语言交互操作,请遵循有关区缩写的使用的下列规则:
- 不要将缩写或缩略形式用作标识符名称的组成部分。例如,使用
GetWindow
,而不要使用GetWin
。 - 不要使用计算机领域中未被普遍接受的缩写。
- 在适当的时候,使用众所周知的缩写替换冗长的词组名称。例如,用
UI
作为User Interface
缩 写,用OLAP
作为On-line Analytical Processing
的缩写。 - 在使用缩写时,对于超过两个字符长度的缩写请使用 Pascal 大小写或 Camel 大小写。例如使用
HtmlButton
或HTMLButton
;但是,应当大写仅有两个字符的缩写,如:System.IO
,而不是System.Io
。 - 不要在标识符或参数名称中使用缩写。如果必须使用缩写,对于由多于两个字符所组成的缩写请使用Camel 大小写。
5.4 命名空间
- 命名命名空间时的一般性规则是使用公司名称,后跟技术名称和可选的功能与设计,如:
CompanyName.TechnologyName[.Feature][.Design]
例如:
namespace SCB.SupplierChain // 赛酷比公司的供应链系统
namespace SCB.SupplierChain.DataRules // 赛酷比公司的供应链系统的业务规则模块
- 命名空间使用Pascal大小写。
TechnologyName
指的是该项目的英文缩写或软件名。- 命名空间和类不能使用同样的名字。例如,有一个类被命名为
Debug
后,就不要再使用Debug
作为一个名称空间名。
5.5 类
- 使用 Pascal 大小写。
- 用名词或名词短语命名类。
- 使用全称避免缩写,除非缩写已是一种公认的约定,如
URL
、HTML
- 不要使用类型前缀,如在类名称上对类使用 C 前缀。例如,使用类名称
FileStream
,而不是CFileStream
。 - 不要使用下划线字符 (_)。
- 有时候需要提供以字母 I 开始的类名称,虽然该类不是接口。只要 I 是作为类名称组成部分的整个单词的第一个字母,这便是适当的。例如,类名称
IdentityStore
是适当的。在适当的地方,使用复合单词命名派生的类。派生类名称的第二个部分应当是基类的名称。例如,ApplicationException
对于从名为Exception
的类派生的类是适当的名称,原因ApplicationException
是一种Exception
。请在应用该规则时进行合理的判断。例如,Button
对于从Control
派生的类是适当的名称。尽管按钮是一种控件,但是将Control
作为类名称的一部分将使名称不必要地加长。
public class FileStream
public class Button
public class String
5.6 接口
- 用名词或名词短语,或者描述行为的形容词命名接口。例:
- 接口名称
IComponent
使用描述性名词 - 接口名称
ICustomAttributeProvider
使用名词短语 - 接口名称
IPersistable
使用形容词。
- 接口名称
- 使用 Pascal 大小写。
- 少用缩写。
- 给接口名称加上字母 I 前缀,以指示该类型为接口。在定义类/接口对(其中类是接口的标准实现)时使用相似的名称。两个名称的区别应该只是接口名称上有字母 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 类继承。
- 对于 Enum 类型和值名称使用 Pascal 大小写。
- 少用缩写。
- 不要在 Enum 类型名称上使用 Enum 后缀。
- 对大多数 Enum 类型使用单数名称,但是对作为位域的 Enum 类型使用复数名称。
- 总是将
FlagsAttribute
添加到位域 Enum 类型。
5.9 参数
- 使用描述性参数名称。参数名称应当具有足够的描述性,以便参数的名称及其类型可用于在大多数情况下确定它的含义。
- 对参数名称使用 Camel 大小写。
- 使用描述参数的含义的名称,而不要使用描述参数的类型的名称。开发工具将提供有关参数的类型的有意义的信息。因此,通过描述意义,可以更好地使用参数的名称。
- 不要给参数名称加匈牙利语类型表示法的前缀,仅在适合使用它们的地方使用它们。
- 不要使用保留的参数。保留的参数是专用参数,如果需要,可以在未来的版本中公开它们。相反,如果在类库的未来版本中需要更多的数据,请为方法添加新的重载。
Type GetType(string typeName)
string Format(string format, object args)
5.10 方法
- 使用动词或动词短语命名方法。
- 使用 Pascal 大小写。
RemoveAll()
GetCharArray()
Invoke()
5.11 属性 (property)
- 使用名词或名词短语命名属性。
- 使用 Pascal 大小写。
- 考虑用与属性的基础类型相同的名称创建属性。例如,如果声明名为
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 事件
- 对事件处理程序名称使用
EventHandler
后缀。 - 指定两个名为
sender
和e
的参数。sender
参数表示引发事件的对象。sender
参数始 终是object
类型的,即使在可以使用更为特定的类型时也如此。与事件相关联的状态封装 在名为e
的事件类的实例中。对e
参数类型使用适当而特定的事件类。 - 用
EventArgs
后缀命名事件参数类。 - 考虑用动词命名事件。
- 使用动名词(动词的“ing”形式)创建表示事件前的概念的事件名称,用过去式表示事
件后。例如,可以取消的
Close
事件应当具有Closing
事件和Closed
事件。不要使用BeforeXxx/AfterXxx
命名模式。 - 不要在类型的事件声明上使用前缀或者后缀。例如,使用
Close
,而不要使用OnClose
。 - 通常情况下,对于可以在派生类中重写的事件,应在类型上提供一个受保护的方法(称为
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)
所有单词大写,多个单词之间用 “_” 隔开。 如:
public const string PAGE_TITLE = "Welcome";
5.14 字段
- private、protected 使用 Camel 大小写。
- public 使用 Pascal 大小写。
- 拼写出字段名称中使用的所有单词。仅在开发人员一般都能理解时使用缩写。
- 字段变量名前可加“_”前缀
class SampleClass
{
string _url;
string _destinationUrl;
}
- 不要对字段名使用匈牙利语表示法。好的名称描述语义,而非类型。
- 不要对字段名或静态字段名应用前缀。具体说来,不要对字段名称应用前缀来区分静态和非静态字段。例如,应用
g_
或s_
前缀是不正确的。 - 对预定义对象实例使用公共静态只读字段。如果存在对象的预定义实例,则将它们声明为 对象本身的公共静态只读字段。使用 Pascal 大小写,原因是字段是公共的。
public struct Color
{
public static readonly Color Red = new Color(0x0000FF);
public Color(int rgb)
{
// Insert code here.
}
public Color(byte r, byte g, byte b)
{
// Insert code here.
}
public byte RedValue
{
get
{
return Color;
}
}
}
5.15 静态字段
- 使用名词、名词短语或者名词的缩写命名静态字段。
- 使用 Pascal 大小写。
- 建议尽可能使用静态属性而不是公共静态字段。
5.16 集合
集合是一组组合在一起的类似的类型化对象,如哈希表、查询、堆栈、字典和列表,集合的命名建议用复数。
5.17 措词
避免使用与常用的 .NET 框架命名空间重复的类名称。例如,不要将以下任何名称用作类名称:System、Collections、Forms 或 UI。有关 .NET 框架命名空间的列表,请参阅类库。
另外,避免使用与C#语言关键字冲突的标识符。
5.18 控件命名规则(参考)
控件名简写+英文描述,英文描述首字母大写
控件名 | 简写 |
---|---|
AdRotator | ar |
Button | btn |
Calender | cld |
CheckBox | chk |
CheckBoxList | chkls |
CompareValidator | cv |
CrystalReportViewer | rptvew |
DropDownList | ddl |
DataGrid | dg |
DataList | dl |
Label | lbl |
LinkButton | lnkbtn |
ListBox | lst |
Panel | pnl |
RadioButton | rdo |
RangeValidator | rv |
RadioButtonList | rdolt |
RequiredFieldValidator | rfv |
RegularExpressionValidator | rev |
Image | img |
ImageButton | imgbtn |
ValidatorSummary | vs |
TextBox | txt |
Table | tbl |
第六章 语句
6.1 每行一个语句
每行最多包含一个语句。如:
a++; // 推荐
b--; // 推荐
a++; b--; // 不推荐
6.2 复合语句
复合语句是指包含”父语句{子语句;子语句;}”的语句,使用复合语句应遵循以下几点
- 子语句要缩进。
- 左花括号“{” 在复合语句父语句的下一行并与之对齐,单独成行。
- 即使只有一条子语句要不要省略花括号“ {}”。 如:
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;
}
注意
- 在循环过程中不要修改循环计数器。
- 对每个空循环体给出确认性注释。
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;
}
注意:
- 语句switch中的每个case各占一行。
- 为所有switch语句提供default分支。
- 所有的非空 case 语句必须用 break; 语句结束。
6.9 try - catch 语句
try - catch语句使用格式
try
{
statements;
}
catch (ExceptionClass e)
{
statements;
}
finally
{
statements;
}
6.10 using 块语句
using 块语句使用格式
using (object)
{
statements;
}
第八章 代码分析
使用Visual Studio自身的代码分析功能,检查内容如下表,分为
- 安全规则。
- 互操作性规则
- 可维护性规则
- 可以只性规则
- 命名规则
- 全球化规则
- 设计规则
- 性能规则
- 移动性规则
- 用法规则
其中“是否检查”一项中为“√”的内容不能违反。需在Visual Studio中设置为错误
8.1.安全性规则
标识 | 详细信息 | 是否检查 |
---|---|---|
CA2100 | 检查Sql查询中是否有安全漏洞 | √ |
CA2104 | 检查Sql查询中是否有安全漏洞 | √ |
CA2105 | 数组字段不应为只读 | √ |
CA2121 | 静态构造函数应为私有 | √ |
8.2.可靠性规则
标识 | 详细信息 | 是否检查 |
---|---|---|
CA2000 | 超出范围前释放对象 | √ |
8.3.可维护性规则
标识 | 详细信息 | 是否检查 |
---|---|---|
CA1500 | 变量名不应与字段名相同 | √ |
CA1501 | 避免过度继承 | √ |
CA1502 | 避免过度复杂 | √ |
8.4.命名规则
标识 | 详细信息 | 是否检查 |
---|---|---|
CA1700 | 不要将枚举值命名为“Reserved” | √ |
CA1705 | 较长的首字母缩略词应采用Pascal大小写格式。 | √ |
CA1706 | 较短的首字母缩略词应全部大写 | √ |
CA1707 | 标识符不应包含下划线 | √ |
CA1709 | 标识符的大小写应该正确 | √ |
CA1710 | 标识符应具有正确的后缀 | √ |
CA1711 | 标识符应采用正确的后缀 | √ |
CA1712 | 不要将类型名用作枚举值的前缀 | √ |
CA1713 | 事件不应具有 before 或 after 前缀 | √ |
CA1715 | 标识符应具有正确的前缀 | √ |
CA1716 | 标识符不应与关键字冲突 | √ |
CA1718 | 避免在参数中使用特定于语言的类型名 | √ |
CA1719 | 参数名不应与成员名冲突 | √ |
CA1720 | 标识符不应包含类型名 | √ |
CA1721 | 属性名不应与 get 方法冲突 | √ |
CA1722 | 标识符应采用正确的前缀 | √ |
CA1724 | 类型名不应与命名空间冲突 | √ |
CA1725 | 参数名应与基方法中的声明保持一致 | √ |
8.5.性能规则
标识 | 详细信息 | 是否检查 |
---|---|---|
CA1800 | 避免进行不必要的强制转换 | √ |
CA1804 | 移除未使用的局部变量 | √ |
CA1805 | 避免进行不必要的初始化 | √ |
CA1809 | 避免过多的局部变量 | √ |
CA1812 | 避免未实例化的内部类 | √ |
CA1813 | 避免未密封的属性 | √ |
CA1819 | 属性不应返回数组 | √ |
CA1823 | 避免未使用的私有字段 | √ |
8.6.用法规则
标识 | 详细信息 | 是否检查 |
---|---|---|
CA1801 | 检查未使用的参数 | √ |
CA2202 | 不要多次释放对象 | √ |
CA2211 | 非常数字段不应该是可见的 | √ |
CA2218 | 重写 Equals 时重写 GetHashCode | √ |
CA2219 | 不要在异常子句中引发异常 | √ |
CA2222 | 不要降低继承成员的可见性 | √ |
CA2230 | 对个数可变的参数使用 params | √ |
CA2233 | 运算不应溢出 | √ |