嵌入式程序编码规范

嵌入式程序编码规范
嵌入式程序编码规范

嵌入式程序编码规范

一、基本要求

1.程序总体要求

1.1程序结构清析,简单易懂,单个函数的程序行数不得超过200行。

1.2打算干什么,要简单,直接了当,代码精简,避免垃圾程序。

1.3尽量使用标准库函数和公共函数。

1.4不要随意定义全局变量,尽量使用局部变量。

1.5使用括号以避免二义性。

1.6单元测试也是编程的一部份,编写程序时,亦必须想好测试的方法。即"单元测试"的

测试方案应在编写程序是一并拟好并提交。

2.可读性要求

2.1可读性第一,效率第二。

2.2保持注释与代码完全一致。

2.3每个源程序文件,都有文件头说明,说明规格见规范。

2.4每个函数,都有函数头说明,说明规格见规范。

2.5主要变量(结构、联合、类或对象)定义或引用时,注释能反映其含义。

2.7常量定义(DEFINE)有相应说明。

2.8处理过程的每个阶段都有相关注释说明。

2.9在典型算法前都有注释。

2.10利用缩进来显示程序的逻辑结构,缩进量一致并以Tab键为单位,定义Tab为6个

字节。

2.11循环、分支层次不要超过五层。

2.12注释可以与语句在同一行,也可以在上行。

2.13空行和空白字符也是一种特殊注释。

2.14一目了然的语句不加注释。

2.15注释的作用范围可以为:定义、引用、条件分支以及一段代码。

2.16注释行数(不包括程序头和函数头说明部份)应占总行数的1/5到1/3。

3.结构化要求

3.1禁止出现两条等价的支路。

3.2禁止GOTO语句。

3.3用IF语句来强调只执行两组语句中的一组。禁止ELSE GOTO和ELSE RETURN。

3.4用CASE实现多路分支。

3.5避免从循环引出多个出口。

3.6函数只有一个出口。

3.7不鼓励使用条件赋值语句。

3.8避免不必要的分支。

3.9不要轻易用条件分支去替换逻辑表达式。

4.正确性与容错性要求

4.1程序首先是正确,其次是优美

4.2无法证明你的程序没有错误,因此在编写完一段程序后,应先回头检查。

4.3改一个错误时可能产生新的错误,因此在修改前首先考虑对其它程序的影响。

4.4所有变量在调用前必须被初始化。

4.5对所有的用户输入,必须进行合法性检查。

4.6不要比较浮点数的相等,

如:10.0 * 0.1 == 1.0,不可靠

4.7程序与环境或状态发生关系时,必须主动去处理发生的意外事件,如文件能否

逻辑锁定、打印机是否联机等。

4.9提交联调测试的程序必须通过单元测试。

5.可重用性要求

5.1重复使用的完成相对独立功能的算法或代码应抽象为公共控件或类。

5.2公共控件或类应考虑OO思想,减少外界联系,考虑独立性或封装性。

5.3公共控件或类应建立使用模板。

二、编程规则

1.Goto语句,尤其是局部的gotos,是不允许的。

解释:遵循结构化编程规范,使代码更加明白易懂。

2.If语句的then和else分支不能为空。

解释:使代码更加明白易懂。

3.在for、do和while循环中,不提倡使用break和continue语句。

解释:如同goto一样,这些语句破坏了代码的结构化程度,在循环中减少使用将会使代码更加明白易懂。

4.For语句中的计数器不应在循环体之中被改变,并且必须是一个局部变量。

解释:减少出错风险且使代码明白易懂。

5.Switch结构中必须要有default语句。

解释:switch结构中所有类型的case分支都要具备(default也是一种分支)。

6.包含有指令语句的Case子句块必须含有break语句,且break语句为该case子句的最后一条语句。如果break不是某switch分支的最后一条语句,应增加分支,为每个分支设置一个break语句。

解释:这使得代码更加明白易懂且降低了出错的可能性和风险。

7.如果在某个函数中使用了return指令语句,鼓励它是唯一的(即该函数中只能有一个return指令),且作为函数的最后一条语句。

解释:只有一个出口的函数更加明白易懂。

8.在goto或return语句之后不能有不可到达的语句。

解释:原则上,不能有不可到达的代码。如果有,很可能就是逻辑上的错误。

9.禁止对附值语句的值进行测试。

