源代码编写规范
版本<1.0>
1简介 (4)
1.1目的 (4)
1.2范围 (4)
2代码格式规范 (4)
3代码注释规范 (5)
4命名规范 (9)
5异常处理规范 (11)
6其他规范 (11)
1简介
1.1目的
本文用于定义本公司程序编码规范。本文的目的在于规范和指导软件编程活动，作为考核标准。
1.2范围
本文仅用于指导软件编程工作，同时作为其他分析和设计工作的参考资料。本文的预期读者是：软件工程师/设计员、程序员。
本公司各项目可以采用不同的编程语言，并参照本规范和各语言的习惯定义各自的编程规范，但是必须经过评审通过。编程规范一旦通过评审，任何人在编程活动中都必须遵循。
2代码格式规范
【规范1】单行代码不得超过120字符。
【规范2】每行代码最多包含一个独立的语句。
【规范3】代码缩进两个空格。
说明：两个空格已经足够清晰了，缩进量过大会导致单行代码很长，反而影响阅读。
【规范4】不要使用TAB缩进代替空格缩进。
【规范5】如果单行代码过长，则应该遵循以下规则断行：
?在逗号的后面。
?在操作符的前面。
?断行的起始位置应该对其原行表达式的起始位置，如果无法满足，则缩进2个空格。
【规范6】每一个变量的声明独占一行。
【规范7】将变量的声明置于代码块的开始位置。
【规范8】在java中for、while、do-whil e循环，if、else if、else、switch-case分支，try-catch-finally块即使仅包含一个语句，也要用{}包含。其他语言参照执行。
【规范9】空行的位置：
?在逻辑代码段之间。
?for、while、do-whil e循环，if、else if、else、switch-case分支，try-catch-finally块的前面。
?在两个类或接口的定义之间。
?在两个方法/函数/过程之间。
?方法/函数/过程内部变量定义行和第一个非变量定义行之间。
?包含(C++)/引入(Java)完毕之后。
【规范10】空格的位置：
?在一个关键字和做括号“（”之间。注意：不要在方法名和左括号之间加空格。
?在参数列表的每个逗号“,”之后。
?一元操作符前后。注意：二元操作符前后都不加空格。例如：int a = 10; a = a + 1; a++;
?for语句的每个表达式之间。例如：for (int i = 0; i < 20; i++)…
?类型转换语句之后。例如：String s = (String) c;
【建议】空行、空格也是代码。空行是一个逻辑段起止的标志，它和编程者的思路是一致的。另外，适当的使用空行和空格可以使你的代码更加清晰。
3代码注释规范
【规范1】代码注释的量应该不少于总代码行数的1/3。
说明：只有足够的注释才能充分的说明你的代码，没有哪个规范可以规定注释量的上限，但是一般来说1/3应该是下限。如果你的代码包括注释、空行共90行，那么注释应该不少于30行。
【规范2】在维护代码的同时，维护你的注释。
说明：我们通常在编写代码的同时都会对代码进行注释，但是往往在维护代码的时候忘记同时维护注释。所以很多注释在代码反复修改之后，失去了说明代码的作用，这样的注释还不如不写。
【规范3】注释不要重复你的代码。
例如：String str;//声明一个String对象：str
上面的代码看上去没有问题，但是注释却是没有用的――只是对代码的简单重复。要记住，注释是用来说明代码的，而不是重复代码的。
【建议】文件注释。
文件注释用于说明代码文件的一些附加信息，它位于源代码文件的顶部。文件注释最重要的作用是记录代码维护历史。
例如：
/*
* 文件名:Demo.java
* 作者：Sam Lee
* 完成日期：2004/02/02
* 维护人员：Sam Lee
* 维护日期：2004/02/02
* 维护原因：修改了对于图的深度遍历的算法
* 当前版本：1.0
* 前继版本：0.9beta
*/
【规范4】为每一个类编写类注释。
类的注释位于类声明的前面，使用/**/进行注释（对于java，是/***/）。
类的注释应该说明一下几点：
1)完成了哪些工作，即这个类是作什么的。
2)使用的方法和注意事项，如果比较难以表达，那么可以写一些示例代码。
3)作者列表
4)当前版本和完成时间
5)参考类，即这个类与哪些类相关。
注意：类注释不要写类的实现方法，例如：“Matrix类采用主选消元法实现矩阵的求逆运算，具体算法是:…”，这样的注释往往会限制类的扩展，并且加重了类的维护的工作量。
我们来看一个好的类注释：
/**
* The Long class wraps a value of the primitive type
* long in an object. An object of type Long
* contains a single field whose type is long.
* 以上是类的作用
*
*
* In addition, this class provides several methods for converting a
* long to a String and a
* String to a long, as well as other
* constants and methods useful when dealing with a long.
* 以上是类的使用简介
* @author Lee Boynton
* @author Arthur van Hoff
* 作者列表
* @version 1.64, 03/21/02
* 版本和时间
*/
public final class Long extends Number implements Comparable {
/**代码省略*/
}
摘自sun Jdk1.4源代码，https://www.doczj.com/doc/4e849404.html,ng.Long
【规范5】为每一个方法（函数、过程）编写方法注释。
方法注释位于方法的前面,使用/**/进行注释（对于java，是/***/）。
方法的注释应该说明一下几点：
1)该方法的作用。
2)使用的注意事项（如果需要）。
3)对每一个输入参数进行说明：作用，取值范围等。
4)对返回值进行说明。
5)对每一个抛出的异常进行说明：什么情况下出现该异常。
6)方法注释不要写算法。
例如：
/**
* Executes the given SQL statement, which returns a single
* ResultSet object.
* 以上是该方法的作用
* @param sql an SQL statement to be sent to the database, typically a
* static SQL SELECT statement
* 以上是参数说明
* @return a ResultSet object that contains the data produced
* by the given query; never null
* 以上是返值说明
* @exception SQLException if a database access error occurs or the given
* SQL statement produces anything other than a single ResultSet object
* 以上是异常说明
*/
ResultSet executeQuery(String sql) throws SQLException;
摘自sun Jdk1.4源代码，java.sql.Statement
【规范6】为每一个属性编写属性注释。
属性是类的状态，应该为每一个属性编写注释：说明该属性的作用，如果需要，说明其取值范围，以及使用的注意事项。
例如：
/**
* The size of the ArrayList (the number of elements it contains).
*/
private int size;
摘自sun Jdk1.4源代码，java.uitl.ArrayList
/** The value is used for character storage. */
private char value[];
摘自sun Jdk1.4源代码，https://www.doczj.com/doc/4e849404.html,ng.String
【规范7】不要编写修饰性的注释。
我们需要的是有用的代码，而不是漂亮的代码。
例如以下的注释是不被推荐的：
/***********************************************************
* The size of the ArrayList (the number of elements it contains).
***********************************************************/
【规范8】为每一个局部变量编写行末注释。
行末注释的好处是：具有明显的针对性。
例如：int length = 0; //the length of the array,initial to zero.
【规范9】在具有复杂算法的代码块前，说明其算法。
例如：
/*
* 以下的代码采用二分法对链表进行排序，具体算法是…
*
*/
【规范10】为每一个for、while、do-whil e循环，if、else if、else、switch-case分支，try-catch-finally块编写注释。
这样的地方通常体现了代码逻辑。对于复杂的代码块，可以采用/**/注释，对于简单的代码块，采用行末注释。
【规范11】对于临时代码，编写详细的注释。
临时代码就是目前不使用的，但是也许以后会用到的代码。对于这样的代码，我们通常使用/**/把它们注释起来：
1)说明注释的原因。
2)说明注释者，和注释时间。
3)说明在什么情况下，可以恢复代码。
4)说明在什么情况下，这些代码需要彻底删除。
5)代码一旦正式发布，必须彻底删除这些注释。
例如：
/*
* 有于xxx原因，将以下代码注释。
* 注释者：Sam Lee，时间 2004/03/04
* 只有xxx的情况下，才可继续使用下面的代码。
* 如果发布之前仍未使用，则删除这些代码
int a = 0;
*/
【规范12】尽量使你的注释简单。
例如：
//采用Iterator遍历整个缓冲区，根据对象最后一次使用的时间，删除过期的对象
while(cache.Iterator().hasNext());
//删除缓冲区中过期的对象
while(cache.Iterator().hasNext());
【建议】在编写代码之前，编写你的注释。
编写注释有助于你仔细的思考你的代码。如果你以前没有这个习惯，请尽量养成它，你会体会到它的好处。
【规范13】对于Java、Java Script、Object ，按照JavaDoc规范编写注释。
请参考【规范4】、【规范5】、【规范6】，这3个规范规定的注释，形成了JavaDoc。
【规范14】对于文档注释（即【规范4】、【规范5】、【规范6】规定的注释），应该只说明“为什么这样做”，而不需要说明“怎样做”。
4命名规范
【规范1】必须慎重的、认真的为你的每一个包、类、方法、变量命名。
说明：要起一个科学合理的名字，因为名字是理解代码的重要依据。同时，一旦代码发布，其依赖者、继承者都要永远维持这种命名。想像一下，如果你和你的同事不得不使用类似tj（统计？条件？）这样的名字，而又不能改变现状（会影响其他使用者），那该是一件多么痛苦的事情。
【规范2】遵循技术框架的命名规范。
【规范3】必须采用英文命名。
说明：英文是全世界软件业通用的交流语言。
【规范4】采用有意义的单词，要求望文知意。
【规范5】可以采用一个单词或多个单词或单词的缩写作为名字，缩写单词的每个字母都要大写。
【规范6】对于难以使用英文的情况，可以参考相关行业标准，比如使用国标。
【规范7】不要使用冠词。
例如：anUser，thePassword，someEmps，没有必要使用冠词。但是在命名的时候，要注意名词复数，例如：users、actions。
【规范8】采用约定俗成的习惯用法。
例如：getUsername比receiveUsername好，虽然它们表达的意思相同。
常见的习惯用法：
?循环变量：i、j、k、m、n
?临时变量：tmp、temp
?数据库：conn、stmt、pstmt、rs、rowSet
?长度：length
?数量：count
?位置：pos或position
?下标或索引：index
?设置/获取：set/get
?布耳变量的命名：isXXX，例如：isEmptySet
?大小：size
?工具类所在的包：util
【规范9】属性、变量、方法参数的命名规范（适用于Java、JavaScript、Object C）。
?首字母小写，其他单词首字母大写。例如：userPrivilege
?采用名词。例如：connection(而不是Connect)
?关于缩写，必须符合【规范3】
【规范10】类、接口命名规范：
?首字母大写，其他单词首字母大写。例如：BufferedStreamReader
?采用名词。
?采用单数形式，因为类或者接口代表了“一类”事物，因此通常采用单数形式。
?关于缩写，必须符合【规范3】
【规范11】包的命名规范：
?包名所有字母都要小写。
?顶级包名采用开发者所在机构的域名的逆序。例如：org.honqun、org.jboss ?非顶级包名采用名词，或名词的缩写。
?如果不在本机构外部发布，可以直接使用项目、产品名称作为顶级包。
【规范12】方法（函数）的命名规范：
?首字母小写，其他单词首字母大写（java专用）。例如：buildXML
?采用强动词。例如：createJSPPage
?关于缩写，必须符合【规范3】
?构造方法的名字与类名相同――语法的要求。
【规范13】常量的命名规范：
常量的每一个字母大写，单词之间用下划线分隔。常量的名字必须涵盖该常量的准确意义。
例如：private static final int MAX_PATH = 255;
【规范14】数组的命名规范：
数组应该总是用下面的方式来命名：
byte[] buffer;
而不是：
byte buffer[];
【规范15】存取器(accesser)方法的命名规范：
?存取器方法用于获取类的一个属性或设置类的一个属性。
?存取器后的单词与对应的属性名称相同，但是首字母大写（符合【规范10】）。
存取器方法的参数与对应的属性名称尽量相同。
【规范16】禁止使用“magic value”
不可为变量直接赋予非零数字或者表现为数字的字符串，请将这些数值定义为常量，大量的常量可以单独提取为常量类。不可重复的使用一个字符串，请将经常使用的字符串定义为常量。
以下是使用magic value的例子：
5异常处理规范
【规范1】如果需要自定义异常（Exception），那么请使用“非可检查”异常，“非可检查”异常不会强制使用者处理异常，极大的简化了代码的复杂程度，提高了代码的可读性。【规范2】如果所使用的API抛出了“可检查”异常，那么在处理异常的时候可以将多个不同的异常同时处理。
【规范3】尽量使用系统提供的异常。
例如：如果方法参数验证失败，则抛出throw new IllegalArgumentException。
【规范4】处理异常，至少做以下工作：
1）输出异常栈。
2）用warning或者error记录日志。
3）如果需要，重新抛出异常，抛出的异常必须是一个“非可检查”异常。
【规范5】不要用异常代替逻辑。
“异常”代表了不可预测的情况，而逻辑一定是可以预测的，因此，不要用异常代替逻辑。简单的说，在catch代码中只能有处理异常的代码，不能加入逻辑代码。
6其他规范
【规范1】禁止拷贝粘贴代码。当你Copy-Paste 代码的时候，说明代码中存在重复，重复的代码往往导致代码难以维护和阅读。一旦那些保存在剪切板中的代码中存在错误，编写者甚至不知道到哪里修改这些错误。每当你Copy-Paste 代码的时候，请停下来，考虑将这些代码提取为方法、类或者组件。
【规范2】对于暂时无法实现的代码，使用// TODO:进行注释。下面的代码，用于处理日期
【规范3】禁止使用FIXME注释，与其将BUG留给别人处理，不如现在就解决它。
【规范4】对于不被推荐使用的API方法，如果为了兼容性不能删除这个方法，那么请用文档注释和注解进行标注，并说明不推荐使用的原因和替换方案，以及在哪个版本中删除这个
方法。
/**
@deprecated Only return the length of the indent string. @see{@link #taskUnassigned} */
@Deprecated
TaskQuery taskUnnassigned();
知识管理系统代码编写规范 一、介绍 本文档为《知识管理系统》代码编写规范，为保证代码风格的一致性和后期的可维护性，文档讲述的内容要求所有开发人员必须遵守。 本规范主要参考了Google Java Style，包括了其他一些业界约定俗成的公约和普遍采用的标准。本规范并非最终标准，一些规定还需再做商讨。 1.1 术语说明 本文档除非特殊说明，否则： 1. 类（class）统指普通类、枚举类、接口和注解类型。 2. 注释（comment）只用来指实现注释（implementation comments）。我们不使用“文 档注释”这样的说法，而会直接说Javadoc。 其他“术语说明”，将在文档中需要说明的地方单独说明。 1.2 文档说明 本文档中的代码并不一定符合所有规范。即使这些代码遵循本规范，但这不是唯一的代码方式。例子中可选的格式风格也不应该作为强制执行的规范。
二、源码文件基础 2.1 文件名 源文件以其最顶层的类名来命名，大小写敏感，文件扩展名为.java。 2.2 文件编码：UTF-8 源码文件使用UTF-8编码。 2.3 特殊字符 2.3.1 空格字符 除了换行符外，ASCII 水平空白字符（0x20）是源码文件中唯一支持的空格字符。这意味着： 1. 其他空白字符将被转义。 2. Tab字符不被用作缩进控制。 2.3.2 特殊转义字符串 任何需要转义字符串表示的字符（例如\b, \t, \n, \f, \r, \", \'和\\等），采用这种转义字符串的方式表示，而不采用对应字符的八进制数（例如\012）或Unicode 码（例如\u000a）表示。 2.3.3 非ASCII 字符 对于其余非ASCII字符，直接使用Unicode字符（例如∞），或者对应的Unicode 码（例如\u221e）转义都是允许的。唯一需要考虑的是，何种方式更能使代码容易阅读和理解。
? 软件销售代理合同范本软件代码编写规范 草稿 2005.2
? 软件销售代理合同范本 1 命名规则 https://www.doczj.com/doc/4e849404.html,命名规则 一致的命名模式是托管类库中可预知性与可发现性最重要的元素之一。对这些命名指南广泛的使用和理解将消除许多最常见的用户问题。本主题提供.NET Framework 类型的命名指南。对于每个类型，还应该注意关于大写样式、区分大小写和措词的一些通用规则。 1.1.1大写样式 描述用于在类库中命名标识符的Pascal 大小写、Camel 大小写和全部大写样式。 使用下面的三种大写标识符约定。 Pascal 大小写 将标识符的首字母和后面连接的每个单词的首字母都大写。可以对三字符或更多字符的标识符使用Pascal 大小写。例如： B ack C olor Camel 大小写 标识符的首字母小写，而每个后面连接的单词的首字母都大写。例如： b ack C olor 大写 标识符中的所有字母都大写。仅对于由两个或者更少字母组成的标识符使用该约定。例如： System.IO System.Web.UI 可能还必须大写标识符以维持与现有非托管符号方案的兼容性，在该方案中所有大写字母经常用于枚举和常数值。一般情况下，在使用它们的程序集之外这些字符应当是不可见的。 下表汇总了大写规则，并提供了不同类型的标识符的示例。 标识符大小写示例 类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
程序代码注释编写规范 为提高控制程序的阅读性与可理解性，现制定相关代码程序代码注释编写的编写规范。 一般情况下，源程序有效注释量必须在20％以上，注释的原则是有助于对程序的阅读理解，在该加的地方都加了，注释不宜太多也不能太少，注释语言必须准确、易懂、简洁。 常规注释有以下两种方式。 单行:以"//"符号开始，任何位于该符号之后的本行文字都视为注释。 多行:以"/*"符号开始，以"*/"结束。任何介于这对符号之间的文字都视为注释。 一、说明性文件 说明性文件（如头文件.h文件、.inc文件、.def文件、编译说明文件.cfg等）头部应进行注释，注释必须列出：版权说明、版本号、生成日期、作者、内容、功能、与其它文件的关系、修改日志等，头文件的注释中还应有函数功能简要说明。 示例：下面这段头文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************* COPYRIGHT (C), MicTiVo International. Co., Ltd. File NAME: // 文件 Author: Version: Date: // 作者、版本及完成日期 DESCRIPTION: // 用于详细说明此程序文件完成的主要功能，与其他模块 // 或函数的接口，输出值、取值范围、含义及参数间的控 // 制、顺序、独立或依赖等关系 Others: // 其它内容的说明 Function List: // 主要函数列表，每条记录应包括函数名及功能简要说明 1.... History: // 修改历史记录列表，每条修改记录应包括修改日期、修改 // 者及修改内容简述 1. Date: Author: Modification: 2. .. *************************************************/ 二、源文件头 源文件头部应进行注释，列出：版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。 示例：下面这段源文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************************ COPYRIGHT (C), MicTiVo International. Co., Ltd. FileName: Author:
百度文库- 让每个人平等地提升自我 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、使用可以准确说明变量/字段/类的完整的英文描述符。例如，采用类似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、避免使用装饰性内容，不要使用象广告横幅那样的注释语句。
程序编写规范及约定 (仅供内部使用) 文档作者：_______________ 日期：___/___/___ 开发/测试经理：_______________ 日期：___/___/___ 项目经理：_______________ 日期：___/___/___ 请在这里输入公司名称 版权所有不得复制
目录 程序编写规范及约定 (3) 1编写目的 (3) 2代码编写风格 (3) 2.1单元风格 (3) 2.2语句风格 (3) 3命名规则 (3) 3.1命名约定 (3) 3.1.1标志符 (3) 3.1.2类class (3) 3.1.3枚举类型enum (4) 3.1.4委托delegate (4) 3.1.5常量const (4) 3.1.6接口interface (4) 3.1.7方法function (4) 3.1.8命名空间namespace (4) 3.1.9参数 (4) 3.1.10局部变量 (5) 3.1.11数据成员 (5) 3.1.12自定义异常类 (5) 3.1.13命名缩写 (5) 3.1.14数据库命名 (5) 3.2代码编写命名规范 (6) 3.3界面常用控件命名约定 (6) 3.4文件命名规范 (7) 3.4.1文档文件命名 (7) 3.4.2配置文件命名 (7) 3.4.3程序文件命名 (7)
程序编写规范及约定 1编写目的 为了使编写代码具有可读性、可理解性、可维护性，对程序编写人员代码实行统一风格，使得程序代码能够以名称反映含义、以形式反映结构。此文档可供程序代码编写人员及代码维护人员使用。 2代码编写风格 2.1单元风格 2.2语句风格 3命名规则 3.1命名约定 Pascal和Camel命名约定： 编程的命名方式主要有Pascal和Camel两种（Pascal：每个单词的首字母大写，例如ProductType；Camel：首个单词的首字母小写，其余单词的首字母大写，例如productType） 3.1.1标志符 规则：Pascal、Camel 实例与描述：例子说明 3.1.2类class 规则：Pascal 实例与描述：Application
命名规范： 1.所有的标识都只能使用ASCII字母（A-Z或a-z）、数字（0-9）和 下划线”_”。 2.一个唯一包名的前缀总是用全部小写的字母。 3.类名是一个名词，采用大小写混合的方式，每个单词的首字母大 写。 4.接口的大小写规则与类名相似。 5.方法名是一个动词或是动词词组，采用大小写混合的方式，第一 个单词的首字母小写，其后单词的首字母大写。 6.变量名的第一个字母小写，任何中间单词的首字母大写，变量名 应简短且可以顾名思义，易于记忆。避免单个字符的变量名，除非是一次性的临时变量。 7.常量的声明应该全部大写，每个单词之间用”_”连接。 注释规范： 1.注释尽可能使用”//”,对于所有的Javadoc的注释使用/***/，而 临时对代码块进行注释应尽量使用/**/。 2.所有的源文件都应该在开头有一个注释，其中列出文件名、日期 和类的功能概述。每个方法必须添加文档注释（main除外）。 3.每个属性必须加注释。 4.代码中至少包含15%的注释。 5.注释使用中文。
缩进排版规范： 1.避免一行的长度超过60个字符。 2.使用Eclipse源代码的格式化功能完成代码的缩进排版。 文件名规范： 1.一个Java源文件只能储存一个Java类。 2.文件名与Java类相同。 3.一个类文件不超过200行。 声明规范： 1.一行声明一个变量。 2.不要将不同类型变量的声明放在同一行。 3.只在代块的开始处声明变量。 4.所有的变量必须在声明时初始化。 5.避免声明的局部变量覆盖上一级声明的变量。 6.方法与方法直接以空行分隔。 语句规范： 1.每行至少包含一条简单语句。 2.在return语句中，返回值不使用小括号”()”括起来。 3.If月总是用{和}括起来。 4.在for语句的初始化或者更新子句中，避免因使用3个以上变量， 而导致复杂度提高。 5.当switch的一个case顺着往下执行时（因为没有break），通常 应在break语句的位置添加注释。
软件开发代码规范（C#版） 拟制:日期：2007-2-13审核:日期： 审核:日期： 批准:日期： 版权所有 ********有限公司
修订纪录
目录 注：Pascal命名法则：即名称中所有单词的第一个字母大写其他字母使用
小写形式。 Camel命名法则：即名称中第一个单词各个字母全部小写，其他部分遵循Pascal命名法则。 1、第一章命名规范 1.1、第一节总则 1．本命名规则除特殊提及外统一使用Camel命名法则。 如：controlMenu 2．命名时尽量不使用拼音，更不可使用拼音缩写（专有名词除外）。 3．如果使用品牌名称命名时其大小写尽量保持和品牌名称一致的样式。 如：LuX则命名时，不要写成LUX，或者Lux，而应该保持与原品牌名称风格一致使用LuX 4．使用专有名词或英文缩写命名时采用大写形式。 如：CNNIC 5．禁止使用仅区分大小写的方式命名。 如：Abc与abc仅用大写A来区分，这样写在类C系语言中不会出错，但是不利于系统的迁移
、第二节变量命名规范 1.2.1、CodeBehind内部命名规范 1．公有字段/属性使用Pascal 命名规则，私有变量/保护变量/局部变量使用Camel命名规则，遵循动宾结构。 例： public class Hello { private string userName; private DateTime loginTime; private bool isOnline; public string UserName { get { return ; } } } 2．即使对于可能仅出现在几个代码行中的生存期很短的变量，仍然使用意义描述性的名称。仅对于短循环索引使用单字母变量名，如 i 或 j 3．在变量名中使用互补对，如 Min/Max、Begin/End 和 Open/Close。 4．当一个方法内部变量繁多的时候，可以使用Camel命名法则，其中第一个单词可以使用变量类型的缩写来说明以示区别。 例：
安全代码编写规范 一、编写目的 为加强武汉楚烟信息技术有限公司在软件开发中的安全规范要求，减少应用上线后带来潜在的安全风险，特拟定安全代码编写规范。二、使用范围 本规范适用于武汉楚烟信息技术有限公司承建的各类开发类的软件类项目。 三、应用安全设计 在总体架构设计阶段，需明确与客户方沟通确认甲方对于软件安全的相关要求，对于有明确安全要求的（例如授权管理要求、用户认证要求、日志审计要求等），须在设计文档中予以详细说明。对于互联网应用，务必明确网络安全、应用安全、数据安全相关的安全防护手段。 在技术架构上，应采用表现层、服务层、持久层分类的架构，实现对底层业务逻辑进行有效隔离，避免将底层实现细节暴露给最终用户。 在部署架构上，应采用应用服务器、数据库服务器的分离部署模式，在应用服务器被攻击时，不会导致核心应用数据的丢失。如软件产品具备有条件时，应优先采用加密数据传输方式（例如https协议）。 在外部接口设计方面，应采用最小接口暴露的原则，避免开发不必要的服务方法带来相关安全隐患，同时对于第三方接口，应共同商定第三方接入的身份认证方式和手段。
四、应用安全编码 4.1. 输入验证 对于用户输入项进行数据验证，除常见的数据格式、数据长度外，还需要对特殊的危险字符进行处理。特殊字符包括<> " ' % ( ) & + \ \' \"等 对于核心业务功能，除在客户端或浏览器进行数据验证外，还必须在服务器端对数据进行合法性检验，规避用户跳过客户端校验，直接将不合规的数据保存到应用中。 对于浏览器重定向地址的数据，需要进行验证核实，确认重定向地址是否在可信，并且需要对换行符（\r或\n）进行移除或者替换。 4.2. 数据输出 对需要输出到用户浏览器的任何由用户创造的内容，应在输出到浏览器之前或持久化存储之前进行转义(至少对<>转义为< >)以防止跨站攻击脚本(XSS)。对于无法规避的HTML片段提交，需对 嵌套的节点应该缩进; 在属性上使用双引号（字符串拼接除外）; 属性名全小写，用“-”做分隔符; 自动闭合标签处不能使用斜线。
代码编写规范说明书（c#.net与https://www.doczj.com/doc/4e849404.html,）目录 1 目的 2 范围 3 注释规范 3.1 概述 3.2 自建代码文件注释 3.3 模块（类）注释 3.4 类属性注释 3.5 方法注释 3.6 代码间注释 4 命名总体规则 5 命名规范 5.1 变量（Variable）命名 5.2 常量命名 5.3 类（Class）命名 5.4 接口（Interface）命名 5.5 方法（Method）命名 5.6 名称空间Namespace）命名 6 编码规则 6.1 错误检查规则 6.2 大括号规则 6.3 缩进规则 6.4 小括号规则 6.5 If Then Else规则 6.6 比较规则 6.7 Case规则 6.8 对齐规则 6.9 单语句规则 6.10 单一功能规则 6.11 简单功能规则 6.12 明确条件规则 6.13 选用FALSE规则 6.14 独立赋值规则 6.15 定义常量规则 6.16 模块化规则 6.17 交流规则 7 编程准则 7.1 变量使用 7.2 数据库操作 7.3 对象使用 7.4 模块设计原则 7.5 结构化要求 7.6 函数返回值原则 8 代码包规范 8.1 代码包的版本号
8.2 代码包的标识 9 代码的控制 9.1 代码库/目录的建立 9.2 代码归档 10 输入控制校验规则 10.1 登陆控制 10.2 数据录入控制 附件1：数据类型缩写表 附件2：服务器控件名缩写表 1 目的 一.为了统一公司软件开发设计过程的编程规范 二.使网站开发人员能很方便的理解每个目录,变量，控件，类，方法的意义 三.为了保证编写出的程序都符合相同的规范，保证一致性、统一性而建立的程序编码规范。 四.编码规范和约定必须能明显改善代码可读性，并有助于代码管理、分类范围适用于企业所有基于.NET平台的软件开发工作 2 范围 本规范适用于开发组全体人员，作用于软件项目开发的代码编写阶段和后期维护阶段。 3 注释规范 3.1 概述 a) 注释要求英文及英文的标点符号。 b) 注释中，应标明对象的完整的名称及其用途，但应避免对代码过于详细的描述。 c) 每行注释的最大长度为100个字符。 d) 将注释与注释分隔符用一个空格分开。 e) 不允许给注释加外框。 f) 编码的同时书写注释。 g) 重要变量必须有注释。 h) 变量注释和变量在同一行，所有注释必须对齐，与变量分开至少四个“空格”键。 如：int m_iLevel,m_iCount; // m_iLevel ....tree level // m_iCount ....count of tree items string m_strSql; //SQL i) 典型算法必须有注释。 j) 在循环和逻辑分支地方的上行必须就近书写注释。 k) 程序段或语句的注释在程序段或语句的上一行 l) 在代码交付之前，必须删掉临时的或无关的注释。 m) 为便于阅读代码，每行代码的长度应少于100个字符。 3.2 自建代码文件注释 对于自己创建的代码文件（如函数、脚本），在文件开头，一般编写如下注释： /****************************************************** FileName: Copyright (c) 2004-xxxx *********公司技术开发部 Writer: create Date: Rewriter:
源代码编写规范 版本<1.0>
1简介 (4) 1.1目的 (4) 1.2范围 (4) 2代码格式规范 (4) 3代码注释规范 (5) 4命名规范 (9) 5异常处理规范 (11) 6其他规范 (11)
1简介 1.1目的 本文用于定义本公司程序编码规范。本文的目的在于规范和指导软件编程活动，作为考核标准。 1.2范围 本文仅用于指导软件编程工作，同时作为其他分析和设计工作的参考资料。本文的预期读者是：软件工程师/设计员、程序员。 本公司各项目可以采用不同的编程语言，并参照本规范和各语言的习惯定义各自的编程规范，但是必须经过评审通过。编程规范一旦通过评审，任何人在编程活动中都必须遵循。 2代码格式规范 【规范1】单行代码不得超过120字符。 【规范2】每行代码最多包含一个独立的语句。 【规范3】代码缩进两个空格。 说明：两个空格已经足够清晰了，缩进量过大会导致单行代码很长，反而影响阅读。 【规范4】不要使用TAB缩进代替空格缩进。 【规范5】如果单行代码过长，则应该遵循以下规则断行： ?在逗号的后面。 ?在操作符的前面。 ?断行的起始位置应该对其原行表达式的起始位置，如果无法满足，则缩进2个空格。 【规范6】每一个变量的声明独占一行。 【规范7】将变量的声明置于代码块的开始位置。 【规范8】在java中for、while、do-whil e循环，if、else if、else、switch-case分支，try-catch-finally块即使仅包含一个语句，也要用{}包含。其他语言参照执行。 【规范9】空行的位置： ?在逻辑代码段之间。 ?for、while、do-whil e循环，if、else if、else、switch-case分支，try-catch-finally块的前面。 ?在两个类或接口的定义之间。 ?在两个方法/函数/过程之间。 ?方法/函数/过程内部变量定义行和第一个非变量定义行之间。 ?包含(C++)/引入(Java)完毕之后。 【规范10】空格的位置：
代码安全编写规范 1.安全编码 1.1.通用编码原则 (一)不要信任外部的用户输入或系统。 应用程序应该彻底验证所有用户输入，然后再根据用户输入执行操作。验证可能包括筛选特殊字符。针对用户意外地错误使用和某些人通过在系统中注入恶意命令蓄意进行攻击的情况，这种预防性措施对应用程序起到了保护作用。常见的例子包括 SQL 注入攻击、脚本注入和缓冲区溢出。此外，对于任何非受控的外部系统，都不要假定其安全性。 (二)不要通过隐藏来保障安全。 尝试使用让人迷惑的变量名来隐藏机密信息或将它们存储在不常用的文件位置，这些方法都不能提供安全保障，最好使用平台功能或使用已被证实可行的技术来保护数据。 (三)以安全的方式处理失效 如果应用程序失效（如发生严重错误等），要恰当的进行处理，一定要保护好机密数据。同时，在向最终用户返回错误消息时，不要公开任何不需要公开的信息。也就是不要提供任何有助于攻击者发现应用程序漏洞的详细信息。 1.2.防范常见安全编码问题 在实现应用软件的编码阶段，也较容易因缺乏严谨思考或不好的编程习惯而引入安全问题，而且这些安全问题产生的危害作用非常大，因其产生的漏洞常常会造成应用程序中其他部分构筑的安全控制措施完全失效.目前存在的相当数量系统漏洞都是由编码问题造成的.因此要想保证应用软件的安全性，必须在编码阶段继续高度贯彻安全性原则. 在编码阶段，避免安全问题的基本原则如下： ?程序只实现指定的功能
?永远不要信任用户输入，对用户输入数据做有效性检查 ?必须考虑意外情况并进行处理 ?不要试图在发现错误之后继续执行 ?尽可能使用安全函数进行编程 ?小心、认真、细致地编程 目前在各种应用软件中常见的安全漏洞如下所示，应对这些常见问题进行有针对性的防范。 1.2.1缓冲区溢出 如果对输入参数（字符串、整数等）处理时长度检查不严格，或对指针和数组越界访问不进行保护，就容易产生缓冲区溢出（Buffer Overflow）问题，这种问题主要出现在主要出现在 C/C++ 语言编写的系统中，它造成的漏洞是当今绝大多数安全漏洞的主要根源。在 Java / .NET 等利用虚拟机的(托管)平台上不会产生此问题。 要避免此问题，则必须对系统输入数据进行严格的长度检查，废弃或截断超长的越界数据，同时利用基础库函数中的一些更为安全的字符串处理函数来处理数据，也可以利用编译器或代码复查工具提供的检查功能来尽早发现可能会产生问题的程序。 1.2.2输入非法数据 恶意的攻击者会尝试在用户界面或接口中向系统输入恶意数据，以便期望绕过系统的安全限制，致使系统出甚至崩溃或其他非法目的，因此在编码时，须要对所有输入数据 (包括用户在界面中输入的数据和其他应用系统通过接口传递的数据)进行严格的合法性检查。 1.2.3SQL 注入式攻击 SQL 注入式（SQL Injection）攻击是一种典型的，因对输入数据不当处理而产生的非常严重的安全漏洞。其原因是基于数据库的应用程序中经常会使用动态 SQL 语句，而且在程序又没有对输入数据严格检查，致使攻击者能在界面层或接口层注入非法的 SQL 语句，从而非法访问和破坏数据、反向工程、甚至对服务器本身造成
引言 软件设计更多地是一种工程，而不是一种个人艺术。如果不统一编程规范，最终写出的程序，其可读性将较差，这不仅给代码的理解带来障碍，增加维护阶段的工作量，同时不规范的代码隐含错误的可能性也比较大。 分析表明，编码阶段产生的错误当中，语法错误大概占20%左右，而由于未严格检查软件逻辑导致的错误、函数（模块）之间接口错误及由于代码可理解度低导致优化维护阶段对代码的错误修改引起的错误则占了一半以上。 可见，提高软件质量必须降低编码阶段的错误率。如何有效降低编码阶段的错误呢？这需要制定详细的软件编程规范，并培训每一位程序员，最终的结果可以把编码阶段的错误降至10%左右，同时也降低了程序的测试费用，效果相当显著。 本文从代码的可维护性（可读性、可理解性、可修改性）、代码逻辑与效率、函数（模块）接口、可测试性四个方面阐述了软件编程规范，规范分成规则和建议两种，其中规则部分为强制执行项目，而建议部分则不作强制，可根据习惯取舍。 1．排版 规则1 程序块使用缩进方式，函数和标号使用空格缩进，程序段混合使用TAB和空格缩进。缩进的目的是使程序结构清晰，便于阅读和理解。 默认宽度应为8个空格，由于Word中为4个空格，为示范清晰，此处用2个代替(下同)。例如： MOV R1, #00H MOV R2, #00H MOV PMR, #PMRNORMAL MOV DPS, #FLAGDPTR MOV DPTR, #ADDREEPROM read1kloop: read1kpage: INC R1 MOVX A, @DPTR MOV SBUF, A JNB TI, $ CLR TI INC DPTR CJNE R1, #20H, read1kpage INC R2 MOV R1, #00H CPL WDI CJNE R2, #20H, read1kloop ;END OF EEPROM 规则2
一、规范存在的意义 应用编码规范对于软件本身和软件开发人员而言尤为重要，有以下几个原因： 1、好的编码规范可以尽可能的减少一个软件的维护成本 , 并且几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护； 2、好的编码规范可以改善软件的可读性，可以让开发人员尽快而彻底地理解新的代码； 3、好的编码规范可以最大限度的提高团队开发的合作效率； 4、长期的规范性编码还可以让开发人员养成好的编码习惯，甚至锻炼出更加严谨的思维； 二、命名规范 1、一般概念 1、尽量使用完整的英文描述符 2、采用适用于相关领域的术语 3、采用大小写混合使名字可读 4、尽量少用缩写，但如果用了，必须符合整个工程中的统一定义 5、避免使用长的名字（小于 15 个字母为正常选择） 6、避免使用类似的名字，或者仅仅是大小写不同的名字 7、避免使用下划线（除静态常量等） 2、标识符类型说明 1、包（ Package ）的命名 Package 的名字应该采用完整的英文描述符，都是由一个小写单词组成。并且包名的前缀总是一个顶级域名， 通常是 com、edu、gov、mil、net、org 等； 如： com.yjhmily.test
2、类（ Class ）的命名 类名应该是个一名词，采用大小写混合的方式，每个单词的首字母大写。尽量保证类名简洁而富于描述。 使用完整单词，避免缩写词( 除非工程内有统一缩写规范或该缩写词被更广泛使用，像 URL ， HTML) 如： FileDescription 3、接口（ Interface ）的命名 基本与Class 的命名规范类似。在满足Classd 命名规则的基础之上，保证开头第一个字母为 ”I”， 便于与普通的Class区别开。其实现类名称取接口名的第二个字母到最后，且满足类名的命名规范； 如： IMenuEngine 4、枚举（ Enum ）的命名 基本与Class 的命名规范类似。在满足Classd 命名规则的基础之上，保证开头第一个字母为 ”E” ， 便于与普通的 Class区别开。 如： EUserRole 5、异常（ Exception ）的命名 异常（Exception ）通常采用字母e 表示异常，对于自定义的异常类，其后缀必须为 Exception 如： BusinessException 6、方法（ Method ）的命名 方法名是一个动词，采用大小写混合的方式，第一个单词的首字母小写，其后单词的首字母大写。 方法名尽可能的描述出该方法的动作行为。返回类型为Boolean 值的方法一般由“ is ”或“ has ”来开头 如： getCurrentUser() 、 addUser() 、 hasAuthority() 7、参数（ Param ）的命名 第一个单词的首字母小写，其后单词的首字母大写。参数量名不允许以下划线或美元符号开头， 虽然这在语法上是允许的。参数名应简短且富于描述。 如： public UserContext getLoginUser(String loginName);