95992828九五至尊2

编码规范,几条软件开发心得

二月 4th, 2019  |  882828九五至尊手机版

几条软件开发心得:

既往的文档,不过很科学整理出来发到博客上,还有越来越多的爱侣要求。
录 

1.向来使用源代码管理种类做版本控制,就算唯有一个开发人士。这么做你无法立即丢失整套源代码,既可以享受代码给其旁人,也能有控制代码历史记录的长处。

1. 简介
3

2.行使自动化工具来遵守编码标准。

2. 适用范围
3

3.万一你用一种艺术编码风格,保持同样的作风(定义变量,方法名等)。

3. 文体
3

4.代码量大并不代表是好的代码。保持它们不难,裁减复杂性。

4. 代码协会与风格
3

5.不用使用数字的字符串,而是利用常量。那样使得代码模块性,可读性更高。

4.1. Tab
3

6.不要诠释即将删除的代码,请直接删除它们。版本控制系统将协助你控制这几个删除的代码。

4.2. 缩进
4

7.去除项目中并未用的办法和类。

4.3. 空行
4

8.Catch实际的exception替代最高级其他’Exception’
类。那样有更好的特性,可读性。

4.4. 函数长度
4

9.施用不难掌握的名字命名长的变量。循环变量可以运用那样的命名类似 i, j,
k,
index。在早晚限制比例内,本地变量命名必须比循环变量长,参数命名必须比地点变量名长,静态变量名必须比参数变量名长。

4.5. {”,“}”
4

10.封装相关的class在一起(那多少个因变更关联的class或已经共同调用过的class),封装变化点儿,哪儿变化就封装哪里。

4.6. 行宽
4

11.编纂不难了然的笺注。难以知晓的笺注还不如不写。

4.7. 空格
4

12.运用方正的论断标准,它比否定判断标准简单了然。

5. 注释
5

13.用到依赖注入来治本几个实例。

5.1. 注脚的主导预约5

14.绝不使用exceptions 控制代码流程。

5.2. 注明类型
5

15.一个办法毫无有太多参数。最多8-10个,如需追加太多参数,须求再一次设计。

5.2.1. 块注释
5

16.永不使用bool标记方法,public void someMethod(bool
flag),重构多少个标志条件写八个章程

5.2.2. 行注释
5

17.艺术命名必须带有”做什么样用”的新闻,以追加代码可读性。

5.2.3. 追随注释
5

18.如果你要求加一个static方法,请多加思索,static方法难以管理。

5.3. 申明哪些部分
6

19.方法中尽量幸免使用ref参数,要是可能行使attributed对象参数代替它们。

5.4. 程序修改注释
7

20.接口措施尽量最小化以减掉偶合与依靠。

6. 命名
7

作者:Petter Liu
出处:http://www.cnblogs.com/wintersun/
正文版权归小编和乐乎共有,欢迎转发,但未经小编同意必须保留此段注明,且在篇章页面鲜明地点给出原文连接,否则保留追究法律权利的责任。
该小说也同时公布在自身的单身博客中-Petter Liu
Blog

6.1. 命名的中坚预约7

6.2. 各类标示符类型的命名约定
9

6.2.1. 程序集命名
9

6.2.2. 命名空间命名
9

6.2.3. 类和接口命名
9

6.2.4. 办法命名
9

6.2.5. 变量命名
10

6.3. 零件名称缩写列表
10

7. 声明
11

8. 表明式和语句
12

9. 档次设计规范
14

9.1. 连串和命名空间
14

9.2. 品类和接口的取舍
15

9.3. 抽象类设计:
15

9.4. 静态类设计
15

9.5. 枚举设计
16

10. 分子设计规范
17

10.1. 分子布署的一般标准
17

10.1.1. 措施的重载规范;
17

10.1.2. 性质和方法的挑选
19

10.2. 属性的设计规范:
19

10.3. 构造函数的设计规范
20

10.4. 字段设计规范
20

10.5. 参数的设计规范
21

10.5.1. 参数设计中枚举和布尔参数的挑选正式
21

10.5.2. 参数验证的科班:
22

10.5.3. 参数传递的正规化:
22

11. 扩充性设计规范
22

12. 十二分处理规范
23

12.1. 分外类型选用规范
23

12.2. 不行处理规范
23

12.3. 正经非常类的使用:
23

12.3.1. Exception与SystemException
23

12.3.2. InvalidOperationException
24

12.3.3.
ArgumentException,ArgumentNullException,ArgumentOutOfRangeException
24

12.3.4.
NullRefernceException,IndexOutOfRangeException,AccessViolationException
24

12.3.5. StackOverflowException:
24

12.3.6. OutOfMemoryException:
24

12.4. 自定义相当类型设计规则:
24

12.5. 分外与特性
24

13. 其他规定
24

14. 参考文档
25


 

1. 简介

本标准为一套编写高效可依赖的 C#
代码的正规、约定和指南。它以安全可靠的软件工程标准为根基,使代码易于明白、维护和增加,提升生产成效。同时,将带来更大的一致性,使软件开发团队的频率斐然增强。

2. 适用范围

本专业适用于公司有着的C#源代码,为详细计划,代码编写和代码审核提供参考和按照。

3. 文体

本专业中的指出分为七种:要,建议,避免,不要,表示必要根据的级别。文档中会以粗体表示。对于应按照的正规化,前边会以“Ö”来代表,对不佳的做法前边会以“´”来表示:

:描述必须比照的正统。例如:

Ö 异常类以“Exception”做为后缀;

建议:描述在一般景色下相应根据的正规化,但万一完全明了规范背后的道理,并有很好的理由不坚守它时,也不畏惧打破常规。例如:

Ö 强制类型转换时,在档次和变量之间建议加一空格。

不要:描述一些差不多绝对不要应该违反的正规化。例如:

´ 每个函数有效代码(不包罗注释和空行)长度不要超过50行。

避免:与建议相对,一般景观下相应依照,但有很好的说辞时也能够打破。例如:

´ 避免块内部的变量与它表面的变量名相同。

对部分正经内容一并提供了演示代码。

4. 代码社团与作风

4.1. Tab

Ö 使一个Tab为4个空格长。

4.2. 缩进

Ö 使一个代码块内的代码都合并缩进一个Tab长度。

4.3. 空行

Ö 建议适度的加码空行,来增加代码的可读性。

Ö 在在类,接口以及互相之间有两行空行:

Ö 在下列意况之间有一行空行:

措施之间;

有些变量和它前面的说话之间;

主意内的职能逻辑部分之间;

4.4. 函数尺寸

´ 每个函数有效代码(不包涵注释和空行)长度不要超过50行。

4.5. {”,“}”

Ö 开括号“{”放在块的主人的下一行,单起一行;

Ö 闭括号“}”单独放在代码块的终极一行,单起一行。

4.6. 行宽

´
每行代码和注释不要超越70个字符或显示器的肥瘦,如超越则应换行,换行后的代码应该缩进一个Tab。

4.7. 空格

´
括号和它里面的字符之间不要并发空格。括号应该和它前边的显要词留有空格,如:while
(true) {};

´ 然而方法名和左括号之间不要有空格。

Ö 参数之间的逗号后加一空格。如:method1(int i1, int i2)

Ö for语句里的表明式之间加一空格。如:for (expr1; expr2; expr3)

Ö 二元操作符和操作数之间用空格隔开。如:i + c;

Ö 强制类型转换时,在类型和变量之间加一空格。如:(int) i ;

5. 注释

5.1. 注脚的为主预约

Ö 注释应该扩张代码的清晰度;

Ö
保持注释的精简,不是任何代码都要求注释的,过多的注释反而会潜移默化代码的可读性。

´ 注释不要包含其余的特殊字符。

Ö 建议先写注释,后写代码,注释和代码一起完结

Ö
假设语句块(比如循环和规则分枝的代码块)代码太长,嵌套太多,则在其得了“}”加上注释,标志对应的发轫讲话。假诺分段条件逻辑比较复杂,也拉长注释。

Ö
在VS2005条件中通过计划工程编译时输出XML文档文件可以检查注释的共同体气象,假设注释不完整会报告编译警告;

5.2. 诠释类型

5.2.1. 块注释

Ö
首要用来描述文件,类,方法,算法等,放在所描述对象的先头。具体格式以IDE编辑器输入“///”自动生成的格式为准,其它再附加大家自定义的格式,如下所列:

/// <Remark>小编,创制日期,修改日期</ Remark >

对类和接口的注释必须抬高上述标记,对艺术可以视景况考虑

5.2.2. 行注释

Ö 主要用在点子内部,对代码,变量,流程等展开求证。整个注释占据一行。