如:if(x=y){?

(y的值附给了x,如果x的值不为0,该if语句将被执行。)

解释:诸如此类的语句是不明确或不清楚的。或许有人会认为作者的意图是要写

if(x==y){?

最好是将附值语句与if语句分开来。

10.在遍历数组中的连续元素时,应该使用指针,而不是下标。

解释:使代码更高效。

11.每一个逻辑块应该使用括号括起来,即使它没有语句或只有一条语句。在switch语句中

该规则不必适用,因为case和default语句隔离开了各个逻辑块。

例如:if(x==0){y=1;}

解释:使指令范围更加清楚,代码更易读。

12.每个函数不得有多于5个的参数,且所有参数都必须使用。

解释:使代码更易读,防止错误出现。

13.不鼓励在指令块中声明局部变量。

解释:避免到处都是声明,使维护更加容易。

14.全局对象应在一个包含文件中声明。

解释:将声明集中化有利于维护。

15.声明了的变量必须要使用。

解释:使代码更易读、更可靠。

16.声明了的函数必须使用。

解释:防止错误出现。

17.不鼓励使用递归调用,除非算法必须或提高效率的考虑。

解释:使代码更易维护。

18.不能使用全局变量作为函数参数。

解释:保证全局变量的使用都是有意的,即随处可用。

19.一个文件不能有超过三级的包含层次,尽量不超过两层(指头文件)。

解释:使代码更易读。

20.禁止使用诸如x==y;或x!=y;的指令语句,它们只应在判断语句中使用。

解释:使代码更可靠。这类指令没有效果,应不被使用。

三、表达规则

1.每行最多只包含一个声明。

解释:使代码更易读。

2.每一行只能包含一条指令语句。

解释:使代码更易读。

3.边界大括号独占一行。

解释:使程序结构清楚,代码更易读。

4.每个函数的代码不能超过200行,每个模块的代码不能超过2000行。

解释:使代码更易读。

5.Switch语句的每一个子句块不能超过30条语句。

解释:使代码更易读。

6.C++的关键字不能用做C的关键字。

如:class, new, friend,

解释:防止在移植到C++上时出现混乱。

7.变量的声明和初始化要分开。

解释:使代码更易读。

8.如果可能的话,必须同时对变量进行声明和初始化。

解释:保证变量在使用前被正确初始化。

9.函数之间,有至少两个空行隔开;函数内部不同的功能块之间,用一个空行隔开。

解释:使代码更易读。

10.运算符前后应留有空格。

解释:使代码更易读。

四、命名规则

1.变量名采用匈牙利命名法。声明时每行一个匈牙利命名法,第一个字母小写表示类型:n:整型;f:浮点;s:字符串;c:字符;p:指针;b:布尔;t:类。

解释:变量标准命名使代码明白易懂。

2.类的定义命名,第一个字母用大写的C,如CmyClass;类的成员变量命名,第一个字母用小写的m,如mpStrVar;类的成员函数命名,第一个字母用大写的M,如Msort()。

解释:类命名规范使程序更具有可读性。

3.全局变量命名:对于多模块适用的全程变量,一律以小写的g开头,如gcUserName;对于只用于本模块的全程变量,一律使用小写的k开头,如:char *kpBookStr[]。

解释:突出全局变量将使代码更明白易懂。

4.局部变量以小写字母开头,其余为小写字母、数字或'_'字符(没有大写字母)。要求使用"类型_模块名_功能"形式;如:pt_lcd_data, pi_http_state 等。

解释:使局部变量容易定位,使代码更加明白易懂。

5.函数命名要求使用" 模块名_功能()"格式,全部使用小写字母;如:lcd_putc(),serial_putc(),http_get()等等。

解释:使函数容易定位,使代码明白易懂。

6.宏及符号常量的定义:所有的宏和符号常量都必须以大写字母开头,其余为大写字母、数字或'_'符号(无小写字母)。程序中出现字符串,必须使用宏定义。

解释:突出符号常量使代码更明白易懂。

7.非预定义的类型名要以大写字母开头,其余为大写字母、数字或'_'字符(无小写字母)。

解释:突出类型名使代码更明白易懂。

8.结构化的类型元素以大写字母开头,其余为小写字母、数字或'_'字符。

解释:突出结构化的类型元素使代码更明白易懂。

10.公共类型定义:

有符号字符:char

有符号短整数:SHORT 有符号整数:int

有符号长整数:long 无符号字符:BYTE

无符号短整数:WORD 无符号整数:DWORD 无符号长整数:ULONG

解释:规定公共类型定义使代码编写更统一,可读性更好。

11.关键字必须多于两个字符。

解释:使代码更加明白易懂。单字符的变量(如i, j, k)可能会在for语句中被用做计数器。

12.关键字不能多于31个字符。

解释:这是 C ANSI标准所要求的。

13.关键字最好不用下划线'_'做开头或结尾。

解释:使代码更易读。很难区分_name和name_。

14.关键字不能有超过一个的'_'字符连续。

解释:使代码更易读。很难区分variable_name和variable__name。

15.关键字不能包含'$'字符。

解释:这是 C ANSI标准所要求的。

16. 各个模块自己使用的变量尽量统一到一个模块结构变量中。

解释:使代码更易读。

17. 各个模块的宏定义名一定要大写,且要求为"模块名_宏定义名"如:SERIAL_MAXRECVBUFS

IZE; HTTP_WAITING。

解释:使宏意义明确,代码更容易读。

五、注释规则

1.注释分为文件头序言性注释、函数模块头序言性注释、功能性注释及其它注释。

2.对序言性注释应有明确、统一的规定,功能性注释不要太多。总体功能由序言性注释描述,细节由代码本身说明。

3.文件头的序言性注释需要有如下注释文字说明:

文件名:

此文件所包含的主要功能说明:

开发简历:设计者,修改日期及记录等

4.每个函数、过程的开头部分,给出此函数或过程的整体说明,即函数模块头序言性注释:程序标题,模块名:

模块的功能和目的:

主要算法:

接口说明:输入输出参数描述。

修改说明:

5.功能性注释嵌入在源程序体中,描述某一功能段做了什么,而不是针对每一语句。功能性注释应占程序总行数的1/5到1/3。

6.所有的数据结构应对每个结构成员加以注释说明。

7.程序中的空语句或含义目的不明确的语句都必须给出注释。

8.错误的注释不如没有注释。

六、逻辑规范

1.编译时的语法检查限制级别选项选择最严格的。

2.程序应该没有error,尽量减少程序中的Warning数。对于少数warning,应该弄清形成原因,以确保不会影响程序的运行。

数据库设计和编码规范

数据库设计和编码规范 Version

目录

简介 读者对象 此文档说明书供开发部全体成员阅读。 目的 一个合理的数据库结构设计是保证系统性能的基础。一个好的规范让新手容易进入状态且少犯错,保持团队支持顺畅,系统长久使用后不至于紊乱,让管理者易于在众多对象中,获取所需或理清问题。 同时,定义标准程序也需要团队合作,讨论出大家愿意遵循的规范。随着时间演进,还需要逐步校订与修改规范,让团队运行更为顺畅。 数据库命名规范 团队开发与管理信息系统讲究默契,而制定服务器、数据库对象、变量等命名规则是建立默契的基本。 命名规则是让所有的数据库用户,如数据库管理员、程序设计人员和程序开发人员,可以直观地辨识对象用途。而命名规则大都约定俗成,可以依照公司文化、团队习惯修改并落实。 规范总体要求 1.避免使用系统产品本身的惯例,让用户混淆自定义对象和系统对象或关键词。 例如,存储过程不要以sp_或xp_开头,因为SQL SERVER的系统存储过程以 sp_开头,扩展存储过程以xp_开头。 2.不要使用空白符号、运算符号、中文字、关键词来命名对象。 3.名称不宜过于简略,要让对象的用途直观易懂,但也不宜过长,造成使用不方 便。 4.不用为数据表内字段名称加上数据类型的缩写。 5.名称中最好不要包括中划线。

6.禁止使用[拼音]+[英语]的方式来命名数据库对象或变量。 数据库对象命名规范 我们约定,数据库对象包括表、视图(查询)、存储过程(参数查询)、函数、约束。对象名字由前缀和实际名字组成,长度不超过30。避免中文和保留关键字,做到简洁又有意义。前缀就是要求每种对象有固定的开头字符串,而开头字符串宜短且字数统一。可以讨论一下对各种对象的命名规范,通过后严格按照要求实施。例如:

编码规范以开发手册范本

1.软件开发手册 1.1.围 本标准规定了基于公司信息系统构建平台进行业务应用系统开发的编程格式规,主要包括命名规、代码注释、性能、以及常用语句的书写要求和约束等。统一规的格式有利于项目的交付和后续维护。 1.2.引言 1.1.1.简介 所有的程序开发手册都包含了各种规则。一些习惯自由程序的人(例如 Java 程序员)可能对这些规则很不适应,但是在多个开发人员共同协作的情况下,这些规则是必需的。这不仅仅是为了开发效率,而且也为了测试和后期维护。 良好的编码习惯有助于标准化程序的结构和编码风格,使源代码对于自己和别人都易读和易懂。在开发周期中越早使用恰当的编码规定,将会最大程度的提高项目的生产率。良好的编码习惯除了代码格式,详细的注释外,还应该包括使用有助于提高程序效率的编码方式。 规的开发有助于提高源码的可读性,可维护性,对于提高项目的整体效率更是不可缺少的(尤其是团队开发)。 1.1. 2.目的 本文是一套面向Java programmer 和Java developer进行开发所应遵循的开发规。按照此规来开发Java程序可带来以下益处: ●代码的编写保持一致性, ●提高代码的可读性和可维护性, ●在团队开发一个项目的情况下,程序员之间可代码共享, ●易于代码的回顾。 1.3.源程序 1.3.1.源程序命名 Java源程序的名字应该是这种形式:ClassOrInterfaceName.java。ClassOrInterfaceName 应该是在Java源程序中定义的 class或者interface的名字(关于classes和interface的命

名规请参考3.2)。源程序的文件名后缀通常为.java。 1.3. 2.供发布的文件 如果文件编译后,需要用打包的形式发布,那么这个包的名字应该是有代表性的(例如应该是这个模块或者这个文件所在单元的名字)。通常包的扩展名有 *.jar(推荐使用)或者 *.zip、*.ear、*.war等。 1.3.3.源文件的组织 一个Java源文件应该包含如下的元素,并按照以下顺序书写: 1)版本信息和声明 2)包的声明 3)引用声明 4)类或者接口的声明 以上元素之间以至少一个空行来分隔。 1.3.3.1.版本信息和声明 每一个源程序应该以一个包含版本信息和声明的块为开始。 例如: /** * application name: sample1 * application describing: this class handels the request of the client * copyright: Copyright ? 2002 金质工程所有 * company: neusoft * time: 2002.02.25 * * author Brunce * version ver 3.1 */

