研发部代码规范
软件工程软件代码编程规范
软件代码编程规范软件代码编程规范编号：发布日期：编制部门：研发部审核人：批准人：目录0.版本记录 (5)1.目的 (6)2.适用范围 (6)3.术语定义 (6)3.1 原则 (6)3.2 规则 (6)3.3 建议 (6)3.4 说明 (6)3.5 正例 (6)3.6 反例 (7)4.职责 (7)5.工作程序 (7)5.1 基本原则 (7)5.1.1 原则1-1 (7)5.1.2 原则1-2 (7)5.1.3 原则1-3 (7)5.1.4 原则1-4 (7)5.1.5 原则1-5 (7)5.1.6 原则1-6 (8)5.1.7 原则1-7 (8)5.2 布局 (8)5.2.1 基本格式 (8)5.2.2 对齐 (10)5.2.3 空行空格 (12)5.2.4 断行 (14)5.3 注释 (15)5.3.1 规则3-1 (15)5.3.3 规则3-3 (16)5.3.4 规则3-4 (16)5.3.5 规则3-5 (17)5.3.6 规则3-6 (17)5.3.7 规则3-7 (18)5.3.8 规则3-8 (18)5.3.9 规则3-9 (19)5.3.10 规则3-10 (20)5.3.11 建议3-1 (20)5.3.12 建议3-2 (20)5.4 命名规则 (20)5.4.1 规则4-1 (21)5.4.2 规则4-2 (21)5.4.3 规则4-3 (21)5.4.4 规则4-4 (23)5.4.5 规则4-5 (23)5.4.6 规则4-6 (23)5.4.7 规则4-7 (23)5.4.8 规则4-8 (23)5.4.9 规则4-9 (24)5.4.10 规则4-10 (24)5.4.11 规则4-11 (25)5.4.12 规则4-12 (25)5.4.13 规则4-13 (25)5.4.14 规则4-14 (25)5.4.15 规则4-15 (26)5.4.16 规则4-16 (26)5.4.17 规则4-17 (26)5.4.19 规则4-19 (27)5.4.20 建议4-1 (27)5.4.21 建议4-2 (27)5.5 声明 (27)5.5.1 规则5-1 (27)5.5.2 规则5-2 (27)5.5.3 建议5-1 (27)5.6 表达式与语句 (28)5.6.1 规则6-1 (28)5.6.2 规则6-2 (29)5.6.3 规则6-3 (29)5.6.4 规则6-4 (29)5.6.5 规则6-5 (30)5.6.6 规则6-6 (30)5.6.7 建议6-1 (30)5.6.8 建议6-2 (30)5.6.9 建议6-3 (31)5.6.10 建议6-4 (31)5.6.11 建议6-5 (32)5.7 类和接口 (33)5.7.1 规则7-1 (33)5.7.2 建议7-1 (34)5.7.3 建议7-2 (34)5.7.4 建议7-3 (34)5.7.5 建议7-4 (34)5.7.6 建议7-5 (35)5.7.7 建议7-6 (35)6.相关文件 (35)0.版本记录以C#代码为例，规范编码规则和注意事项，明确编程的各项要求，提高代码的可靠性、可读性、可修改性、可维护性、一致性、可再利用性等。
研发项目编码的规范
科技研发项目编码的规范
为进一步规范研发项目的管理，现对公司研发项目的编码规范如下： 04 . ☐☐☐. ☐☐ . ☐☐
1、项目类别：研发项目专用类别代号04；
2、项目时间：采用项目立项年度的后3位，例如：2018年立项目为018，2019年立项项目为019。
3、项目责任部门：项目实施的主要责任部门（或子公司）。
采用各部门（或子公司）的指定代码，如下所示：
研发部01，工程部02，软件部03，工艺技术部04，市场部05。
4、项目序列号：同一年度同一部门项目的流水号，例如：研发部2019年承担并立项的第1个研发项目，项目序列号则为01，第2个项目则为02。
示例：04.019.01.03，研发部2019年承担的第3个研发项目
其它说明：为区别于公司的工程项目编码，研发项目首分段固定为04。
以上规范从即日起执行。
研发部
2018年3月10日
项目时间
项目责任部门
项目序列号
项目类别。
企业文件编码规则及部门代码
文件编码建议按如下规则：1. 文件编码结构：1.1 抬头码：通常是公司简写1.2 文件阶层码：表明文件是哪一层的,比如,属于质量手册的用QM来表示1.3 文件类别码：代表过程,比如：用5来代表与管理职责相关的1.4 文件序列码：比如,在第5部分,用01来表示质量目标,用02来表示管理评审等等1.5 文件版本码：表明文件的版本2. 各部分详细规则：2.1 抬头码：表表阅读者能够很清楚地知道,这个文件是一个关于管理职责部分的A/0版程序文件ABC/QW/501—A/1关于管理职责部分的A/1版本的三级文件ABC/QR/501—A/1关于管理职责部分的A/1版本的记录表单ABC/ED/501—A/1关于管理职责部分的A/1版本的外来文件采用上述编码规则的好处在于：阅读者清楚文件分类和属性编写者清楚,在新编一个文件的时候,如何进行明确准确编码;对应的ISO9001标准相关条款"S&M 7.2.1、7.2.2、7.2.3、7.5.4、8.2.1、4.2.4 MNF 5.4.1、7.5.1、8.2.4、6.3、6.4 4.2.4、7.5.2、6.2.2、7.5.3、7.5.5、8.3、ENG 4.2.3、4.2.4、7.2.2、7.1、6.3P&L 4.2.4、7.2.2、8.4、7.2.1、4.2.4、5.5.3、8.2.3、7.5.3、7.5.5、6.2.2、4.2.3、4.2.4、8.3PUR 4.2.3、4.2.4、7.4.1、7.4.2、、、行政管理部Administration Management Department客户服务部Customer Service Department信息管理部Information Management Department市场部Marketing Department销售部Sales Department计划部Planning Department设备部Equipment Department仓储部Storage Department财务部Finance DepartmentISO国际文件编号目的：使品质系统所使用之文件,能迅速流通、正确应用,并确保各相关部门可适时获得适当且有效之最新文件;范围：凡公司内所有与产品质量相关之文件、资料及外部客户、供货商所提供与品质系统相关文件均属之;5.2.1 经审查通过之各类文件,于颁布发行前,由文管中心文件编号规定给予统一编码、标识并登录于文件控制总表;5.2.2 版本版次制订：5.2.2.1 版本：以“A”表示,换版以B、C、D…Z…表示;5.2.2.2 版次：以数字“1~5”表示;版次制订若超过五次为避免版次修订过多影响文件真实内容,则更新为下一版本;5.3 文件制订、归档：5.3.1 制订作业：文件制订依系统需求由各主办单位制订后填写文件制订、修订、废止申请单注明“制订”,送交各相关单位审核并填写所需份数,经权责主管核准后,送交文管中心编号、发行、列管;5.3.2 归档作业：对生产一课、生产二课、HOSE 生产课的作业标准、产品设计表的电子版本的文件由ISO事务局保存；其他所有文件的原件必须交ISO文控存档;5.4 文件分发：5.4.1 文件发行：对的作业标准、产品设计表由ISO事务局发行并记入作业标准管理台账,写明分发分数,并由接收人签名;其他文件由文控中心依文件制订、修,5.6.2 如在回收过程中发现原文件持有单位有文件遗失现象,应即刻寻回,如果确实无能力找回时,应于文件遗失记录表上填写遗失原因以便文控中心管理;5.7 外来文件管制5.7.1 外来文件的确认由品保课长或管理者代表确认,由文控中心于文件控制总表中登录;为使外来文件便于管理及正常应用,可由文控中心依文件编号规定直接对于外来文件正面书写文件编号;5.7.2 外来文件需签署分发时,由接受单位填写外来文件申请单经部门主管审核,经理核准后执行,发行同5.4.1;5.7.3 外来文件使用过程中如发现有异常时,因属客户财产,使用部门不得私自更改其中内容,如需更改应实时联络客户共同探讨;5.7.4 为维护客户权益,外来文件只能局限于使用部门应用或参考,他人不能随便借阅或申请影印;如特殊情况需借阅或申请影印时应取得管理者代表品保部朴部长同意;5.7.5 对于业务原因需将顾客资料发给供应商的必须获得顾客的事先确认；否则必须将其进行转化才可以发放,发放应由发放部门做好发放纪录;5.7.6 废止外来文件的保管根据客户或总经理意愿决定;5.8 文件档案管理：年号文件序号程序文件公司英文缩写5.1.3三层次文件FLY/QA-OI-000-EX文件来源IN内部省略,EX外部序列号文件类型部门代码公司英文缩写部门代码部门总经理室技术部质量部生产部经营部综合部代码GM TD QA PD MD HR文件类型代码A、质量手册的编号方法：QM - XX发布年号B、程序文件的编号方法：QP - ××对应的ISO标准条款- ××流水号C、作业指导书,检验标准,设备操作规范等三阶文件编号方法:QI WI/SOP– XX部门代号- X X X流水号D、表单编号方法：X X X X X表单出自的文件的编号 - ××流水号。
2.研发部源代码控制管理规定
三方软件、控件和其它支撑库等文件，然后进行测试。 所有提交到 SVN 上的代码必须保证编译通过,而且提交的时候不会影响主干其它程序的 正常运行.
2、 源代码的授权访问
源代码服务器对于共享的 SVN 库的访问建立操作系统级的，基于身份和口令的访问授 权。（由 SVN 管理员进行管理和设置） 在 SVN 库中设置用户，为不同用户分配不同的、适合工作的最小访问权限。要求连接 SVN 库时必须校验 SVN 中用户身份及其口令。在 SVN 库中要求区别对待不同用户的可 访问权、可创建权、可编辑权、可删除权、可销毁权。每个用户切实保证自己的用户 身份和口令不泄露,用户要经常更换自己在 SVN 库中账号的口令。同时，工作任务变化 或岗位调整后 SVN 管理员要实时回收用户的相关权限。要获取不属于自己范围内的文 件，例如：代码、数据库，需求文档等，需经项目经理和技术部经理审批同意后由 SVN 管理员授权。 组建特殊项目团队时，SVN 管理员为每个参与项目的人设置权限，每人只有自己的权 限范围内的代码，核心代码由项目经理或技术经理专人管理。 涉及、接触源代码的计算机必须建立专人专用制度，任何其他人不得在未获得技术部 经理授权的情况下操作和使用此计算机。此计算机的专用人也不得私自同意或者漠视 他人非获得授权使用本计算机。 曾经涉及、触及源代码的计算机在转作它用，或者离开技术部门之前必须由运维人员 全面清除计算机硬盘中存储的源代码。如果不能确定，必须对计算机中所有硬盘进行 全面格式化后方可以转做它用或离开技术部门。 开发人员如果在自己的任务范围内,需要调用他人的代码或者方法时,需要向系统组提出 申请,不能直接 copy 他人的代码放入自己的包内。 任何人如果需要调用其他工程的代码,在不必要的情况下,不提供原代码,理论上提供 API 供其调用,如有必要,需要提出申请,并且最小范围参看源代码。
软件研发项目编码规范与开发标准
软件研发项目编码规范与开发标准在软件研发项目中，编码规范与开发标准是至关重要的。
良好的编码规范可以增加代码的可读性和可维护性，提高团队合作效率，降低软件开发的错误率。
本文将探讨软件研发项目中编码规范与开发标准的重要性，并介绍一些常用的编码规范和开发标准。
首先，编码规范是指在软件开发过程中制定的一系列规则和约定，用来规范开发人员编写代码的风格和格式。
良好的编码规范可以使代码更易于阅读和理解，减少代码的bug和错误。
此外，编码规范还可以统一团队成员的编码习惯，提高团队合作效率。
因此，一个团队如果能够遵守一套统一的编码规范，在软件开发过程中将会更加高效和顺畅。
其次，开发标准是指在软件开发项目中约定的一套规范和标准，用来指导开发人员在软件开发过程中的行为和决策。
开发标准可以包括项目的架构设计、模块划分、代码管理、测试方法等方面的规范。
遵守开发标准可以确保项目的稳定性和可靠性，提高软件的质量和性能。
在实际的软件研发项目中，编码规范和开发标准起到了至关重要的作用。
在编写代码时，开发人员需要遵守统一的编码规范，确保代码的格式、命名规范、注释等方面符合规范要求。
在项目的架构设计和模块划分阶段，开发人员需要按照约定的开发标准进行规划和设计，确保项目的整体结构和组织清晰明了。
为了有效地制定和实施编码规范与开发标准，团队可以通过以下几个方面进行改进：1. 建立统一的编码规范和开发标准：团队需要制定一套统一的编码规范和开发标准，确保所有成员遵守相同的规范。
这些规范可以包括代码的格式、命名规范、注释规范等方面的要求。
2. 培训和指导开发人员：团队可以组织相关的培训和指导活动，帮助开发人员了解并遵守编码规范和开发标准。
通过培训，开发人员可以更好地理解规范的重要性，提高代码编写的质量和效率。
3. 使用自动化工具检查代码规范：团队可以借助一些自动化工具，如代码静态分析工具，来检查代码是否符合编码规范和开发标准。
这些工具可以帮助团队及时发现和纠正代码中的问题，提高代码的质量和可维护性。
代码版本管理规范_v1.1
XXXXXXXX 代码版本管理规范历史版本目录历史版本 (2)1引言 (4)1.1目的 (4)1.2管理工具 (4)2现状概述 (5)3现状分析 (5)3.1现状详述 (5)3.2目标细化 (6)3.3SVN版本管理 (6)3.3.1概述 (6)3.3.2使用对比 (7)4完整的实施方案 (9)4.1开发阶段 (9)4.2预发布测试阶段 (9)1引言1.1目的为了规范和制度化公司的软件版本管理制度，并保障项目开发资料的完整性和安全性，同时明确开发源代码的控制管理流程，特此制定此规范。
1.2管理工具沿用SVN管理工具来进行开发的版本管理，源代码管理和开发资料归档。
2现状概述目前公司研发部门对于代码的版本管理方式较为简单，只是在每次发版后做了基线库存档，导致所有正在开发的需求和项目都在同一个目录里面进行修改，造成每次发版的代码都有可能包含了本次发版以外的内容。
这样会造成如下两点影响：●会有不稳定的因素存在，比如：测试只会对当前需要发版的内容进行测试，但是代码库中同时存在多个版本和项目的代码，对于本次发版无涉及的代码没有进过测试就部署到了服务器上，影响运行的稳定性。
●一旦出现点问题不好定位，比如：出现问题后通常会优先排查发版涉及的内容，但是部分问题是由于其他项目代码引起的。
因此，随着公司和项目规模的壮大，对软件代码版本管理提出了更高的要求。
3现状分析3.1现状详述当前代码版本管理现状如下：1.所有的开发都在一个目录里面做，各种需求、项目、代码、文件混杂在一起。
2.提交测试服务器时，只考虑了编译能通过，而没有考虑功能本身有没有完成。
3.测试出bug以后，会在开发目录进行修改，然后再次提交到测试服务器。
这时提交的代码就可能包含了他人对其他功能/项目的修改，而测试又只会针对此bug再做测试。
这就导致了除了此bug之外的修改可能会没有测试过就直接发布到了服务器上，引起预发布环境不稳定并增加预发布bug数量。
总体来说，当前工作流程是：预发布出bug，研发修改，再提交测试，然后预发布测试通过的代码。
软件开发编码规范
软件安全开发编码规范1. 代码编写1) 开发人员应保证工程中不存在无用的资源（如代码、图片文件等）。
2) 代码中每个类名上的注释必须留下创建者和修改者的名字。
3) 每个需要import的类都应使用一行import声明，不得使用import xxx.*。
4) System.out.println()仅在调试时使用，正式代码里不应出现。
5) 开发人员编写代码时应遵循以下命名规则：●Package 名称应该都是由一组小写字母组成；●Class 名称中的每个单词的首字母必须大写；●Static Final 变量的名称全用大写，并且名称后加注释；●参数的名称必须和变量的命名规范一致；●使用有意义的参数命名，如果可能的话，使用和要赋值的字段一样的名称。
6) 代码应该用unix的格式，而不是windows的。
7) exit 除了在main 中可以被调用外，其他的地方不应被调用。
8) 代码中应尽量使用interfaces，不要使用abstract类。
9) 在需要换行的情况下，尽量使用println 来代替在字符串中使用的"\n"。
10) 涉及HTML的文档，尽量使用XHTML1.0 transitional文件类型，其中所有HTML标签都应关闭。
11) 在HTML、JavaScript、XML代码中，缩进应为两个空格，不得使用Tab。
12) HTML标签的name和id属性的命名方式应与Java变量名相同。
13) 在需要经常创建开销较大的对象时，开发人员应考虑使用对象池。
14) 在进行log的获取时开发人员应尽量使用isXXXEnabled。
15) log的生成环境上尽量避免输出文件名和行号。
16) 产品中不要包含后门代码，隔离系统中的后门代码，确保其不能出现在产品中。
作为一种特殊的调试代码，后门访问代码是为了使开发者和测试工程师访问一部分终端用户不能访问的程序代码。
但是，如果后门代码被留到产品中，对攻击者来说，它就是一条不需要通过正常安全手段来攻陷系统的通路。
软件开发编码及命名规范
软件开发编码及命名规范1.目的为了保证企业编写出的程序都符合相同的规范，保证一致性、统一性而建立的程序编码规范。
2.范围适用于企业所有基于.NET平台的软件开发工作。
3.规范内容3.1.代码格式所有的缩进为4个空格，使用的默认设置。
在代码中垂直对齐左括号和右括号。
if(x==0){Response.Write("用户编号必须输入！");}不允许以下情况：if(x==0) {Response.Write("用户编号必须输入！"); }或者：if(x==0){ Response.Write("用户编号必须输入！");}为了防止在阅读代码时不得不滚动源代码编辑器，每行代码或注释在1024*800的显示频率下不得超过一显示屏当一行被分为几行时，通过将串联运算符放在每一行的末尾而不是开头，清楚地表示没有后面的行是不完整的。
每一行上放置的语句避免超过一条。
在大多数运算符之前和之后使用空格，这样做时不会改变代码的意图却可以使代码容易阅读。
例：int j = i + k;而不应写为int j=i+k;将大的复杂代码节分为较小的、易于理解的模块。
编写SQL语句时，对于关键字使用全部大写，对于数据库元素（如表、列和视图）使用大小写混合。
将每个主要的SQL子句放在不同的行上，这样更容易阅读和编辑语句，例如： SELECT FirstName, LastNameFROM CustomersWHERE State = 'WA'3.2.注释（Comment）规范注释规范包括：模块（类）注释规范、类的属性、方法注释规范、代码间注释3.2.1.模块（类）注释规范模块开始必须以以下形式书写模块注释：///<summary>///模块编号：<模块编号，可以引用系统设计中的模块编号>///作用：<对此类的描述，可以引用系统设计中的描述>///作者：作者中文名///编写日期：<模块创建日期，格式：YYYY-MM-DD>///</summary>如果模块有修改，则每次修改必须添加以下注释：///<summary>///Log编号：<Log编号,从1开始一次增加>///修改描述：<对此修改的描述>///作者：修改者中文名///修改日期：<模块修改日期，格式：YYYY-MM-DD>///</summary>3.2.2.类属性注释规范在类的属性必须以以下格式编写属性注释：/// <summary>///属性说明/// </summary>3.2.3.方法注释规范在类的方法声明前必须以以下格式编写注释/// <summary>/// 说明：<对该方法的说明>/// </summary>/// <param name="<参数名称>"><参数说明></param>/// <returns>///<对方法返回值的说明，该说明必须明确说明返回的值代表什么含义> /// </returns>3.2.4.代码间注释规范代码间注释分为单行注释和多行注释：单行注释： //<单行注释>多行注释：/*多行注释1多行注释2多行注释3*/代码中遇到语句块时必须添加注释（if,for,foreach,……）,添加的注释必须能够说明此语句块的作用和实现手段（所用算法等等）。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
版/次：2015.10.29研发部代码规范编制：钱凌杰审核：批准：分发号：无锡同方融达信息科技有限公司2015年10月目录一、概述 51.1编写目的 51.2文档约定 51.3预期的读者和阅读建议 51.4参考文献 5二、排版要求 52.1程序块缩进 52.2程序块之间空行 52.3长语句和长表达式 62.4循环、判断等长表达式或语句 62.5长参数 72.6短语句 82.7条件、循环语句 82.8语句对齐 82.9函数、过程和结构等语句块 92.10程序块分界符 92.11操作符前后空格 102.12其他 11三、注释 113.1有效注释量 113.2公司标识 113.3说明性文件 123.4源文件头 133.5函数头部说明 133.6注释与代码一致 143.7注释内容 143.8注释缩写 143.9注释位置 143.10变量、常量注释 153.11数据结构的注释 153.12全局变量 163.13注释缩排 163.14注释与代码之间空行 173.15变量定义、分支语句 173.16其他 19四、标识符命名 204.1命名清晰 204.2特殊命名需注释 214.3命名风格保持一致 214.4变量命名 214.5命名规范与系统风格一致 214.6其他 22五、可读性 235.1运算符优先级 235.2避免直接使用数字作为标识符 245.3其他 24六、变量、结构 256.1公共变量 256.2公共变量说明 256.3公共变量访问说明 266.4公共变量赋值 266.5防止局部变量与公共变量同名。
266.6严禁使用未经初始化的变量作为右值。
266.7其他 27七、函数、过程 347.1对所调用函数的错误返回码要仔细、全面地处理。
347.2明确函数功能，精确（而不是近似）地实现函数设计。
347.3局部变量 347.4全局变量 347.5接口函数参数 357.6其他 35八、可测性 448.1调测开关 448.2打印信息 458.3单元测试 458.4集成测试 458.5断言使用 458.6设置与取消有关测试手段时，不能影响软件功能功能 488.7版本维护 488.8其他 48九、程序效率 509.1编程时要经常注意代码的效率。
509.2提高代码效率 509.3全局效率高于局部效率 519.4提高代码空间效率 519.5循环体内工作量最小化 529.6其他 53十、质量保证 5610.1在软件设计过程中构筑软件质量。
5610.2代码质量保证优先原则 5610.3只引用属于自己的存贮空间。
5610.4防止引用已经释放的内存空间。
5610.5内存及时释放 5710.6文件句柄及时关闭 5710.7防止内存操作越界 5810.8认真处理程序所能遇到的各种出错情况 5910.9初始化变量 5910.10数据一致性检查 5910.11严禁随意更改其它模块或系统的有关设置和配置 5910.12不能随意改变与其它模块的接口 5910.13系统接口 5910.14编程时，要防止差1错误 6110.15操作符检查 6110.16分支语句写完整 6210.17使用return语句 6210.18不要滥用goto语句 6210.19其他 62十一、代码编辑、编译、审查 6511.1打开编译器的所有告警开关对程序进行编译 6511.2在产品软件（项目组）中，要统一编译开关选项 6511.3通过代码走读及审查方式对代码进行检查。
6511.4测试部测试产品之前，应对代码进行抽查及评审 6511.5其他 65十二、代码测试、维护 6712.1单元测试要求至少达到语句覆盖 6712.2单元测试开始要跟踪每一条语句，并观察数据流及变量的变化 6712.3清理、整理或优化后的代码要经过审查及测试。
6712.4代码版本升级要经过严格测试 6712.5使用工具软件对代码版本进行维护 6712.6正式版本上软件的任何修改都应有详细的文档记录 6712.7其他 67十三、宏 6813.1用宏定义表达式时，要使用完备的括号 6813.2将宏所定义的多条表达式放在大括号中 6813.3使用宏时，不允许参数发生变化 69一、概述.1 编写目的为规范软件开发人员的代码编写提供参考依据和统一标准。
.2 文档约定.3 预期的读者和阅读建议本文档适用于所有软件开发人员。
.4 参考文献二、排版要求11.1 程序块缩进程序块要采用缩进风格编写，缩进的空格数为4个。
说明：对于由开发工具自动生成的代码可以有不一致。
1.2 程序块之间空行相对独立的程序块之间、变量说明之后必须加空行。
示例：如下例子不符合规范。
if (!valid_ni(ni)){... // program code}repssn_ind = ssn_data[index].repssn_index;repssn_ni = ssn_data[index].ni;应如下书写if (!valid_ni(ni)){... // program code}repssn_ind = ssn_data[index].repssn_index;repssn_ni = ssn_data[index].ni;1.3 长语句和长表达式较长的语句（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读。
示例：perm_count_msg.head.len = 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)); 1.4 循环、判断等长表达式或语句循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分，长表达式要在低优先级操作符处划分新行，操作符放在新行之首。
示例：if ((taskno < max_act_task_number)&& (n7stat_stat_item_valid (stat_item))){... // program code}for (i = 0, j = 0; (i <BufferKeyword[word_index].word_length)&& (j <NewKeyword.word_length); i++, j++){... // program code}for (i = 0, j = 0;(i < first_word_length) && (j <second_word_length);i++, j++){... // program code}1.5 长参数若函数或过程中的参数较长，则要进行适当的划分。
示例：n7stat_str_compare((BYTE *) & stat_object,(BYTE *) &(act_task_table[taskno].stat_object),sizeof (_STAT_OBJECT));n7stat_flash_act_duration( stat_item, frame_id*STAT_TASK_CHECK_NUMBER+ index, stat_object );1.6 短语句不允许把多个短语句写在一行中，即一行只写一条语句。
示例：如下例子不符合规范。
rect.length = 0; rect.width = 0;应如下书写rect.length = 0;rect.width = 0;1.7 条件、循环语句if、for、do、while、case、switch、default等语句自占一行，且if、for、do、while等语句的执行语句部分无论多少都要加括号{}。
示例：如下例子不符合规范。
if (pUserCR == NULL) return;应如下书写：if (pUserCR == NULL){return;}1.8 语句对齐对齐只使用空格键，不使用TAB键。
说明：以免用不同的编辑器阅读程序时，因TAB键所设置的空格数目不同而造成程序布局不整齐，不要使用BC作为编辑器合版本，因为BC会自动将8个空格变为一个TAB 键，因此使用BC合入的版本大多会将缩进变乱。
1.9 函数、过程和结构等语句块函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格，case语句下的情况处理语句也要遵从语句缩进要求。
1.10 程序块分界符程序块的分界符（如C/C++语言的大括号‘{’和‘}’）应各独占一行并且位于同一列，同时与引用它们的语句左对齐。
在函数体的开始、类的定义、结构的定义、枚举的定义以及if、for、do、while、switch、case语句中的程序都要采用如上的缩进方式。
示例：如下例子不符合规范。
for (...) {... // program code}if (...){... // program code}void example_fun( void ){... // program code}应如下书写。
for (...){... // program code}if (...){... // program code}void example_fun( void ){... // program code}1.11 操作符前后空格在两个以上的关键字、变量、常量进行对等操作时，它们之间的操作符之前、之后或者前后要加空格；进行非对等操作时，如果是关系密切的立即操作符（如－>），后不应加空格。
说明：采用这种松散方式编写代码的目的是使代码更加清晰。
由于留空格所产生的清晰性是相对的，所以，在已经非常清晰的语句中没有必要再留空格，如果语句已足够清晰则括号内侧(即左括号后面和右括号前面)不需要加空格，多重括号间不必加空格，因为在C/C++语言中括号已经是最清晰的标志了。