5.2.3. 随行注释

Ö
与行注释作用相似,放在代码的同行,但是要与代码之间有丰盛的半空中,便于分清。例:

int m = 4 ; // 注释

Ö 假若一个程序块内有八个尾随注释,每个注释的缩进保持一致。

5.3. 诠释哪些部分

项目

注释哪些部分

参数 

参数用来做什么

任何约束或前提条件

字段/属性

字段描述

类的目的

已知的问题

类的开发/维护历史

接口

目的

它应如何被使用以及如何不被使用

局部变量

用处/目的

成员函数注释

成员函数做什么以及它为什么做这个

哪些参数必须传递给一个成员函数

成员函数返回什么

已知的问题

任何由某个成员函数抛出的异常

成员函数是如何改变对象的

包含任何修改代码的历史

如何在适当情况下调用成员函数的例子适用的前提条件和后置条件

成员函数内部注释

控制结构

代码做了些什么以及为什么这样做

局部变量

难或复杂的代码

处理顺序

5.4. 先后修改注释

Ö
新增代码行的内外有注释行表明,对具体格式不作需求,但不可能不带有作者,新增时间,新增目标。在疯长代码的结尾必须抬高得了标志;

Ö
删除代码行的内外用注释行表达,删除代码用注释原有代码的法门。注释方法和情节同新增;删除的代码行建议用#region
XXX #endregion 代码段折叠,保持代码文件到底清洁

Ö
修改代码行建议以删除代码行后再新增代码行的办法进行(针对旁人的代码进行修改时,必须标明,对于团结的代码举行改动时,酌情进行)。注释方法和内容同新增;

6. 命名

6.1. 命名的焦点预约

Ö
选用可以规范表明变量/字段/类的完全的英文描述符,如firstName。对一部分作用不问可知的变量可以动用简便易行的命名,如在循环里的递增(减)变量就足以被取名为
” i ”。

Ö 尽心尽力选择项目所提到领域的术语。

Ö
接纳高低写混合,提升名字的可读性。为不相同一个标识符中的多少个单词,把标识符中的每个单词的首字母大写。不行使下划线作分隔字符的写法。有三种适合的书写方式,适应于差别门类的标识符:

PasalCasing:标识符的首个单词的假名大写;

camelCasing:标识符的首个单词的字母小写。

下表描述了不一致序列标识符的大大小小写规则:

标识符

大小写

示例

命名空间

Pascal

namespace Com.Techstar.ProductionCenter

类型

Pascal

public class DevsList

接口

Pascal

public interface ITableModel

方法

Pascal

public void UpdateData()

属性

Pascal

Public int Length{…}

事件

Pascal

public event EventHandler Changed;

私有字段

Camel

private string fieldName;

非私有字段

Pascal

public string FieldName;

枚举值

Pascal

FileMode{Append}

参数

Camel

public void UpdateData(string fieldName)

局部变量

Camel

string fieldName;

´
避免接纳缩写,若是一定要运用,就谨慎采纳。同时,应该保留一个专业缩写的列表,并且在行使时保持一致。

Ö
对普遍缩略词,三个假名的缩写运用统一大小写的不二法门(示例:ioStream,getIOStream);多字母缩写拔取首字母大写,其余字母小写的方法(示例:getHtmlTag);

´ 避免利用长名字(最好不超越 15 个假名)。

´ 避免行使相似或者仅在大小写上有区其他名字。

6.2. 种种标示符类型的命名约定

6.2.1. 先后集命名

Ö 集团域名(Techstar)+ 项目名称 + 模块名称(可选),例如:

骨干系统程序集:Techstar.ProductionCenter;

宗旨系统工作逻辑程序集:Techstar. ProductionCenter.Business;

6.2.2. 命名空间命名

Ö 拔取和次序集命名相同的主意:公司域名(Techstar)+ 项目名称 +
模块名称。 其它,一般景观下提议命名空间和目录结构同样。例如:

骨干系统:Techstar.ProductionCenter;

着力系统下的用户控件:Techstar.ProductionCenter.UserControl;

主干系统工作逻辑:Techstar. ProductionCenter.Business;

骨干系统数据访问:Techstar. ProductionCenter.Data;

6.2.3. 类和接口命名

Ö 类的名字用名词;

´ 防止选择单词的缩写,除非它的缩写已经妇孺皆知,如HTTP。