项目编码规范

项目代码编程规范 1.应用范围 本规范应用于采用J2EE规范的项目中,所有项目中的JAVA代码(含JSP,SERVLET,JAVABEAN,EJB)JS代码、HTML代码及数据库设计均应遵守这个规范。同时,也可作为其它项目的参考。 2.设计类和方法 2.1. 创建具有很强内聚力的类 方法的重要性往往比类的重要性更容易理解,方法是指执行一个独立逻辑的一段代码。类常被错误的视为是一个仅仅用于存放方法的容器。有些开发人员甚至把这种思路作了进一步的发挥,将他们的所有方法放入单个类之中。 之所以不能正确的认识类的功能,原因之一是类的实现实际上并不影响程序的执行。当一个工程被编译时,如果所有方法都放在单个类中或者放在几十个类中,这没有任何关系。虽然类的数量对代码的执行并无太大的影响,但是当创建便于调试和维护的代码时,类的数量有时会带来很大的影响。 类应该用来将相关的方法组织在一起。 当类包含一组紧密关联的方法时,该类可以说具有强大的内聚力。当类包含许多互不相关的方法时,该类便具有较弱的内聚力。应该努力创建内聚力比较强的类。 大多数工程都包含许多并不十分适合与其他方法组合在一起的方法。在这种情况下,可以为这些不合群的方法创建一个综合性收容类。 创建类时,应知道“模块化”这个术语的含义是什么。类的基本目的是创建相当独立的程序单元。 2.2. 创建松散连接和高度专用的方法 2.2.1.使所有方法都执行专门的任务 每个方法都应执行一项特定的任务,它应出色的完成这项任务。应避免创建执行许多不同任务的方法。 创建专用方法有许多好处。首先调试将变得更加容易。 2.2.2.尽量使方法成为自成一体的独立方法 当一个方法依赖于其他方法的调用时,称为与其他方法紧密连接的方法。紧密连接的方法

