软件源代码编写规范
1. 目的 (3)
2. 适用范围 (3)
3. 规范内容 (3)
3.1. 基本要求 (3)
3.1.1. 程序结构要求 (3)
3.1.2. 可读性要求 (3)
3.1.3. 结构化要求 (4)
3.1.4. 正确性与容错性要求 (4)
3.2. 标识符命名及书写规则： (5)
3.2.1. 基本规则 (5)
3.3. 注释 (5)
3.3.1. 注释及格式要求 (5)
3.3.2. 源代码文件的注释 (6)
3.3.3. 函数或过程的注释 (6)
3.3.4. 语句的注释 (6)
3.3.5. 常量和变量的注释 (6)
3.3.6. 文件的注释模板 (7)
3.4. 其他要求 (7)
1.目的
良好的编程风格是提高程序可靠性非常重要的手段，也是大型项目多人合
作开发的技术基础。本规范的目的在于通过规范定义来避免不好的编程风
格，增强程序的易读性，便于自己和其它程序员理解。
2.适用范围
本规定适用于所有软件的源程序编写。客户有特殊要求时，则遵循客户提
出的要求。
3.规范内容
3.1.基本要求
3.1.1.程序结构要求
1）程序结构清晰，简单易懂，单个函数的程序代码行数建议不超过100行，函数功能尽量单一。
2）目标明确，代码简洁清晰，单行代码最大字符数建议不超过120个。
3）避免随意定义全局变量，尽量使用局部变量。
3.1.2.可读性要求
1）在保证代码可读性的前提下提高代码执行效率，对执行效率要求比较高的关键代码可以除外。
2）保持注释与代码完全一致，当代码更改后及时更新相应的注释。
3）每个源程序文件，都有文件头说明，说明内容见“源代码文件的注释”。
4）每个函数，都有函数头说明，说明内容见“函数或过程的注释”。
5）函数中尽量减少输出参数的使用。
6）主要变量（结构、联合、类或对象）定义或引用时，添加注释，反映其含义。
7）处理过程的每个主要阶段、典型算法前都应有相应的简单说明性注释。
8）利用缩进来显示程序的逻辑结构，缩进量一致并以Tab键为单位，不建议使用空格。
9）循环、分支层次尽量不要超过五层。建议多层循环在每层循环结束语句后注释说明退出的相应层次。
10）注释的位置可以在相应代码的上一行或同一行。
11）一目了然的语句不加注释。
12）常量定义（DEFINE）有相应说明。
3.1.3.结构化要求
1）不建议使用GOTO语句。
2）用IF 语句来强调只执行两组语句中的一组。不建议使用ELSE GOTO 和ELSE RETURN。
3）避免从循环引出多个出口。
4）避免不必要的分支。
3.1.
4.正确性与容错性要求
1）除特殊使用情况，所有变量在定义时建议进行初始化。
2）对所有的用户输入，建议在函数或程序开始前进行合法性检查。
3）在修改错误前首先考虑是否对其它代码的影响，避免因此产生新的错误。
4）使用规范的容错语句，提供完善的异常处理措施，如文件能否逻辑锁定、打印机是否联机等,对于明确的错误,要有明确的容错代码提示用户。
3.2.标识符命名及书写规则：
3.2.1.基本规则
1）这里的标识符是指编程语言中语法对象的名字，它们有常量名、变量名、函数名、类和类型名、文件名等，标识符的基本语法是以字母开始，由
字母数字及下划线组成的单词。建议全局变量用g_开头，局部变量用
m_开头。
2）标识符本身最好能够表明其自身的含义，以便于使用和他人阅读。按其在应用中的含义由一个或多个词组成。可以是英文词或中文拼音词。
3）标识符的基本形式建议为：
范围标志+ 类型标志+ 含义
范围标志为g_、m_或者其他变量作用范围标志；类型标志可以为变量的类型，如str（string类型）、i（int类型）、f（float类型）、txt（文本
框控件类型）等；含义可以是任意的词组，当标识符由多个词组成时，
每个词的第一个字母大写，其余全部小写。例如：m_strMyExample。
常量标识符全部大写。中文词由中文描述含义的每个汉字的头一个拼音字母组成。英文词尽量不缩写，如果有缩写，在同一系统中对同一单
词使用相同的表示法。
4）标识的总长度尽量不要超过32个字符。
3.3.注释
3.3.1.注释及格式要求
注释总是加在程序的需要一个概括性说明或不易理解或易理解错的地方。
注释应语言简炼、易懂而又准确，所采用的语种首选是中文，如有输入困
难、编译环境限制或特殊需求也可采用英文。
3.3.2.源代码文件的注释
1）在文件的头部应标明程序名称，它所完成的主要功能。
2）文件的创建者、创建时间、版本。
3）公司名称、版权。
4）阶段测试结束后，主要修改活动的修改人、时间、简单原因说明列表。
5）维护过程中需要修改程序时，应在被修改语句前面注明修改时间和原因说明。
3.3.3.函数或过程的注释
1）在函数头部应对函数进行功能和参数（值参、变参）说明；
2）在函数的主体部分，如算法复杂时，应以注释的方式对其算法结构作出说明；
3）函数申请过全局资源且有可能导致资源紧张应加以注明(如内存，文件柄等)；
4）函数有副作用建议以十分醒目的方式（如加!号等）注明。
3.3.
4.语句的注释
1）应对不易理解的分支条件表达式加注释；
2）不易理解的循环，应说明出口条件；
3）过长的函数实现，应将其语句按实现的功能分段加以概括性说明；
4）供别的文件或函数调用的函数，避免使用全局变量交换数据。
3.3.5.常量和变量的注释
在常量名字(或有宏机制的语言中的宏)声明后应对该名字作适当注释，注释说明的要点是：
1）被保存值的含义(必须)；
2）合法取值的范围(可选)；
3）全局量需要对以上逐点做充分的说明。
3.3.6.文件的注释模板
/*
* =========================================================
* 文件名: PlotItemSetting.h
* 描述: 曲线设置头文件
* 版本号: 1.1
* 创建日期: 2010-4-1 15:52:03
* IDE环境: Microsoft Visual Studio 2005 ( sp1 )
* 字符编码: UTF-8
* 作者: XXX
* 版权所有: XXXXXX技术有限公司
* 版本修改历史:
* 2011-4-1 XXX:创建文件
* 2011-4-22 XXX:增加方法Sub、Add
* ===========================================================
*/
3.4.其他要求
1）项目组可以根据实际需要，对本规范内的条款进行补充说明，或者增加新的条款，但不得与本规范的原条款相冲突。
2）如补充条款与本规范不一致的，以本规范为准。
程序设计综合训练<图书馆管理系统> 设计报告 院系：材料科学与工程学院 专业班级：材料成型一班 姓名：张成智 学号： 20111402128 指导老师：肖老师
一、程序功能简介 图书排序功能 1）按图书编号排序 可以按图书编号的大小排序，显示到屏幕上。（从小到大） 2）按图书出版时间排序 可以按图书出版时间的前后排序，显示到屏幕上。（从近到远） 3）按图书价格排序 可以按图书价格的贵宜排序，显示到屏幕上。（从便宜到贵） 4）按图书书名排序 可以按图书书名字符的大小排序，显示到屏幕上。（从小到大） 5）按图书作者名排序 可以按图书作者名字符的大小排序，显示到屏幕上。（从小到大） 二、本人完成的主要工作 图书排序功能（排序比较简单只要做出来一个，其他都和它雷同。） 三、设计方案 1.设计分析； 1)序功能简介： s 进入系统
|| 2）各个功能流程图 1、按图书编号排序 菜单 1-添加图书 4-图书排序 5-查询图书 6-修改图书 7-录入数据 0-退出系统 2-删除图书 3-图书列表 输入编号、书名、 作者名、出版社、 类别、出版时间、 价格。 按照编号、书名、作者名、出版社、类别、出版时间、 价格进行删除。 按照编号、书名、作者名、出版社、类别、出版时间、 价格进行列出。 按照编号、书名、作者名、出版社、类别、出版时间、 价格进行排列。 按照编号、书名、作者名、出版社、类别、出版时间、 价格进行咨询。 依次录入编号、书名、作者名、出版社、类别、出版时间、 选择编号、书名、作者名、出版社、类别、出版时间、 价格进行修改。 输入0返回原始菜单。
知识管理系统代码编写规范 一、介绍 本文档为《知识管理系统》代码编写规范，为保证代码风格的一致性和后期的可维护性，文档讲述的内容要求所有开发人员必须遵守。 本规范主要参考了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）转义都是允许的。唯一需要考虑的是，何种方式更能使代码容易阅读和理解。
项目代码编程规范 1.应用范围 本规范应用于采用J2EE规范的项目中，所有项目中的JAVA代码（含JSP，SERVLET，JAVABEAN，EJB）JS代码、HTML代码及数据库设计均应遵守这个规范。同时，也可作为其它项目的参考。 2.设计类和方法 2.1. 创建具有很强内聚力的类 方法的重要性往往比类的重要性更容易理解，方法是指执行一个独立逻辑的一段代码。类常被错误的视为是一个仅仅用于存放方法的容器。有些开发人员甚至把这种思路作了进一步的发挥，将他们的所有方法放入单个类之中。 之所以不能正确的认识类的功能，原因之一是类的实现实际上并不影响程序的执行。当一个工程被编译时，如果所有方法都放在单个类中或者放在几十个类中，这没有任何关系。虽然类的数量对代码的执行并无太大的影响，但是当创建便于调试和维护的代码时，类的数量有时会带来很大的影响。 类应该用来将相关的方法组织在一起。 当类包含一组紧密关联的方法时，该类可以说具有强大的内聚力。当类包含许多互不相关的方法时，该类便具有较弱的内聚力。应该努力创建内聚力比较强的类。 大多数工程都包含许多并不十分适合与其他方法组合在一起的方法。在这种情况下，可以为这些不合群的方法创建一个综合性收容类。 创建类时，应知道“模块化”这个术语的含义是什么。类的基本目的是创建相当独立的程序单元。 2.2. 创建松散连接和高度专用的方法 2.2.1.使所有方法都执行专门的任务 每个方法都应执行一项特定的任务，它应出色的完成这项任务。应避免创建执行许多不同任务的方法。 创建专用方法有许多好处。首先调试将变得更加容易。 2.2.2.尽量使方法成为自成一体的独立方法 当一个方法依赖于其他方法的调用时，称为与其他方法紧密连接的方法。紧密连接的方法
技术部源代码控制管理制度V1.0 一、总则 1、目的: 为保障公司源代码安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、使用范围: 本办法适用于所有涉及接触源代码的各部门各岗位，所涉及部门都必须严格执行本管理办法。 3、责权: 源代码直接控制管理部门为技术部。本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个平台系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 二、管理内容及要求(根据部门工作情况撰写) 1、源代码完整性保障 所有系统的源代码及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定SVN库中。
我们研发的平台系统运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的SVN库中。 功能开始编写或者调整代码之前，其相应的设计文档必须签入SVN库（由测试组文档管理员负责检查）。 系统编码或代码调整优化结束后，提交技术测试组功能测试之前，相应的源代码必须提交到SVN库。 测试组对功能进行测试时必须从源代码服务器上的SVN库中获取代码，包括必须的第三方软件、控件和其它支撑库等文件，然后进行测试。 所有提交到SVN上的代码必须保证编译通过,而且提交的时候不会影响主干其它程序的正常运行. 2、源代码的授权访问 源代码服务器对于共享的SVN库的访问建立操作系统级的，基于身份和口令的访问授权。（由SVN管理员进行管理和设置） 在SVN库中设置用户，为不同用户分配不同的、适合工作的最小访问权限。要求连接SVN库时必须校验SVN中用户身份及其口令。在SVN库中要求区别对待不同用户的可访问权、可创建权、可编辑权、可删除权、可销毁权。每个用户切实保证自己的用户身份和口令不泄露,用户要经常更换自己在SVN库中账号的口令。同时，工作任务变化或岗位调整后SVN管理员要实时回收用户的相关权限。要获取不属于自己范围内的文件，例如：代码、数据库，需求文档等，需经项目经理和技术部经理审批同意后由SVN管理员授权。
Git源代码管理规范 一、分支管理 使用git进行源代码管理, 一般将某个项目的所有分支分为以下几条主线: 1.Master 顾名思义, 既然名字叫Master, 那么该分支就是主分支的意思。master分支永远是production-ready的状态, 即稳定可产品化发布的状态。 2.Develop 这个分支就是我们平常开发的一个主要分支了, 不论是要做新的feature还是需要做bug fix, 都是从这个分支分出来做。在这个分支下主要负责记录开发状态下相对稳定的版本, 即完成了某个feature或者修复了某个bug后的开发稳定版本。 3.Feature branches 这是由许多分别负责不同feature开发的分支组成的一个分支系列。new feature主要就在这个分支系列下进行开发。当功能点开发测试完毕之后, 就会合并到develop分支去。
4.release branches 这个分支系列从develop分支出来, 也就是预发分支。在预发状态下, 我们往往会进行预发环境下的测试, 如果出现缺陷, 那么就在该release分支下进行修复, 修复完毕测试经过后, 即分别并入master分支后develop分支, 随后master分支做正常发布。 5.Hotfix branches 这个分支系列也就是我们常说的紧急线上修复, 当线上出现bug且特别紧急的时候, 就能够从master拉出分支到这里进行 修复, 修复完成后分别并入master和develop分支。 下面这张图将完整展示这一个流程
二、工作原理Git的工作方式:
也就是说, 每次提交版本变动的时候, git会保存一个快照(snapshot)。如果文件没有被更改, git也不会再次保存, 而是提供一个到原来文件的链接。这样一来, git更像是一个小型的文件系统。另外, git的所有操作都能够是本地的, 仅仅在将新版本的内容上传到服务器上时才需要连接网络。 Git目录( repository) 是Git保存元数据和对象数据库的地方。这也是Git最重要的部分。
百度文库- 让每个人平等地提升自我 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、避免使用装饰性内容，不要使用象广告横幅那样的注释语句。
命名规范： 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语句的位置添加注释。
项目开发规范文档修订历史记录
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) 成员方法尽量私有化。
? 软件销售代理合同范本软件代码编写规范 草稿 2005.2
? 软件销售代理合同范本 1 命名规则 https://www.doczj.com/doc/d61434944.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
源代码管理制度 1代码管理 1.1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 1.2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。 1.3源代码的授权访问 1、源代码服务器对于共享的SVN库的访问建立操作系统级的，基于身份和口令的访问授权。在SVN库中设置用户，并为不同用户分配不同的权限，适合工作的最小访问权限。
要求连接SVN库时必须校验SVN中用户身份及其口令。在SVN库中要求区别对待不同用户的可访问权、可读权、可写权。 2、曾经涉及、触及源代码的计算机在转作它用，或者离开研发部门之前必须由网络管理人员全面清除计算机硬盘中存储的源代码。如果不能确定，必须对计算机中所有硬盘进行全面格式化后方可以转做它用或离开研发部门。 1.4代码版本管理 1、终端软件的版本标识管理 终端软件版本由终端型号、版本号和内部修订号来进行标识。终端型号：终端型号是硬件标识号，也唯一的标识了我们的项目。版本号：由“＜主版本号＞.＜次版本号＞.＜修订号＞”三段组成，中间是点号分开。版本号的目的主要是管理终端软件的对外发布，终端软件的bug的记录和统计，主要是针对于版本号的，测试部、项目部、客户等会记录某个版本号的终端软件存在哪些bug，bug会在哪个版本号中得到修正。终端软件一个新的版本号出来后，我们会统计新的版本号解决了上一个版本号中的哪些bug，以及增加了哪些新功能，等等。 内部修订号：也就是“应用程序的源代码的svn修订号”，主要是由软件部和测试部内部来使用，内部修订号唯一标识我们的终端软件，即：通过内部修订号能够唯一的找出我们发布的终端软件所对应的全部软件源代码，目的是为了软件排错使用。 另外，终端软件在发布时，还会给出发布日期，以便开发、测试、项目、客户等相关人员参考。 2、终端软件版本发布管理 终端软件主要是以版本号为基准，对外发布，目前采用不定时发布策略，发布的时间由软件部、项目部和客户方根据情况，共同商量决定。 由于目前项目时间紧，终端软件无法得到完整的测试就要发布，在发布之后，有一些需要紧急需要修复的bug，软件部需要紧急修复后就要发布更新包，以便用户能够使用，所以，在一个版本号发布后，需要进行多次修订，对于这些修订的版本，其版本号保持不变，内部修订发生变化。 3、软件bug记录、管理和统计 软件bug的记录、管理和统计主要以版本号为基准，但为了软件开发人员能够找到bug
安全代码编写规范 一、编写目的 为加强武汉楚烟信息技术有限公司在软件开发中的安全规范要求，减少应用上线后带来潜在的安全风险，特拟定安全代码编写规范。二、使用范围 本规范适用于武汉楚烟信息技术有限公司承建的各类开发类的软件类项目。 三、应用安全设计 在总体架构设计阶段，需明确与客户方沟通确认甲方对于软件安全的相关要求，对于有明确安全要求的（例如授权管理要求、用户认证要求、日志审计要求等），须在设计文档中予以详细说明。对于互联网应用，务必明确网络安全、应用安全、数据安全相关的安全防护手段。 在技术架构上，应采用表现层、服务层、持久层分类的架构，实现对底层业务逻辑进行有效隔离，避免将底层实现细节暴露给最终用户。 在部署架构上，应采用应用服务器、数据库服务器的分离部署模式，在应用服务器被攻击时，不会导致核心应用数据的丢失。如软件产品具备有条件时，应优先采用加密数据传输方式（例如https协议）。 在外部接口设计方面，应采用最小接口暴露的原则，避免开发不必要的服务方法带来相关安全隐患，同时对于第三方接口，应共同商定第三方接入的身份认证方式和手段。
四、应用安全编码 4.1. 输入验证 对于用户输入项进行数据验证，除常见的数据格式、数据长度外，还需要对特殊的危险字符进行处理。特殊字符包括<> " ' % ( ) & + \ \' \"等 对于核心业务功能，除在客户端或浏览器进行数据验证外，还必须在服务器端对数据进行合法性检验，规避用户跳过客户端校验，直接将不合规的数据保存到应用中。 对于浏览器重定向地址的数据，需要进行验证核实，确认重定向地址是否在可信，并且需要对换行符（\r或\n）进行移除或者替换。 4.2. 数据输出 对需要输出到用户浏览器的任何由用户创造的内容，应在输出到浏览器之前或持久化存储之前进行转义(至少对<>转义为< >)以防止跨站攻击脚本(XSS)。对于无法规避的HTML片段提交，需对 嵌套的节点应该缩进; 在属性上使用双引号（字符串拼接除外）; 属性名全小写，用“-”做分隔符; 自动闭合标签处不能使用斜线。
1源代码管理 (1) 1.1总则 (1) 1.2源代码完整性保障 (1) 1.3源代码的授权访问 (2) 1.4代码版本管理 (2) 1.5源代码复制和传播 (5) 1.6系统测试验收流程 (5) 1.6.1系统初验 (6) 1.6.2试运行 (6) 1.6.3系统终验 (6) 1.6.4应用系统验收标准 (8) 1.6.5文档评审通过标准 (9) 1.6.6确认测试通过标准 (9) 1.6.7系统试运行通过标准 (10)
1代码管理 1.1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 1.2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。
代码编写规范说明书（c#.net与https://www.doczj.com/doc/d61434944.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: