C#代码规范-编程秘笈

原文地址:https://www.cnblogs.com/zzp0320/p/6949973.html

1、引言

本文是一套面向C# programmer和C# developer进行开发所应遵循的开发规范

按照此规范来开发C#程序可带来以下益处:

代码的编写保持一致性,提高代码的可读性和可维护性,在团队开发一个项目的情况下,程序员之间可代码共享,易于代码的回顾

本规范是初版,只适用于一般情况的通用规范,并不能覆盖所有的情况

2、文件组织

2.1C#源文件

类名或文件名要简短,不要超过2000LOC,将代码分割开,使结构清晰。将每个类放在一个单独的文件中,使用类名来命名文件名(当然扩展名是.cs),这种约定会使大家工作更简单

2.2目录设计

为每一个命名空间创建一个目录。(用MyProject/TestSuite/TestTier作为MyProject.TestSuite.TestTier的路径,而不用带点的命名空间名做路径)这样可以更容易地将命名空间映射到目录

层次划分。

3、缩进

3.1换行

当一个表达式超过一行时,根据这些通用原则进行处理:

在逗号后换行,在操作符后换行,在高层换行而不要在低层处换行,折行后对齐上一行语句同一层的表达式起始位置。

方法调用换行示例:

longMethodCall(expr1,expr2,expr3,expr4,expr5);

算术表达式换行示例:

推荐:

var = a * b / (c - g + f) +

4 * z;

不好的格式——应避免:

var = a * b / (c - g +

f) + 4 * z;

推荐使用第一种方法,因为是在括号表达式之外折行(高层次折行原则)。注意要用制表符到缩进的位置,然后用用空格到折行的位置。在我们的例子中是:

> var = a * b / (c - g + f) +

> ......4 * z;

‘>‘表示是制表符,‘.‘表示是空格符。(制表符后是空白是用制表符缩进)。一个好的编码习惯就是在所用的编辑器中显示制表符和空格符。

3.2 空白

利用空格进行缩进从未有过统一的标准。一些人喜欢用两个空格,一些人喜欢用四个空格而还有一些人喜欢用八个空格,甚至有的人喜欢用更多的空格。好的做法是用制表符。制表符有一些优点:

·         每个人都可以设置他们自己喜欢的缩进层级。

·         它仅仅是1个字符而不是2,4,8等等,因此它将减少输入(甚至因为自动缩进,有时你不得不手工设置缩进或取消设置,等等诸如此类的操作)。

·         如果你想增加或减少缩进,可以标记一块,使用Tab增加缩进层级而用Shift-Tab减少缩进层级。这几乎对于任何文本编辑器都是适用的。

这里,我们定义制表符为标准缩进符。

不要用空格缩进—用制表符!

4、注释

4.1块注释

块注释通常应该是被避免的 。推荐使用///注释作为C#的标准声明。如果希望用块注释时你应该用以下风格:

/*Line1

*Line2

*Line3

*/

因为这样可以为读者将注释块与代码块区分开。虽然并不提倡使用C风格的单行注释,但你仍然可以使用。一旦用这种方式,那么在注释行后应有断行,因为很难看清在同一行中前面有注释的代码

/*blah blah blah */

块注释在极少情况下是有用的。通常块注释用于注释掉大的代码段

4.2单行注释

你应该用//注释风格"注释掉”代码(快捷键,Alt+/),它也可以被用于代码的注释部分

单行注释被用于代码说明时必须缩进到相应的编进层级。注释掉的代码应该放在第一行被注释掉以使注释掉的代码更容易看清

一条经验,注释的长度不应该超过被解释代码的长度太长,因为这表示代码过于复杂,有潜在的bug

4.3文件注释

在.net框架,Microsoft已经介绍了一个基于XML注释的文件。这些文件是包括XML标签的正规的单行的C#注释。他们遵循单行注释的模式:

///<summary>

///This class

///</summary>

多行XML注释遵循这种模式:

///<exception cref="BogusException">

///This exception gets thrown as soon as a

///</exception>

为了被认作是XML注释行,所有的行都必须用三个反斜线开始。标签有以下两类:

文件说明项   格式/参考

第一类包括像<summary><param>or<exception> 的标签。描述一个程序的API元素的这些文档说明项必须写清楚以方便其他程序员。如上面的多行注释示例所示,这些标签通常带有名

称或cref属性。编译器会检查这些属性,所以它们必须是有效正确的。第二类用诸如<code>,<list>or<para>标签,用于控制备注说明的布局。文件可以用‘文件’菜单中的“创建”菜单产生。文件

以html格式产生:

5、声明

5.1每行的声明数

推荐每行只有一个声明,因为它可以方便注释

int level;//indentation level

int size;//size of table

当声明变量时,不要把多个变量或不同类型的变量放在同一行,例如:

int a, b; //What is ‘a‘? What does ‘b‘ stand for?

上面的例子也显示了变量名不明显的缺陷。当命名变量时要清晰。

5.2 初始化

局部变量一旦被声明就要初始化。例如:

string name = myObject.Name;

int val = time.Hours;

注意:如果你初始化一个dialog,设计使用using语句:

using (OpenFileDialog openFileDialog = new OpenFileDialog()) {

...

}

5.3 类和接口声明

当编写C#类和接口时,应遵循以下格式化规则:

