当前位置:文档之家› 腾讯PHP开发规范

腾讯PHP开发规范

腾讯PHP开发规范
腾讯PHP开发规范

海豹平台开发规范v1.0

腾讯科技(深圳)有限公司

*版本信息&保密等级

版本更改日期更改要点说明编制审核批准V1.0 2013/12/24 新建wilsonwsong

V1.1 2013/12/26 修订rusherding

文档保密等级:□机密■内部□公开

目录

海豹平台开发规范V1.0 (1)

1 引言 (5)

1.1定义及缩略语 (5)

1.2参考文档 (5)

1.3目的 (5)

1.4适用范围 (5)

1.5标准化作用 (5)

2 目录结构规范 (6)

2.1框架路径 (6)

2.2应用目录结构 (6)

2.2.1 配置config (7)

2.2.2 控制器controllers (7)

2.2.3 模型models (7)

2.2.4 视图views (8)

2.2.5 国际化messages (8)

2.2.6 组件components (8)

2.2.7 命令commands (8)

2.2.8 临时目录runtime (8)

2.3路径别名 (8)

2.3.1 类型导入 (8)

3 PHP编码规范 (9)

3.1标签 (9)

3.2编码 (9)

3.3注释 (9)

3.3.1 文件注释 (9)

3.3.2 类注释 (10)

3.3.3 方法注释 (10)

3.3.4 属性注释 (11)

3.3.5 其它 (11)

3.4命名规则 (11)

3.4.1 文件 (11)

3.4.2 类 (12)

3.4.3 函数/方法 (12)

3.4.4 变量名 (12)

3.4.5 常量名 (12)

3.5书写规则 (13)

3.5.1 文件 (13)

3.5.2 行 (13)

3.5.3 缩进 (13)

3.5.4 控制结构 (13)

3.5.5 运算符 (16)

3.5.6 引号 (16)

3.5.7 关键词 (17)

3.5.8 函数 (17)

3.5.9 类 (17)

3.5.10 属性 (18)

3.5.11 方法 (18)

4 数据库命名规范 (20)

4.1命名规范 (20)

4.2实体命名 (20)

4.2.1 前缀命名 (20)

4.2.2 后缀命名 (21)

4.3字段命名 (21)

4.3.1 后缀命名 (22)

4.4字段类型 (22)

4.4.1 数值类型 (22)

4.4.2 字符类型 (23)

4.4.3 时间类型 (23)

4.4.4 ENUM&SET (23)

4.4.5 LOB 类型 (23)

4.5表结构设计 (24)

4.5.1 适度冗余 (24)

4.5.2 尽量使用NOT NULL (24)

4.5.3 索引 (24)

5 附件 (24)

5.1附录一:MYSQL保留字 (24)

1引言

1.1 定义及缩略语

缩略词说明

海豹平台运维中心提供的研发平台,提供框架、公共基础组件、公共业务组件加速业

务的日常研发工作

1.2参考文档

海豹平台WIKI:https://www.doczj.com/doc/0b6721181.html,/

1.3目的

本规范由编程原则组成,融合并提炼了开发人员长时间积累下来的成熟经验,意在帮助形成良好一致的编程风格。以达到事半功倍的效果,如果有需要本文档会不定期更新。

1.4适用范围

如无特殊说明,以下规则要求完全适用于基于海豹平台框架开发的应用,同时也可大部分适用于部门其他PHP项目。

1.5标准化作用

当一个软件项目尝试着遵守公共一致的标准时,可以使参与项目的开发人员更容易了解项目中的代码、弄清程序的状况。使新的参与者可以很快的适应环境,防止部分参与者出于节省时间的需要,自创一套风格并养成终生的习惯,导致其它人在阅读时浪费过多的时间和

精力。而且在一致的环境下,也可以减少编码出错的机会。

缺陷是由于每个人的标准不同,所以需要一段时间来适应和改变自己的编码风格,暂时性的降底了工作效率。从使项目长远健康的发展以及后期更高的团队工作效率来考虑暂时的工作效率降低是值得的,也是必须要经过的一个过程。标准不是项目成功的关键,但可以帮助我们在团队协作中有更高的效率并且更加顺利的完成既定的任务。

1)程序员可以了解任何代码,弄清程序的状况

2)新人可以很快的适应环境

3)防止新接触PHP的开发出于节省时间的需要,自创一套风格并养成终生的习惯

4)防止新接触PHP的开发一次次的犯同样的错误

5)在一致的环境下,可以减少犯错的机会

2目录结构规范

2.1框架路径

框架引用路径必须采用绝对路径,托管的开发、测试和正式环境必须为:

/data/php/framework

2.2应用目录结构

应用需要严格参考以下目录安排代码位置:

webroot/

index.php Web 应用入口脚本文件

index-test.php 功能测试使用的入口脚本文件

assets/ 包含公开的资源文件

css/ 包含 CSS 文件

images/ 包含图片文件

themes/ 包含应用主题

protected/ 包含受保护的应用文件

modc 命令行脚本

modc.bat Windows 下的命令行脚本

modc.php 命令行 PHP 脚本

commands/ 包含自定义的 'modc' 命令

components/ 包含可重用的用户组件

config/ 包含配置文件

controllers/ 包含控制器的类文件

SiteController.php 默认控制器的类文件

extensions/ 包含第三方扩展

messages/ 包含翻译过的消息(i8n相关)

models/ 包含模型的类文件

runtime/ 包含临时生成的文件

tests/ 包含测试脚本

views/ 包含控制器的视图和布局文件

layouts/ 包含布局视图文件

main.php 所有视图的默认布局

site/ 包含 'site' 控制器的视图文件 system/ 包含系统视图文件

2.2.1配置config

存放应用配置目录,具体参考WII人口K脚本

2.2.2控制器controllers

存放控制逻辑的类目录,具体参考WIKI控制器

2.2.3模型models

存放模型定义的类目录,具体参考WIKI模型

