C#编码规范及命名规范

第一篇：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． 对不受控制的引用方法，要做适当的安全处理，如加入断言控制

4． 不要使用SuppressUnmanagedCodeSecurity属性 5． 不要使用/unsafe来切换TlbImp.exe的默认行为。

6． 在服务器端要使用自定义的安全规则来扩展Microsoft的默认配置，以保证更高级别的安全性

7． 为防止引诱性攻击，应修改组件级别的运行权限，限制其可能的不安全行为

8． 在编写Windows程序时，在每个Main（）中都要使用相应的安全规则

第二篇：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;

第三篇：C# 注释规范

C# 注释（Comment）规范

注释规范包括：模块（类）注释规范、类的属性、方法注释规范、代码间注释

1.模块（类）注释规范

模块开始必须以以下形式书写模块注释：

///

///

2.类属性注释规范

在类的属性必须以以下格式编写属性注释：

///

3.方法注释规范

在类的方法声明前必须以以下格式编写注释

///

"><参数说明> /// ///<对方法返回值的说明，该说明必须明确说明返回的值代表什么含义> ///

4.代码间注释规范

代码间注释分为单行注释和多行注释：

单行注释： //<单行注释>

多行注释： /*多行注释1 多行注释2 多行注释3*/

代码中遇到语句块时必须添加注释（if,for,foreach,……）,添加的注释必须能够说明此语句块的作用和实现手段（所用算法等等）。

详细介绍见：

http://

第四篇：金融机构编码规范

金融机构编码规范

中国人民银行发布《金融机构编码规范》

日前，中国人民银行发布了《金融机构编码规范》(以下简称《规范》)，从宏观层面统一了我国金融机构分类标准，首次明确了我国金融机构涵盖范围，界定了各类金融机构具体组成，规范了金融机构统计编码方式与方法。《规范》是加强金融业管理，维护金融安全的基础，也是构建金融信息系统，促进金融信息共享的前提。《规范》的发布是提高我国金融业管理水平的必然要求，为宏观管理信息与微观统计数据、国民经济运行信息与金融运行信息之间搭建了协调、沟通的桥梁。

金融机构编码规范

1.范围

本规范规定了金融机构的编码对象、编码结构和表示形式，使每个编码对象获得一个唯一的代码，以适应金融机构信息系统

建设和数据交换的需求。

本规范适用于金融机构新建信息系统的开发、数据仓库的建

设，也可用于指导已有信息系统的升级改造。

2.规范性引用文件

下列文件中的条款通过本规范的引用而成为本规范的条款。

凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内

容）或修订版均不适用于本标准，然而，鼓励根据本规范达成协

议的各方研究是否可使用这些文件的最新版本。

GB/T 2260-2007中华人民共和国行政区划代码

GB/T 2659-2000世界各国和地区名称代码(eqv ISO

3166-1:1997)

3.术语和定义

下列术语和定义适用于本规范。

3.1 货币当局

代表国家制定并执行货币政策、金融运行规则，管理国家储

备，从事货币发行与管理，与国际货币基金组织交易及向其他存

款性公司提供信贷，以及承担其他相关职能的金融机构或政府部

门。

3.2 监管当局

对金融机构及其经营活动实施全面的、经常性的检查和督

促，实行领导、组织、协调和控制，行使实施监督管理职能的政

府机构或准政府机构。

3.3 银行

依法设立的吸收公众存款、发放贷款、办理结算等业务的企

业法人。

3.4 城市信用合作社

依照有关规定在城市市区内由城市居民、个体工商户和中小 企业法人出资设立的，主要为社员提供服务，具有独立企业法人 资格的合作金融组织。

3.5 农村信用合作社

经相关国家部门批准设立，由社员入股组成、实行社员民主 管理、主要为社员提供金融服务的农村合作金融机构。

3.6 农村合作银行

由辖内农民、农村工商户、企业法人和其它经济组织入股组 成的股份合作制社区性地方金融机构。

3.7 农村商业银行

由辖内农民、农村工商户、企业法人和其它经济组织共同发 起成立的股份制地方性金融机构。

3.8 村镇银行

经中国银行业监督管理委员会依据有关法律、法规批准，由 境内外金融机构、境内非金融机构企业法人、境内自然人出资，在农村地区设立的主要为当地农民、农业和农村经济发展提供金 融服务的金融机构。

3.9 农村资金互助社

经中国银行业监督管理机构批准，由乡（镇）、行政村农民

和农村小企业自愿入股组成，为社员提供存款、贷款、结算等业 务的社区互助性金融机构。

3.10 财务公司

以加强企业集团资金集中管理和提高企业集团资金使用效

率为目的，为企业集团成员单位提供财务管理服务的金融机构。

3.11 信托公司

依照《中华人民共和国公司法》和《信托公司管理办法》设 立的主要经营信托业务的金融机构。