C语言注释规范

C语言注释规范 1.注释原则 同一软件项目开发中,尽量保持代码注释规范和统一。 注释方便了代码的阅读和维护。 边写代码边注释,修改代码时要相应修改注释,保证注释和代码的一致性。 注释要简洁明确,不要出现形容词。 对于写的好的注释,我们将是第一个受益者。 大型软件开发中,通过别人的注释可以快速知道他人所写函数的功能,返回值,参数的使用。 2.文件头部的注释 示例: / * Program Assignment : 该文件的作用 * Author: 作者 * Date: 2013/8/6 14:34 * Description: 该文件的描述 *****/ /* * Source code in : 源代码的路径 * Function List: * initLinear 初始化线性表 * destoryLinear 释放线性表申请的空间 * isLinearEmpty 判断线性表是否为空 * isLinearFull 判断线性表是否为满 * getLinearElementValue 取得下标为index的元素的值 */ 注意:这个函数列表可以快速查询到我们想要了解的函数。 3.结构体,全局变量等的注释 示例: typedef POLYNOMIAL USER_TYPE; /* 新的数据类型的描述*/ int a; /* 全局变量的作用*/ /* 说明结构体的功能*/ typedef struct LINEAR { USER_TYPE *data; /* 每个成员的意义(作用) */ int maxRoom; /* 每个成员的意义(作用) */

int elementCount; /* 每个成员的意义(作用) */ }LINEAR; 4.函数的注释 在逻辑性较强的的地方加入注释,以便其他人的理解,在一定的程度上排除bug。 示例: /* * Function Name: getLinearElementIndex * Purpose: 取得元素的index值 * Params : * @LINEAR linear 线性表实例 * @USER_TYPE var 类型为USER_TYPE的实例 * @int (*)() cmp 提供接口,让用户定义具体比较函数 * Return: int 返回元素的index值 * Limitation: 如果返回-1,则代表不存在var的元素 */ int getLinearElementIndex(LINEAR linear, USER_TYPE var, int (*cmp)()) { /* * 如果逻辑太过复杂,这里写明该算法的过程和思路。 */ boolean found = FALSE; int i; for(i = 0; i < && !found; i++) if(cmp[i], var) == 0) found = TRUE; if(i >= i = NOT_FOUND; return i; }