Ö
接口的名字以字母I开首。保险对接口的专业兑现名字只相差一个“I”前缀,例如对IComponent的正儿八经兑现为Component;

Ö 泛型类型参数的命名:命名为T或者以T开首的描述性名字,例如:

public class List<T>

public class MyClass<TSession>

´
对同样类型的例外命名空间中的类,命名避免双重。幸免引用时的龃龉和模糊;

6.2.4. 方法命名

Ö 第三个单词一般是动词

Ö 假如措施重临一个分子变量的值,方法名一般为Get+成员变量名,假若重返的值
是bool变量,一般以Is作为前缀。别的,倘使必要,考虑用属性来顶替形式,具
体指出见10.1.2节;

Ö 如果措施修改一个分子变量的值,方法名一般为:Set +
成员变量名。同上,考虑 用属性来代替方式;

6.2.5. 变量命名

Ö
依照使用范围来分,大家代码中的变量的大多有以下三种档次,类的公有变量;类的私家变量(受保险同国有);方法的参数变量;方法内部选用的有些变量。这么些变量的命名规则基本相同,见标识符大小写对照表。分裂如下:

i. 类的国有变量按一般的艺术命名,无特殊要求;

ii. 类的个人变量选择三种办法均可:选取加“m”前缀,例如mWorkerName;

iii. 方法的参数变量选择camalString,例如workerName;

iv. 方法内部的一些变量采取camalString,例如workerName;

´ 不要用_或&作为第四个字母;

Ö 尽量选拔短而且具有意义的单词;

Ö
单字符的变量名一般只用于生命期格外短暂的变量。i,j,k,m,n一般用来integer;c,d,e
一般用来characters;s用于string

Ö
如若变量是集结,则变量名用复数。例如表格的行数,命名应为:RowsCount;

Ö 命名组件选拔匈牙利(Hungary)命名法,所有前缀均应遵守同一个零部件名称缩写列表

6.3. 组件名称缩写列表

缩写的主导规则是取组件类名各单词的第三个字母,若是唯有一个单词,则去掉其中的元音,留下辅音。缩写全部为小写。

组件类型

缩写

例子

Label

Lbl

lblNote

TextBox

Txt

txtName

Button

Btn

btnOK

ImageButton

Ib

ibOK

LinkButton

Lb

lbJump

HyperLink

Hl

hlJump

DropDownList

Ddl

ddlList

CheckBox

Cb

cbChoice

CheckBoxList

Cbl

cblGroup

RadioButton

Rb

rbChoice

RadioButtonList

Rbl

rblGroup

Image

Img

imgBeauty

Panel

Pnl

pnlTree

TreeView

Tv

tvUnit

WebComTable

Wct

wctBasic

ImageDateTimeInput

Dti

dtiStart

ComboBox

Cb

cbList

MyImageButton

Mib

mibOK

WebComm.TreeView

Tv

tvUnit

PageBar

Pb

pbMaster

7. 声明

Ö 每行唯有一个声称,倘若是注脚i,j,k之类的简易变量可以放在一行;

Ö
除了for循环外,声明放在块的开始河部分。for循环中的变量阐明可以放在for语句中。如:for(int
i = 0; I < 10; i++) 。

´ 避免块内部的变量与它外表的变量名相同。

8. 表达式和言语

Ö 每行提出唯有一条语句。

Ö if-else,if-elseif语句,任何动静下,都应有有“{”,“}”,格式如下:

if (condition)

{

statements;

}

else if (condition)

{

statements;

}

else

{

statements;

}

Ö for语句格式如下:

for (initialization; condition; update)

{

statements;

}

假设语句为空:

for (initialization; condition; update) ;

Ö while语句格式如下:

while (condition)

{

statements;

}

要是语句为空:

while (condition);

Ö do-while语句格式如下:

do

{

statements;

}

while (condition);

Ö switch语句,每个switch里都应涵盖default子语句,格式如下:

switch (condition)

{

case ABC:

statements;

/* falls through */

case DEF:

statements;

break;

case XYZ:

statements;

break;

default:

statements;

break;

}

Ö try-catch语句格式如下:

try

{

statements;

}

catch (ExceptionClass e)

{

statements;

}

finally

{

statements;

}

 

9. 品种设计规范

Ö
管教每个门类由一组定义明确,相互关联的分子构成,而不仅仅是有些毫不相干成效的随
机集合;