3.12 金融资产管理公司

经国务院决定设立的，收购、管理和处置金融机构、公司及 其他企业（集团）不良资产，兼营金融租赁、投资银行等业务的 金融机构。

3.13 金融租赁公司

经中国银行业监督管理委员会批准，以经营融资租赁业务为 主的金融机构。

3.14 汽车金融公司

经中国银行业监督管理委员会批准设立的，为中国境内的汽 车购买者及销售者提供金融服务的金融机构。

3.15 贷款公司

经中国银行业监督管理委员会依据有关法律、法规批准，由 境内商业银行或农村合作银行在农村地区设立的专门为县域农 民、农业和农村经济发展提供贷款服务的金融机构。

3.16 货币经纪公司

经中国银行业监督管理委员会批准在中国境内设立的，通过 电子技术或其他手段，专门从事促进金融机构间资金融通和外汇 交易等经纪服务，并从中收取佣金的金融机构。

3.17 证券公司

依照《中华人民共和国公司法》规定设立的并经国务院证券 监督管理机构审查批准而成立的专门经营证券业务，具有独立法 人地位的金融机构。

3.18 证券投资基金管理公司

经中国证券监督管理委员会批准，在中华人民共和国境内设 立，从事证券投资基金管理业务的企业法人。

3.19 期货公司

依照《中华人民共和国公司法》和《期货交易管理条例》规 定设立的经营期货业务的金融机构。

3.20 投资咨询公司

经中国证券监督管理委员会批准设立，为证券、期货投资人 或者客户提供证券、期货投资分析、预测或者建议等直接或者间 接有偿咨询服务的金融机构。

3.21 财产保险公司

经中国保险监督管理委员会批准设立，依法登记注册，从事 经营财产损失保险、责任保险、信用保险、短期健康保险和意外 伤害保险等财产保险业务的保险公司。

3.22 人身保险公司

经中国保险监督管理委员会批准设立，依法登记注册，从事

意外伤害保险、健康保险、人寿保险等人身保险业务的保险公司。5

3.23 再保险公司

经中国保险监督管理机构批准设立，并依法登记注册的，专 门从事再保险业务、不直接向投保人签发保单的保险公司。

3.24 保险资产管理公司

经中国保监会会同有关部门批准，依法登记注册、受托管理 保险资金的金融机构。

3.25 保险经纪公司

经中国保险监督管理委员会批准设立，基于投保人的利益，为投保人与保险人订立保险合同提供中介服务，并依法收取佣金 的金融机构。

3.26 保险代理公司

经中国保险监督管理委员会批准设立，根据保险公司的委

托，向保险公司收取代理佣金，并在保险公司授权的范围内代为 办理保险业务的金融机构。

3.27 保险公估公司

经中国保险监督管理委员会批准设立的，接受保险当事人委 托，专门从事保险标的的评估、勘验、鉴定、估损、理算等业务 的单位。

3.28 企业年金

指企业及其职工在依法参加基本养老保险的基础上，自愿建 立的补充养老保险制度。

3.29 交易所

经国家有关主管部门批准设立的，提供证券、商品、期货等 集中竞价交易场所，不以营利为目的的法人。

3.30 登记结算类机构

经国家有关主管部门批准设立的，为金融交易提供集中的登 记、托管与结算服务，不以营利为目的的法人。

3.31 金融控股公司

依据《中华人民共和国公司法》设立，拥有或控制一个或多 个金融性公司，并且这些金融性公司净资产占全部控股公司合并 净资产的50%以上，所属的受监管实体应是至少明显地在从事两 种以上的银行、证券和保险业务独立企业法人。

3.32 小额贷款公司

由自然人、企业法人或其他社会组织依法设立，不吸收公众 存款，经营小额贷款业务的有限责任公司或股份有限公司。4 编码对象

本规范的编码对象是中华人民共和国的货币当局、监管当局 及其境内外派出机构；境内银行、证券、保险类金融机构的法人 机构及其境内外具有经营许可的分支机构；交易结算类金融机构 及其境内分支机构；境内设立的金融控股公司；国外金融机构在 我国境内设立的具有经营许可的非法人分支机构，中国人民银行 认定的其他有关金融机构。“境内”指中华人民共和国（不含港、澳、台地区）境内的地区。编码的结构和表示形式

5.1 结构

金融机构编码是特征组合码，长度为十四位，分别为大写拉 丁字母或阿拉伯数字。编码分为六段，从左至右分别为：一位金 融机构一级分类码；一位金融机构二级分类码；四位金融机构三 级分类码；两位地区代码；五位顺序码；一位校验码。7

5.1.1 金融机构一级分类码

长度为一位，采用大写拉丁字母或阿拉伯数字编码，表示金 融机构的一级分类。

A－货币当局

B－监管当局

C－银行业存款类金融机构

D－银行业非存款类金融机构

E－证券业金融机构