软件项目代码编码规范

变更履历

目录 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库中设置用户,并为不同用户分配不同的,适合工作的最小

项目开发及编码规范

项目开发规范文档修订历史记录

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) 成员方法尽量私有化。

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空格宽度)。示例:

java项目团队开发规范

项目团队开发规范

修订历史记录

目录 1引言 (6) 1.1 编写目的 (6) 1.2 预期读者 (6) 1.3 编写背景 (6) 2概述 (7) 2.1 目标 (7) 2.2 修改及完善 (7) 3详细规范 (7) 3.1 使用的工具 (7) 3.2 框架设计 (7) 3.3 包目录 (8) 3.4 编码规范 (10) 3.4.1 目的 (10) 3.4.2 依据 (10) 3.4.3 具体规范 (10) 3.4.3.1 编码风格 (10) 3.4.3.1.1 缩进 (10) 3.4.3.1.2 空格 (11) 3.4.3.1.3 对齐 (12) 3.4.3.1.4 空行 (12)

3.4.3.1.5 代码长度 (13) 3.4.3.1.6 行数 (13) 3.4.3.1.7 注释 (14) 3.4.3.2 代码效率 (17) 3.4.3.2.1 综述 (17) 3.4.3.2.2 具体实现 (17) 3.4.3.3 异常处理 (17) 3.4.3.3.1 处理CHECK 异常与UNCHECK异常 (17) 3.4.3.4 程序调试 (17) 3.4.4 日常交流 (18) 3.4.4.1 互相促进 (18)

1引言 1.1 编写目的 本文档作为项目团队开发规范的说明书,描述了项目开发过程中的使用的工具,框架,代码编写规范及注意问题,作为项目团队建设,开发及测试工作的依据。 1.2 预期读者 本文档的预期读者包括以下几类: ?项目组长 ?项目组全体成员 1.3 编写背景 根据公司现有的开发状况,决定组件稳定的项目开发团队,制定全体团队成员共识的开发规范,有助于提高项目开发的效率、项目团队整体水平的提升。

软件设计编码规范

质量管理体系过程文件 软件设计编码过程 文件版本信息:

目录 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语言编程规范