2.2.4视图views

存放视图文件的目录,具体目录参考WIKI视图

2.2.5国际化messages

存放国际化定义文件的目录

2.2.6组件components

存放组件的类目录,具体目录参考WIKI组件

2.2.7命令commands

存放Console命令的类目录,具体目录参考WIKI之Cli使用

2.2.8临时目录runtime

目录权限777,可用于存放临时生成的文件。

2.3路径别名

1)system: 表示平台框架目录,默认为/data/php/framework。

2)webroot: 表示入口脚本文件所在的目录,一般为应用的根目录。

3)application: 表示应用的基础目录,一般为webroot/protected。

4)ext: 表示包含了所有第三方扩展的目录,一般为webroot/protected/extensions。

通过使用Mod::getPathOfAlias(), 别名可以被翻译为其相应的路径。例如:

https://www.doczj.com/doc/0b6721181.html,ontroll er 会被翻译为/data/php/framework/core/web/CControll er。

2.3.1类型导入

使用别名可以很方便的导入类的定义,如导入webroot/protected/components/Controller Mod::import('https://www.doczj.com/doc/0b6721181.html,ponents.Controller');

同样可以使用目录导入

Mod::import('https://www.doczj.com/doc/0b6721181.html,ponents.*');

3PHP编码规范

3.1标签

PHP程序可以使用来界定PHP 代码,在HTML页面中嵌入纯变量时,可以使用这样的形式,不可使用其他的标签变种。

纯PHP类文件,文件最后一个?>省略。

3.2编码

PHP代码必须只使用不带BOM的UTF-8。

3.3注释

1)单行注释:在语句结尾用双反斜杠”// “注释

2)多行注释:多行注视以”/*”或“/**”符号开头,以”*/ “符号作为注释结束符。

需要生成文档的注释必须是以“/**”开头,以“*/”结尾。主流的IDE开发工具(如Eclipse,Zend)会用不同的颜色来区分下面的几种注释。

3.3.1文件注释

/**

*(简述,用在索引列表中)

*

* 详细的功能描述(可略)

*

* @copyright Copyright© 2013, 公司名或作者名

* @author ${AUTHOR}

* @version $Id: ${FILE_NAME}, v ${VERSION} ${TIME} ${AUTHOR} Exp $ *

*/

3.3.2类注释

/**

*(概要)

*

* 详细的功能描述

*

* @property 类型$prop 属性描述

*

* @author ${AUTHOR}

* @package https://www.doczj.com/doc/0b6721181.html,ponents(参见路径别名)

*

*/

3.3.3方法注释

/**

* 功能描述

*

* @param 类型$fields 描述

*

* @return 类型描述

*/

3.3.4属性注释

/**

* @var 类型$fields 描述

*/

3.3.5其它

1)适当的使用HTML标记语言来美化文档。不管是生成HTML格式还是CHM格式的

文档手册,文档工具都是先生成HTML文档页面,所以适当的使用
标签

可以美化文档,方便阅读。

2)public和private方法:一般情况下,private私有方法不会暴露给其他开发人员,