9.1. 品种和命名空间

Ö 用命名空间把项目组织成相关域的层次结构。例如:

界面层:Techstar.ProductionCenter;

业务逻辑层:Techstar.ProductionCenter.Business;

数量访问层:Techstar.ProductionCenter.Data;

´ 避免过深的命名空间;

´ 避免太多的命名空间;

9.2. 系列和接口的抉择

Ö 事先选择类而不是接口。

接口的短处在于语义变化时改变困难。注意接口并不是签订,把协定和落到实处分开并非一
定用接口落成,用基类和抽象类同样可以表明;

Ö 建议运用抽象类而不是接口来解除协定与已毕间的巧合;

Ö 概念接口,来兑现类似多重继承的效果;

细心定义接口的标志是一个接口只做一件事情。关键是接口的订立需求保持不变,
假如一个接口包涵太多效益,那么那几个胖接口爆发变化的火候就会大得多。

9.3. 抽象类设计:

´
不要在抽象类中定义公有的或内部受保证的构造函数。因为抽象类无法实例化,所以那种设计会误导用户;

Ö 为抽象类定义受保险的构造函数或内部构造函数;

9.4. 静态类设计

静态类是一个只包括静态成员的类,它提供了一种纯面向对象设计和简单性之间的一个权衡,广泛用来提供类似于全局变量或局地通用成效。

Ö 少用静态类。静态类应该仅看成支持类;

´ 避免把静态类当作杂物箱。每个静态类都应该有其驾驭目标;

Ö 不要在静态类中扬言或掩盖实例成员;

9.5. 枚举设计

Ö 用枚举来提升那多少个表示值的聚众的参数,属性以及重回值的类型性;

Ö 预先使用枚举而不是静态常量。例如:

//倒霉的写法

public static class Color

{

public static int Red = 0;

public static int Green = 1;

public static int Blue = 2;

}

//好的写法

public enum Color

{

Red,

Green,

Blue

}

´ 不要把枚举用于开放的场合,例如操作系统的版本,朋友的名字等;

´ 枚举最终一个值不要加逗号;

´ 枚举中不要提供为了未来应用而保留的枚举值;

10. 成员设计规范

方法,属性,事件,构造函数以及字段等统称为成员。

10.1. 成员布置的相似标准

10.2. 艺术的重载规范;

´
避免在重载中随心所欲的给参数命名。倘诺七个重载中的某个参数表示无异的输入,那么该参数的名字应该亦然。例如:

public class String

{

//好的写法

public int IndexOf(string value) { …}

public int IndexOf(string value, int startIndex) { …}

//不好的写法

public int IndexOf(string value) { …}

public int IndexOf(string str, int startIndex) { …}

}

´
避免使重载成员的参数顺序不平等。在装有的重载中,同名参数应该出现在一如既往的职分。
例如:

public class EventLog

{

public EventLog();

public EventLog(string logName);

public EventLog(string logName, string machineName);

public EventLog(string logName, string machineName, string source);

}

Ö
较短的重载应该只是调用较长的来兑现。其它,重载假若需求增添性,把最长重载
做成虚函数。例如:

public class String

{

public int IndexOf(string s)

{

//调用

return IndexOf(s, 0);

}

public int IndexOf(string s, int startIndex)

{

//调用

return IndexOf(s, startIndex, s.Length);

}

public virtual int IndexOf(string s, int startIndex, int Count)

{

//实际的代码

}

}

Ö
允许可选参选为null。那样做是为了防止调用者调用从前需求检讨参数是否null。例
如:

//允许为null时的调用

DrawGeometry(brush, pen, geometry);

//不允许为null时的调用

if (geometry == null) DrawGeometry(brush, pen);

else DrawGeometry(brush, pen, geometry);

10.3. 特性和格局的选料

Ö
基本条件是艺术表示操作,属性表示数据。即使其它各省点都相同,优先利用性质而不
是方法。

Ö 应用品质,即使该成员代表项目标逻辑attribue

Ö
如果属性的值存储在内存中,而提供属性的目标只有是为了访问该值,拔取品质而不
要使用方式

Ö 若是该操作每一回回去的结果差别,那么运用方法。例释迦牟尼自于.net
framework的例子:

//好的写法

Guid.NewGuid();

//倒霉的写法

DateTime.Now;

Ö 借使该操作比访问字段慢一个或七个数据级,行使方法。