编码规范 1. 头文件编码规范 (2) 2. 函数编写规范 (2) 3. 标识符命名与定义 (2) 3.1通用命名规则 (2) 3.2 变量命名规则 (3) 3.3函数命名规则 (3) 3.4 宏的命名规则 (3) 4. 变量 (3) 5. 宏、常量 (4) 6. 质量保证 (4) 7. 程序效率 (5) 8. 注释 (5) 9. 排版与格式 (6) 10. 表达式 (7) 11. 代码编辑、编译 (7) 12. 安全性 (7) 13. 可读性 (7) 14. 可测性 (7) 15. 单元测试 (8) 16. 可移植性 (8)

1. 头文件编码规范 1. 禁止头文件循环依赖。 2. .c/.h文件不要包含用不到的头文件。 3. 禁止在头文件中定义变量。 4. 同一产品统一包含头文件排列方式。(如功能块排序、文件名升序、稳定度排序。) 5. 只能通过包含头文件的方式使用其他.c提供的接口,禁止在.c中通过extern的方式使用外部函数接口、变量。 2. 函数编写规范 1. 一个函数仅完成一件功能。 2. 重复代码应该尽可能提炼成函数。 3.为简单功能编写函数 4.函数的返回值要清楚、明了,让使用者不容易忽视错误情况。 5. 避免函数过长,新增函数不超过100行(非空非注释行)。 6. 避免函数的代码块嵌套过深,新增函数的代码块嵌套不超过4层。 7. 可重入函数应避免使用全局变量和禁止使用static变量。 8. 设计高扇入,合理扇出(小于7)的函数。 9. 废弃代码(没有被调用的函数和变量)要及时注释(有助于更好理解程序)。 10. 对所调用函数的错误返回码要仔细、全面地处理。 11. 函数不变参数使用const。 12. 函数应避免使用全局变量、静态局部变量和I/O操作,不可避免的地方应集中使用。 13. 函数的参数个数不超过5个。 14. 减少或禁止函数本身或函数间的递归调用 3. 标识符命名与定义 3.1通用命名规则 1. 标识符的命名要清晰、明了,有明确含义,同时使用完整的单词或大家基本可以理解的缩写,避免使人产生误解。 2. 除了常见的通用缩写以外,不使用单词缩写,不得使用汉语拼音。 示例: argument 可缩写为arg buffer 可缩写为buff clock 可缩写为clk command 可缩写为cmd compare 可缩写为cmp configuration 可缩写为cfg device 可缩写为dev error 可缩写为err hexadecimal 可缩写为hex increment 可缩写为inc initialize 可缩写为init maximum 可缩写为max message 可缩写为msg minimum 可缩写为min parameter 可缩写为para

代码开发规范

代码开发规范 1 前言 1.1 为什么需要开发规范 编码规范对于程序员而言尤为重要,有以下几个原因: * 一个软件的生命周期中,80%的花费在于维护 * 几乎没有任何一个软件,在其整个生命周期中,均由最初的开发人员来维护* 编码规范可以改善软件的可读性,可以让程序员尽快而彻底地理解新的代码 * 如果你将源码作为产品发布,就需要确任它是否被很好的打包并且清晰无误,一如你已构建的其它任何产品 1.2 开发规范的作用 * 减少维护花费 * 提高可读性 * 加快工作交接 * 减少名字增生 * 降低缺陷引入的机会

2 命名规范 2.1 常量命名规范 2.1.1 类型 常量命名规范 2.1.2 说明 常量用于保存需要常驻内存中并且经常使用变化不多的数据,定义常量的名称的时候需要遵循望文知意的原则; 2.1.3 规则 1.全部为大写字母; 2.中间以“_”连接; 3.望文知意原则; 2.1.4 备注 代码中涉及到直接使用某个字符串或者其他基本类型的值时,建议定义成常量,避免多处直接使用同样的值作为参数。 2.1.5 举例 ?如:定义一个常量表示最小屏幕宽度的常量,则可以定义一个int类型的常 量,该常量可以命名为:“MIN_SCREEN_WIDTH“; ?其他举例: ?例如:static final int MIN_SCREEN_WIDTH = 4;( √) ?例如:static final int min_screen_width = 4;(×) ?例如:static final int minScreenWidth = 4; (×) ?例如:static final int WIDTH = 4;(×)

项目编码规范编写指南