F－保险业金融机构

G－交易及结算类金融机构

H－金融控股公司

Z－其他

J～Y（I、O除外），1～9（0除外）－预留

5.1.2 金融机构二级分类码

长度为一位，采用阿拉伯数字编码在同一一级分类内按顺序 编码，表示金融机构的二级分类。

A－货币当局

1－中国人民银行

2－国家外汇管理局

B－监管当局

1－中国银行业监督管理委员会

2－中国证券监督管理委员会

3－中国保险监督管理委员会

C－银行业存款类金融机构

1－银行

2－城市信用合作社（含联社）

3－农村信用合作社（含联社）

4－农村资金互助社

5－财务公司

D－银行业非存款类金融机构

1－信托公司

2－金融资产管理公司

3－金融租赁公司

4－汽车金融公司

5－贷款公司

6－货币经纪公司

E－证券业金融机构

1－证券公司

2－证券投资基金管理公司

3－期货公司

4－投资咨询公司

F－保险业金融机构

1－财产保险公司

2－人身保险公司

3－再保险公司

4－保险资产管理公司

5－保险经纪公司

6－保险代理公司

7－保险公估公司

8－企业年金

G－交易及结算类金融机构

1－交易所

2－登记结算类机构

H－金融控股公司

1－中央金融控股公司

2－其他金融控股公司

Z－其他

1－小额贷款公司

5.1.3 金融机构三级分码

长度为四位，采用阿拉伯数字0001～9999在同一二级分类内 按顺序编码，表示金融机构的三级分类，三级分类指境内单家法 人金融机构或境外金融机构直接在境内设立的不具备法人资格 的机构。

5.1.4 地区代码

长度为两位，采用拉丁字母和阿拉伯数字编码，表示金融机 构所在地区的代码。

按金融机构所在地不同，分别按照如下两种方式赋码： ——当为境内金融机构时，采用《GB/T 2260-2007 中华人

民共和国行政区划代码》，取其数字码前两位为金融机构所属省、自治区、直辖市代码。

——当为境外金融机构时，采用《GB/T 2659-2000 世界各 国和地区名称代码（eqv ISO 3166-1:1997）》，取其两字符拉 丁字母代码为金融机构属地国家或地区的代码。（台湾、香港、澳门视为境外）

5.1.5 顺序码

长度为五位，采用阿拉伯数字编码，表示金融机构的顺序号。同一金融机构（三级）分类、同一地区代码下，多个不同营 业机构的顺序编号从00001-99999顺序连续编码。

5.1.6 校验码

长度为一位，采用阿拉伯数字编码，使用The Luhn Mod-10Method算法生成。

5.2 编码的表示形式

金融机构编码的各段依次连接，不留空格，其表示形式如下。位置***1314 编码 XXXXXXXXXXXXXX 码段 一 二 三四五六 其中：各码段的含义如下。

一：金融机构一级分类码

二：金融机构二级分类码

三：金融机构三级分类码

四：地区代码

五：顺序码

六：校验码

第五篇：Java命名规范

Java包的名字都是由小写单词组成。但是由于Java面向对象编程的特性，每一名Java程序员都可以编写属于自己的Java包，为了保障每个Java包命名的唯一性，在最新的Java编程规范中，要求程序员在自己定义的包的名称之前加上唯一的前缀。由于互联网上的域名称是不会重复的，所以程序员一般采用自己在互联网上的域名称作为自己程序包的唯一前缀。例如： net.frontfree.javagroup

类的名字必须由大写字母开头而单词中的其他字母均为小写；如果类名称由多个单词组成，则每个单词的首字母均应为大写例如TestPage；如果类名称中包含单词缩写，则这个所写词的每个字母均应大写，如：XMLExample,还有一点命名技巧就是由于类是设计用来代表对象的，所以在命名类时应尽量选择名词。

例如： Circle

interface RasterDelegate;

interface Storing;

方法的名字的第一个单词应以小写字母作为开头，后面的单词则用大写字母开头。例如： sendMessge

变量(Variables)除了变量名外，所有实例，包括类，类常量，均采用大小写混合的方式，第一个单词的首字母小写，其后单词的首字母大写。变量名不应以下划线或美元符号开头，尽管这在语法上是允许的。

变量名应简短且富于描述。变量名的选用应该易于记忆，即，能够指出其用途。尽量避免单个字符的变量名，除非是一次性的临时变量。临时变量通常被取名为i，j，k，m和n，它们一般用于整型；c，d，e，它们一般用于字符型。char c;

int i;

float myWidth;

实例变量(Instance Variables)大小写规则和变量名相似，除了前面需要一个下划线 int _employeeId;

String _name;

Customer _customer;

常量的名字应该都使用大写字母，并且指出该常量完整含义。如果一个常量名称由多个单词组成，则应该用下划线来分割这些单词。

例如： MAX_VALUE