iOS软件代码规范.docx

上传人:b****6 文档编号:7211802 上传时间:2023-01-21 格式:DOCX 页数:35 大小:209.55KB
下载 相关 举报
iOS软件代码规范.docx_第1页
第1页 / 共35页
iOS软件代码规范.docx_第2页
第2页 / 共35页
iOS软件代码规范.docx_第3页
第3页 / 共35页
iOS软件代码规范.docx_第4页
第4页 / 共35页
iOS软件代码规范.docx_第5页
第5页 / 共35页
点击查看更多>>
下载资源
资源描述

iOS软件代码规范.docx

《iOS软件代码规范.docx》由会员分享,可在线阅读,更多相关《iOS软件代码规范.docx(35页珍藏版)》请在冰豆网上搜索。

iOS软件代码规范.docx

iOS软件代码规范

iOS软件代码规范

修订记录

1.

指导原则.

2.

布局.

2.1.

文件布局.

2.2.

基本格式.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

2.3.

2.4.

2.5.

4.1.

4.2.

5.1.

5.2.

9.1.

9.2.

9.3.

对齐.

空行空格.

断行.

注释.

命名规则.

基本规则.

资源命名.

变量,常量,宏与类型

变量、常量以及宏.

类型.

表达式与语句.

函数、方法、接口.

头文件.

可靠性.

内存使用.

指针使用.

断言与错误处理.

其它补充.

参考文档.

11

13

14

17

17

19

19

19

21

22

27

28

29

29

31

32

32

33

34

 

修订记录

日期

修订版本

描述

修改人

2011-11-30

V1.0.1

参考BREW编程规范拟制iOS代码规范

陈达剑

2011-12-12

V1.0.2

增加指针规则以及其它补充

陈达剑

本规范针对于iOS的object-c开发语言。

【原则1-1】首先是为人编写程序,其次才是计算机。

说明:

这是软件开发的基本要点,软件的生命周期贯穿产品的开发、测试、生产、用户使用、

版本升级和后期维护等长期过程,只有易读、易维护的软件代码才具有生命力。

【原则1-2】保持代码的简明清晰,避免过分的编程技巧。

不要过分追求技巧,否则

说明:

简单是最美。

保持代码的简单化是软件工程化的基本要求。

会降低程序的可读性。

【原则1-3】编程时首先达到正确性,其次考虑效率。

说明:

编程首先考虑的是满足正确性、健壮性、可维护性、可移植性等质量因素,最后才考虑程序的效率和资源占用。

【原则1-4】编写代码时要考虑到代码的可测试性。

说明:

不可以测试的代码是无法保障质量的,开发人员要牢记这一点来设计、编码。

实现设

计功能的同时,要提供可以测试、验证的方法。

【原则1-5】函数(方法)是为一特定功能而编写,不是万能工具箱。

不能是所有东西

说明:

方法是一个处理单元,是有特定功能的,所以应该很好地规划方法,都放在一个方法里实现

【原则1-6】鼓励多加注释。

【原则1-7】内存空间在哪分配在哪释放。

2.布局

程序布局的目的是显示出程序良好的逻辑结构,提高程序的准确性、连续性、可读性、可维护性。

更重要的是,统一的程序布局和编程风格,有助于提高整个项目的开发质量,提高开发效率,降低开发成本。

同时,对于普通程序员来说,养成良好的编程习惯有助于提高

自己的编程水平,提高编程效率。

因此,统一的、良好的程序布局和编程风格不仅仅是个人

主观美学上的或是形式上的问题,而且会涉及到产品质量,涉及到个人编程能力的提高,

须引起大家重视。

2.1.文件布局

【规则2-1-1】遵循统一的布局顺序来书写头文件。

说明:

以下内容如果某些节不需要,可以忽略。

但是其它节要保持该次序。

头文件布局

文件头(参见“注释”一节)

#import(依次为标准库头文件、非标准库头文件)全局宏

常量定义

全局数据类型

类定义

正例:

/***************************************************************************

*文件引用

***************************************************************************/

/***************************************************************************

*类引用

***************************************************************************/

/***************************************************************************

宏定义

***************************************************************************/

/***************************************************************************

*常量

***************************************************************************/

/***************************************************************************

类型定义

***************************************************************************//***************************************************************************

*类定义

***************************************************************************/