所以private方法的注释一般以“/*”开头,而public方法以“/**”开头。

3.4命名规则

Pascal命名法:所有单词第一个字母大写,其他字母小写。

Camel命名法(驼峰命名法) :除了第一个单词,所有单词第一个字母大写,其他字母小写。采用英文单词或其组合,便于记忆和阅读,切忌使用汉语拼音来命名。

3.4.1文件

1)类文件的名称和类名一致,如类HelloWorld,相应的文件名为HelloWorld.php

2)配置文件名小写,如config.php

3)嵌套php的view文件使用Camel命名法,第一个字母小写,其他单词的第一个字

母大写。如:addApp.php

3.4.2类

类命名采用Pascal命名方法,类名应该和文件名相匹配。

3.4.3函数/方法

通常方法一般为一个动作或行为动词,函数/方法的命名采用Camel命名方法

function run()

function runFast()

function getBackground()

尽量用有意义,描述性的词语来命名

用checkForErrors()代替errorCheck(),用dumpDataToFile()代替dataFile()。

有时前缀名是有用的:

is - 含义为问一个关于某样事物的问题。无论何时,当人们看到is就会知道这是一个问题。get - 含义为取得一个数值。

set - 含义为设定一个数值

例如:isHitRetryLimit

内部成员函数命名应该是以“_”开始:

function _isUserTicket ();

3.4.4变量名

1)用有意义的,描述性的词语来命名变量

2)别用缩写。用name, address, salary等代替 nam, addr, sal 全局变量以”g_”开头

3)别使用单个字母的变量象i, n, x 等. 使用 index, temp等,用于循环迭代的变量例

外: for ($i = 0; $i < count; $i++) { ... }

3.4.5常量名

量全部使用大写字母和下滑线组成,常量的名称中不允许出现小写字母,可使用分隔符作为下划线。

3.5书写规则

3.5.1文件

1)所有的PHP文件必须使用Unix LF(换行)作为行结束符。

2)所有PHP文件必须以一个空行结束。

3)纯PHP代码的文件关闭标签?>必须省略

3.5.2行

1)行长度不可有硬限制。

2)行实际长度不应超过80个字符;较长的行应当被拆分成多个不超过80个字符的后

续行。

3)空行可以用来改善可读性和区分相关的代码块。

4)一行不应多于一个语句。

3.5.3缩进

每个缩进的单位约定是4个空格的缩进,并且不可使用制表符作为缩进,需每个参与项目的开发人员在编辑器(Eclipse、EditPlus、Zend Studio等)中进行强制设定将TAB转化为4个空格,以防在编写代码时遗忘而造成格式上的不规范。

3.5.4控制结构

对于控制结构的样式规则概括如下:

1)控制结构关键词之后必须有一个空格

2)左括号之后不可有空格

3)右括号之前不可有空格

4)在右括号和左花括号之间必须有一个空格

5)代码主体必须有一次缩进

6)右花括号必须主体的下一行

每个结构的主体必须被括在花括号里。这结构看上去更标准化,并且当加新行的时候可以减少引入错误的可能性。

3.5.

4.1if,elseif, else

一个if结构看起来应该像下面这样。注意括号,空格,花括号的位置;并且else和elseif 和前一个主体的右花括号在同一行。

if ($expr1) {

// if body

} elseif ($expr2) {

// elseif body

} else {

// else body;

}

关键词elseif应该替代else if使用以保持所有的控制关键词像一个单词。

3.5.

4.2switch, case

一个switch结构看起来应该像下面这样。注意括号,空格和花括号。case语句必须从switch处缩进,并且break关键字(或其他中止关键字)必须和case主体缩进在同级。如果一个非空的case主体往下落空则必须有一个类似// no break的注释。

switch ($expr) {

case 0:

echo 'First case, with a break';

break;

case 1:

echo 'Second case, which falls through';

// no break

case 2:

case 3:

case 4:

echo 'Third case, return instead of break';

return;

default:

echo 'Default case';

break;

}

3.5.

4.3while, do while

一个while语句看起来应该像下面这样。注意括号,空格和花括号的位置。

while ($expr) {

// structure body

}

同样的,一个do while语句看起来应该像下面这样。注意括号,空格和花括号的位置。

do {

// structure body;

} while ($expr);

3.5.

4.4for

一个for语句看起来应该像下面这样。注意括号,空格和花括号的位置。

for ($i = 0; $i < 10; $i++) {

// for body

}

3.5.

4.5foreach

一个foreach语句看起来应该像下面这样。注意括号,空格和花括号的位置。

foreach ($iterabl e as $key => $value) {

// foreach body

}

3.5.

4.6try, catch

一个try catch语句看起来应该像下面这样。注意括号,空格和花括号的位置。

try {

// try body

} catch (FirstExceptionType $e) {

// catch body

} catch (OtherExceptionType $e) {

// catch body

}

3.5.5运算符

1)每个运算符与两边参与运算的值或表达式中间要有一个空格

3.5.6引号

在绝大多数可以使用单引号的场合,禁止使用双引号(性能考虑)。可以或必须使用单引号的情况包括但不限于下述:

1)字符串为固定值,不包含“\t”等特殊转义字符;

2)数组的固定下标,例如$array['key'];

3)表达式中不需要带入变量,例如$string = 'test';,而非$string = "test$var";

3.5.7关键词

1)PHP keywords 必须使用小写。

2)PHP常量true, false和null必须使用小写。

3.5.8函数

3.5.9类

1)类必须单独一个源文件,并且类名和文件名相同。

2)类的左花括号必须放到下一行,右花括号必须放在类主体的下一行。

3)类文件“?>”结束标记去掉

class Foo

{

[body]

}

4)一个类的extends和implements关键词必须和类名在同一行。

class ClassName extends ParentClass implements ArrayAccess, Countabl e

{

// constants, properties, methods

}

5)implements一个列表可以被拆分为多个有一次缩进的后续行。如果这么做,列表

的第一项必须要放在下一行,并且每行必须只有一个接口。

class ClassName extends ParentClass implements

ArrayAccess,

Countable,

Serializable

{

// constants, properties, methods

}

3.5.10属性

1)所有的属性必须声明可见性。

2)var关键词不可用来声明属性。

3)一个语句不可声明多个属性。

4)属性名称可以使用单个下划线作为前缀来表明保护或私有的可见性。

class ClassName

{

public $foo = null;

private $_bar = 1;

}

3.5.11方法

1)所有的方法必须声明可见性。

2)方法名不应只使用单个下划线来表明是保护或私有的可见性。

3)方法名在声明之后不可跟随一个空格。左花括号必须放在下面自成一行,并且右花

括号必须放在方法主体的下面自成一行。左括号后面不可有空格,右括号前面不可

有空格。

4)一个方法定义看来应该像下面这样。注意括号,逗号,空格和花括号:

5)在参数列表中,逗号之前不可有空格,逗号之后必须要有一个空格。

6)方法中有默认值的参数必须放在参数列表的最后面。

class ClassName

{

public function fooBarBaz($arg1, &$arg2, $arg3 = [])

{

// method body

}

}

7)参数列表可以被分为多个有一次缩进的多个后续行。如果这么做,列表的第一项必

须放在下一行,并且每行必须只放一个参数。

8)当参数列表被分为多行,右括号和左花括号必须夹带一个空格放在一起自成一行。

class ClassName

{

public function aVeryLongMethodName(

ClassTypeHint $arg1,

&$arg2,

array $arg3 = []

) {

// method body

}

}

9)如果存在,abstract和final声明必须放在可见性声明前面。

10)如果存在,static声明必须跟着可见性声明。

4数据库命名规范

4.1命名规范

数据库的所有表(Table)、视图(View)、索引(Index)、触发器(Trigger)、函数(Function)和存储过程(Store Procedure)均应遵循以下命名规范。

1)命名统一用大写

2)命名只能由小写字母和数字构成,并且只能是以小写字母打头

3)命名应采用能够准确反映其中文含义的英文单词或英文单词缩写构成,避免出现英

文单词和汉语拼音混用的局面

4)命名长度不可以超过25个字符(表名尽量保持在20个字符的长度,然后再其上建

立索引、主键、触发器等等的时候,便于加扩展信息)

5)名称的各部分之间以"_"(下划线)连接

6)字段如有相同定义,应该用相同命名

7)命名应避免用关键字,参见附录一《关键字列表》

4.2实体命名

实体(包括库表、视图、函数和索引等)命名结构如下:

prefix[_modul e]_body[_suffix]

1)为前缀名,表示数据库对象的类型

2)为模块名,按应用模块进行分类,为可选项

3)为主体名,应该能够清楚地说明对象的含义

4)是后缀名,提供特效的含义,比如在该对象需分表存放时使用,如按月分开

存放的表,为可选项。

4.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));

软件开发代码规范C版

软件开发代码规范(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命名法则,其中第一个单词可以使用变量类型的缩写来说明以示区别。 例:

软件开发代码规范(Java)

软件开发代码规范(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;

软件开发代码规范(C#版)

软件开发代码规范(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/0b6721181.html,erName; } } } 2.即使对于可能仅出现在几个代码行中的生存期很短的变量,仍然使用意义描述性的名称。仅对于短循环索引使用单字母变量名,如i 或j 3.在变量名中使用互补对,如Min/Max、Begin/End 和Open/Close。 4.当一个方法内部变量繁多的时候,可以使用Camel命名法则,其中第一个单词可以使用变量类型的缩写来说明以示区别。 例:

软件开发代码规范(C#版)

软件开发代码规(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、第三章编写规 (8) 3.1、第一节格式规 (8) 3.2、第二节编程规 (9) 3.2.1 、程序结构要求 (9) 3.2.2 、可读性要求 (9) 3.2.3 、结构化要求 (10) 3.2.4 、正确性与容错性要求 (10) 3.2.5 、可重用性要求 (10) 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/0b6721181.html,erName; } } } 2.即使对于可能仅出现在几个代码行中的生存期很短的变量,仍然使用意义描述性的名称。仅对于短循环索引使用单字母变量名,如 i 或 j 3.在变量名中使用互补对,如 Min/Max、Begin/End 和 Open/Close。 4.当一个方法部变量繁多的时候,可以使用Camel命名法则,其中第一个单词可以使用变量类型的缩写来说明以示区别。 例:

软件开发编码规范86601

"\n"。 HTML Tab。 作

遵循下面列出的准则有利于编写更加安全的代码。但是总体来说,这些准则不能对安全性做出任何保证。遵循这些准则可能好的实践,但是即使遵循了这些准则,写出的代码仍然可能是不安全的。风险永远存在,不管在编写代码时是如何的警觉。 这些准则的目标,不是为了保证代码的安全性,而是为了消除若干特定类型攻击带来的风险。遵循这些准则,某些特定类型的攻击将无法实现;但是其它类型的攻击仍然可能成功。因此遵循这些准则仅仅是安全的第一步。当书写可能和非守信链接或混用的代码时,应当仔细的考虑如下准则: ?静态字段 ?缩小作用域 ?公共方法和字段 ?保护包 ?尽可能使对象不可变(immutable) ?序列化 ?清除敏感信息 1) 静态字段 避免使用非final的公共静态变量,应尽可能地避免使用非final公共静态变量,因为无法判断代码有无权限改变这些静态变量的值。 一般地,应谨慎使用可变的静态状态,因为这可能导致设想中应该相互独立的子系统之间发生不曾预期的交互。 2) 缩小作用域 作为一个惯例,尽可能缩小成员方法和成员变量的作用域。检查包访问权限成员(package-private)能否改成私有成员(private),保护访问成员(protected)可否改成包访问权限成员(package-private)/私有成员(private)等等。 3) 公共方法/字段 公共变量应当避免使用,访问这些变量时应当通过getter/setter法。在这种方式下,必要时可以增加集中的安全检查。 任何能够访问或修改任何敏感内部状态的公共方法,务必包含安全检查。 参考如下代码段,该代码段中不可信任代码可能修改TimeZone的值: private static TimeZone defaultZone = null; public static synchronized void setDefault(TimeZone zone) { defaultZone = zone;

软件开发代码规范(Java)

软件开发代码规范(C)(仅通普信息技术股份有限公司供内部使用) 黑龙江通普信息技术股份有限公司 版本历史

目录 第一章代码开发规范及其指南 (1) 1.1 目的 (1) 1.2 程序内命名规范 (1)

1.3 文件命名规范 (2) 1.4 J AVA文件样式 (2) 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; }

1.3文件命名规范 文件名由英文单词组成,每个单词的首字母大写,不要超过4个单词, 如ShipOrder.jsp Java文件的文件名要与程序中的public类名相同。 Servet文件要以Servlet做为结尾,如AddCompanyServlet.java 业务处理组 件Java Bean要以Bean为结尾,如ProcessBean.java 1.4 Java文件样式 所有的Java(*java)文件都必须遵守如下的样式规则 头部 版权信息 版权信息必须在java文件的开头,比如: 其他不需要出现在javadoc的信息也可以包含在这里。 Package/lmports package行要在import行之前,import中标准的包名要在本地的包名之前,而且按照字母顺序排列。如果import行中包含了同一个包中的不同子目 录,则应该用*来处理。 package hotlava .n et.stats; import java.io.*; import java.util.Observable; import hotlava.util.Applicati on;

软件开发编码规范

精心整理软件安全开发编码规范 1. 代码编写 1) 开发人员应保证工程中不存在无用的资源(如代码、图片文件等)。 2) 3) 4) ● ● ● ● ● 5) 6) 7) 8) 9) 13) 在进行log的获取时开发人员应尽量使用isXXXEnabled。 14) log的生成环境上尽量避免输出文件名和行号。 15) 产品中不要包含后门代码,隔离系统中的后门代码,确保其不能出现在产品中。作为一种 特殊的调试代码,后门访问代码是为了使开发者和测试工程师访问一部分终端用户不能访问的程序代码。但是,如果后门代码被留到产品中,对攻击者来说,它就是一条不需要通过正常安全手段来攻陷系统的通路。

2. JAVA安全 遵循下面列出的准则有利于编写更加安全的代码。但是总体来说,这些准则不能对安全性做出任何保证。遵循这些准则可能好的实践,但是即使遵循了这些准则,写出的代码仍然可能是不安全的。风险永远存在,不管在编写代码时是如何的警觉。 这些准则的目标,不是为了保证代码的安全性,而是为了消除若干特定类型攻击带来的风险。遵循这些准则,某些特定类型的攻击将无法实现;但是其它类型的攻击仍然可能成功。因此遵循这些准则仅仅是安全的第一步。当书写可能和非守信链接或混用的代码时,应当仔细的考虑如下准则: ? ? ? ? ? ? ? 1) 2) ( 3) 以增加集中的安全检查。 任何能够访问或修改任何敏感内部状态的公共方法,务必包含安全检查。 参考如下代码段,该代码段中不可信任代码可能修改TimeZone的值: privatestaticTimeZonedefaultZone=null; publicstaticsynchronizedvoidsetDefault(TimeZonezone) { defaultZone=zone;

软件开发代码规范(C语言)

软件开发代码规范(仅供内部使用) 拟制: 审核: 核准: 签发: 文档版本:V0.11日期: 日期: 日期: 日期: 2011-5-11

目录 第一章原则 (4) 第二章排版 (5) 2.1 空行 (5) 2.2 代码行 (6) 2.3 代码行内的空格 (6) 2.4 对齐缩进 (7) 2.5 长行拆分 (8) 第三章注释 (10) 3.1 通用规则 (10) 3.2 文件注释 (10) 3.3 函数注释 (11) 3.4 数据注释 (12) 3.5 代码注释 (12) 第四章命名 (15) 4.1 通用命名规则 (15) 4.2 文件命名 (15) 4.3 类型命名 (15) 4.4 变量命名 (16) 4.5 常量命名 (17) 4.6 函数命名 (17) 4.7 枚举命名 (17) 4.8 宏命名 (18)

第五章杂项 (19)

文件修改记录

第一章原则 本文档的目的是提供一个公共的编码规范。 这个规范详细阐述在编码时要怎样写、不要怎样写,旨在提高代码的可读性、可维护性, 使代码易于管理,使所有人可以集中精力去实现内容,而非处理各种复杂的表现形式。 使代码易于管理的方法之一是增强代码一致性,让别人可以读懂你的代码是很重要的,保持统一编程风格意味着可以轻松根据模式匹配”规则推断各种符号的含义。创建通用的、 必需的习惯用语和模式可以使代码更加容易理解。虽然在某些情况下改变一些编程风格可能 会是好的选择,但我们还是应该遵循一致性原则,尽量不这样去做。 关键在于保持一致。

第二章排版 2.1 空行 【规则2-1-1】在每个函数、结构体、枚举定义结束之后都要加空行。 【规则2-1-2】在一个函数体内,逻辑密切相关的语句之间不加空行,其它地方应加空行分隔。 【规则2-1-3】相对独立的程序块之间、变量说明之后必须加空行。 不规范代码规范代码

软件项目开发和管理规范V1.0

软件项目开发和管理规范 版本V1.0 2010年1月15日

目录 1.软件项目管理概述 (3) 2.软件项目管理过程 (3) 3.软件项目管理内容 (5) 3.1.需求阶段管理 (5) 3.2.设计阶段管理 (7) 3.3.开发阶段管理 (7) 3.4.测试阶段管理 (8) 3.5.维护阶段管理 (8) 3.6.工具管理 (8) 3.7.软件项目估算与进度管理 (9) 3.7.1.软件项目估算 (9) 3.7.2.进度安排 (10)

1.软件项目管理概述 软件项目管理是软件工程和项目管理的交叉学科,软件项目管理的概念涵盖了管理软件产品开发所必须的知识、技术及工具。根据美国项目管理协会PMI 对项目管理的定义可以将软件项目管理定义为:在软件项目活动中运用一系列知识、技能、工具和技术,以满足软件需求方的整体要求。 软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成,而对成本、人员、进度、质量、风险等进行分析和管理的活动。实际上,软件项目管理的意义不仅仅如此,进行软件项目管理有利于将开发人员的个人开发能力转化成企业的开发能力,企业的软件开发能力越高,表明这个企业的软件生产越趋向于成熟,企业越能够稳定发展。 软件生存周期包括可行性分析与项目开发计划、需求分析、设计(概要设计和详细设计)、编码、测试、维护等活动,所有这些活动都必须进行管理,在每个阶段都存在着权限角色控制、文档管理、版本控制、管理工具等,软件项目管理贯穿于软件生命的演化过程之中。 2.软件项目管理过程 为保证软件项目获得成功,必须对软件开发项目的工作范围、要完成的任务、需要的资源、需要的工作量、进度的安排、可能遇到的风险等做到心中有数。软件项目的管理工作开始于技术工作开始之前,在软件从概念到实现的过程中持续进行,最后终止于软件开发工作结束。 根据公司的实际情况,结合软件工程及软件过程标准等,特制定我公司软件项目管理流程如下:

软件开发规范

目录 1. 目的 为了统一公司软件开发的设计过程中关于代码编写时的编写规范和具体开发工作时的编程规范,保证代码的一致性,便于交流和维护,特制定此规范。 2. 范围 本规范适用于开发组全体人员,作用于软件项目开发的代码编写阶段和后期维护阶段。 3. 注释规范 .概述 a) 注释要求中文及中文的标点符号。 b) 注释中,应标明对象的完整的名称及其用途,但应避免对代码过于详细的描述。 c) 每行注释的最大长度为100个字符。 d) 将注释与注释分隔符用一个空格分开。 e)不允许给注释加外框。 f)编码的同时书写注释。 g)重要变量必须有注释。

h)变量注释和变量在同一行,所有注释必须对齐,与变量分开至少两个空格。 如: string title; 模块(类)注释 模块开始必须以以下形式书写模块注释: 类属性注释 在类的属性必须以以下格式编写属性注释: 方法注释 在类的方法声明前必须以以下格式编写注释 代码间注释 代码间注释分为单行注释和多行注释: 单行注释: 命名总体规则 ?名字应该能够标识事物的特性,是有意义的,描述性的词语。能够一眼看出它作什么。 别使用会引起误解的名字。如果名字一目了然,就无需用文档来解释方法的功能了。?名字尽量使用英文单词。 ?名字尽量不使用缩写,除非它是众所周知的。 ?名字可以有两个或三个单词组成,但不应多于三个,控制在3至30个字母以内。 ?在名字中,多个单词用大写第一个字母(其它字母小写)来分隔。例如:IsSuperUser。?名字尽量使用前缀而不是后缀。 ?名字中的单词尽量使用名词,如有动词,也尽量放在后面。例如:FunctionUserDelete (而不是FunctionDeleteUser)。 在具体任务开发中,如果有特定的命名约定,则在相应的软件开发计划中予以明确定义及上报。 5. 命名规范 具体可参考微软命名规范 . 命名规范样式的分类

软件开发流程规范标准

软 件 开 发 流 程 规 V1.0 德联软件有限责任公司 编制人:侯秀美审核人:2015 年8 月19 日

目录 目录 0 一、概述 (2) 二、开发流程规 (3) 2.1 系统软硬件开发环境 (3) 2.2 系统架构(系统组成) (5) 2.3 系统功能模块设计 (6) 2.4 系统功能开发流程图 (6) 2.5 开发修改记录 (7) 三、开发代码规 (8) 3.1 文件结构 (8) 3.1.1 文件信息声明 (8) 3.1.2 头文件的结构 (10) 3.1.3 定义文件的结构 (11) 3.1.4 头文件的作用 (12) 3.1.5 目录结构 (13) 3.2 命名规则 (13) 3.2.1 共性原则 (13) 3.2.2 Windows变量命名规则 (14) 3.3 程序风格 (16) 3.3.1 空行 (17) 3.3.2 代码行 (18) 3.3.3 代码行的空格 (19) 3.3.4 对齐 (20) 3.3.5 长行拆分 (22) 3.3.6 修饰符的位置 (23) 3.3.7 注释 (23) 3.4 函数设计 (26) 3.4.1 参数的规则 (26) 3.4.2 返回值的规则 (27) 3.4.3 函数部实现的规则 (30) 3.4.4 其它建议 (32) 3.4.5 使用断言 (32) 3.4.6 引用与指针的比较 (33) 3.5 变量类型定义 (35) 四、软件测试规 (36) 4.1 单元测试 (36) 4.2 系统测试 (37) 4.6 业务测试 (38) 4.7 验收测试 (38)

4.8 用户现场测试 (38) 五、软件版本管理 (39) 4.1版本管理的必要性 (39)

软件开发编码规范

软件安全开发编码规范 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) 产品中不要包含后门代码,隔离系统中的后门代码,确保其不能出现在产品中。作 为一种特殊的调试代码,后门访问代码是为了使开发者和测试工程师访问一部分终 端用户不能访问的程序代码。但是,如果后门代码被留到产品中,对攻击者来说,它就是一条不需要通过正常安全手段来攻陷系统的通路。

软件开发规范v

开发规范文档版本 <1.0>

修订历史记录

目录 1. 前言5 1.1 目的5 1.2 概述5 2. 命名规范(Naming Conventions) 5 2.1 包命名6 2.2 类命名6 2.3 接口命名6 2.4 方法命名6 2.5 类成员参数7 2.6 局部变量7 2.7 常量7 2.8 集合7 2.9 魔法数字7 2.10 其他8 2.11 项目分层8 3. 代码排版规范9

3.1 空行9 3.2 空格9 3.3 大括号(Braces) 10 3.4 换行(New Lines) 10 3.5 长度(Length) 10 4. 声明10 4.1 类、接口10 4.2 方法10 4.3 字段11 5. 其他约束11 5.1 类成员可见性11 5.2 赋值(Assignment) 11 5.3 12 5.4 条件表达式使用12 5.5 无效语句12 5.6 Import 规范12 5.7 String比较13

5.8 注释要求13 5.9 Try if嵌套层次和分支复杂度14 5.10 Switch 语句14 6. 设计规范15 6.1 类与接口15 6.2 方法15 6.3 表达式与语句16 6.4 控制语句16 6.5 循环语句17 6.6 异常处理18

软件开发规范文档 1.前言 1.1目的 本规范的目的是使本组织能以标准的、规范的方式设计和编码。通过建立编码规范,以使每个开发人员养成良好的编码风格和习惯;并以此形成开发小组编码约定,提高程序的可靠性、可读性、可修改性、可维护性和一致性等,增进团队间的交流,并保证软件产品的质量。 1.2概述 对于代码,首要要求是它必须正确,能够按照设计预定功能去运行;第二是要求代码必须清晰易懂,使自己和其他的程序员能够很容易地理解代码所执行的功能等。然而,在实际开发中,每个程序员所写的代码却经常自成一套,很少统一,导致理解困难,影响团队的开发效率及系统的质量等。因此,一份完整并被严格执行的开发规范是非常必须的,特别是对软件公司的开发团队而言。 最根本的原则: 代码虽然是给机器运行的,但却是给人读的! 2.命名规范(Naming Conventions) 命名规范使程序更易读,从而更易于理解。它们也可以提供一些有关标识符功能的信息,以助于理解代码,例如,不论它是一个常量,包,还是类。大家遵守一定的规范,相互看其他人的代码也会更加方便。 ?使用可以准确说明变量/字段/类/接口/包等的完整的英文描述符。例如,采用类似firstName,listAllUsers 或CorporateCustomer 这样的名字,尽量不使用汉语拼音及不相关单词命名,严禁使用汉语拼音首字母组合命名,虽然Java 支持

软件开发规范:编码规范

软件开发规范:编码规范 C#编码规范 目标: 1. 安全:代码完成所需的功能之余,不要产生负作用,即要稳定可靠。 2. 易读: 类、实例、成员变量、成员函数的命名一目了然 3. 美观: 尽量统一项目组内人员的编程风格。 第一部分:命名 1. 命名原则 1) 所有的函数(变量/类/文件名)应该代表其实际的作用,应该使用有意义的单词或 多个词组合,但不要使用人名、项目组名。 2) 所有的函数(变量/类名)一律使用英文。 3) 使用多个单词时不需要使用连线(如下划线), 但对于全部大写的宏需要使用连 线。 4) 多个词组合较长时, 可以使用单词的缩写。 5) 不得使用非常相近的名字类表示几个不同含义的函数(变量/类)。 6) 命名时请考虑名字的唯一性和含义的准确性。 7) 使用项目组专用词汇来表达特定的含义(概念), 不得把专用词汇挪作他用。 2. 变量的命名 原则: 使用匈牙利命名法命名变量

1) 变量名一般由“类型修饰+代表变量含意的英文单词或单词缩写”等部分 组成。 类型修饰(小写字母): n: int,l: LONG/long, s: short,u: UINT,f: float b: bool,by: BYTE,ch: char, sz: char[],str: string 2) 针对异常捕获过程中的 Exception 变量命名,在没有冲突的情况下,统一 命名为 e;如果有冲突的情况下,可以重复 e,比如:ee。 3. 函数的命名 1) 使用动宾词组表达函数实际所作的事。 2) 同名的函数(重载函数)在功能上应该完全相同, 在参数上的差别也应一目 了然。 3) 不得出现名字非常相近但功能不同的函数. 如 CreatePage1(), CreatePage2()等。 4. 类命名 1) 名字应该能够标识事物的特性。 2) 名字尽量不使用缩写,除非它是众所周知的。 3) 名字可以有两个或三个单词组成,但通常不应多于三个。 4) 在名字中,所有单词第一个字母大写,缩写都要大写。 5.控件命名规则 5) 不要使用下划线字符 ( _ )。 1) 控件命名=Web控件缩写前缀+ “_” +变量名 控件 Label TextBox Button ListBox DropDownList 等等 缩写 lb_XXX tb_XXX Btn_XXX Lb_XXX Drd_XXX XXXXX 6. 文件命名 1) 文件起名要有实际意义。

软件开发代码规范(C语言)

收文:XX产品研究部软件开发人员 软件开发代码规范 (仅供内部使用) 拟制:周超日期:2011-5-11 审核:日期: 核准:日期: 签发:日期: 文档版本:V0.11

目录 第一章原则 (5) 第二章排版 (6) 2.1 空行 (6) 2.2 代码行 (7) 2.3 代码行内的空格 (7) 2.4 对齐缩进 (8) 2.5 长行拆分 (9) 第三章注释 (11) 3.1 通用规则 (11) 3.2 文件注释 (11) 3.3 函数注释 (12) 3.4 数据注释 (13) 3.5 代码注释 (13) 第四章命名 (16) 4.1 通用命名规则 (16) 4.2 文件命名 (16) 4.3 类型命名 (16) 4.4 变量命名 (17) 4.5 常量命名 (18) 4.6 函数命名 (18) 4.7 枚举命名 (18) 4.8 宏命名 (18) 第五章杂项 (20)

文件修改记录

本文档的目的是提供一个公共的编码规范。 这个规范详细阐述在编码时要怎样写、不要怎样写,旨在提高代码的可读性、可维护性,使代码易于管理,使所有人可以集中精力去实现内容,而非处理各种复杂的表现形式。 使代码易于管理的方法之一是增强代码一致性,让别人可以读懂你的代码是很重要的,保持统一编程风格意味着可以轻松根据“模式匹配”规则推断各种符号的含义。创建通用的、必需的习惯用语和模式可以使代码更加容易理解。虽然在某些情况下改变一些编程风格可能会是好的选择,但我们还是应该遵循一致性原则,尽量不这样去做。 关键在于保持一致。

2.1 空行 ● 【规则2-1-1】在每个函数、结构体、枚举定义结束之后都要加空行。 ● 【规则2-1-2】在一个函数体内,逻辑密切相关的语句之间不加空行,其它地方应加空 行分隔。 struct st1 { … }; // 空行 enum { … }; // 空行 void Function1(…) { … } // 空行 void Function2(…) { … } // 空行 while (condition) { statement1; // 空行 if (condition) { statement2; } else { statement3; } // 空行 statement4; } 函数之间的空行 函数内部的空行 ● 【规则2-1-3】相对独立的程序块之间、变量说明之后必须加空行。 不规范代码 规范代码

软件开发标准规范

软件开发标准规范 本规范规定了公司软件开发各阶段所必须遵循的标准,旨在提高软件产品的系统性与统一性。 一、代码书写规范 1. 命名规范 1)菜单 FrmXX (Frm 菜单名称) 例:门诊收费为FrmMZSF 2)窗口 DlgXX (Dlg 功能名称) 例:门诊收费中挂号窗口为DlgGH 3)程序集/命名空间 服务器Com 组件程序集:XXCom (系统简写Com ) 服务器Com 组件统一命名空间:MT.HISCom YYVB.XX (YYVB. 系统简写) VB 客户端程序 集: C# 客户端程序 YYCS.XX (YYCS. 系统简写) 集:

客户端命名空间:MT.YYGL.XX (MT.YYGL. 系统简写) 例:门诊收费管理系统为MT.YYGL.MZSF

客户端菜单及窗口:MT.YYGL.XX.XXX(MT.YYGL. 系统简写.菜单/窗口名称)例:门诊收费为MT.YYGL.MZSF.FrmMZSF 4)数据类型/控件类型

5)变量 全局变量:_xxXxXx (_数据类型+ 名称)例:宽度为int _iKD 、_iKuaiDu 局部变量:xxXxXx (数据类型+名称) 例:宽度为int iKD 、iKuaiDu 6)函数 函数命名:XxxXxx (驼峰格式) 例:ToString 、GetBRXX

参数命名:xxXxXx (数据类型+ 名称) 例:宽度为int iKD 、iKuaiDu 2. 注释 3. 空行 4. 换行 二、界面规范 1) 显示模式默认803*475 显示方式,有特殊要求的应用程序除外; 2) 窗体中各控件安排均匀,分布合理,整个窗体应清晰,整洁,稳重; 3) 窗体内字体采用宋体9 号字,12 号字,题头可选宋体加粗二号, 不准用斜体字型; 4) 数值型的数据显示或录入必须右对齐,日期型可居中或左对齐,字 符串型必须左对齐(包括以下拉数据窗口形式显示的列) ; 5) 窗体输入部分支持ENTER 键跳转; 6) 窗体控体布局顺序与TAB 键跳转顺序一致; 7) 输入部分避免采用滚动条;

软件项目开发流程规范(精)

软件项目开发流程规范 1总则 制定 LiveBOS 平台软件项目开发规范的目的是为 LiveBOS 应用开发人员基于LiveBOS Studio 开发出高效的,灵活的企业级应用系统提供,提高系统可重用性、可维护性。 2 适用对象和范围 2.1 对象 本规范是为以下人员制定的: 项目管理人员 ----在软件开发过程中负责技术管理和项目管理的人员。 软件质量保证人员 ----在软件开发过程中负责质量控制的人员。 软件开发人员 ----在软件开发过程中负责系统分析、设计、实现的人员。 技术支持人员 ----在软件开发过程中参与方案规划和系统技术支持的人员。 软件维护人员 ----在软件开发结束后负责对产品进行维护的人员。 2.2范围 基于 LiveBOS 平台的软件开发项目 3 软件生存周期划分 一个软件从定义、开发、使用和维护,直至最终被废去的过程,叫软件生存周期。 目前,多数软件开发仍采用“瀑布模型” , 将软件生存周期各阶段视如瀑布流水,逐级下落, 逐步进行。本规范将应用软件产品开发生存周期划分为七个阶段 :

1. 计划阶段 2. 需求分析 3. 开发计划 4. 软件开发 5. 测试阶段 6. 系统确认 7. 系统维护 4软件开发原则 4.1基本原则 不论采用何种开发模型,都必须坚持软件工程的原则: ● 软件开发过程一定要划分成一系列界面清晰的工作阶段, 每个阶段都有明确的目标和要求,都要产生一定的阶段成果; ● 用可见的文档描述每个阶段的任务、实施步骤、要求和完成标志; ● 对每个阶段的工作结果,都要进行严格的检查、评审或验证; ● 前一阶段的工作经审查通过方能进入下一阶段的工作。 4.2 项目管理 软件项目或产品在整个软件生存周期之内都要按照项目管理的方式进行进度、质量、成本等方面的控制。 软件开发项目组织在逻辑上应有三方面人员参加:管理人员,质量保证人员,开发人员,并以管理为核心,以质量为保证,遵循本开发规范进行开发。

软件开发要求规范整体要求规范

软件开发规范 Software Development Specification Version: V1.0 Date: 2010-06-22 Prepared by

Document Revision History文档修订记录

Table of Contents目录 1Introduction 简介5 1.1Purpose 目标5 1.2Scope 范围6 1.3Definitions, Acronyms, and Abbreviations. 术语,缩略词6 1.4References 引用7 1.5Overview 文档组织7 2The Overall Description 概述8 2.1Software Development Organizing 开发团队组织结构8 2.2Project Base Process 项目基本流程9 2.3CMM Base Process CMM基本过程10 2.3.1SCM软件配置管理10 2.3.2SPP 计划策划12 2.3.3SPTO项目追踪16 2.3.4PR同行评审18 2.3.5SQA质量保证19 2.4SDLC 生命周期选择20 2.5Development Process 开发过程21 2.5.1Development Phase 开发阶段21 2.5.2Phase Product 阶段制品22 2.6Role Duty 角色职责23 2.7Constraints 限制24 3Specific Requirements 详细描述25 3.1Precondition 前提25 3.1.1SCM配置库25 3.1.2Test Environment 测试环境26 3.2Development Control Process 开发控制流程27 3.2.1项目启动和策划阶段27 3.2.2需求分析、设计、编码阶段27 3.2.3提交测试阶段28 3.2.4生产发布、终测28 3.2.5发布后问题反馈修改过程29 3.3TSP 团队软件过程30 3.3.1会议组织30 3.3.2沟通问题30

软件源码版本管理规范标准

软件版本管理规范 1.第一章目的 本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容,使软件项目版本管理流程化并规范化,确保在系统开发和实施过程中项目的完整性和一致性。 2.第二章适用范围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库(可使用工具建立配置库,本文所述使用的是SVN)进行版本管理。 3.第三章职责 配置库管理员:负责配置库的日常维护和管理;监督开发及测试部门及时提交版本管理对象(即配置项)。 此岗位可由开发或测试人员兼任。 4.第四章内容 4.1. 版本管理对象 包括但不限于: ?项目总体计划 ?可行性研究报告 ?开发计划 ?需求说明书 ?需求设计原型 ?设计说明书 ?系统开发变更申请单 ?系统管理手册 ?用户操作手册 ?培训计划 ?培训记录 ?源程序 ?支持系统运行的配置文件

?存储过程脚本 ?测试计划 ?测试用例 ?测试脚本 ?测试报告 ?上线计划 ?上线申请 ?版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目内部的目录结构建议按下列格式创建。 配置库目录结构规划: ┠tags(发布) ┃ ├v1.0.0_T1_2016909 ┃ ├v1.0.0.33899_T1_20161009 ┃ ├v1.0.0_R1_20161109 ┃ ├v1.1.0_T1_20170109 ┃ └v1.1.0_R1_20170209 ┠trunk(主版本) ┃ └projectA ┃ ├src ┃ ├MY_MOOC ┃ ├doc ┃ ├tool ┃ ├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC

相关主题
相关文档 最新文档