C#.Net 编码规范
盛视科技有限公司
2013年6月19日
一、前言
一致的命名模式是托管类库中可预知性与可发现性最重要的元素之一。对这些命名指南广泛的使用和理解将消除许多最常见的用户问题。本主题提供 .NET Framework 类型的命名指南。对于每个类型，还应该注意关于大写样式、区分大小写和措词的一些通用规则。
二、命名指南
2.1 大写样式
使用下面的三种大写标识符约定。
2.1.1Pascal 大小写
将标识符的首字母和后面连接的每个单词的首字母都大写。可以对三字符或更多字符的标识符使用Pascal 大小写。例如：
2.1.2Camel 大小写
标识符的首字母小写，而每个后面连接的单词的首字母都大写。例如：
2.1.3大写
标识符中的所有字母都大写。仅对于由两个或者更少字母组成的标识符使用该约定。例如：
可能还必须大写标识符以维持与现有非托管符号方案的兼容性，在该方案中所有大写字母经常用于枚举和常数值。一般情况下，在使用它们的程序集之外这些字符应当是不可见的。
下表汇总了大写规则，并提供了不同类型的标识符的示例。
标识符大小写示例
类Pascal AppDomain
枚举类型Pascal ErrorLevel
枚举值Pascal FatalError
事件Pascal ValueChange
异常类Pascal WebException
注意总是以Exception后缀结尾。
只读的静态字段Pascal RedValue
接口Pascal IDisposable
注意总是以I前缀开始。
方法Pascal ToString
命名空间Pascal System.Drawing
参数Camel typeName
属性Pascal BackColor
受保护的实例字段Camel redValue
注意很少使用。属性优于使用受保护的实例字段。
公共实例字段Pascal RedValue
注意很少使用。属性优于使用公共实例字段。
2.2 区分大小写
为了避免混淆和保证跨语言交互操作，请遵循有关区分大小写的使用的下列规则：
●不要使用要求区分大小写的名称。对于区分大小写和不区分大小写的语言，组件都必须完全可以
使用。不区分大小写的语言无法区分同一上下文中仅大小写不同的两个名称。因此，在创建的组
件或类中必须避免这种情况。
●不要创建仅是名称大小写有区别的两个命名空间。例如，不区分大小写的语言无法区分以下两个
命名空间声明。
●不要创建具有仅是大小写有区别的参数名称的函数。下面的示例是不正确的。
●不要创建具有仅是大小写有区别的类型名称的命名空间。在下面的示例中，Point p 和 POINT p
是不适当的类型名称，原因是它们仅在大小写方面有区别。
●不要创建具有仅是大小写有区别的属性名称的类型。在下面的示例中，int Color 和 int COLOR
是不适当的属性名称，原因是它们仅在大小写方面有区别。
●不要创建具有仅是大小写有区别的方法名称的类型。在下面的示例中，calculate 和 Calculate
是不适当的方法名称，原因是它们仅在大小写方面有区别。
2.3 缩写
为了避免混淆和保证跨语言交互操作，请遵循有关区缩写的使用的下列规则：
●不要将缩写或缩略形式用作标识符名称的组成部分。例如，使用 GetWindow，而不要使用 GetWin。
●不要使用计算机领域中未被普遍接受的缩写。
●在适当的时候，使用众所周知的缩写替换冗长的词组名称。例如，用 UI 作为 User Interface 的
缩写，用 OLAP 作为 On-line Analytical Processing 的缩写。
●在使用缩写时，对于超过两个字符长度的缩写，请使用 Pascal 大小写或 Camel 大小写。例如，
使用 HtmlButton 或 htmlButton。但是，应当大写仅有两个字符的缩写，如，System.IO，而不
是 System.Io。
●不要在标识符或参数名称中使用缩写。如果必须使用缩写，对于由多于两个字符所组成的缩写请
使用 Camel 大小写，虽然这和单词的标准缩写相冲突。
2.4 措词
避免使用与常用的 .NET Framework 命名空间重复的类名称。例如，不要将以下任何名称用作类名称：System、Collections、Forms或UI。有关 .NET Framework 命名空间的列表，请参见类库。
另外，避免使用和以下关键字冲突的标识符。
2.5 避免类型名称混淆
不同的编程语言使用不同的术语标识基本托管类型。类库设计人员必须避免使用语言特定的术语。请遵循本节中描述的规则以避免类型名称混淆。
使用描述类型的含义的名称，而不是描述类型的名称。如果参数除了其类型之外没有任何语义含义，那么在这种罕见的情况下请使用一般性名称。例如，支持将各种数据类型写入到流中的类可以有以下方法。
不要创建语言特定的方法名称，如下面的示例所示。
2.6 命名空间命名指南
命名命名空间时的一般性规则是使用公司名称，后跟技术名称和可选的功能与设计，如下所示。
CompanyName.TechnologyName[.Feature][.Design]
例如：
给命名空间名称加上公司名称或者其他知名商标的前缀可以避免两个已经发布的命名空间名称相同的
可能性。例如，Microsoft.Office 是由 Microsoft 提供的 Office Automation Classes 的一个适当的前缀。
在第二级分层名称上使用稳定的、公认的技术名称。将组织层次架构用作命名空间层次架构的基础。命名一个命名空间，该命名空间包含为具有 .Design 后缀的基命名空间提供设计时功能的类型。例如，System.Windows.Forms.Design 命名空间包含用于设计基于 System.Windows.Forms 的应用程序的设计器和相关的类。
嵌套的命名空间应当在包含它的命名空间中的类型上有依赖项。例如，System.Web.UI.Design 中的类依赖于 System.Web.UI 中的类。但是，System.Web.UI 中的类不依赖于 System.Web.UI.Design 中的类。
应当对命名空间使用 Pascal 大小写，并用句点分隔逻辑组件，如 Microsoft.Office.PowerPoint 中所示。如果您的商标使用非传统的大小写，请遵循您的商标所定义的大小写，即使它与规定的 Pascal 大小写相背离。例如，命名空间 NeXT.WebObjects 和 ee.cummings 阐释了对于 Pascal 大小写规则的适当背离。
如果在语义上适当，使用复数命名空间名称。例如，使用System.Collections 而不是System.Collection。此规则的例外是商标名称和缩写。例如，使用 System.IO 而不是 System.IOs。
不要为命名空间和类使用相同的名称。例如，不要既提供 Debug 命名空间也提供 Debug 类。
最后，请注意命名空间名称不必非得与程序集名称相似。例如，如果命名程序集MyCompany.MyTechnology.dll，它没有必要非得包含 MyCompany.MyTechnology 命名空间。
2.7 类命名指南
以下规则概述命名类的指南：
●使用名词或名词短语命名类。
●使用 Pascal 大小写。
●少用缩写。
●不要使用类型前缀，如在类名称上对类使用 C 前缀。例如，使用类名称 FileStream，而不是
CFileStream。
●不要使用下划线字符 (_)。
●有时候需要提供以字母 I 开始的类名称，虽然该类不是接口。只要 I 是作为类名称组成部分的
整个单词的第一个字母，这便是适当的。例如，类名称 IdentityStore 就是适当的。
●在适当的地方，使用复合单词命名派生的类。派生类名称的第二个部分应当是基类的名称。例如，
ApplicationException 对于从名为Exception 的类派生的类是适当的名称，原因是
ApplicationException 是一种 Exception。请在应用该规则时进行合理的判断。例如，Button 对
于从 Control 派生的类是适当的名称。尽管按钮是一种控件，但是将 Control 作为类名称的一
部分将使名称不必要地加长。
下面是正确命名的类的示例。
2.8 接口命名指南
●用名词或名词短语，或者描述行为的形容词命名接口。例如，接口名称 IComponent 使用描述性
名词。接口名称 ICustomAttributeProvider 使用名词短语。名称 IPersistable 使用形容词。
●使用 Pascal 大小写。
●少用缩写。
●给接口名称加上字母 I 前缀，以指示该类型为接口。
●在定义类/接口对（其中类是接口的标准实现）时使用相似的名称。两个名称的区别应该只是接
口名称上有字母 I 前缀。
●不要使用下划线字符 (_)。
以下是正确命名的接口的示例。
以下代码示例阐释如何定义 IComponent 接口及其标准实现 Component 类。
2.9 属性命名指南
应该总是将后缀 Attribute 添加到自定义属性类。以下是正确命名的属性类的示例。
2.10 枚举类型命名指南
枚举 (Enum) 值类型从 Enum 类继承。以下规则概述枚举的命名指南：
●对于 Enum 类型和值名称使用Pascal 大小写。
●少用缩写。
●不要在 Enum 类型名称上使用Enum后缀。
●对大多数 Enum 类型使用单数名称，但是对作为位域的 Enum 类型使用复数名称。
●总是将 FlagsAttribute 添加到位域 Enum 类型。
2.11 静态字段命名指南
以下规则概述静态字段的命名指南：
●使用名词、名词短语或者名词的缩写命名静态字段。
●使用 Pascal 大小写。
●不要在静态字段名称中使用匈牙利语表示法的前缀。
●建议尽可能使用静态属性而不是公共静态字段。
2.12 参数命名指南
必须仔细遵守这些参数的命名指南，这非常重要，因为提供上下文相关帮助和类浏览功能的可视化设计工具会在设计器中对用户显示方法参数名称。以下规则概述参数的命名指南：
●对参数名称使用 Camel 大小写。
●使用描述性参数名称。参数名称应当具有足够的描述性，以便参数的名称及其类型可用于在大多
数情况下确定它的含义。例如，提供上下文相关帮助的可视化设计工具会按开发人员键入的实际
内容显示方法参数。在这种情况下，方法参数名称的表述必须清楚明白，开发人员才能提供正确
的参数。
●使用描述参数的含义的名称，而不要使用描述参数的类型的名称。开发工具将提供有关参数的类
型的有意义的信息。因此，通过描述意义，可以更好地使用参数的名称。少用基于类型的参数名
称，仅在适合使用它们的地方使用它们。
●不要使用保留的参数。保留的参数是专用参数，如果需要，可以在未来的版本中公开它们。相反，
如果在类库的未来版本中需要更多的数据，请为方法添加新的重载。
●不要给参数名称加匈牙利语类型表示法的前缀。
以下是正确命名的参数的示例。
2.13 方法命名指南
以下规则概述方法的命名指南：
●使用动词或动词短语命名方法。
●使用 Pascal 大小写。
以下是正确命名的方法的实例。
2.14 属性命名指南
以下规则概述属性的命名指南：
●使用名词或名词短语命名属性。
●使用 Pascal 大小写。
●不要使用匈牙利语表示法。
●考虑用与属性的基础类型相同的名称创建属性。例如，如果声明名为 Color 的属性，则属性的
类型同样应该是 Color。请参见本主题内下文中的示例。
以下代码示例阐释正确的属性命名。
以下代码示例阐释提供其名称与类型相同的属性。
以下代码示例不正确，原因是 Color 属性是 Integer 类型的。
在不正确的示例中，不可能引用 Color 枚举的成员。Color.Xxx 将被解释为访问一个成员，该成员首先获取 Color 属性（在 Visual Basic 中为 Integer 类型，在 C# 中为 int 类型）的值，然后再访问该值的某个成员（该成员必须是 System.Int32 的实例成员）。
2.15 事件命名指南
以下规则概述事件的命名指南：
●使用 Pascal 大小写。
●不要使用匈牙利语表示法。
●对事件处理程序名称使用 EventHandler 后缀。
●指定两个名为 sender 和 e 的参数。sender 参数表示引发事件的对象。sender 参数始终是
object 类型的，即使在可以使用更为特定的类型时也如此。与事件相关联的状态封装在名为 e 的事件类的实例中。对 e 参数类型使用适当而特定的事件类。
●用 EventArgs 后缀命名事件参数类。
●考虑用动词命名事件。例如，命名正确的事件名称包括 Clicked、Painting 和 DroppedDown。
●使用动名词（动词的“ing”形式）创建表示事件前的概念的事件名称，用过去式表示事件后。
例如，可以取消的Close 事件应当具有Closing 事件和Closed 事件。不要使用BeforeXxx/AfterXxx 命名模式。
●不要在类型的事件声明上使用前缀或者后缀。例如，使用 Close，而不要使用 OnClose。
●通常情况下，对于可以在派生类中重写的事件，应在类型上提供一个受保护的方法（称为 OnXxx）。
此方法只应具有事件参数 e，因为发送方总是类型的实例。
以下示例阐释具有适当名称和参数的事件处理程序。
以下示例阐释正确命名的事件参数类。
2.16 常量(const)命名指南
以下规则概述事件的命名指南：
●所有单词大写，多个单词之间用"_" 隔开。如
三、编码规范
3.1 类命名规范
参考类命名指南。
以下类派生的子类使用相应的后缀：
3.2 类变量编码规范
原则上，在类内部不使用任何public变量，仅使用private变量。private变量的命名参考参数命名指南。其它参考如下：
●使用Camel大小写，不要用匈牙利命名法。
●对于bool类型，不要用b或f开头，应使用is或has等动词开头。
●仅对于短循环索引使用单字母变量名，如 i 或 j。
●对于声明为DataSet的变量，以ds开头。声明为DataTable的变量以table开头。
3.3 窗体类命名
用Pascal大小写，用名词或名词短语，或者描述行为的形容词命名窗体类，使用Form结尾，例如LoginForm，ProductDetailForm等窗体类名。
3.4 窗体内控件命名
窗体内控件用Camel大小写，使用该控件变量名称作为开头，后面接用名词或名词短语，或者描述行为的形容词。例如，buttonOK，labelAge，textBoxName，checkBoxIsMember等。具体只须把原控件名称中末尾的数字改为控件名称，象button1改为buttonOK。
由于窗体也是控件的子类，声明为窗体的变量命名也类似，但可能窗体类名中已包含用途，所以可以不加任何后缀，仅以Camel大小写命名其变量。例如LoginForm的实例命名为loginForm。
3.5 窗体内非控件变量命名
参考类变量编码规范。
3.6 文件夹及命名空间分布
●项目根文件夹下尽量少文件，仅放置启动类，也可以放配置文件。
●把用途相似或行为并列的类放到同一个文件夹中，文件夹命名参考命名空间的命名指南，文件夹
尽量保持与类所在的命名空间一致。
●资源包括图片、音频等放置到资源目录。
3.7 方法编码规范简述
对于每个类里面的方法，规范较多并且复杂，以下简述一些：
●方法命名应以动词或动词短语开头，后面可加名词或形容词表示动作的对象或结果。例如
ToString()，Show()，Refresh()等。
●方法的参数用该方法的动词的对象命名。例如Delete(Student student)。
●每个方法代码行数不应超过100行。尽量把集中的动作移到另外的方法中，并准确命名。
●
安全标准化体系文件目录及编号 序号大类属性小类属性文件/台帐名称分类编号版本代码 1 法律、法规和标 准 制度 安全法律、法规、标准及 其他要求识别和获取管理 制度 WHAB-04-A-02 2012-A 文件/台帐 适用的安全生产法律法规 及其他要求清单 WHAB-01-B-01 2012-A 法律、法规和标准的文本 数据库 WHAB-01-B-02 2012-A 安全生产法律、法规、标 准及其它要求执行情况符 合性评价报告 WHAB-01-B-03 2012-A 记录 适用的法律法规、标准及 其他要求清单定期更新记 录 WHAB-01-C-01 2012-A 文件发放记录WHAB-01-C-02 2012-A 法规安全培训记录WHAB-01-C-03 2012-A 法规安全宣传记录WHAB-01-C-04 2012-A 2 机构和职责 制度 安全生产责任制WHAB-04-A-01 2012-A 安全生产费用管理制度WHAB-04-A-04 2012-A 领导干部带班制度WHAB-04-A-55 2012-A 安全生产责任制考核制度WHAB-04-A-58 2012-A 文件/台帐 关于发布安全生产方针、 目标的通知 WHAB-02-B-01 2012-A 发布公司年度安全生产目 标的文件 WHAB-02-B-02 2012-A 公司年度安全工作计划WHAB-02-B-03 2012-A 公司各级组织的年度安全 工作计划 WHAB-02-B-04 2012-A 各级组织安全目标责任书WHAB-02-B-05 2012-A 化工生产企业主要负责人 安全生产履职情况报告表 WHAB-02-B-06 2012-A 安全标准化实施方案WHAB-02-B-07 2012-A 安全文化建设方案WHAB-02-B-08 2012-A 主要负责人安全承诺文件WHAB-02-B-09 2012-A 关于标准化资源配备的通 知 WHAB-02-B-10 2012-A 安委会、安全部、安全员 设置文件 WHAB-02-B-11 2012-A 公司行政机构设置图WHAB-02-B-12 2012-A 安全管理网络WHAB-02-B-13 2012-A 关于设置治安保卫部和配 备专职治安保卫人员的通 知 WHAB-02-B-14 2012-A
编码安全规范 编码安全规范 安全
V1.0
拟 制： 内 容 范畴： 保 密 级别： 范 围 ：
安全中心 信息安全 保密 全体员工
关 键 字 文 档 类 别 文 件 名 版 本
： ： ： ：
安全, 编码规范 开发技术文档 编码安全规范.doc 1.0
文档历史
日期 作者 wolfliu
applelin Tony, Coolcyang applelin stevezheng Dum applelin
版本号 V0.1
V0.2 V0.3 V0.4 V0.5 V0.6
备注
2007-02-19 2007-2-28 2007-3-8 2007-3-12
分割了一下原来的 V0.2 的文档，抽出一个单列 的格式，以便后续修改。 根据新的格式整理并补充 补充示例
第一篇 防止堆栈溢出类漏洞 ..........................................................................................................4 1.1 对任何用户输入数据必须首先校验其长度，避免由于长度越界引起的缓冲区溢出。 ...........4 1.2C＋＋和 MFC 程序字符串处理，选择现有的处理类库，禁止自己编写类库。 ......................4 1.3 编码中禁止使用危险函数。.......................................................................................................4 1.4Unicode 和 ANSI 缓冲区大小不匹配问题，必须注意大小计算的单位。 .................................5 1.5 不将用户输入串拼接到任何格式字符串内。避免字符格式化漏洞。 ......................................6 1.6 多个字符串存储在一个数据区时，尽量不依靠分隔符区分边界。用户数据需要转义后传输， 存储。 ..............................................................................................................................................7 1.7 C\C++中数组大小应该是 sizeof(pArray)/sizof(pArray[0]) ..........................................................7 1.8 其他可能出现缓冲区溢出的函数 ...............................................................................................7 第二篇 防止 SQL 恶意构造性漏洞 .................................................................................................8 2.1 防止 SQL 恶意构造漏洞。 不直接使用外部输入的数字、字符串拼接 SQL 语句。 ...........8 2.2 web 编程对于用户的任何输入必须做关键字过滤 ..................................................................9 第三篇 防止目录，文件名恶意构造性漏洞....................................................................................9 3.1 必须：禁止使用外部输入字串作为下列函数的参数的一部分, 确保用户不能欺骗系统从而执 行任意命令。如果必须传递参数，从数据库、文件、管道、套接字等 IPC 通信方式传递。 .....9 3.4 验证所有可能的数据，甚至包括数据库中的数据，本地文件。 ........................................... 10 3.5 不将用户输入串直接加入 html 文件、js 脚本、xml 文件、配置文件、模板文件。 ............. 10 3.6 避免使用有安全风险的 windows API。 .................................................................................. 10 第四篇 防止内存堆溢出漏洞 ...................................................................................................... 11 4.1 分配内存，要判断返回值。..................................................................................................... 11 4.2 内存操作，特别是内存拷贝，必须检查长度是否超出分配内存的大小 ................................ 11 4.3 对于无效指针，一定要置 NULL，同时数组不要保存无效指针 ............................................ 12 4.4 时刻注意表达式是否会上溢、下溢 ......................................................................................... 13 4.5 过程/函数中分配的资源（包括内存、文件等） ，在过程/函数退出之前要释放。................. 13 4.6 MFC 中使用 CArray 删除数据，需要倒后遍历. ...................................................................... 13 第五篇 其他一些注意事项 .......................................................................................................... 14 5.1 检查所有与安全相关的函数的返回值 ..................................................................................... 14 5.2 调用可能被预测的函数前，引入随机量.................................................................................. 14 5.3 在代码中添加安全性注释 ....................................................................................................... 15 关键词： 关键词： 摘 要： 为了提高公司软件安全质量，公司对安全编程作出统一的规范约束。 本规范由安全中心负责维护更新。 本规范是一个最初级的基本规范。所有的开发者均应熟练掌握。 本规范的示例多以 C\C++为背景。 缩略语清单： 缩略语清单 必须：强制必须遵守的原则。 建议：可以加以考虑的原则。 禁止：必须加以避免的原则。 示例：对此规则或建议从正、反两个方面给出例子。
C语言编程规范 对于程序员来说，能工作的代码并不等于“好”的代码。“好”代码的指标很多，包括易读、易维护、易移植和可靠等。其中，可靠性对嵌入式系统非常重要，尤其是在那些对安全性要求很高的系统中，如飞行器、汽车和工业控制中。这些系统的特点是：只要工作稍有偏差，就有可能造成重大损失或者人员伤亡。一个不容易出错的系统，除了要有很好的硬件设计(如电磁兼容性)，还要有很健壮或者说“安全”的程序。 然而，很少有程序员知道什么样的程序是安全的程序。很多程序只是表面上可以干活，还存在着大量的隐患。当然，这其中也有C语言自身的原因。因为C语言是一门难以掌握的语言，其灵活的编程方式和语法规则对于一个新手来说很可能会成为机关重重的陷阱。同时，C语言的定义还并不完全，即使是国际通用的C语言标准，也还存在着很多未完全定义的地方。要求所有的嵌入式程序员都成为C语言专家，避开所有可能带来危险的编程方式，是不现实的。最好的方法是有一个针对安全性的C语言编程规范，告诉程序员该如何做。 本规范在制定过程中，主要参考了业界比较推崇的《华为软件编程规范和范例》和《MI SRA 2004规则》，适合C语言初学者使用，目的在于在教学中培养学生良好的编程规范和意识、素质，促进所设计程序安全、健壮、可靠、可读与可维护(程序简单、清晰)。考虑到面向的是初学者，为便于教学和课程考核操作，本规范中的要求比较基本。事实上，很多公司都有自己规定的代码风格，包括命名规则、缩进规则等，学生参加工作后，应再进一步学习和应用公司的规范。 建议学生在学习本规范的同时，花点时间阅读本规范的参考文献原文，特别是熟读本规范的参考文献之一的《“安全第一”的C语言编程规范》，深刻理解编程规范与程序安全、健壮、可靠、可读、可维护间的关系和作用，在学习和工作中养成良好的编程风格。 1 排版 1.1 严格采用阶梯层次组织程序代码 函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格，case 语句下的情况处理语句也要遵从语句缩进要求。 程序块的分界符(如C/C++ 语言的大括号‘{’和‘}’)应各独占一行并且位于同一列，同时与引用它们的语句左对齐。在函数体的开始、类的定义、结构的定义、枚举的定义以及if 、for 、do 、while 、switch 、case 语句中的程序都要采用如上的缩进方式。 各层次缩进的风格采用TAB缩进(TAB宽度原则上使用系统默认值，TC使用8空格宽度，VC使用4空格宽度)。示例：
【最新整理，下载后即可编辑】 1程序结构 所有源代码的结构均采用以下顺序布局，对于没有的部分可以省略，便于阅读代码。 //============================================== ================================================ #region Constant #endregion Constant //---------------------------------------------------------------------------------------------- #region Members #endregion Members //---------------------------------------------------------------------------------------------- #region Defaults #endregion Defaults //---------------------------------------------------------------------------------------------- #region Properties #endregion Properties //============================================== ================================================ #region Constructors #endregion Constructors //---------------------------------------------------------------------------------------------- #region InterfaceMethods #endregion InterfaceMethods //---------------------------------------------------------------------------------------------- #region StaticMethods #endregion StaticMethods //---------------------------------------------------------------------------------------------- #region OverrideMethods #endregion OverrideMethods //---------------------------------------------------------------------------------------------- #region PrivateMethods #endregion PrivateMethods //---------------------------------------------------------------------------------------------- #region ProtectedMethods #endregion ProtectedMethods //---------------------------------------------------------------------------------------------- #region PublicMethods #endregion PublicMethods //============================================== ================================================ #region Events #endregion Events //============================================== ================================================ 2命名规则和风格 ⑴类、方法、常量采用Pascal风格命名 public class SomeClass { const int DefaultSize = 100;
代码编写安全规范 一、本总则提供编码的总体要求与遵循原则。 二、本总则制订是为了规范程序的编码风格，使项目开发过程中所有开发人员的编码有一个良好的、规范的、统一的编码风格，确保在开发成员或开发团队之间的工作可以顺利交接，同时不必花费大力气便能理解已编写的代码，以便继续维护和改进以前的工作。 三、本总则对所有技术开发部编码人有效。 四、本总则对所有开发语言有效，凡任何开发规范与本总则相冲突，以本总则为准。 五、本总则提供各种语言的编码规范，编码人员开发（编码）前应选取相应的语言编码规范进行编码。具体的“开发语言编码规范”请参见附件。 六、若总则附件中无所规范的开发语言规范，请先制订出（一般由项目经理制订）该语言的编码规范后再进行编码。 七、编码命名准则： 1、使用可以准确说明变量/字段/类的完整的英文描述符。例如，采用类似firstName，grandTotal 或CorporateCustomer 这样的名字。禁止使用一些象x1，y1 或fn 这样的名字很简短，输入起来容易，辨别含义困难的命名，使得代码难以理解、维护和改进。 2、采用领域的术语命名。如果用户称他们的“客户”(clients) 为“顾客”(customers)，那么就采用术语Customer 来命名这个类，而不用Client。保证命名使用行业或领域里已经存在着很完美的术语，避免生造词汇。
3、采用大小写混合，提高名字的可读性。一般应该采用小写字母，但类名、接口名以及任何非初始单词的第一个字母要大写，一些特殊场合以具体规范为准。 4、尽量少用缩写，但如果一定要使用，必须使用一个统一遵守的缩写，并且在使用时保持一致。例如，如果要对单词“number”采用缩写，那么可从nbr，no 或者num 中选取一个，采用其中一个（具体是哪个倒无所谓），并且只使用这一种形式。 5、避免使用长名字（最好不超过20 个字母）。避免类似如PhysicalOrVirtualProductOrService 之类的超长命名。 6、避免使用相似或者仅在大小写上有区别的名字。例如，不应同时使用变量名persistentObject 和persistentObjects，以及anSqlDatabase 和anSQLDatabase。 7、避免使用下划线作为名字的首末字母。以下划线为首末字母的名字通常为系统保留，除预处理定义之外，一般不用作用户命名。 八、编码注释准则： 1、必须明确注释的重要性。如果你的程序不值得注释，那么它也不值得运行。 2、注释应该增加代码的清晰度。代码注释的目的是要使代码更易于被同时参与程序设计的开发人员以及其他后继开发人员理解。如果不能被他人所理解，则代码的注释是失败的注释，等同于无注释。 3、避免使用装饰性内容，不要使用象广告横幅那样的注释语句。
项目开发规范文档修订历史记录
1.简介 目的 1、用于规范指导开发组进行开发 2、便于成员间的沟通与交流。 3、有助于项目质量和稳定。 4、为后期维护提供支持 2. 项目开发流程 项目开发过程归纳分为以下步骤： 1. 建立SVN项目版本控制。包括文档，源码，Lib包等。 2. 了解需求，并对需求文档的书写。(见文档结构规则附录)。 3. 详细设计文档。(见文档结构规则附录)。 功能模块设计，重要模块的算法设计。 数据库设计等。 根据需求定义开发平台及环境。 4. 编码。 搭建开发平台，配置开发环境。 编码。 单元测试案例。 5. 书写软件安装手册文件，数据库脚本文件，以及注意事项(release notes)。 6. 交互测试组测试。根据测试组测试结果是否回归第4步（测试回归最好不要超过2 次）。 7. 测试通过，交付上线使用。 维护手册 使用手册
3. 代码规范 Java 代码规范 3.1.1 Java类名 类名可由：英文字母，数字，下划线组成。（数字，下划线不能够开头） 类名由一个或者多个单词组成。单词通常要求简洁明了达意。能够通过类名能够大致了解此类的作用和用途。 类名要求首字母大写，多个单词组成类名时，单词的首字母要求大写。 建议：类名不要过于简单或者太长。可以对单词采用简化的名称：入： Number 简化为：num 。 3.1.2 Java类结构 类仅作为数据结构，没有行为，他封装了一组或者相似的一些行为方法。所以一个类尽量功能单一，或者功能类似共有行为的。一个类不要过于庞大。 通常情况下： 一般逻辑类中应该有构造方法和main方法，main方法中应该有测试代码。 每个类应该有 toString() 方法。 3.1.2.1 包和引入语句 在多数Java源文件中，第一个非注释行是包语句。在它之后可以跟引入语句。 报名的定义全部是小写字母。具体定义依据项目而定。 引入包时候，同一类型的归纳到一块，用空行隔开。例如： import 3.1.2 类注释 Java类开头应该有相应的注释：类版本描述，作者签名，日期时间，公司备注，类的功能作用相关描述等。（详细查看：注释） 3.1.2.2 类成员变量 a) 类变量要求放在类的开始声明。一行声明一个。 b) 变量名称首字母要求小写。其他命名规则类似与类名。 c) static , final 类型的变量，字母要求全部大写。 d) 尽量在声明局部变量的同时初始化。 e) 避免局部变量和成员变量同名，覆盖了成员变量。 f) 尽量变量私有化，缩小变量的作用域。 3.1.2.3 类成员方法 a) 方法名命名规则类似于成员变量命名规则。 b) 成员方法尽量私有化。
管理制度编号：LX-FS-A77872 工程安全管理规范标准范本 In The Daily Work Environment, The Operation Standards Are Restricted, And Relevant Personnel Are Required To Abide By The Corresponding Procedures And Codes Of Conduct, So That The Overall Behavior Can Reach The Specified Standards 编写：_________________________ 审批：_________________________ 时间：________年_____月_____日 A4打印/ 新修订/ 完整/ 内容可编辑
工程安全管理规范标准范本 使用说明：本管理制度资料适用于日常工作环境中对既定操作标准、规范进行约束，并要求相关人员共同遵守对应的办事规程与行动准则，使整体行为或活动达到或超越规定的标准。资料内容可按真实状况进行条款调整，套用时请仔细阅读。 1.未经工程部批准，外来人员(包括参观学习、探亲访友、施工等)严禁进入配电房、电梯机房、消防控制中心、水泵房、消防泵房等地。经批准的，办好进出登记手续，并由工程部人员陪同。 2.各岗位值班员,必须严守岗位责任制，必须对所属机房范围内进行安全检查。如发现有不安全因素，须及时上报处理。 3.高空及外墙擦洗工作安全操作规定 3.1从事高空作业的人，必须进行身体检查。凡患有高血压、心脏病、癫痫及其他不适宜高空作业的人，一律不允许从事高空作业。
百度文库- 让每个人平等地提升自我 1 程序代码注释编写规范 为提高控制程序的阅读性与可理解性，现制定相关代码程序代码注释编写的编写规范。 一般情况下，源程序有效注释量必须在20％以上，注释的原则是有助于对程序的阅读理解，在该加的地方都加了，注释不宜太多也不能太少，注释语言必须准确、易懂、简洁。 常规注释有以下两种方式。 单行:以"文件、.inc文件、.def文件、编译说明文件.cfg等）头部应进行注释，注释必须列出：版权说明、版本号、生成日期、作者、内容、功能、与其它文件的关系、修改日志等，头文件的注释中还应有函数功能简要说明。 示例：下面这段头文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************* (C), MicTiVo International. Co., Ltd. 1.File : . History: Date: Author: Modification: 2. .. *************************************************/ 一、源文件头 源文件头部应进行注释，列出：版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。 示例：下面这段源文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************************ (C), MicTiVo International. Co., Ltd. FileName: Author: Version : Date: : / /*receive _process() */ 意:与溢出中断写初值不同}
程序的书写规则(程序的编码规范) 随着软件产品的功能增加和版本的提高，代码越来越复杂，源文件也越来越多，对于软件开发人员来说，除了保证程序运行的正确性和提高代码的运行效率之外，规范风格的编码会对软件的升级、修改、维护带来极大的方便性，也保证程序员不会陷入“代码泥潭”中无法自拔。开发一个成熟的软件产品，除了有详细丰富的开发文档之外，必须在编写代码的时候就有条不紊，细致严谨。 以下的编码规范包含了程序排版、注释、命名、可读性、变量、程序效率、质量保证、代码编译、代码测试和版本控制等注意事项。 一、排版： 1.关键词和操作符之间加适当的空格。 2.相对独立的程序块与块之间加空行 3.较长的语句、表达式等要分成多行书写。 4.划分出的新行要进行适应的缩进，使排版整齐，语句可读。 5.长表达式要在低优先级操作符处划分新行，操作符放在新行之首。 6.循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分。 7.若函数或过程中的参数较长，则要进行适当的划分。 8.不允许把多个短语句写在一行中，即一行只写一条语句。 9.函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风 格。 10.C/C 语言是用大括号‘{’和‘}’界定一段程序块的，编写程序块时‘{’和 ‘}’应各独占一行并且位于同一列，同时与引用它们的语句左对齐。在函数体的开始、类的定义、结构的定义、枚举的定义以及if、for、do、while、switch、case语句中的程序都要采用如上的缩进方式。
二、注释 1.注释要简单明了。 2.边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性。 3.在必要的地方注释，注释量要适中。注释的内容要清楚、明了，含义准确，防 止注释二义性。保持注释与其描述的代码相邻，即注释的就近原则。 4.对代码的注释应放在其上方相邻位置，不可放在下面。 5.对数据结构的注释应放在其上方相邻位置，不可放在下面；对结构中的每个域 的注释应放在此域的右方；同一结构中不同域的注释要对齐。 6.变量、常量的注释应放在其上方相邻位置或右方。 7.全局变量要有较详细的注释，包括对其功能、取值范围、哪些函数或过程存取 它以及存取时注意事项等的说明。 8.在每个源文件的头部要有必要的注释信息，包括：文件名；版本号；作者；生 成日期；模块功能描述（如功能、主要算法、内部各部分之间的关系、该文件与其它文件关系等）；主要函数或过程清单及本文件历史修改记录等。 9.在每个函数或过程的前面要有必要的注释信息，包括：函数或过程名称；功能 描述；输入、输出及返回值说明；调用关系及被调用关系说明等。 三、命名 1.较短的单词可通过去掉“元音”形成缩写； 2.较长的单词可取单词的头几发符的优先级，并用括号明确表达式的操作顺序， 避免使用默认优先级。 3.使用匈牙利表示法 四、可读性 1.避免使用不易理解的数字，用有意义的标识来替代。 2.不要使用难懂的技巧性很高的语句。
https://www.doczj.com/doc/2b8378277.html, C#开发规范 第一部分 第一章ASP编码规范通述 ASP编码分为两大部分，一部分为静态文件编码，一部分为包含服务器端脚本的动态文件编码。 静态文件编码分Script编码和HTML编码两部分。 服务器端编码则分为服务器脚本、客户端脚本、HTML脚本三部分。 编码规范采用如下约定： 所有客户端脚本一律使用JavaScript 所有服务器端脚本一律使用c# 静态页面输出一律使用HTML脚本 本规范不适用于由服务器端脚本所产生的客户端脚本代码。 第二章静态文件编码规范： 静态文件脚本部分采用JavaScript编写。输出部分采用HTML标记语言。 1. HTML标记语言编码规范 1.1 标记的换行规范： * 一个标记必须占用一行。不得出现两个标记在同一行的情况(同一标记的关闭标记除外)，如：