【规则2-1-2】遵循统一的布局顺序来书写实现文件。

说明:

以下内容如果某些节不需要,可以忽略。

但是其它节要保持该次序。

实现文件布局:

文件头(参见“注释”一节)

#import(依次为标准库头文件、非标准库头文件)文件内部使用的宏

常量定义

文件内部使用的数据类型

全局变量

本地变量(即静态全局变量)

类的实现

正例:

/***************************************************************************

*文件引用

***************************************************************************/

/***************************************************************************

*宏定义

***************************************************************************/

/***************************************************************************

*常量

***************************************************************************/

/***************************************************************************

*类型定义

***************************************************************************/

/***************************************************************************

*全局变量

***************************************************************************/

/***************************************************************************

*原型

***************************************************************************/

/***************************************************************************

*类特性

***************************************************************************/

@implementationClassName

@synthesizevariableName;

/***************************************************************************

*类的实现

***************************************************************************/

【规则2-1-4]包含标准库头文件用尖括号<>,包含非标准库头文件用双引号

正例:

#import

#import“heads.h"

2.2.基本格式

【规则2-2-1]if、elseelseif、for、while、do等语句自占一行,执行语句不得紧跟其后。

不论执行语句有多少都要加

正例:

if(varible1

{

varible1=varible2;

}

反例:

F面的代码执行语句紧跟if的条件之后,而且没有加{},违反规则。

if(varible1

【规则2-2-2]定义指针类型的变量,*应放在变量前。

正例:

float*pfBuffer;

反例:

float*pfBuffer;

1建议2-2-1〗源程序中关系较为紧密的代码应尽可能相邻。

正例:

iLength=10;

iWidth=5;//矩形的长与宽关系较密切,放在一起。

StrCaption=“Test”;

反例:

2.3.对齐

【规则2-3-1】禁止使用TAB键,必须使用空格进行缩进。

缩进为4个空格。

【规则2-3-2】程序的分界符’{'和’}'应独占一行并且位于同一列,同时与引用它们的语句左对齐。

{}之内的代码块使用缩进规则对齐。

}}

【规则2-3-3】结构型的数组、多维的数组如果在定义时初始化,按照数组的矩阵结构分行书写。

正例:

intaiNumbers[4][3]={

1,1,1,

2,4,8,

3,9,27,4,16,64

【规则2-3-4】相关的赋值语句等号对齐。

正例:

 

〖建议2-3-1〗在switch语句中,每一个case分支和default要用{}括起来,{}中的内容需要缩进。

说明:

使程序可读性更好。

正例:

switch(iCode)

{

case1:

{

〃缩进4格

DoSomething();break;

}

case2:

//每一个case分支和default要用{}括起来

DoOtherThing();break;

//其它case分支

default:

DoNothing();break;

}

}

24空行空格

【规则2-4-1】函数(方法)块之间使用两个空行分隔。

说明:

空行起着分隔程序段落的作用。

适当的空行可以使程序的布局更加清晰。

正例:

(void)hey

{

[hey实现代码]

反例:

}

//

空一行

空一行

//

(void)ack

{

[ack实现代码]

}

voidFoo:

:

Hey(void)

{

[Hey实现代码]

}

voidFoo:

:

Ack(void)

{

[Ack实现代码]

}

//两个函数的实现是两个逻辑程序块,应该用空行加以分隔。

【规则2-4-2】一元操作符如“!

”“~”、“++”“--”“*”、“&”(地址运算符)等前后不加空格。

“□”、“•”、“->”这类操作符前后不加空格。

正例:

!

bValue

-iValue

++iCount

*strSource

&fSum

 

aiNumber[i]=5;tBox.dWidthtBox->dWidth

正例:

fValue

【规则2-4-3】多元运算符和它们的操作数之间至少需要一个空格。

fOldValue;fTotal+fValueiNumber+=2;

【规则2-4-4】关键字之后要留空格。

说明:

if、for、while等关键字之后应留一个空格再跟左括号’('以突出关键字。

【规则2-4-5】函数名之后不要留空格。

说明:

函数名后紧跟左括号‘('以与关键字区别。

【规则2-4-6】方法名与形参不能留空格,返回类型与方法标识符有一个空格。

说明:

方法名后紧跟',然后紧跟形参,返回类型’(与'之间有一个空格。

正例:

-凵(BOOL)shouldAutorotateToInterfaceOrientation:

(UIInterfaceOrientation)interfaceOrientation{

//ReturnYESforsupportedorientations.

return(interfaceOrientation==UllnterfaceOrientationPortrait);

【规则2-4-7】‘(’向后紧跟,’)'‘,‘、‘;’向前紧跟,紧跟处不留空格。

‘,’之后要留空

格。

‘;’不是行结束符号时其后要留空格。

正例:

例子中的凵代表空格。

for凵(i凵=凵0;凵i凵<凵MAX_BSC_NUM;凵i++){

DoSomething(iWidth,凵iHeight);

}

【规则2-4-8】注释符与注释内容之间要用一个空格进行分隔。

正例:

/*注释内容*/

//注释内容

反例:

/*注释内容*/

//注释内容

【规则2-5-1】长表达式(超过80列)要在低优先级操作符处拆分成新行,操作符放在新行之首(以便突出操作符)。

拆分出的新行要进行适当的缩进,使排版整齐。

说明:

条件表达式的续行在第一个条件处对齐。

for循环语句的续行在初始化条件语句处对齐。

函数调用和函数声明的续行在第一个参数处对齐。

赋值语句的续行应在赋值号处对齐。

正例:

if((iFormat==CH_A_Format_M)

&&(iOfficeType==CH_BSC_M))//条件表达式的续行在第一个条件处对齐

{

doSomething();

}

//for循环语句续行在初始化条件语句处对齐

for(longjnitialization_statement;long_condiction_statement;long_update_statement)

函数声明的续行在第一个参数处对齐

doSomething();

//

BYTEReportStatusCheckPara(HWNDhWnd,

BYTEucCallNo,

BYTEucStatusReportNo);

//赋值语句的续行应在赋值号处对齐

fTotalBill=fTotalBill+faCustomerPurchases[ilD]

+fSalesTax(faCustomerPurchases[ilD]);

【规则2-5-2】函数(方法)声明时,类型与名称不允许分行书写。

正例:

externdoubleFARCalcArea(doubledWidth,doubledHeight);反例:

externdoubleFAR

CalcArea(doubledWidth,doubledHeight);

3.注释

注释有助于理解代码,有效的注释是指在代码的功能、意图层次上进行注释,提供有用、额外的信息,而不是代码表面意义的简单重复。

【规则3-1】C语言的注释符为“/*…*/”。

C++语言中,多行注释采用“/*…*/”,单行注

释采用“〃…”。

1建议3-1〗不管多行还是单行,采用注释符“/*…*/”。

【规则3-2】一般情况下,源程序有效注释量必须在30%以上。

说明:

注释的原则是有助于对程序的阅读理解,注释不宜太多也不能太少,注释语言必须准

确、易懂、简洁。

有效的注释是指在代码的功能、意图层次上进行注释,提供有用、额外的信息。

【规则3-3】注释使用中文。

说明:

对于特殊要求的可以使用英文注释,如工具不支持中文或国际化版本时。

【规则3-4】文件头部必须进行注释,包括:

.h文件、.c文件、.m文件、.inc文件、.def文

件、编译说明文件.cfg等。

说明:

注释必须列出:

版权信息、文件标识、内容摘要、版本号、作者、完成日期、修改信息等。

修改记录部分建议在代码做了大修改之后添加修改记录。

备注:

文件名称,内

容摘要,作者等部分一定要写清楚。

正例:

下面是文件头部的中文注释:

/*********************************************************************

*版权所有(C)2011中兴软件技术(南昌)有限公司

//修改历史记录,包括修改日期、修改者及修改内容

*修改记录1:

*修改日期:

*版本号:

〃或版本号

*修改人:

*修改内容:

//修改原因以及修改内容说明

*修改记录2:

**********************************************************************/

【规则3-5】方法头部应进行注释,列出:

函数的目的/功能、输入参数、输出参数、返回值、访问和修改的表、修改信息等,除了函数(方法)名称和功能描述必须描述外,其它部分建议

写描述。

说明:

注释必须列出:

函数名称、功能描述、输入参数、输出参数、返回值、修改信息等。

备注:

方法名称、功能描述要正确描述。

正例:

***********************************************************************

【规则3-6】注释应与其描述的代码相近,对代码的注释应放在其上方或右方(对单条语句的注释)相邻位置,不可放在下面,如放于上方则需与其上面的代码用空行隔开。

说明:

在使用缩写时或之前,应对缩写进行必要的说明。

正例:

如下书写比较结构清晰

/*获得子系统索引*/

iSubSysIndex=aData[ilndex].iSysIndex;

反例

1:

/*代码段1注释*/

[代码段1]

/*代码段2注释*/

[代码段2]

 

如下例子注释与描述的代码相隔太远。

/*获得子系统索引*/

iSubSysIndex=aData[ilndex].iSysIndex;

反例

2:

如下例子注释不应放在所描述的代码下面。

iSubSysIndex=aData[iIndex].iSysIndex;

/*获得子系统索引*/

反例

3:

如下例子,显得代码与注释过于紧凑。

/*代码段1注释*/

[代码段1]

/*代码段2注释*/

[代码段2]

【规则3-7】全局变量要有详细的注释,包括对其功能、取值范围、访问信息及访问时注意事项等的说明。

正例:

/*

*变量作用说明

*变量值说明

*/

BYTEg_ucTranErrorCode;

【规则3-8】注释与所描述内容进行同样的缩排。

说明:

可使程序排版整齐,并方便注释的阅读与理解。

正例:

如下注释结构比较清晰

-(int)doSomething

{

/*代码段1注释

[代码段1]

*/

/*代码段2注释

[代码段2]

*/

 

 

阅读不方便;

1注释*/

[代码段1]

反例:

如下例子,排版不整齐,intDoSomething(void)

{

/*代码段

 

/*代码段

2注释*/

[代码段2]

 

 

1建议3-2〗尽量避免在注释中使用缩写,特别是不常用缩写。

说明:

在使用缩写时,应对缩写进行必要的说明。

4.命名规则

4.1.基本规则

好的命名规则能极大地增加可读性和可维护性。

同时,对于一个有上百个人共同完成的

大项目来说,统一命名约定也是一项必不可少的内容。

本章对程序中的所有标识符(包括变

量名、常量名、函数名、类名、结构名、宏定义等)的命名做出约定。

【规则4-1】标识符要采用英文单词或其组合,便于记忆和阅读,切忌使用汉语拼音来命名。

说明:

标识符应当直观且可以拼读,可望文知义,避免使人产生误解。

程序中的英文单词一般不要太复杂,用词应当准确。

【规则4-2】严格禁止使用连续的下划线,下划线也不能出现在标识符头或结尾(预编译开关除外)。

说明:

这样做的目的是为了使程序易读。

因为variable—name和variable__name很难区分,

下划线符号‘_'若出现在标识符头或结尾,容易与不带下划线‘_'的标识符混淆。

【规则4-3】程序中不要出现仅靠大小写区分的相似的标识符。

分割单词。

预编译开关的定义

【规则4-4】宏、常量名都要使用大写字母,用下划线使用下划线‘’开始。

正例:

女0DISP_BUF_SIZE、MIN_VALUE、MAX_VALUE等等。

【规则4-5】程序中局部变量不要与全局变量重名。

说明:

尽管局部变量和全局变量的作用域不同而不会发生语法错误,但容易使人误解。

【规则4-6】使用一致的前缀来区分变量的作用域。

说明:

变量活动范围前缀规范如下(少用全局变量)

g_

s_

全局变量

模块内静态变量

局部变量不加范围前缀

【规则4-7】方法名用小写字母开头的单词组合而成。

说明:

方法名力求清晰、明了,通过方法名就能够判断方法的主要功能。

方法名中不同意义字段之间不要用下划线连接,而要把每个字段的首字母大写以示区分。

方法命名采用

大小写字母结合的形式,但专有名词不受限制。

str

fn

说明:

参考匈牙利命名规则,常见的简写如下:

整型指针字符串布尔字符函数

正例:

@interfaceCMainMenu

intm_nWidth;

NString*m_strName;

BOOLm_bCheck;

〖建议4-1〗尽量避免名字中出现数字编号,如Value1、Value2等,除非逻辑上的确需要编

号。

1建议4-2〗标识符前最好不加项目、产品、部门的标识。

说明:

这样做的目的是为了代码的可重用性。

4.2.资源命名

•字符串:

以“IDS_”开头,如:

IDS_VIEW

•图

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高等教育 > 研究生入学考试

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1