软件编码规范
中国人民银行清算总中心
支付系统开发中心
注：变化状态：A—增加，M—修改，D—删除
目录
第一篇C/C++编码规范 (6)
第一章代码组织 (6)
第二章命名 (9)
2.1文件命名 (9)
2.2变量命名 (9)
2.3常量与宏命名 (10)
2.4类命名 (10)
2.5函数命名 (10)
2.6参数命名 (11)
第三章注释 (12)
3.1文档化注释 (12)
3.2语句块注释 (17)
3.3代码维护注释 (20)
第四章编码风格 (22)
4.1排版风格 (22)
4.2头文件 (26)
4.3宏定义 (27)
4.4变量与常量 (30)
4.5条件判断 (32)
4.6空间申请与释放 (33)
4.7函数编写 (33)
4.8类的编写 (37)
4.9异常处理 (40)
4.10特殊限制 (40)
第五章编译 (41)
第六章ESQL/C编码 (46)
第二篇JAVA编码规范 (47)
第一章代码组织 (48)
第二章命名 (51)
2.1包命名 (51)
2.2类命名 (51)
2.3接口命名 (51)
2.4方法命名 (51)
2.5变量命名 (51)
2.6类变量命名 (52)
2.7常量命名 (52)
2.8参数命名 (52)
第三章注释 (53)
3.1文档化注释 (53)
3.2语句块注释 (57)
3.3代码维护注释 (59)
第四章编码风格 (61)
4.1排版风格 (61)
4.2包与类引用 (66)
4.3变量与常量 (66)
4.4类编写 (67)
4.5方法编写 (68)
4.6异常处理 (71)
4.7特殊限制 (71)
第五章编译 (73)
第六章JSP编码 (74)
6.1文件命名及存放位置 (74)
6.2内容组织 (74)
6.3编码风格 (76)
6.4注释 (78)
6.5缩进与对齐 (78)
6.6表达式 (79)
6.7JavaScript (79)
第三篇POWERBUILDER编码规范 (80)
第一章代码组织 (81)
第二章命名 (82)
2.1文件命名 (82)
2.2对象命名 (82)
2.3变量命名 (84)
2.4常量命名 (85)
2.5函数与事件命名 (85)
2.6参数命名 (85)
第三章注释 (85)
3.1文档化注释 (85)
3.2语句块注释 (88)
3.3代码维护注释 (88)
第四章编码风格 (89)
4.1界面风格 (89)
4.2排版风格 (93)
4.3变量与常量 (95)
4.4条件判断 (96)
4.5空间申请与释放 (97)
4.6函数编写 (97)
4.7特殊限制 (97)
第五章SQL编码 (98)
前言
程序编码是一种艺术，既灵活又严谨，充满了创造性与奇思妙想。然而应用软件设计是一项团结协作工程，而非程序员展示个人艺术的舞台，大型应用软件项目更是由很多程序员组成的大型开发团队协同完成的。每个程序员都有自己的编码经验与风格，如果缺乏统一的编程规范，则可能导致软件产品最终程序代码风格迥异，可读性与可维护性均较差，不仅给程序代码的理解带来障碍，也增加维护阶段的工作量。此外，经验证明不规范的编码行为往往还会导致程序出现更多的隐含错误。
为规范编码行为，增强程序代码的可读性、可维护性，提高编码质量与效率，保障应用软件产品整体品质与可持续开发性，特制定本规范。本规范分C/C++编码规范、Java编码规范、PB 编码规范三篇，分别从代码组织、命名、注释、编码风格、编译等方面加以阐述。规范文本分为规则与建议两种，其中规则是强制执行的条款，建议则由程序员根据实际情况灵活掌握。
第一篇C/C++编码规范
第一章代码组织
规则1: 使用不同的文件分别放置模块的约束与实现。C++程序的约束文件使用.hpp做扩展名，实现文件使用.cpp做扩展名；C程序的约束文件使用.h做扩展名，实现文件使用.c做扩展名。
规则2: 一个模块可以包含一个类或功能上紧密联系的多个类。禁止将功能关联松散的多个类，放置到一个模块中。
规则3: 模块约束应仅包含模块对外提供的功能，禁止将模块内部使用的功能声明在模块约束中。下例中IsChineseChar()是内部使用的函数，不提供给外部应用使用，因此不能在
简单应用应创建下列目录结构，模块程序代码应分别放置到src/include目录与src/source目录，编译文件放置到src/source目录，编译后的可执行文件放置到rel/bin目录，静态库或动态库放置到rel/lib目录（应用使用的外部库及头文件放置在rel同级的lib与lib/include目录）。
Work Directory
src
source
makefile
*.cpp
*.c
include
*.hpp
*.h
rel
bin
lib
规则5: 复杂应用应分子系统创建目录结构，模块程序代码应分别放置到src/module/include目录与src/module/source目录，应用编译文件放置到src目录，编译后的可执行文件放置到rel/bin目录，静态库或动态库放置到rel/lib目录。（应用使用的外部库及头文件放置在rel同级的lib与lib/include目录）
规则6: 各子系统可以创建独立的编译文件并放置到src/module/source目录，编译后的可执行文件放置到rel/bin/module目录或rel/bin，静态库或动态库放置到rel/lib/module或rel/lib目录。此时，应创建一个编译全部子系统的编译文件或脚本放置到src目录。
Work Directory
src
makefile|make.sh
module1
source
makefile
*.cpp
*.c
include
*.hpp
*.h
module2
source
makefile
*.cpp
*.c
include
*.hpp
*.h
rel
bin
lib
module1
bin
lib
module2
bin
lib
第二章命名
规则7: 命名应遵循下列原则：
●应简单清晰通俗；
●应使用英文命名，禁止使用中文命名；
●应尽量选择通用词汇；
●应使用完整单词或词组，避免使用简称；
●应准确表达其含义；
●避免同时使用易混淆的字母与数字，如1与l，0与o；
●禁止使用只靠大小写区分的多个名称；
●多单词组成的名称，单词的首字母应大写，如FileName。
规则8: 名称太长超过15字符时应使用简称。简称应遵循：
●应使用标准的或常用的简写，如Temp（tmp），Length（len）；
●应用范围内简写应一致且规范，避免各处简写各不相同；
●简写可以使用单词的前一个或多个字母，如Channel（Chan）、Connect（Conn）；也可
以使用去掉所有的不在词头的元音字母，如screen（scrn），primtive（prmv）；
●多个单词组成的名称，使用有意义的单词或去掉无用的后缀并简称，如Count of
Failure（FailCnt），Paging Request（PagReq）。
2.1文件命名
规则9: 文件命名应使用模块名的小写字母形式。禁止使用汉字或大、小写字母混用作为代码文件名。
2.2变量命名
规则10: 变量命名主要采用匈牙利命名法，格式为[作用域范围前缀_][前缀]基本类型＋名称。其中，作用域范围前缀、前缀以小写字母表示且可选，基本类型以小写字母表示且必选。
禁止使用单字母作为变量名。但下列常用单字母变量除外：
2.3常量与宏命名
规则12: 常量与宏应使用全大写名称，多词组名称使用_分隔各单词，并使用断行注释说明
为防止重复包含而定义的头文件预处理宏，应使用__NAME_HPP__（C++）或
2.4类命名
规则16: 类命名应使用字符C|T＋名称形式。其中名称应使用名词或名词短语，且每个单词首字母大写。如：CSignal，CFile，CString，CTagMgr。
2.5函数命名
规则17: 函数命名应使用能够表达函数功能的英文动词或动宾结构短语，且每个单词的首字母大写。如：GetName()，StrTrimLeft()，KillProc()。禁止在函数名称中使用非字母或数字的
其他字符，如下划线_。
建议1: 不应在函数名中使用数字，如：GetName1()，Kill2()。但数字是短语一部分的，可以使用，如KillSigusr2()。
2.6参数命名
建议2: 函数或方法的参数命名参考变量命名，但应使用In，Out、Ret等简写修饰参数，
第三章注释
规则18: 程序代码中增加注释的目标是帮助对程序的阅读理解，不宜太多或太少，太多则会对阅读产生干扰，太少则不利于代码理解，因此只在必要的地方才加注释，且准确、易懂、简洁。
3.1文档化注释
3.1.1文件注释
规则19: 文件注释放置在文件头部，主要包括此文件的功能说明，编写人和修改人以及编写
3.1.2类注释
3.1.3函数或方法注释
规则21: 函数或方法注释放置在其声明前，主要介绍函数的功能、参数、返回值、异常、使
3.1.4数据成员注释
3.1.5结构注释
规则23: 结构可使用简单注释，也可使用与类相同的注释格式，其数据成员使用断行注释。
3.1.6宏与变量注释
规则24: 宏与变量使用简单注释或断行注释。特别重要的宏可以使用与类相同的文档注释。
3.1.7文档注释技巧
建议4: 为使doxygen工具能生成更好的文档，编写文档注释时参考下列技巧： 注释中使用的标识符前后均应留一个空格，以便doxygen识别此标识符，并自动生成一
注释中可使用HTML标记美化最终文档，但别滥用美化标记；
●较长的文档注释需要分段说明时，使用
分段。如果需要段首缩进两字符，使用全角
的空格。
●文档注释中可以使用@par增加一个小节，灵活使用此标记可以任意地扩展文档的结构，
需要生成圆点列表时使用－，需要生成编号列表时使用－#。
为使doxygen正确生成函数或方法的连接，注释中的函数名或方法名前后应留一个空格。
如该函数或方法没有重载，则不必使用参数列表，如 GetTag()。如该函数或方法重载，则应必须使用参数（类型）列表，如GetTag(LPCSTR, AMOUNT&, BOOL, int, int)。
3.2语句块注释
规则25: 程序代码主要流程、重要算法以及逻辑性较强的代码和有特殊设计意图的代码（如没有break的case块、空循环体、空语句块）等位置，应添加语句块注释。通过语句块注释，应能反映程序功能的概貌，注释量不应少于该模块概要设计的流程描述量。
规则26: 语句块注释应遵循下列原则：
●应使用断行注释，即//；
●一目了然的语句不应注释；
●每个分支、每个功能段均应注释；
●应放置在紧临该语句块上方或语句右侧，与其上方的语句块应留一空行，禁止放置在
语句块的下方，但可以在语句块下方放置该语句块结束的注释。放置在语句右侧的注
需要注释一段代码时，避免使用/* */注释，而应使用#ifdef 0 … #endif形式，
3.3代码维护注释
规则27: 维护已经定版的代码时，禁止直接删除或编辑旧代码，而应使用注释保留旧代码，然后在旧代码下方增加新修改后的代码。
规则28: 代码维护注释应放置到被修改代码的上方，使用断行注释，并应注明修改日期、修改人、修改原因。对代码块进行修改的，还应标明修改结束的位置。
软件系统JAVA 编码规范 版本V1.0
文档信息： 内容范围： 本文档是软件系统JAVA编码规范。适用的对象： 公司相关技术人员。
目录 1 介绍（INTRODUCTION） (5) 2 2 文件名（FILE NAMES） (6) 2.1文件后缀（F ILE S UFFIXES） (6) 2.2常用文件名（C OMMON F ILE N AMES） (6) 3 文件组织（FILE ORGANIZATION） (7) 3.1J AVA源文件（J AVA S OURCE F ILES） (7) 3.1.1开首注释（B EGINNING C OMMENTS） (7) 3.1.2包和引入语句（P ACKAGE AND I MPORT S TATEMENTS） (8) 3.1.3类和接口声明（C LASS AND I NTERFACE D ECLARATIONS） (8) 4 缩进排版（INDENTATION） (9) 4.1行长度（L INE L ENGTH） (9) 4.2换行（W RAPPING L INES） (9) 5 注释（COMMENTS） (13) 5.1实现注释的格局（I MPLEMENTATION C OMMENT F ORMATS） (13) 5.1.1块注释（B LOCK C OMMENTS） (13) 5.1.2单行注释（S INGLE-L INE C OMMENTS） (14) 5.1.3尾端注释（T RAILING C OMMENTS） (15) 5.1.4行末注释（E ND-O F-L INE C OMMENTS） (15) 5.2文档注释（D OCUMENTATION C OMMENTS） (16) 6 声明（DECLARATIONS） (17) 6.1每行声明变量的数量（N UMBER P ER L INE） (17) 6.2初始化（I NITIALIZATION） (17) 6.3布局（P LACEMENT） (17) 6.4类和接口的声明（C LASS AND I NTERFACE D ECLARATIONS） (18) 7 语句（STATEMENTS） (20) 7.1简单语句（S IMPLE S TATEMENTS） (20) 7.2复合语句（C OMPOUND S TATEMENTS） (20)
数据库设计和编码规范 Version
目录
简介 读者对象 此文档说明书供开发部全体成员阅读。 目的 一个合理的数据库结构设计是保证系统性能的基础。一个好的规范让新手容易进入状态且少犯错，保持团队支持顺畅，系统长久使用后不至于紊乱，让管理者易于在众多对象中，获取所需或理清问题。 同时，定义标准程序也需要团队合作，讨论出大家愿意遵循的规范。随着时间演进，还需要逐步校订与修改规范，让团队运行更为顺畅。 数据库命名规范 团队开发与管理信息系统讲究默契，而制定服务器、数据库对象、变量等命名规则是建立默契的基本。 命名规则是让所有的数据库用户，如数据库管理员、程序设计人员和程序开发人员，可以直观地辨识对象用途。而命名规则大都约定俗成，可以依照公司文化、团队习惯修改并落实。 规范总体要求 1.避免使用系统产品本身的惯例，让用户混淆自定义对象和系统对象或关键词。 例如，存储过程不要以sp_或xp_开头，因为SQL SERVER的系统存储过程以 sp_开头，扩展存储过程以xp_开头。 2.不要使用空白符号、运算符号、中文字、关键词来命名对象。 3.名称不宜过于简略，要让对象的用途直观易懂，但也不宜过长，造成使用不方 便。 4.不用为数据表内字段名称加上数据类型的缩写。 5.名称中最好不要包括中划线。
6.禁止使用[拼音]+[英语]的方式来命名数据库对象或变量。 数据库对象命名规范 我们约定，数据库对象包括表、视图（查询）、存储过程（参数查询）、函数、约束。对象名字由前缀和实际名字组成，长度不超过30。避免中文和保留关键字，做到简洁又有意义。前缀就是要求每种对象有固定的开头字符串，而开头字符串宜短且字数统一。可以讨论一下对各种对象的命名规范，通过后严格按照要求实施。例如：
软件设计文档国家标准GB8567-88 一、文档编写标准化 在整个项目开发及使用过程中，应该有完备的文档支持，文档编制要求具有针对性、精确性、清晰性、完整性、灵活性和可追溯性。 完备的文档对软件的开发及使用起了很大的作用。一般要求编写好十三种文档。 1、可行性分析报告 说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。 2、项目开发计划 为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。 3、软件需求说明书（软件规格说明书） 对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。 4、概要设计说明书 是概要设计阶段的工作总结。主要包括功能分配、模块划分、程序总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理等，为详细设计作好准备。 5、详细设计说明书 着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。 6、用户操作手册 详细描述了该软件的功能、性能和用户界面，使用该软件的具体方法等。 7、测试计划 包括测试内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。8、测试分析报告 测试计划的执行情况，对测试结果的分析，提出测试结论。 9、开发进度月报 按月提交的项目进展情况报告。包括计划与实际执行情况的对比、阶段成果、遇到的问题、解决的方法以及下一步的打算。 10、项目开发总结报告 项目完成以后，总结实际执行情况。如进度、成果、资源利用、成本和投入的人力，对项目开发作出评价，总结经验与教训。 11、软件维护手册 主要包括软件系统说明、程序模块说明、操作环境、支持软件说明、维护过程说明等。12、软件问题报告 记录软件出现问题的日期、发现人、状态、问题所属模块等，为软件修改提供准备文档。13、软件修改报告 软件产品投入使用后，发现了需修改、更正的问题，要将出现的问题、修改意见、修改可能出现影响作出详细描述，提交审批。 二、可行性分析报告的撰写要求 可行性研究报告的编写内容要求如下： 1 引言
变更履历
目录 1总则 (4) 2源代码完整性保障 (4) 3源代码的授权访问 (4) 4代码版本管理 (5) 4.1系统初验 (6) 4.2试运行 (6) 4.3系统终验 (7) 4.4系统验收标准 (7)
1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。 3源代码的授权访问 1、源代码服务器对于共享的SVN库的访问建立操作系统级的，基于身份和口令的访问授权。 第十条在SVN库中设置用户，并为不同用户分配不同的，适合工作的最小
软件配置项标识编码规则设计方案 刘宏 2011-9-18 Mail:lh@https://www.doczj.com/doc/e211957499.html, 1.背景 1.1.服务外包中迁移 在服务外包中，难度较大的阶段为——服务外包的迁移工程。 服务迁移工程难度大的主要原因之一，是没有实施迁移前准备标准和迁移后的验收标准。也就是在服务成熟到何种程度——包括管理与技术成熟度，服务才能够向外包方进行迁移，以便发包方有效控制服务外包中的风险，达到服务外包的目的。 服务外包迁移前应达到的准备标准——包括管理标准与技术标准，技术标准是管理标准的基础。技术标准是在服务外包迁移中的必要条件，管理标准是服务外包迁移中的充分条件。 不同服务业务在外包迁移中，具有不同的技术标准，但是具有相同的管理标准——ISO20000规定了管理相关的内容。 因为不同的服务业务具有不同的服务技术标准要求，因此正对IT服务外包业务应根据业务的特点编制相关的技术标准要求。IT服务外包业务可以包括： ●IT系统基础平台维护服务外包 ●IT系统支撑环境维护服务外包 ●应用系统的维护服务外包 1.2.服务外包迁移标准内容 每类服务有可以分成：运营服务（一线服务）、支持性服务（二线服务）、变更性服务（三线服务）。 在IT服务外包中风险较大的是运营服务，因为运营服务一直是直接在客户的生产环境实施，一旦发生错误，有可能给客户造成无法挽回的损失。目前一般风险较大的运营服务，有客户自己承担，不进行外包。 支持性服务也是在客户生产环境实施，但是一般需要进行策划与实施结果测试。由于支
持服务具有一定的技术性，因此这种服务外包迁移前应按照技术标准要求通过验收。只有通过技术标准验收的服务才能够实施服务外包的迁移。 变更性服务是在其他环境中测试完成后，在反映到生产环境中。因此变更性服务与系统建设期的系统开发存在不同的风险。在系统建设期，可以进行充分的测试与试运行测试。在变更性服务由于工期与成本的原因，可能不能充分进行测试与试运行。 1.3.服务外包迁移中标准需求 服务外包方为了及时提供服务需要将分包方的技术成果迁移到外包方处，因此分包方向服务外包方进行服务迁移时，在服务迁移时，迁移哪些内容，迁移的内容在迁移前应到技术标准要求应进行验证与确认。若是没有达到服务外包迁移技术标准，很显然是增加服务外包迁移的风险。 在服务外包迁移实施中，需要对服务外包迁移内容结果进行验证，因此需要服务外包迁移结果验证与确认的技术标准要求。 1.4.应用软件服务迁移标准需求分析 在应用软件系统维护服务外包的迁移中，技术标准主要是针对分包方迁移给外包方的所有技术成果物。对这些成果物需要相关的技术标准要求，以便在服务外包迁移过程，分包方与外包方能够有效沟通与交接，确保服务能够连续，不因为服务外包迁移发生中断或服务水平下降。 为了确保分包方与外包方能够有效进行技术沟通，首先需要明确出工程成果物的标识标准——配置项标识编码标准。这一标准能够是双方能够正确地在配置管理库中找到所需要的配置项。 为了能够有效避免交付过程中，使用错误的成果物。就需要双方共同承认的成果物的编码规则或标准。 由此得出结论：软件配置项标识编码规则，是IT应用系统维护服务外包的技术标准中的基础。 2.方案的目的与目标 2.1.目的 通过提供一般软件配置项编码规则，为企业的软件配置项的管理提供自动化处理的解决
软件开发规范 1 排版 11-1：程序块要采用缩进风格编写，缩进的空格数为4个。 说明：对于由开发工具自动生成的代码可以有不一致。 11-2：相对独立的程序块之间、变量说明之后必须加空行。 示例：如下例子不符合规范。 if (!valid_ni(ni)) { ... epssn_index; repssn_ni = ssn_data[index].ni; 应如下书写 if (!valid_ni(ni)) { ... epssn_index; repssn_ni = ssn_data[index].ni; 11-3：较长的语句（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读。 示例： = NO7_TO_STAT_PERM_COUNT_LEN + STAT_SIZE_PER_FRAM * sizeof( _UL ); act_task_table[frame_id * STAT_TASK_CHECK_NUMBER + index].occupied
= stat_poi[index].occupied; act_task_table[taskno].duration_true_or_false = SYS_get_sccp_statistic_state( stat_item ); report_or_not_flag = ((taskno < MAX_ACT_TASK_NUMBER) && (n7stat_stat_item_valid (stat_item)) && (act_task_table[taskno].result_data != 0));
软件开发工作规范章程 Document serial number【KK89K-LLS98YT-SS8CB-SSUT-SST108】
软件开发工作规范章程 编写目的 本文档是开发团队的日常工作规范，主要侧重开发工作流程的控制，明确软件工程的各阶段开发团队应完成的工作。开发技术和策略等问题不在本文档描述范围内。开发团队构成 1.1职责 肩负着如下责任： 负责开发项目的系统分析、研发与组织实施。 负责开发符合要求的软件。 制定软件开发规范。 协助相关应用软件的安装调试工作。 1.2角色划分 在人力资源有限的情况下，一个团队成员可能会同时承担多个角色。 角色名称相关主要责任 开发组长负责研发团队建设 负责研发项目的工作分工、实施、监控及后续完善工作 参与确定研发产品的种类，并制定研发产品的相关标准及研发工作计划 负责技术路线与方向 完成研发过程中的其他任务 超出能力权限向上一级汇报 根据项目情况，向所属组制定技能提升计划并实施 特性负责人负责研发特性的工作分工、实施、监控及后续完善工作 制定特性的软件开发技术规范及研发工作计划
负责《详细设计》的编写。 按期、按预算交付高质量的产品 建设有凝聚力团队环境，并促使高效的团队协作 负责软件实施规范执行 根据开发规范实施开发工作 软件的程序设计、代码编写与单元测试。 协助《详细设计》的编写。 承担开发任务，按计划完成任务目标。 配合系统分析人员完成软件系统以及模块的需求调 研、需求分析。 协助测试人员完成软件系统及模块的测试。 1.3需求澄清 1.4编码阶段 1.4.1开发规范
1.4.2开发环境准备 1.4.3详细设计 1.4.4编码
质量管理体系过程文件 软件设计编码过程 文件版本信息：
目录 1.目的 设计编码的目的在于设计和实现关于需求的解决方案。保证《需求规格说明书》中的各项要求在设计时都能够得到满足；对项目的编码实现进行质量控制，保证编码实现活动按计划顺利完成并与设计相一致。 2.范围 适用于公司的各类软件项目的系统设计编码过程。 3.术语 无 4.角色与职责
5.入口准则 ●《需求规格说明书》已通过评审。 6.输入 ●《需求规格说明书》 7.流程图 图1: 系统设计编码过程 8.主要活动 系统设计编码过程包括系统设计、系统实现。系统设计是指设计软件系统的体系结构、数据库、模块等，在需求和代码之间建立桥梁，一般分概要设计和详细设计两个阶段；系统实现是指开发人员按照系统设计去编码开发，并进行单元测试、代码走查；在设计编码过程中同时进行用户文档的编制。 8.1.概要设计 概要设计是分析各种设计方案和定义软件体系结构的过程。设计人员在充分了解需求的基础上，依据《需求规格说明书》选用适当的设计方法，分析与设计软件的结构、模块功能。通过系统分解，确定子系统的功能和子系统之间的关系，以及模块的功能和模块之间的关系，编写《概要设计说明书》。《概要设计说明书》必须经过技术评审。 8.1.1.解决方案选择 系统设计时可能会涉及到多种解决方案的选择，如： ●系统实现路线； ●采用的工具和技术； ●产品架构； ●设计模式； ●模块的制作、购买或重用等。 当出现多种候选方案，难以通过简单的方法判断出方案的优劣时，应按照《S_DAR00_决策分析和决定过程》进行决策。
8.1.2.概要设计 概要设计是建立整个软件的体系结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义等。概要设计的主要步骤有： ?选择设计方法； ?识别解决方案的主要组件：根据解决方案的技术架构和分析方法（面向对象、面向结 构），相应确定解决方案的组件模块； ?对候选技术和工具、组件进行评估，确定是进行开发、购买还是复用已有技术（工具 或者组件）。评估开发、购买或复用方案时需要考虑的事项包括：业务方面：可行性、产品成本、经验、投资回报、成熟度及其他因素；企业体系结构方面：解决方案必须 与当前状态和远景状态计划的约束相适应。包括与企业现有系统的集成等；技术方面：安全、组件模块交互标准、数据访问、数据存储、系统服务、开发工具、操作系统等。 ?识别解决方案主要组件的重要属性和关键关系：在前一任务的基础上，对解决方案主 要组件的重要属性和关键关系进行识别； ?进行数据库设计，建立数据库的逻辑模型和物理模型； ?进行用户界面设计，确定整个系统的界面框架以及界面风格； ?形成《概要设计说明书》。 8.1.3.概要设计评审 概要设计的结果应进行技术评审。技术评审由设计人员提出，由项目经理组织召开。技术评审会议应邀请需求分析师、公司的技术专家、开发人员、测试人员等参加。 关于技术评审会议的要求详见《评审过程》。 8.2.详细设计 详细设计可以和概要设计并行进行，但应考虑并行设计不会因概要设计而导致较大的详细设计返工。 8.2.1.详细设计 详细设计是从开发需求的角度描述解决方案的组件、服务和技术的过程。详细设计定义了解决方案的各个组成部分，以及这些组成部分的开发方法和交互方式。详细设计的步骤包括： ?选择用于开发解决方案的技术并完善设计模型：在概要设计的基础上，选择开发解决 方案采用的技术，并且完善对应的设计模型。
软件开发代码规范（C） (仅通普信息技术股份有限公司供内部使用) 拟制：杨超日期：2015-3-10审核：夏峰日期：2015-3-10核准：冯敬刚日期：2015-3-17签发：韩殿成日期：2015-3-21文档版本：V1.11 黑龙江通普信息技术股份有限公司
版本历史
目录 第一章代码开发规范及其指南 0 1.1目的 0 1.2程序内命名规范 0 1.3文件命名规范 (1) 1.4J AVA 文件样式 (1) 1.5代码编写格式 (6) 第二章程序编写规范方法 (8) 2.1权限修饰 (8) 2.2其他规范 (8) 2.3编程指南 (10) 第三章其他要求 (12)
第一章代码开发规范及其指南 1.1 目的 定义这个规范的目的是让项目中所有的文档都看起来像一个人写的，增加可读性，减少项目组中因为换人而带来的损失。（这些规范并不是一定要绝对遵守，但是一定要让程序有良好的可读性） 1.2 程序内命名规范 ●Package的命名：Package 的名字应该都是由一个小写单词组成。 ●Class 的命名：Class 的名字必须由大写字母开头而其他字母都小写的单词组 成 ●Class 变量的命名：变量的名字必须用一个小写字母开头。后面的单词用大 写字母开头。 ●Static Final 变量的命名：Static Final 变量的名字应该都大写，并且指出完整 含义。 ●参数的命名：参数的名字必须和变量的命名规范一致。 ●数组的命名：数组应该总是用下面的方式来命名： byte[] buffer; 而不是 byte buffer[]; ●方法的参数：使用有意义的参数命名，如果可能的话，使用和要赋值的字 段一样的名字： SetCounter(int size){ this.size = size;
软件设计规范 概述 软件设计是把需求转化为软件系统的最重要的环节，系统设计的优劣在根本上决定了软 件系统的质量。 在此，主要阐述软件系统设计的5个核心内容：体系结构设计、用户界面设计、数据库设计、模块设计、数据结构和算法设计。旨在帮助开发人员搞清楚“设计什么”以及“如何 设计”。 一般把设计过程划分为两个阶段：概要设计阶段和详细设计阶段，如下所示： *概要设计阶段的重点是体系结构设计。 *详细设计阶段的重点是用户界面设计、数据库设计、模块设计、数据结构与算法设计 等。 可根据项目的情况进行文档裁减和过程合并，如项目开发过程只有一个设计阶段和设计 文档。 体系结构 体系结构如同人的骨架。如果某个家伙的骨架是猴子，那么无论怎样喂养和美容，这家 伙始终都是猴子，不会成为人。 由此可见，体系结构乃是系统设计的重中之重。 目前业界比较流行的软件结构模式有C/S（客户/服务器）、B/S（BROWSE/SERVER）、层次结构（上下级层次结构、顺序相邻的层次结构、含中间件的层次结构） 体系结构设计原则 ● 合适性 即体系结构是否适合于软件的“功能性需求”和“非功能性需求”。高水平的设计师高就高在“设计出恰好满足客户需求的软件，并且使开发方和客户方获取最大的利益，而不是 不惜代价设计出最先进的软件。 ● 结构稳定性 详细设计阶段的工作如用户界面设计、数据库设计、模块设计、数据结构与算法设计等等，都是在体系结构确定之后开展的，而编程和测试则是更后面的工作，因此体系结构应在 一定的时间内保持稳定。
软件开发最怕的就是需求变化，但“需求会发生变化”是个无法逃避的现实。人们希望在需求发生变化时，最好只对软件做些皮皮毛毛的修改，可千万别改动软件的体系结构。如果当需求发生变化时，程序员不得不去修改软件的体系结构，那么这个软件的系统设计是失 败的。 高水平的设计师应当能够分析需求文档，判断出哪些需求是稳定不变的，哪些需求是可能变动的。于是根据那些稳定不变的需求设计体系结构，而根据那些可变的需求设计软件的 “可扩展性”。 ● 可扩展性 可扩展性是指软件扩展新功能的容易程度。可扩展性越好，表示软件适应“变化”的能 力越强。 可扩展性越来越重要，这是由现代软件的商业模式决定的： *社会的商业越发达，需求变化就越快。需求变化必将导致修改（或者扩展）软件的功能，现代软件的规模和复杂性要比十年前的大得多（对比一下操作系统的变化就明白了），如果软件的可扩展性比较差的话，那么修改（或者扩展）功能的代价会很高。 *现代软件产品通常采用“增量开发模式”，开发商不断地推出软件产品的新版本，从而不断地获取增值利润。如果软件的可扩展性比较差的话，每次开发新版本的代价就会很高。虽然开发商抓住了商机，但却由于设计水平差而导致没有赚取多少利润，真是要活活气死。 ● 可复用性 由经验可知，通常在一个新系统中，大部分的内容是成熟的，只有小部分内容是创新的。一般地可以相信成熟的东西总是比较可靠的（即具有高质量），而大量成熟的工作可以通过 复用来快速实现（即具有高生产率）。 可复用性是设计出来的，而不是偶然碰到的。要使体系结构具有良好的可复用性，设计师应当分析应用域的共性问题，然后设计出一种通用的体系结构模式，这样的体系结构才可 以被复用。 用户界面设计 为了提高用户界面的易用性和美观程度，总结了十个设计原则。用于提高易用性的界面 设计原则有8个： *用户界面适合于软件的功能 *容易理解 *风格一致
软件开发代码规范（C#版） 拟制: 日期：2007-2-13 审核: 日期： 审核: 日期： 批准: 日期： 版权所有********有限公司
修订纪录
目录 1、第一章命名规范 (4) 1.1、第一节总则 (4) 1.2、第二节变量命名规范 (4) 1.2.1、CodeBehind内部命名规范 (4) 1.2.2、控件命名规范 (5) 1.3、第三节常量命名规范 (5) 1.4、第四节命名空间、类、方法命名规范 (5) 1.5、第五节接口命名规范 (6) 1.6、第六节命名规范小结 (6) 2、第二章代码注释规范 (6) 2.1、第一节模块级注释规范（命名空间、类等） (6) 2.2、第二节方法级注释规范 (7) 2.2.1 、属性注释 (7) 2.2.2 、方法注释 (7) 2.3、第三节代码间注释规范 (8) 3、第三章编写规范 (9) 3.1、第一节格式规范 (9) 3.2、第二节编程规范 (9) 3.2.1 、程序结构要求 (9) 3.2.2 、可读性要求 (10) 3.2.3 、结构化要求 (10) 3.2.4 、正确性与容错性要求 (10) 3.2.5 、可重用性要求 (11) 3.2.6 、interface使用注意事项 (11) 3.2.7 、类使用注意事项 (11) 3.2.8 、流程控制语句注意事项 (12) 3.2.8 、其他应注意事项 (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.2.1、CodeBehind内部命名规范 1．公有字段/属性使用Pascal 命名规则，私有变量/保护变量/局部变量使用Camel命名规则，遵循动宾结构。 例： public class Hello { private string userName; private DateTime loginTime; private bool isOnline; public string UserName { get { return https://www.doczj.com/doc/e211957499.html,erName; } } } 2．即使对于可能仅出现在几个代码行中的生存期很短的变量，仍然使用意义描述性的名称。仅对于短循环索引使用单字母变量名，如i 或j 3．在变量名中使用互补对，如Min/Max、Begin/End 和Open/Close。 4．当一个方法内部变量繁多的时候，可以使用Camel命名法则，其中第一个单词可以使用变量类型的缩写来说明以示区别。 例：
软件开发管理规范 Document serial number【KK89K-LLS98YT-SS8CB-SSUT-SST108】
软件开发过程管理规范济南明湖建筑节能技术开发有限公司
一、总则 1.软件开发项目管理的目的 为保障按时、保质、保量完成预期交付的任务，让整个组织能清楚了解项目实施的目的、影响、进度，做到项目组所有成员都理解项目实施的原因、意义及客户的要求。通过制度化管理来合理组织安排项目组成员的工作职责和角色转换。 2.软件开发项目管理规范适用对象 为了达到软件开发项目管理的根本目的，要求公司全体员工必须严格按照本规范执行，同时要求公司业务人员引导合作单位和客户接受并适应公司本《软件项目开发管理规范》。 3.软件项目开发组织管理 根据软件开发的标准流程，结合公司的实际情况对软件项目分三个主要阶段进行组织管理，分别为项目立项阶段、项目实施阶段和项目验收总结阶段。 二、软件项目立项阶段 1.成立公司项目评估委员会负责公司的项目立项审批。 2.公司项目评估委员会由公司总经理或指定负责人召集，成员为公司管 理层人员、商务负责人、市场负责人、技术总监、技术研发经理、财务负责人组成。 3.公司业务部门按照公司发展要求或外部需求形成《软件项目需求说明 书》，确定项目需求管理人或项目申请人。 4.项目申请人填写《软件项目立项申请书》向项目评估委员会提出项目
立项申请，主要说明项目的背景、目的、效益、成本、需求等方面，并由技术部门提供支持和技术说明。 5.项目评估委员会收到《项目立项申请书》后三个工作日内，召开评估 会议。给出评估结果。如果批准立项交公司技术总监组织开发。如果不批准，给出理由后项目中止。中止后的项目可根据情况重新申请。 6.评估结果必须包括：建议项目启动日期，期望项目完成日期，项目等 级系数，项目优先级（高中低），资源冲突程度(1~9)。对于资源冲突程度大于5的项目技术总监有权拒绝接受。 三、软件项目实施阶段 1.公司批准立项的项目交由公司技术总监组织实施。 2.技术总监根据资源情况和项目需求组织相关技术人员进行初步需求讨 论会，确定项目的等级系数（如分大、中、小对应3、2、1）、指定项目开发负责人。在立项后五个工作日内技术总监和项目开发负责人共同制定《软件项目开发计划》，确定项目启动日并提交项目评估委员会做反馈确认。如果项目评估委员会二位成员以上对计划有异议，项目评估委员会应该召开项目计划协调会，协调《软件项目开发计划》的修改和通过。如果无异议授权技术总监按照《软件项目开发计划》执行。 3.项目启动日后，项目开发负责人根据《软件项目开发计划》的进度每 周进行一次分析汇报，形成《项目分析周报》确定项目的状态、分析
软件界面设计规范 1.界面规范 .总体原则以用户为中心。 设计由用户控制的界面，而不是界面控制用户。清楚一致的设计。所有界面的风格保持一致，所有具有相同含义的术语保持一致，且易于理解拥有良好的直觉特征。以用户所熟悉的现实世界事务的抽象来给用户暗示和隐喻，来帮助用户能迅速学会软件的使用。较快的响应速度。简单且美观。 .原则详述 1.2.1.用户控制用户界面设计的一个重要原则是用户应该总是感觉在控制软件而不是感觉被软件所控制。操作上假设是用户--而不是计算机或软件--开始动作。用户扮演主动角色，而不是扮演被动角色。在需要自动执行任务时，要以允许用户进行选择或控制它的方式来实现该自动任务。提供用户自定义设置。因为用户的技能和喜好各不相同，因此他们必须能够个性化界面的某些方面。Windows为用户提供了对许多这方面的访问。您的软件应该反应不同的系统属性--例如颜色、字体或其他选项的用户设置。采取交互式和易于感应的窗口，尽量避免使用模态对话框，而使用"非模式"辅助窗口。"模式"是一种状态，它排除一般的交互，或者限制用户只能进行特定的交互。当最好使用一个模式或该模式只是可替换的设计时--例如，用于在一个绘图程序中选定一个特定感觉--请确保该模式是显然的、可见的，是一个明确的用户选定的结果，并且容易取消。在后台运行长进程时，保持前台式交互。例如，当正在打印一个文档，即使该文档不能被改变，用户也应该可以最小化该窗口。谅解。用户喜欢探索一个界面，并经常从尝试和错误中学习。一个有效的界面允许交互式的发现，它只提供一组合适的选择，并在用户可能破坏系统或数据的情况时发出警告。如果可行，还应提供可逆转或可还原的操作。即使在设计得很好得界面中，用户也可能犯错误。这些错误既可以是物理上得（偶然地指向了错误的命令或数据），也可以是逻辑上的（对选定哪一个命令或哪些数据做出了错误的决定）。有效的设计避免很可能导致错误的情况。它还包容潜在的用户错误，并且使用户易于还原。 1.2.2.清楚一致的设计一致允许用户将已有的知识传递到新的任务中，更快地学习新事物，并将更多的注意力集中在任务上。这是因为他们不必花时间来尝
质量管理体系过程文件软件设计编码过程
文件版本信息：
目录 1.目的 (3) 2.围 (3) 3.术语 (3) 4.角色与职责 (3) 5.入口准则 (3) 6.输入 (3) 7.流程图 (3) 8.主要活动 (4) 8.1.设计原则 (4) 8.2.设计方法.................................................................................... 错误!未定义书签。 8.3.多方案选择 (4) 8.4.概要设计.................................................................................... 错误!未定义书签。 8.4.1.概要设计............................................................................ 错误!未定义书签。 8.4.2.概要设计评审.................................................................... 错误!未定义书签。 8.5.详细设计.................................................................................... 错误!未定义书签。 8.5.1.详细设计 (5) 8.5.2.详细设计评审 (6) 8.6.编码............................................................................................ 错误!未定义书签。 8.7.单元测试 (7) 8.8.代码走查 (7) 8.9.制作用户文档............................................................................ 错误!未定义书签。 8.10.变更............................................................................................ 错误!未定义书签。 9.输出 (8) 10.出口准则 (8) 11.引用文档 (8)
操作手册（G B8567——88） 1引言 编写目的 说明编写这份操作手册的目的，指出预期的读者。 前景 说明： a．这份操作手册所描述的软件系统的名称； b．该软件项目的任务提出者、开发者、用户（或首批用户）及安装该软件的计算中心。 定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 参考资料 列出有用的参考资料，如： a．本项目的经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料，包括所列出的这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 2软件征述 软件的结构 结合软件系统所具有的功能包括输入、处理和输出提供该软件的总体结构图表。 程序表 列出本系统内每个程序的标识符、编号和助记名。 文卷表 列出将由本系统引用、建立或更新的每个永久性文卷，说明它们各自的标识符、编号、助记名、存储媒体和存储要求。 3安装与初始化 一步一步地说明为使用本软件而需要进行的安装与初始化过程，包括程序的存载形式，安装与初始化过程中的全部操作命令，系统对这些命令的反应与答复，表征安装工作完成的测试实例等。如果有的话，还应说明安装过程中所需用到的专用软件。 4运行说明 所谓一个运行是指提供一个启动控制信息后，直到计算机系统等待另一个启动控制信息时为止的计算机系统执行的全部过程。 运行表 列出每种可能的运行，摘要说明每个运行的目的，指出每个运行各自所执行的程序。 运行步骤 说明从一个运行转向另一个运行以完成整个系统运行的步骤。 运行1（标识符）说明 把运行1的有关信息，以对操作人员为最方便最有用的形式加以说明。 运行控制 列出为本运行所需要”的运行流向控制的说明。 操作信息 给出为操作中心的操作人员和管理人员所需要的信息，如：
标识规范 沈阳东大阿尔派软件股份有限公司（版权所有，翻版必究）
文件修改控制
目录 1. 目的 2. 适用范围 3. 术语和缩略语 4. 标识规则 4.1 标识对象 4.2 文档版本控制 4.3 发行版本控制 4.4 软件项标识方式 4.5 不合格品的标识 5. 引用文件 5.1 NW602102《文件编号规定》 6. 质量记录 6.1 NR602101A“文件备份清单”
1．目的 为便于标识、控制和追踪软件开发过程中产生的各种软件项及介质，特制定本文件。 2．适用范围 适用于软件开发过程中所需的各种软件项及介质。 3．术语和缩略语 本程序采用NQ402100《质量手册》中的术语和缩略语及其定义。 4．标识规则 4.1 标识对象 标识对象主要包括：技术文档（可行性分析报告、需求分析报告、开发计划、质 量计划、系统设计报告、技术报告、测试计划等）、提交产品（计算机程序、释 放产品等），主要通过介质标识和版本控制以便于存取和查阅。 4.2 文档版本控制 对于计划性文档、技术文档和用户文档，其版本按修改的先后顺序确定。新生成 的文档第一次发行为第一版，修改后第二次发行为第二版，以此类推。 4.3 发行版本控制 最终完成的软件版本用三位符号表示：“s.xy”。各符号位的含义如下： 1）“y”为第二次版本号，表示纠正错误时的版本升级，用一位数字表示：“1~9”，对上一次产品或项目中的缺陷做修正，第二次版本号增加；
2）“x”为第一次版本号，表示增加功能时的版本升级，用一位数字表示：“0~9”。与上一产品或项目相比，功能进行了小量的增加或修正时，第一次 版本号增加，第二次版本号为零，第二版本号为零时可以省略不写； 3）“s”为主版本号，用一位数字表示：“1~9”。对产品作重大调整，或与已发行的上一产品相比，在功能与性能上有较大改善时主版本号增加，次版本号 为零，产品或项目概念全新，第一次完成，版本号为1.0。 4.4 软件项标识方式 4.4.1 技术文档标识方式 技术文档的标识体现在相应文件的封面上，由开发人员参照相应文档模板的格式 要求，对技术文档进行标识。 技术文档编号用十五位符号表示：“xxxxxxxxxxxttnn”。各符号位的含义如下：1）“xxxxxxxxxxx”为本次开发的项目编号，共十一位，具体含义见NW602102《文件编号规定》； 2）“tt”为文档类别代号，用两位大写字母表示。“tt”的取值范围如下：FA(Feasibility Analysis)：可行性分析报告 RA(Requirement Analysis)：需求分析报告 DP(Developing Plan)：开发计划 QP(Quality Plan)：质量计划 SD(System Design)：系统设计报告 TR(Technical Report)：技术报告 SR(Summary Report)：项目开发总结报告 本部分未给出代号的文档，其代号由相应的文档编写部门确定。
软件编码规范 中国人民银行清算总中心 支付系统开发中心
注：变化状态：A—增加，M—修改，D—删除
目录 第一篇C/C++编码规范 (6) 第一章代码组织 (6) 第二章命名 (9) 2.1文件命名 (9) 2.2变量命名 (9) 2.3常量与宏命名 (10) 2.4类命名 (10) 2.5函数命名 (10) 2.6参数命名 (11) 第三章注释 (12) 3.1文档化注释 (12) 3.2语句块注释 (17) 3.3代码维护注释 (20) 第四章编码风格 (22) 4.1排版风格 (22) 4.2头文件 (26) 4.3宏定义 (27) 4.4变量与常量 (30) 4.5条件判断 (32) 4.6空间申请与释放 (33) 4.7函数编写 (33) 4.8类的编写 (37) 4.9异常处理 (40) 4.10特殊限制 (40) 第五章编译 (41) 第六章ESQL/C编码 (46) 第二篇JAVA编码规范 (47) 第一章代码组织 (48) 第二章命名 (51) 2.1包命名 (51) 2.2类命名 (51) 2.3接口命名 (51) 2.4方法命名 (51) 2.5变量命名 (51) 2.6类变量命名 (52) 2.7常量命名 (52) 2.8参数命名 (52) 第三章注释 (53) 3.1文档化注释 (53) 3.2语句块注释 (57) 3.3代码维护注释 (59) 第四章编码风格 (61) 4.1排版风格 (61) 4.2包与类引用 (66) 4.3变量与常量 (66) 4.4类编写 (67) 4.5方法编写 (68)
4.6异常处理 (71) 4.7特殊限制 (71) 第五章编译 (73) 第六章JSP编码 (74) 6.1文件命名及存放位置 (74) 6.2内容组织 (74) 6.3编码风格 (76) 6.4注释 (78) 6.5缩进与对齐 (78) 6.6表达式 (79) 6.7JavaScript (79) 第三篇POWERBUILDER编码规范 (80) 第一章代码组织 (81) 第二章命名 (82) 2.1文件命名 (82) 2.2对象命名 (82) 2.3变量命名 (84) 2.4常量命名 (85) 2.5函数与事件命名 (85) 2.6参数命名 (85) 第三章注释 (85) 3.1文档化注释 (85) 3.2语句块注释 (88) 3.3代码维护注释 (88) 第四章编码风格 (89) 4.1界面风格 (89) 4.2排版风格 (93) 4.3变量与常量 (95) 4.4条件判断 (96) 4.5空间申请与释放 (97) 4.6函数编写 (97) 4.7特殊限制 (97) 第五章SQL编码 (98)
1 设计规范 这里主要摘取了OO设计原则的其中几条，其中开闭原则、里氏替换原则必须遵守，单一职责原则尽量要求遵守，接口分离、合成聚合、依赖倒置原则强烈推荐遵守，另外补充了一些其他规范。 1.1开闭原则(Open-Closed Principle, OCP) 这是最基本的原则，一个模块应当对扩展开放,对修改关闭。确切地说，模块的对外接口不能被修改，而只能被扩展，当某个开发者使用了你的接口，而却被你后期修改了这个接口，那对程序是一个灾难。 因此在进行设计时要尽量考虑接口封装机制、抽象机制和多态技术。 1.2单一职责原则SRP (Simple responsibility pinciple) 不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。 很多人可能觉得它很简单，但在实际中，我们多有不遵守这条原则。即便是经验丰富的程序员写出的程序，也会有违背这一原则的代码存在。为什么会出现这种现象呢？因为有职责扩散。所谓职责扩散，就是因为某种原因，职责P被分化为粒度更细的职责P1和P2。 比如：类T只负责一个职责P，这样设计是符合单一职责原则的。后来由于某种原因，也许是需求变更，也许是程序的设计者境界提高，需要将职责P细分为粒度更细的职责P1，P2，这时如果要使程序遵循单一职责原则，需要将类T也分解为两个类T1和T2，分别负责P1、P2两个职责。但是在程序已经写好的情况下，这样做简直太费时间了。所以，简单的修改类T，用它来负责两个职责是一个比较不错的选择，虽然这样做有悖于单一职责原则。（这样做的风险在于职责扩散的不确定性，因为我们不会想到这个职责P，在未来可能会扩散为P1，P2，P3，P4……Pn。所以记住，在职责扩散到我们无法控制的程度之前，立刻对代码进行重构。） 遵循单一职责的优点有： 可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；