C 编码规范之命名空间

2024-05-03

C 编码规范之命名空间（共2篇）

篇1：C 编码规范之命名空间

C++编码规范之命名空间

C++编码规范之命名空间Namespaces在.cc文件中,提倡使用不具名的命名空间。使用具名命名空间时,其名称可基于项目或路径名称,不要使用using指示符。定义:命名空间将全局作用域细分为不同的,具名的作用域,可有效防止全局作用域的命名冲突。优点:命名空间提供了命名轴线.当然类也提供了命名轴线。缺点:命名空间具有迷惑性,因为它们和类一样提供了额外的命名轴线。在头文件中使用不具名的空间容易违背C++的唯一定义原则。1)不具名命名空间在.cc文件中,允许甚至提倡使用不具名命名空间,以避免运行时的命名冲突:namespace{//命名空间的内容无需缩进enum{UNUSED,EOF,ERROR};bool AtEof(){return pos_ == EOF;}}//namespace然而,与特定类关联的文件作用域声明在该类中被声明为类型,静态数据成员或静态成员函数,而不是不具名命名空间的成员。像上文展示的那样，不具名命名空间结束时用注释//namespace标识。注:不能在.h文件中使用不具名命名空间。2)具名命名空间命名空间将除文件包含,全局标识的声明/定义以及类的前置声明外的整个源文件封装起来,以同其他命名空间相区分。//.h文件namespace mynamespace{class MyClass{public:...void Foo();};}//namespace mynamespace//.cc文件namespace mynamespace{//函数定义都置于命名空间中void MyClass::Foo(){...} }//namespace mynamespace禁止污染命名空间using namespace foo;

篇2：C 编码规范之命名空间

C# 编码规范

指导规则和最佳实践 Version 1.0

董毅 2010/4/26

第一条编码的风格和细节要求

编码风格

至少在单一文件中缩进和风格要保持一致，同一行中内容不要太长，最好不要大于10个单词。不要随意地或者以容易混淆作用域嵌套关系的方式放置括号，要尽量遵循每个文件中已经使用的体例。

命名约定和规范

1.不要使用晦涩的名称，起名要简单易懂

a.避免使用单字母做变量名，比如：i 或者 t。应使用index或者temp进行替代 b.不要缩写单词，比如用num代替number 2.使用全大写字母表示宏，常量，如：LIKE_THIS 3.类，函数和枚举的名称的单词首字母大写，如：LikeThis public class SomeClass {

const int DefaultSize = 100;public void SomeMethod(){ } } 4.变量的首字母小写，其他单词首字母大写，如：likeThis void MyMethod(int someNumber){ int number;} 5.接口的第一个字母用I开头

interface IMyInterface {...} 6.私有成员变量以m_开头，剩余内容遵从首字母大写的规范

public class SomeClass { private int m_Number;} 7.属性类以Attribute做后缀，异常类以Exception做后缀

8.命名方法以【动词】-【目标】组成，比如：ShowDialog（）

9.拥有返回值的方法应该以返回值描述其方法名，比如：GetObjectState（）10.总是使用C#的预定义类型，而不是System命名空间中的别名，比如：

object 而不是

Object string 而不是

String int

而不是

Int32 11.对于基类，类型描述采用大写字母。当处理.NET中的类型时才保留后缀Type //正确

public class LinkedList { } //避免

public class LikedList { }

12.使用有意义的名字空间，比如项目名称或者公司名称 13.避免使用类的全称，而是使用using语句进行引用 14.避免在命名空间内使用using语句

15.将所有framework命名空间吗放在一起，后面放自定义或第三方的命名空间名

using System;using System.Collections;using System.ComponentModel;using System.Data;using MyCompany;using MyControls;

16.采用委托推断，不要显式实例化委托

delegate void SomeDelegate();public void SomeMethod(){ } SomeDelegate someDelegate = SomeMethod;

17.缩进至少在同一文件中要保持统一风格，注释缩进和其注释的代码在同一层次 18.所有注释要经过认真检查，不要有不明语义或者错别字 19.所有成员变量应该定义在前面，和属性或方法间空开一行

public class MyClass { int m_Number;string m_Name;

public void SomeMethod1(){ } public void SomeMethod2(){ } }

20.局部变量的定义尽可能靠近它的初次使用 21.文件名应该体现其包含的类

22.当使用partial类型且每部分分配一个文件时，以类名+逻辑部分的方式来命名文件

//MyClass.cs public partial class MyClass { } //MyClass.Designer.cs public partial class MyClass { } 23.做大括号总是放在新行中

24.匿名方法模仿普通方法布局，但是大括号要和委托声明对其

delegate void SomeDelegate(string someString);//正确

void InvokeMethod(){ SomeDelegate someDelegate = delegate(string name){ MessageBox.Show(name);};someDelegate(“Juval”);} //错误

void InvokeMethod(){ SomeDelegate someDelegate = delegate(string name){ MessageBox.Show(name);};someDelegate(“Juval”);}

25.没有参数的匿名方法使用空括号，仅当匿名方法被用于任何委托时才可以省略括号

delegate void SomeDelegate();//正确

SomeDelegate someDelegate1 = delegate(){ MessageBox.Show(“Hello”);};//错误

SomeDelegate someDelegate1 = delegate { MessageBox.Show(“Hello”);};

26.在使用Lambda表达式时，模仿一般的方法规范。

delegate void SomeDelegate(string someString);

SomeDelegate someDelegate =(name)=> { Trace.WriteLine(name);MessageBox.Show(name);};

27.当内联Lambda表达式仅包含一个简单的语句时，应避免多语句或者返回语句出现在大括号中。可以简单使用小括号表达：

delegate void SomeDelegate(string someString);

void MyMethod(SomeDelegate someDelegate){ }

//正确

MyMethod(name=>MessageBox.Show(name));

//错误

MyMethod((name)=>{Trace.WriteLine(name);MessageBox.Show(name);});注释

编写有用的注释，不要在注释中重复写代码语义。应该编写的是解释方法和原理的说明性注释。

函数

不要在一个函数中包含太多内容，函数的功能要简单，短小，使人更容易理解，也有利于防错。

第二条尽量在代码中不包含被警告的内容

高度重视警告：使用编译器的最高警告级别。构建尽量做到干净利落（没有警告）。理解所有的警告。通过修改代码而不是降低警告级别来排除警告。

即使程序一开始似乎能够正确运行，也还是要这样做。即使你能够肯定警告是良心的，仍然要这样做。因为良性警告的背后可能隐藏着未来指向真正危险的警告。

项目设置和项目结构

1．总是以4级警告建立项目

2．在发布版中将警告当作错误（注意这不是VS.NET的缺省设置）

3．永远不要抑制特定的编译警告

4．总是在应用程序的配置文件中显式地说明支持的运行时版本

5．避免显式的自定义版本改向和绑定到CLR程序集

6．不要在AssemblyInfo.cs中放任何逻辑。除了在AssemblyInfo.cs中，不要在任何文件中放程序集属性（应包括公司名称、描述、版权等）7．所有程序集应该使用相对路径引用 8．不允许在程序集中循环引用

9．努力对同一逻辑应用程序中（通常是一个解决方案）的所有程序集和客户端使用统一的版本号

10．将Visual Studio.NET应用配置文件命名为App.config，并将其包括在项目中 11．将Visual Studio.NET缺省的项目结构改为标准的布局，对项目文件夹和文件应用统一的结构 12．一个发布版本应该包含Debug标记

第三方头文件

无法修改的库头文件可能包含引起警告的构造。如果这样，可以用自己的包含原头文件的版本将此文件包装起来，并有选择的为该作用域关闭警告，然后在整个项目的其他地方包含此包装文件。

代码中尽量不包含未使用的函数，变量

经确认确实不需要使用的函数，变量（不包括为未来使用而设的占位符），可以进行删除处理。

不要遗漏return语句

PS:例外情况

有时候编译器可能会发出一些确实无意义的警告。这些警告要经过团队确认后尽量在局部进行屏蔽，但要做出明确的注释，说明为什么必须禁用。

第三条使用自动构建系统第四条使用版本控制系统

应确保每次提交的代码都可以构建成功。

第五条定期进行代码审查

互相阅读彼此的代码不但可以尽快提高自己的编码水平，也可以相互借鉴更好的方法。

第六条一个实体应该只有一个紧凑的职责

一次只解决一个问题：只给一个实体（变量、类、函数、名称空间、模块和库）赋予一个定义良好的职责。应该只选择目的单一的函数，小而且目的单一的类，和边界清晰的紧凑模块。

应该用较小的低层抽象构建更高层次的抽象，要避免将几个低层抽象集合成一个较大的低层次抽象聚合体。用几个简单的行为来实现一个复杂的行为，比反其道而行之更加容易。

第七条正确，简单和清晰第一

软件简单为美：正确优于速度，简单优于复杂，清晰优于机巧，安全优于不安全。

要避免使用程序设计语言中的冷僻特性。应该使用最简单的有效技术。不要使用不必要的操作符重载

构造函数的参数，应该使用命名变量，而不要使用临时变量

这能够避免可能的声明二义性，还经常能使代码的意图更加清晰，从而更容易维护，而且也更安全。

第八条编程中应该知道何时和如何考虑可伸缩性

当数据爆炸性增长时：不要进行不成熟的优化，如果能够证明优化必要而且非常重要，则应该集中精力改善算法的复杂性，而不是进行小型的优化，比如节省一个多余的加法运算。

为了避免未来可能遭遇到的数据处理容量上的瓶颈问题，应该预先做这些事情：

使用灵活的、动态分配的数据，不要使用固定大小的数组

那种“比现在所需要的最大数组还要大”的数组，在正确性和安全性方面都存在严重问题。只有在编译时大小固定不变的数组才是可接受的。

了解算法的实际复杂性

要留心那些不易发觉的陷阱，比如看似线性的算法实际上要调用其他线性操作，结果算法实际上是二次的。

优先使用线性算法或者尽可能快的算法尽可能避免劣于线性复杂性的算法

如果面对的是一个O（NlogN）或者O（N²）算法，就必须花费精力寻找替代方案，只有代码才不至于在数据量显著增长的情况下陷入深度激增的性能深潭。例如：建议使用范围成员函数（通常是线性的）而不是反复调用单元素替代函数，后者会很容易在一个线性的操作要调用另一个线性操作时变成二次复杂性。永远不要使用指数复杂性的算法，除非真的别无选择

在决定接受指数算法之前，必须尽力寻找替代方案，因为对于指数算法来说，即使是数据量的有限增加，也会使算法的性能急剧下降。

总而言之，要尽可能优先使用线性（或者更好的）算法，尽可能合理的避免使用比线性算法差的多项式算法。竭尽全力避免使用指数算法。

第九条不要进行不成熟的优化

我们将不成熟的优化定义为这样的行为：以性能为名，使设计或代码更加复杂，从而导致可读性更差，却没有经过验证的性能需求（比如实际的度量数据与目标的比较结果）作为正当理由，因此本质上对程序没有真正的好处。

因此，默认时，不要把注意力集中在如何使代码更快上；首先关注的应该是使代码尽可能的清晰和易读。

第十条不要进行不必要的劣化

所谓不成熟的劣化一词，指的就是编写如下这些没有必要的、可能比较低效的程序：

在可以用通过引用传递的时候，却定义了通过值传递的参数在使用前缀++操作符很合适的场合，却使用后缀版本在构造函数中使用赋值操作而不是初始化列表

第十一条尽量减少全局和共享数据

共享会导致冲突：避免共享数据，尤其是全局数据。共享数据会增加耦合度，从而降低可维护性，通常还会降低性能。

名字空间作用域中的对象、静态成员对象或者跨线程或跨进程共享的对象会减少多线程和多处理器环境中的并行性，往往是产生性能和可伸缩性瓶颈的源头。建议用通信方式（比如消息队列）代替数据共享。尽量降低类之间的耦合，尽量减少交互

第十二条隐藏信息

不要泄密：不要公开提供抽象的实体的内部信息。而应该公开抽象（至少是get/set抽象），而不是数据。

数据只是抽象、概念性状态的一种可能的具体化而已。如果将注意力集中在概念而不是其表示形式上，就能够提供富于提示性的接口，并按需要对实现进行调整。比如缓存还是实时地计算，又比如使用不同的表示方式，针对某种使用模式进行优化。

绝对不要将类的数据成员设为public，仅对最需要的类型标记为public，其他的标记为internal。它同样适用于更大的实体比如程序库。模块和程序库同样应该提供定义抽象和其中信息流的接口，从而使与调用代码的通信比采用数据共享方式更安全，耦合度更低。

第十三条尽量在编译和连接时检查错误，而不要等到运行时

运行时检查取决于控制流和数据的具体情况，这意味着很难知道检查是否彻底。相比而言，编译时检查与控制流和数据无关，一般情况下能够获得更高的可信度。

第十四条尽量合理的使用const常量

不变的值更易于理解、跟踪和分析，所以应该尽可能地使用常量代替变量，定义值的时候，应该把常量作为默认的选项：常量很安全，在编译时会对其进行检查。尽量不要强制转换常量的类型。

例如：

const int x = 0;public const double productWeight = 11.7;private const string productName = “Visual C#”;

第十五条避免使用语义不清的参数

要避免在代码中使用诸如42和3.14159这样的文字常量。它们本身没有提供任何说明，并且因为增加了检测的重复而使维护更加复杂。可以用符号名称和表达式替换它们，比如width*aspectRatio

名称能够增加信息，并提供单一的维护点，而程序中到处重复的原始数据是无名的，维护起来很麻烦。常量应该是枚举或者const值，有合适的作用域和名称。

重要的特定于领域的常量应该放在名字空间一级

第十六条尽可能局部的使用变量第十七条避免函数过长，避免嵌套过深

过长的函数和嵌套过深的代码块的出现，经常是因为没能赋予一个函数以一个紧凑的职责所致，这两种情况通常都能够通过更好的重构予以解决。每个函数都应该是顾其名而能思其义，易于理解的工作单元，要避免将多个小概念单元合并到一个长的函数体中的做法。

一些建议：

尽量紧凑：对一个函数只赋予一种职责

不要自我重复：优先使用命名函数，而不要让相似的代码片断反复出现优先使用&&：在可以使用&&条件判断的地方要避免使用连续嵌套的if 不要过分使用try 优先使用标准算法

不要根据类型标签（type tag）进行分支（switch）第十八条尽量减少定义性依赖，避免循环依赖

循环依赖是指两个模块直接或者间接地相互依赖。所谓模块就是一个紧凑的发布单元，而互相依赖的多个模块并不是真正的独立模块，而是紧紧胶着在一起的一个更大的模块，因此，循环依赖有碍于模块性，是大型项目的祸根。请避免循环依赖。

第十九条不要引用多余的资源文件第二十条尽量不要重载默认的操作符，至少应保证操作符的自然语义不被破坏第二十一条优先使用++和—的标准形式。优先调用前缀形式。第二十二条用小类代替巨类

小类更易于编写，更易于保证正确、测试和使用。小类更有可能适用于各种不同情况。应该用这种小类体现简单概念，不要用大杂烩式的类。

第二十三条要避免使用隐式转换

在做类型提供隐式转换之前，请三思而行，应该依赖的是显式转换。

隐式转换有两个主要的问题：

1.它们会在最意料不到的地方抛出异常

2.它们并不总是能与语言的其他元素有效地配合第二十四条将数据成员设为私有的，无行为的聚集

要避免将公用数据和非公用数据混合在一起，因为这几乎总是设计混乱的标志。信息隐藏是优秀软件工程的关键，应该将所有数据成员都设为私有的，这是类用来保持其不变式的最佳方式。

第二十五条不要允许异常跨越模块边界传播

最低限度，应用程序必须在以下位置有捕获所有异常的catch（…）兜底语句，其中大多数都直接适用于模块：

1.在main函数的附近：捕获并用日志记录任何将使程序不正常终止而其他地方又没有捕获的异常。

2.在从无法控制的代码中执行回调附近3.在现场边界的附近4.在模块接口边界的附近

5.在IO，数据库连接等高危操作附近

第二十六条如有可能，尽量用算法调用代替手工编写的循环

对非常简单的循环而言，手工编写的循环有可能是最简单也是最有效的解决方案。但是编写算法调用代替手工编写的循环，可以使表达力更强、维护性更好、更不易出错，而且同样高效。

第二十七条编码惯例

1．避免在一个文件中放多个类

2．一个文件应该只对一个命名空间提供类型，避免在同一文件中有多个命名空间 3．避免一个文件的长度超过500行（除了机器生成的代码）4．避免方法定义超过25行

5．避免超过5个参数的方法，使用结构传递多个参数 6．每行应该不超过80个字符，或者10个单词 7．不要手工编辑任何机器生成的代码

A.如果修改机器生成的代码，修改代码格式和风格以符合本编码标准 B.尽可能使用partial类以分解出需要维护的部分 8．避免对显而易见的内容作注释

A.代码应该是自解释的，由可读性强的变量和方法组成的好的代码应该不需要注释 B.参加第一条中的注释部分

9．仅对操作的前提、内在的算法等写文档 10．避免方法级的文档

A.对API文档采用大量的外部文档

B.方法级注释仅作为对其他开发人员的提示 11．决不要硬编码数值，声明一个常量是最好的选择 12．仅对本轮就是常量的值使用const修饰符，例如一周的天数 13．避免对只读变量使用const修饰符。在此情况下，采用readonly修饰符

public class MyClass { public const int DaysInWeek = 7;public readonly int Number;public MyClass(int someValue){ Number = someValue;} }

14．对任何假设采用assert。平均来讲，每五行代码中就有一行是断言

using System.Diagnostics;object GetObject(){} object someObject = GetObject();Debug.Assert(someObject!= null);

15． 16． 17．每行代码都应该经过白盒测试仅捕获已经显式处理了的异常

在抛出异常的catch语句中，总是抛出最初异常以保持最初错误的堆栈位置

catch(Exception exception){ MessageBox.Show(exception.Message);throw;}

18．定义自定义的异常时

A.从ApplicationException继承 B.提供自定义的序列化 19．避免采用friend程序集，因为这样增加了程序集间的耦合度 20．避免使用依赖于从特定位置运行的程序集的代码。21．尽量减少应用程序集（客户端EXE程序集）的代码，采用类库而不要包含业务逻辑层代码。22．避免对枚举提供明确的值

//正确

public enum Color { Red,Green,Blue } //错误

public enum Color { Red=1,Green=2,Blue=3 }

23．避免对枚举指定类型

//错误

public enum Color : long { Red, Green, Blue }

24． 25． 26． If语句总是使用括号，即使它只包含一句语句避免使用?:条件运算符避免使用（#if…#endif），应使用conditional方法代替

[Conditianal(“MySpecialCondition”] public void MyMethod(){}

27．避免在布尔条件语句中调用函数，赋值到局部变量并检查它们的值。

bool IsEverythingOK(){} //错误

if(IsEverythingOK()){} //正确

bool ok=IsEverythingOK();if(ok){}

28．29．总是使用从0开始的数组

总是使用一个for循环显式地初始化一个引用类型数组

public class MyClass {} const int ArraySize=100;MyClass[] array=new MyClass{ArraySize];for(int index=0;index

30． 31．不用提供public或protected成员变量，而是使用属性应尽量使用get/set的自动返回属性

//错误

class MyClass { int m_Number;

public int Number { get { return m_Number;} set { m_Number=value;} } } //正确

class MyClass { public int Number { get;set;} }

32． 33． 34． 35．避免使用new,应使用override替代

在一个密封的类里总是把public和protected方法标记为virtual 永远不要使用不安全的代码合理使用as操作符进行映射

Dog dog = new GermanShepherd();GermanSheperd shepherd = dog as GermanShepherd;if(shepherd!= null){} 36． 37．

{ 在使用一个委托前总是要先检查它是否为空（null）

不要提供公有成员变量，使用存取器（accessors）进行替代

public class MyPublisher MyDelegate m_SomeEvent;public event MyDelegate SomeEvent { add { m_SomeEvent += value;} remove { m_SomeEvent-= value;} } }

38．避免定义事件处理委托，使用EventHandler或者GenericEventHandler进行替代 39．使用EventsHelper安全的发布事件 40．总是优先使用接口，但要避免一个接口只包含一个成员，包含3-5个成员较为合适。上限为12。41．避免事件成为接口成员 42．提供明确定义的接口描述 43．不要假设一个接口是可以安全运作的，永远都要做好处理意外的准备

SomeType obj1;IMyInterface obj2;

obj2=obj1 as IMyInterface;if(obj2!= null){ obj2.Method1();} else { //处理可能出现的错误

}

44．不要将可能改变的，或用于数据库连接的，或者交付给最终客户使用的任何字符串进行硬编码，要使用资源文件定义他们 45．使用String.Empty代替””

//错误

string name = “";//正确

string name = String.Empty;

46． 47． 48．

定义长字符串的时候，应该使用StringBuilder，而不是string 永远不要使用goto语句，除非迫不得已

在switch代码块中总要包含一个default项，并且为其设置断言

int number = SomeMethod();switch(number){ case 1: Trace.WriteLine(”Case 1:“);break;case 2: Trace.WriteLine(”Case 2:“);break;default: Debug.Assert(false);break;}

49．不要使用this引用，除非某些特殊情况，比如从一个构造器中运行另外一个

//一个正确使用this的例子

public class MyClass { public MyClass(string message){} public MyClass():this(”Hello"){} }

50．不要使用base关键词。除非你想要解决一个子类成员和基类间的名称冲突，或者运行一个基类构造器

//一个正确使用base的例子

public class Dog { public Dog(string name){} virtual public void Bark(int howLong){} } public class GermanShepherd:Dog { public GermanShepherd(string name):base(name){} public override void Bark(int howLong){ base.Bark(howLong);} }

51．不要使用GC.AddMemortyPressure()，不要依赖HandleCollector。合理的使用Dispose()和Finalize()方法 52．一般情况下不要使用check来检查代码（防止性能损失），但是在可能的溢出区则使用check来保持代码的安全性。安全性的优先级永远高于性能。

int CalcPower(int number,int power){ int result=1;for(int count=1;count<=power;count++){ checked { result*=number;} } return result;}

53．在代码中要避免直接使用object数据类型（System.Object），可以使用约束或者as进行替代。

class SomeClass {} //错误

class MyClass { void SomeMethod(T t){ object temp=t;SomeClass obj=(SomeClass)temp;} } //正确

class MyClass where T: SomeClass { void SomeMethod(T t){ SomeClass obj =t;} }

54．{} 一般而言，不要在通用接口中定义约束。接口级别的约束经常会被强类型所覆盖

public class Customer //错误

public interface IList where T: Customer {} //正确

public interface ICustomerList:IList {} 第二十八条安全

1．总是对应用程序私有的组件，集合等使用强名，这样可以保证安全性

2．在应用程序配置文件中使用加密算法，进行安全保护

3．对不受控制的引用方法，要做适当的安全处理，如加入断言控制