项目编码规范 1 命名规范 1).包名采用域后缀倒置的加上自定义的包名,采用小写字母。 在部门内部应该规划好包名的范围,防止产生冲突。部门内部产品使用部门的名称加上模块名称。产品线的产品使用产品的名称加上模块的名称。 格式: com.huawei.产品名.模块名称 com.huawei.部门名称. 项目名称 示例: Relay模块包名 com.huawei.msg.relay 通用日志模块包名 com.huawei.msg.log 2). 类名和接口使用类意义完整的英文描述,每个英文单词的首字母使用大写、其余字母使用小写的大小写混合法。 示例: OrderInformation, CustomerList, LogManager, LogConfig 3). 方法名使用类意义完整的英文描述:第一个单词的字母使用小写、剩余单词首字母大写其余字母小写的大小写混合法。 示例: private void calculateRate(); public void addNewOrder(); 4). 方法中,存取属性的方法采用setter 和 getter方法,动作方法采用动词和动宾结构。格式: get + 非布尔属性名() is + 布尔属性名() set + 属性名() 动词() 动词 + 宾语() 示例: public String getType(); public boolean isFinished(); public void setVisible(boolean); public void show();

public void addKeyListener(Listener); 5).属性名使用意义完整的英文描述:第一个单词的字母使用小写、剩余单词首字母大写其余字母小写的大小写混合法。属性名不能与方法名相同。 示例: private customerName; private orderNumber; private smpSession; 6). 常量名使用全大写的英文描述,英文单词之间用下划线分隔开,并且使用 final static 修饰。 示例: public final static int MAX_VALUE = 1000; public final static String DEFAULT_START_DATE = "2001-12-08"; 7). 属性名可以和公有方法参数相同,不能和局部变量相同,引用非静态成员变量时使用 this 引用,引用静态成员变量时使用类名引用。 示例: public class Person { private String name; private static List properties; public void setName (String name) { https://www.360docs.net/doc/8d9120185.html, = name; } public void setProperties (List properties) { Person.properties = properties; } } 8).如果函数名超过15 个字母,可采用以去掉元音字母的方法或者以行业内约定俗成的缩写方式缩写函数名。 示例: getCustomerInformation() 改为 getCustomerInfo() 2 程序注释规范 1)、基本注释(必须加)

C语言编写规范之注释

1、头文件包含Includes 2、私有类型定义 Private typedef 3、私有定义Private define 4、私有宏定义 Private macro 5、私有变量 Private variables 6、私有函数原型Private function prototypes 7、私有函数Private functions 8、私有函数前注释 /****************************************************************************** * * Function Name : FSMC_NOR_Init * Description : Configures the FSMC and GPIOs to interface with the NOR memory. * This function must be called before any write/read operation * on the NOR. * Input : None * Output : None * Return : None ******************************************************************************* / 9、程序块采用缩进风格编写,缩进空格为4。 10、相对独立的程序块之间、变量说明之后必须加空行; 11、较长的字符(>80字符)要分成多行书写,长表达式要在低优先级操作符划分新行,操作符放在新行之首,新行要恰当缩进,保持排版整齐; 12、循环、判断等语句中若有较长的表达式或语句,则要进行适应的划分,长表达式要在低优先级操作符处划分新行,操作符放在新行之首; 13、若函数或过程中的参数较长,则要进行适当的划分。 14、不允许把多个短语句写在一行中,即一行只写一条语句。 15、if、for、do、while、case、switch、default等语句自占一行,且if、for、 do、while等语句的执行语句部分无论多少都要加括号{}。 16、对齐只使用空格键,不使用TAB键; 17、 函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格,case 语句下的情况处理语句也要遵从语句缩进要求 18、 程序块的分界符(如C/C++语言的大括号‘{’和‘}’)应各独占一行并且位于同一 列,同时与引用它们的语句左对齐。在函数体的开始、类的定义、结构的定义、枚举的定义以 及if、for、do、while、switch、case语句中的程序都要采用如上的缩进方式。 19、 在两个以上的关键字、变量、常量进行对等操作时,它们之间的操作符之前、之后或

华为软件开发规范

软件开发规范 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));

软件设计编码规范标准[详]

质量管理体系过程文件软件设计编码过程

文件版本信息:

目录 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)

开发管理之代码编码规范

1.程序版式 1.1.对齐 1.1.1.程序块要采用缩进风格编写,缩进的空格数为4个。使用VC提供的Tab 键对齐。 1.1. 2.“{”和“}”应独占一行并且位于同一列,同时引用他们的语句对齐1.1. 3.{}之内的代码块在“{”右边数格外左对齐 例: 正确错误

1.2.空行 1.2.1.每个声明之后,每个函数定义之后要加空行 1.2.2.在一个函数体内,逻辑上密切相关的语句之间不加空行,其它地方应加空 行分隔 1.2.3.变量声明和代码之间加空行 1.2.4.函数返回语句用空行 例:

1.3.代码行 1.3.1.一行代码只做一件事情,如只定义一个变量,或只写一条语句。 1.3. 2.if、for、do、while、case、switch、default等语句自占一行,且if、for、 do、while等语句的执行语句部分无论多少都要加括号{} 例: 示例:风格良好的代码行示例:风格不良的代码行 1.4.空格 1.4.1.关键字之后要留空格:const, virtual, inline, if, while, for 1.4. 2.函数名之后不要留空格 1.4.3.“(”向后紧跟“,”,“、”,“.”,“;”,“)”向前紧跟 1.4.4.“,”后要留空格,“”;之后如果不是一行的结束,后面要留空格 1.4.5.赋值操作符,比较,算术,逻辑,第二元操作符前后加空格 1.4.6.一元操作符!、~、++、--、—等前后不加空格 1.4.7.像[]、“.”、—>等前后不加空格

例: 1.5.长行拆分 1.5.1.代码行最长度宜控制在70到80个字符以内,代码行不宜过长 1.5. 2.长表达式拆分,应将操作符放在新行之首,拆分出新行要适当缩进,使排 版整齐 例:

软件编码规范.doc

软件编码规范 中国人民银行清算总中心 支付系统开发中心

注:变化状态: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)

HTML/CSS代码开发规范文档

HTML/CSS代码开发规范文档

目录 1、前言 (4) 2、HTML编码规范 (4) 2-1HTML标记的关闭规范 (4) 2-2HTML文件头基本标记 (4) 2-2HTML正文代码标记元素 (5) 2-3HTML标记的缩进规范 (6) 3、HTML文件引入CSS样式代码和Javascript代码规范 (6) 3-1引入css样式代码规范 (6) 3-2引入Javascript代码规范 (7) 4、HTML注释标签 (8) 5、CSS编码规范 (8) 5-1 CSS编码要求 (8) 5-2 CSS样式表规范 (8) 5-3 CSS命名规范 (9) 5-4样式文件命名 (10) 5-5样式文件布局 (11) 6、CSS常规书写规范及方法 (11) 6-1文件调用方法: (11) 6-2 CSS结构化书写 (11) 6.2.1派生选择器: (11) 6.2.2辅助图片用背影图处理: (12) 6.2.3结构与样式分离: (12) 6.2.4文档的结构化书写 (12) 6-3 HACK CSS书写规范 (13) 6.3.1 IE6、IE7、Firefox之间的兼容写法 (13) 6.3.2屏蔽IE浏览器 (14) 6.3.3清除浮动 (14) 6.3.4鼠标手势 (15) 7、CSS性代码缩写 (15) 7.1不同类有相同属性及属性值的缩写 (15) 7.2同一属性的缩写 (16) 7.3内外侧边框的缩写 (16) 7.4颜色值的缩写 (18) 8、CSS注释书规范 (18) 8.1行间注释 (18) 8.2整段注释 (18)

1、前言 本编程规范适用于需要编写HTML/CSS代码的网页程序开发人员。本规范并不是一个一成不变的必须严格遵守的条文,特殊情况下要灵活运用,做一定的变通。 2、HTML编码规范 HTML是一种标记语言, HTML没有任何真正的编程语言中的循环或是流程控制语句。然而,HTML代码的格式和风格是非常重要的,因为要经常对HTML代码进行维护和修改,因此HTML代码必须有很清晰的逻辑结构和布局,增强可读性,而使其易懂和易于维护。HTML代码本身是不区分大小写的,但是为了更好的统一代码布局,项目中HTML文件标记都以小写为主。 2-1HTML标记的关闭规范 HTML文档的正文都应在标记中间,而标记则应包含在和标记之间。如: 正文 不同类的标记不能交叉编码: eg: 内容 正确编码应为:内容 开始和关闭标记放在一行的标记有: eg: 各种标题标记,如

2-2HTML文件头基本标记 ① ②

相关文档
最新文档