Ö 假使该操作有生死攸关的副功用,应用办法。

10.4. 属性的设计规范:

Ö 假如不该让调用方法改变属性值,创设只读属性;

´ 不要提供只写属性;

Ö
为具有的特性提供合理合法的默许值,那样可以有限支撑默许值不会招致漏洞或功效低的代
码;

Ö 允许用户以别的顺序来设置属性的值;

Ö 避免在性质的获得方式抛出非凡。

性能的拿走格局应该是个简单的操作,不该有其他的准绳。要是一个获得方法会抛出
万分,按么可能它更应有设计为格局。

10.5. 构造函数的设计规范

Ö
建议提供不难的构造函数,最好是默许构造函数。简单的构造函数增强易用性;

Ö
考虑扩张性,假若构造函数设计的不自然,建议用静态的工厂方法来顶替构造函数;

Ö
把构造函数的参数作为设置首要品质的方便格局。借使构造函数参数仅用来安装属
性,应和品质名称一致。仅有大小写的界别;

Ö 在构造函数中做最少的干活。任何此外处理相应推迟到需求的时候;

Ö 在类中突显的宣示公用的默许构造函数,假诺这么的构造函数是必须的。

如若没有出示默许构造函数,填加有参数构造函数时屡屡会毁掉已有使用默许构造函数
的代码;

´
避免在目的的构造函数内部调用虚成员。那样在壮大设计的时候会招致难以了然的现
象;

10.6. 字段设计规范

´ 不要提供公有的或受有限支撑的字段。代之以属性来访问字段;

Ö
只用常量字段来代表永远不会改变的量。否则会促成兼容性难题。上面是不错的例子:

public struct Int32

{

public const int MaxValue = 0x7fffffff;

public const int MinValue = unchecked((int)0x80000000);

}

Ö 用公有的静态只读字段来定义预约义的目的实例。例如:

public struct Color

{

public static readonly Color Red = new Color(0x0000FF);

}

10.7. 参数的设计规范

Ö
用类协会层次中最相近基类类型来作为参数的系列,同时要力保该项目可以提供成员
所需的作用。例如:

要设计一个集合遍历的格局,那么参数应该是IEnbumerable为参数,而不应该是IList,
这样方法具有更强的适应性。

´
不要使用保留参数。借使今日必要愈多的参数,那么可以增添重载成员。例如:

//不好的写法

public void Method(string reserved, SomeOption option);

//好的写法

public void Method(SomeOption option);

//以后填加

public void Method(SomeOption option, string path);

10.7.1. 参数设计中枚举和布尔参数的精选标准

Ö 用枚举。在代码阅读,书写中,枚举都比布尔的可读性好过多。例如:

//使用布尔型,阅读的时候不会自由领悟参数的含义

FileStream f = File.Open(“1.txt”, true, false);

//使用枚举型

FileStream f = File.Open(“1.txt”,CasingOptions.CaseSenstive,
FileMode.Open);

´
不要运用布尔参数,除非整套必将相对不必要四个以上的值。即便此时,接纳枚举
往往也足以提供更好的可读性,如上例。

Ö
考虑在构造函数中,对确实只有三种状态值的参数以及用于开端化布尔属性的参数使用
布尔类型;

10.7.2. 参数验证的正规:

Ö
讲明传给公有的,受有限帮忙的或显示成员的参数是还是不是合法。假若申明败北,应该抛出
System.ArgutmentException或其子类;

Ö
抛出System.ArgutmentNullException,假设传入的null,而该成员不帮衬null;

10.7.3. 参数传递的业内:

´ 避免应用输出参数或引用参数;

11. 扩充性设计规范

´ 假若没有适合理由,不要把类密封起来。那些理由不外乎:

A)类为静态类;

B)类的受保险成员保存了高度机密音信;

C)类继承了广大虚成员,逐个密封的代价太高,不如密封整个类;

D)不要在密封类中宣称敬爱成员或虚成员,因为无法掩盖其达成;

Ö
建议用有限协助成员用于高级定制。它提供了扩充性,同时也避免了公用接口过于复杂;

´ 不要应用虚成员,除非有合适的理由;

Ö 建议只有在相对必须的时候才用虚成员提供伸张性,并运用Template
Method格局;

Ö
预先使用受有限支撑的虚成员,而不是国有虚成员。公有成员通用调用受有限帮助的虚成员的形式来提供增添性;