·         在方法名和圆括号“(”开始它的参数列表之间不要使用空格。

·         在声明语句的下一行以大括号"{"标志开始。

·         以"}"结束,通过它自身的缩进与相应的开始标志匹配。

例如:

Class MySample : MyClass, IMyInterface

{

int myInt;

public MySample(int myInt)

{

this.myInt = myInt ;

}

void Inc()

{

++myInt;

}

void EmptyMethod()

{

}

}

对于一个大括号的位置参考10.1部分。

6. 语句

6.1 简单语句

每行都应该只包含一条语句。

6.2 返回语句

一个返回语句不要用最外围圆括号。不用:

return (n * (n + 1) / 2);

用: return n * (n + 1) / 2;

6.3 If, if-else, if else-if else 语句

if, if-else and if else-if else 语句看起来应该像这样:

if (condition) {

DoSomething();

...

}

if (condition) {

DoSomething();

...

} else {

DoSomethingOther();

...

}

if (condition) {

DoSomething();

...

} else if (condition) {

DoSomethingOther();

...

} else {

DoSomethingOtherAgain();

...

}

6.4 for / foreach 语句

一个for语句应该如下形式:

for (int i = 0; i < 5; ++i) {

...

}

或者放置一行(考虑用一个while语句代替)

for (initialization; condition; update) ;

foreach语句应该像下面所示 :

foreach (int i in IntList) {

...

}

注意:在一个循环中,即使只有一个语句通常也用括弧括起来。

6.5 While/do-while 语句

一个while语句应该写成如下形式:

while (condition) {

...

}

一个空while语句应该是以下格式:

while (condition) ;

一个do-while语句应该是如下格式:

do

{

...

} while (condition);

6.6 Switch 语句

一个switch语句应该如下格式:

switch (condition) {

case A:

...

break;

case B:

...

break;

default:

...

break;

}

6.7 Try-catch 语句

一个try-catch statement语句应该遵循以下格式:

try {

...

} catch (Exception) {}

or

try {

...

} catch (Exception e) {

...

}

or

try {

...

} catch (Exception e) {

...

} finally {

...

}

7. 空白

7.1 空行

空行提高可读性。它们分开那些逻辑上自身相关联的代码块。两行空格行应该用于以下之间:

·         一个源文件的逻辑段。

·         类和接口定义(每个文件只定义一个类或接口以避免这种情况)。

一个空格行应该总是被用于以下之间:

·         方法

·         属性

·         一个方法中的局部变量和它的第一条语句

·         一个方法中的逻辑段为了提高可读性。注意空白行必须被缩进因为它们包括一条语句这使得插入这些行更容易。

7.2 内部空格

在一个逗号或一个分号之后应该由一个空格,例如:

TestMethod(a, b, c); 不要用: TestMethod(a,b,c)

TestMethod( a, b, c );

单个空格包围操作符(除了像加的一元操作符和逻辑非),例:

a = b; // don‘t use a=b;

for (int i = 0; i < 10; ++i) // don‘t use for (int i=0; i<10; ++i)

// or

// for(int i=0;i<10;++i)

7.3 表格格式化

行的一个逻辑块应该作为一个表格被格式化:

string name = "Mr. Ed";

int myValue = 5;

Test aTest = Test.TestYou;

对于表格的格式化用空格而不用制表符因为在某些制表符缩进设置会使表格格式化看起来是很奇怪。

8. 命名习惯

8.1 大写格式

8.1.1 Pascal Casing

习惯大写每个单词的第一个字母(就像在TestCounter)。

8.1.2 Camel Casing

习惯除了第一个单词外大写每个单词的第一个字母例如testCounter。

8.1.3 全大写情况

对于只有一两个字符缩写组成的标识符才用全大写的情况。有三个或更多个字符组成的标识符应该用Pascal情况代替。例如:

public class Math

{

public const PI = ...

public const E = ...

public const feigenBaumNumber = ...

}

8.2. 命名指导方针

通常根据指导方针在名字和命名内用低线字符对Hungarian 符号来说被认为是坏习惯。

Hungarian 符号是一组应用于命名来映射变量类型的前缀和后缀。这种命名风格在早期的Windows程序中被广泛应用,但现在被取消了至少不提倡了。如果你遵循这个指南用Hungarian 符号是不允许的。

但要记住一个好的变量名描述了语义而不失类型。

对于这个规则有个例外就是GUI编码。包括像按钮(buttton)的GUI元素,所有领域和变量名都应该带有它们类型名的后缀不是缩写。例如:

System.Windows.Forms.Button cancelButton;

System.Windows.Forms.TextBox nameTextBox;

8.2.1 类命名指导方针

·         类命名必须是名词或名词短语。

·         UsePascal 情况参考8.1.1

·         不要用任何类前缀

8.2.2 接口命名指导方针Guidelines

·         用可以描述行为的名词或名词短语或形容词命名接口。(例如IComponent 或 IEnumberable)

·         用Pascal情况(参考8.1.1)

·         用I作为名字的前缀,它应该紧跟一个大写字母(接口名的第一个字母)

8.2.3 枚举命名指导方针

·         用Pascal情况命名枚举值名字和类型名字

·         枚举类型和枚举值不要前缀

·         对于枚举用单一名字

·         对于位领域用复数名字

8.2.4 只读和常量命名

·         用名词,名词短语或名词的缩写命名静态领域

·         使用Pascal 情况(参考8.1.1)

8.2.5 参数/非常量领域命名

·         一定要用描述性名字,应该能够足够表现变量的意义和它的类型。但一个好的名字应该基于参数的意义。

·         使用Camel情况(参考8.1.2)

8.2.6 变量命名

·         计数变量当用在琐碎的计数循环式更适宜叫i, j, k, l, m, n。(参考10.2例如对全局计数的更智能命名等等)—

·         使用Camel情况(参考8.1.2)

8.2.7 方法命名

·         用动词或动词短语命名方法。

·         使用Pascal(参考8.1.2)

8.2.8 属性命名

·         用名词或名词短语命名属性

·         使用Pascal 情况(参考8.1.2)

·         考虑用与其类型相同的名字命名一个属性

8.2.9 事件命名

·         用事件处理器后缀命名事件处理器

·         用sender 和 e命名两个参数

·         使用Pascal情况(参考8.1.1)

·         用EventArgs 后缀命名事件参数

·         用现在和过去时态命名有前缀和复制概念的事件名字。

·         考虑用一个动词命名事件。

8.2.10 大写总结


Type


Case


Notes


Class / Struct


Pascal Casing


Interface


Pascal Casing


Starts with I


Enum values


Pascal Casing


Enum type


Pascal Casing


Events


Pascal Casing


Exception class


Pascal Casing


End with Exception


public Fields


Pascal Casing


Methods


Pascal Casing


Namespace


Pascal Casing


Property


Pascal Casing


Protected/private Fields


Camel Casing


Parameters


Camel Casing

9. 编程习惯

9.1 可见性

不要任何公共实例或类变量,让它们为私有的。对于私有成员最好不用“private”作修饰语什么都不写。私有是默认情况,每个C#程序员都应该知道这一点。

用属性代替。你可以用公共静态(或常量)对于这个规则是以例外,带它不应该是规则。

9.2 没有“幻”数

不要用幻数,也就是在源代码中直接用常数值。替代这些后者以防变化(比方说,你的应用程序可以处理3540用户代替427你的代码在50行中通过分散25000LOC)是错误和没有收益的。声明一个带有数的常量来代替:

public class MyMath

{

public const double PI = 3.14159...

}

10. 编码举例

10.1 Brace placement example

namespace ShowMeTheBracket

{

public enum Test {

TestMe,

TestYou

}

public class TestMeClass

{

Test test;

public Test Test {

get {

return test;

}

set {

test = value;

}

}

void DoSomething()

{

if (test == Test.TestMe) {

//...stuff gets done

} else {

//...other stuff gets done

}

}

}

}

括弧应该在以下情况之后以新行开始:

·         命名空间声明(注意这在0.3版本中是新添的与0.2版本不同)

·         类/接口/结构声明

·         方法声明

10.2 变量命名举例

代替:

for (int i = 1; i < num; ++i) {

meetsCriteria[i] = true;

}

for (int i = 2; i < num / 2; ++i) {

int j = i + i;

while (j <= num) {

meetsCriteria[j] = false;

j += i;

}

}

for (int i = 0; i < num; ++i) {

if (meetsCriteria[i]) {

Console.WriteLine(i + " meets criteria");

}

}

try intelligent naming :

for (int primeCandidate = 1; primeCandidate < num; ++primeCandidate)

{

isPrime[primeCandidate] = true;

}

for (int factor = 2; factor < num / 2; ++factor) {

int factorableNumber = factor + factor;

while (factorableNumber <= num) {

isPrime[factorableNumber] = false;

factorableNumber += factor;

}

}

for (int primeCandidate = 0; primeCandidate < num; ++primeCandidate)

{

if (isPrime[primeCandidate]) {

Console.WriteLine(primeCandidate + " is prime.");

}

}

注意:索引变量通常叫i, j, k 等等。但Note: Indexer variables generally should be called i, j, k etc. But 万一像这样,使得重新考虑这个原则更有意义。一般来说,当同一个计数器或索引器被重用,给它们有意义的名字。

原文地址:https://www.cnblogs.com/boonya/p/9146584.html

时间: 2024-10-12 07:41:04

C#代码规范-编程秘笈的相关文章

我的高效编程秘笈

准确来说是2012年11月的时候开始学编程的,那个时候我上大二,到现在学习编程快三年了,期间大部分时间处于自学状态,今天就跟大家聊聊我的高效编程秘笈. 一.活学活用office 首先请大家看清楚标题,我说的是office,不是wps,这两个差异还是非常大的,特别是excel中的差异非常明显.如果你能够熟练掌握Word和Excel的使用,这对你的编程效率会有质的提高. 说说我自己身上的一个事吧. 前些天公司产品要升级2.0,手机上有个数据表要根据服务端返回的字段重新设计,我把服务端返回的数据打印出

标C编程笔记day08~day10代码规范、编译、库函数、命名空间、函数调用、哑元函数

代码编写规范,命令行编译,库函数简介,命名空间介绍,函数调用介绍,哑元函数介绍 一般来说,有.c实现文件,应该都要有.h头文件,.c文件中的所有函数都应该在.h文件中声明. 命令行编译方法: 1.gcc 后面带所有.c 文件 -o 输出文件名   直接生成可执行文件 2.依次gcc -c .c文件  -o ***.o  生成***.o文件 然后 gcc 所有.o文件 -o 输出文件   生成可执行文件 程序中的静态全局变量不可以被其他文件中的语句使用. .c文件使用.h文件中的全局变量:exte

nodejs 编程建议(代码规范)

1. 不要使用 "try ... catch" ,因为nodejs都是异步操作,try catch无法捕捉回调里面的异常,除非你在回调里面也写try catch try...catch statement cannot catch the error in callback. Here is an example: fs = require('fs'); try { fs.stat('doesnt_exist.txt', function(err, stats) { if (err)

嵌入式linux GUI--DirectFB + GTK至尊秘笈

1 前言 数年前,曾经开发过一个嵌入式的产品,如今市场依然存在,但由于电子产品的升级换代很快,许多元器件都采购不到了,为了延续产品的生命周期,计划在linux平台上开发新的版本.而在linux上的GUI上成了大问题,最开始有用Minigui的打算,也同飞漫公司联系过,但费用我这里无法承受.(Minigui作为国产优秀的嵌入式GUI,如果不是费用的问题,应该是最优的选择.) QT我也看了下,也是收费的,没有仔细研究.最开始我打算用MicroWindow的,但后来发现这个东西好久没有更新了,bug一

Clojure数据分析秘笈 笔记

Clojure数据分析秘笈 目录 1 导入分析数据 2 清洗和校验数据 3 使用并发编程管理复杂度 4 使用并行编程提高性能 5 Cascalog 6 使用Incanter数据集 7 使用Incanter准备并执行数据分析 8 使用Mathematica和R 9 聚类.分类和使用Weka 10 使用Incanter绘图 11 创建网页图表 导入分析数据 $ lein new getting-data 从CSV 从JSON 使用Incanter 从JDBC 从XML 利用zipper浏览XML结构

作业三: 代码规范、代码复审、PSP

(1) 是否需要有代码规范         1.这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西.(反对) 答:首先编码规范 包括了编码风格和其它规范 一个团队遵守一些规范有很多的好处! (1). 遵守编码风格使代码更容易维护 (2). 编码风格使形成代码集体所有制(集体所有制的作用很大,它能有效的增大巴士因子——一个项目能承受多少个程序员被车撞了而不影响项目的正常进行) (3). 编码风格能消除那些长久的纷争(你不需要喜欢这种编码风格.如果你不喜欢里面的某条规

代码规范

1.这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西 一个项目大多都是由一个团队来完成,如果没有统一的代码规范,那么每个人的代码必定会风格迥异.且不说会存在多个人同时开发同一模块的情况,即使是分工十分明晰的,等到要整合代码的时候也有够头疼的了.大多数情况下,并非程序中有复杂的算法或是复杂的逻辑,而是去读别人的代码实在是一件痛苦的事情.统一的风格使得代码可读性大大提高了,人们看到任何一段代码都会觉得异常熟悉. 2.我是个艺术家,手艺人,我有自己的规范和原则 每一个

作业三:代码规范

对于是否需要有代码规范,请考虑下列论点并反驳/支持: 1. 这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西. 对于以上观点我是反对的 .如果说这些规范都是官僚制度产生的,那么更应该一丝不苟的执行,官僚制度,往大了说是法,应该无条件执行,往小了说是规范,可以帮助我们规范在打代码时自身不好的习惯.也许在编辑代码时,会比随意敲打耽误些许时间,但在检查错误时,规矩的编排格式,可以一目了然的看到自己的错误,为自己节省了更多的时间,会提高开发效率. 2. 我是个艺术家,手

作业三 (一) :是否需要有代码规范

这个作业主要是讨论代码规范的,围绕以下几个问题讨论 1.这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西. 答:首先编码规范 包括了编码风格和其它规范 一个团队遵守一些规范有很多的好处! (1). 遵守编码风格使代码更容易维护 (2). 编码风格使形成代码集体所有制(集体所有制的作用很大,它能有效的增大巴士因子——一个项目能承受多少个程序员被车撞了而不影响项目的正常进行) (3). 编码风格能消除那些长久的纷争(你不需要喜欢这种编码风格.如果你不喜欢里面的某条规