12. 不胜处理标准

Ö
非常的挂念是只对不当使用分外处理:逻辑和编程错误,设置错误,被破坏的数码,资源耗尽,等等。平常的法则是系统在健康状态下以及无重载和硬件失效状态下,不应暴发其它卓殊。万分处理时可以使用适当的日志机制来报告相当,包含丰富暴发的时刻;

´ 一般景观下毫无采纳更加完毕来决定程序流程结构;

´ 接纳相当而不要用错误代码来告诉错误;

Ö
要由此抛出非凡的点子来告诉操作战败。如若成员不可能成功地成功它应该做的职务,那么应该抛出十分;

12.1. 不行类型拔取标准

Ö
预先考虑选拔System命名空间中已部分格外,而不是友善创设新的老大类型;

Ö 要利用最说的有道理,最具针对性的可怜。例如,对参数为空,应抛出
System.ArgutmentNullException,而不是System.ArgutmentException

12.2. 不行处理规范

´ 不是一切规定的意况,不要吞掉极度;

Ö 建议破获特定类型的百般,若是知道该越发在切实可行条件当中暴发的原由;

´ 不要破获不应有捕获的要命,经常应该允许很是沿着调用栈传递;

Ö 进行清理工作时用try-finally,幸免选拔try-catch;

Ö
在捕获并再一次抛出相当时使用空的throw语句,那是维系调用栈的最好格局

12.3. 正规万分类的拔取:

12.3.1. Exception与SystemException

´ 不要抛出那二种档次的那么些;

´ 避免抓获那三种相当,除非是在顶层的可怜处理器中;

12.3.2. InvalidOperationException

Ö 对象处于不科学状态时抛出;

12.3.3. ArgumentException,ArgumentNullException,ArgumentOutOfRangeException

Ö
若是传入的是无效参数,抛出参数至极,尽可能接纳位于继承层次末尾的项目;

Ö 在抛出尤其时设置ParaName属性;

12.3.4. NullRefernceException,IndexOutOfRangeException,AccessViolationException

´ 不要显示抛出或捕获;

12.3.5. StackOverflowException:

´ 不要来得抛出或捕获;

12.3.6. OutOfMemoryException:

´ 不要显示抛出或捕获;

12.4. 自定义至极类型设计规则:

´ 避免太深的接轨层次;

Ö 从已部分非常基类继承;

Ö 异常类以“Exception”做为后缀;

Ö 使十分可连串化,使其能跨应用程序域和长距离边界还是能正常使用;

Ö 把与安全性有关的新闻保存在个人的不得了景况中

12.5. 充裕与品质

Ö
假若在平日场景都会抛出分外,选用先效验合法性的点子来幸免抛出格外引起的性质
难点;

13. 其他规定

Ö
为幸免频仍变更代码,代码中只写相比较简单的和不会经常暴发变化的SQL,假诺SQL
日常暴发变化或是比较复杂,存到SysMisc中,比如统计用到的SQL;

Ö
在VS2005花费条件中,选拔代码分析工具来做自动化的代码分析,以确保代码质量,
具体的行使提出如下:

A)启用代码分析,并设置当风格不符合必要时为错误而不是告诫;

B)即便不是做代码审核,此开关应关闭。加上了那些选项的时候编译很慢;

C)详设的时候打开开关,检查详设是或不是合乎编程规范;

D)所有的选项都应当打开。以下内容须要单独设置:

编码

名称

大类

建议

使用等级

CA2209

程序集应声明最小安全性

用法规则

不建议使用

警告

CA1814

与多维数组相比,首选使用交错的数组

性能规则

使用,但降低等级

警告

CA1822

将成员标记为 static

性能规则

较繁锁,且影响代码质量

禁用

CA2210

程序集应具有有效的强名称

设计规则

影响Xcopy部署

禁用

CA1302

不要对区域设置特定的字符串进行硬编码

全球化规则

很繁琐,并且工具支持的不好。全球化规则全部禁用

禁用

CA2100

检查 Sql 查询中是否有安全漏洞

安全性规则

都采用参数化查询,有可能会参数过长;如果是内部参数,也不会有安全问题

警告

14. 参照文档

1,《.NET设计规范》,本标准很多内容都参照了那本书,书中对正规背后的背景和条件做了深深研商;

<逆水行舟,不进则退>

相关文章

Your Comments

近期评论

    功能


    网站地图xml地图