ObjectiveC编码规范.docx
《ObjectiveC编码规范.docx》由会员分享，可在线阅读，更多相关《ObjectiveC编码规范.docx（25页珍藏版）》请在冰豆网上搜索。
ObjectiveC编码规范
Objective-C软件编码规范
目录
1.目的4
2.适用范围4
3.定义4
4.示例4
5.代码布局6
5.1.间隔与格式化6
5.2.行长度6
5.3.方法声明与定义6
5.4.方法7
5.5.@public和@private7
5.6.异常8
5.7.Protocols8
6.命名8
6.1.文件命名8
6.2.Objective-C++9
6.3.类命名10
6.4.类别命名10
6.5.Objective-C方法命名10
6.6.变量命名10
6.7.实体变量11
6.8.常量11
7.注释11
7.1.声明注释12
7.2.注释内容12
8.Cocoa和Objective-C特性12
8.1.成员变量应该定义为@private12
8.2.明确指定初始化12
8.3.重写指定初始化13
8.4.重写NSObject的方法13
8.5.避免调用new方法13
8.6.初始化变量13
8.7.保持公有API简明13
8.8.#import和#include14
8.9.使用根框架14
8.10.构建时即设定autorelease15
8.11.优先autorelease而非retain15
8.12.以声明时的顺序dealloc处理实例变量15
8.13.SetterscopyNSStrings15
8.14.避免抛出异常15
8.15.nil检查16
8.16.BOOL类型陷阱17
8.17.属性17
8.18.为NSString使用Copy属性18
1.
目的
统一编程风格，提高的可读性与编码效率，避免团队开发可能带来的混乱。
2.适用范围
本规范适用于公司项目产品运用Objective-C作为开发语言的编码活动。
3.定义
规则:
编程时必须遵守的约定
建议:
编程时需要考虑的约定
绿色代码:
对此规则或建议给出的正确例子
红色代码:
对此规则或建议给出的反面例子
匈牙利命名法：
是一种编程时的命名规范。
基本原则是：
变量名＝属性＋类型＋对象描述，其中每一对象的名称都要求有明确含义，可以取对象名字全称或名字的一部分
驼峰命名法：
就是当变量名或函式名是由一个或多个单字连结在一起，而构成的唯一识别字时，驼峰命名法第一个单字以小写字母开始；第二个单字的首字母大写或每一个单字的首字母都采用大写字母
4.示例
先看一个实例对代码的基本格式有大致了解，可以看到基本的间距，命名等等。
下例是一份头文件，展示对@interface声明正确的注释和留间距。
//GTMFoo.h
//FooProject
//
//CreatedbyGregMilleron6/13/08.
//Copyright2008Google,Inc.Allrightsreserved.
//
#import
//AsampleclassdemonstratinggoodObjective-Cstyle.Allinterfaces,
//categories,andprotocols（read:
alltop-leveldeclarationsinaheader）
//MUSTbecommented.Commentsmustalsobeadjacenttotheobjectthey're
//documenting.
//
//（noblanklinebetweenthiscommentandtheinterface）
@interfaceGTMFoo:
NSObject{
@private
NSString*foo_;
NSString*bar_;
}
//ReturnsanautoreleasedinstanceofGMFoo.See-initWithString:
fordetails
//abouttheargument.
+（id）fooWithString:
（NSString*）string;
//Designatedinitializer.|string|willbecopiedandassignedto|foo_|.
-（id）initWithString:
（NSString*）string;
//Getsandsetsthestringfor|foo_|.
-（NSString*）foo;
-（void）setFoo:
（NSString*）newFoo;
//Doessomeworkon|blah|andreturnsYESiftheworkwascompleted
//successfuly,andNOotherwise.
-（BOOL）doWorkWithString:
（NSString*）blah;
@end
下例是一份源文件，展示对接口的@implementation的实现的正确注释和留间隔。
它也包括了主要方法如getters，setters，init和dealloc的相关实现。
//
//GTMFoo.m
//FooProject
//
//CreatedbyGregMilleron6/13/08.
//Copyright2008Google,Inc.Allrightsreserved.
//
#import"GTMFoo.h"
@implementationGTMFoo
+（id）fooWithString:
（NSString*）string{
return[[[selfalloc]initWithString:
string]autorelease];
}
//Mustalwaysoverridesuper'sdesignatedinitializer.
-（id）init{
return[selfinitWithString:
nil];
}
-（id）initWithString:
（NSString*）string{
if（（self=[superinit]））{
foo_=[stringcopy];
bar_=[[NSStringalloc]initWithFormat:
@"hi%d",3];
}
returnself;
}
-（void）dealloc{
[foo_release];
[bar_release];
[superdealloc];
}
-（NSString*）foo{
returnfoo_;
}
-（void）setFoo:
（NSString*）newFoo{
[foo_autorelease];
foo_=[newFoocopy];
}
-（BOOL）doWorkWithString:
（NSString*）blah{
//...
returnNO;
}
@end
5.代码布局
5.1.间隔与格式化
空格对tab键，仅使用空格，缩进两个。
使用空格用于缩进，不要在编码时使用tab键。
如果要使用应该设置你的编辑器将tab键转换成对应的空格。
5.2.行长度
代码中的每行文本不要超过80个字符的长度。
尽管Objective-C正变得比C++更加繁冗，为了保持规范的互通性，还是决定保持80字符长度的限制。
你可以在Xcode里清楚地发现代码中的违规，设置Xcode>Preferences>TextEditing>Showpageguide。
（之后就可以在代码编辑区域里看到一条指定字符长度的指示线了）
5.3.方法声明与定义
留一个空格在-或+和返回类型之间，但参数列表里的参数之间不要留间隔。
参数对象的星号前需要加空格。
方法应该写成这样:
-（void）doSomethingWithString:
（NSString*）theString{
...
}
如果参数过多，推荐每个参数各占一行。
使用多行的情况下，在参数前加冒号用于对齐:
-（void）doSomethingWith:
（GTMFoo*）theFoo
rect:
（NSRect）theRect
interval:
（float）theInterval{
...
}
当第一个关键字比其他的短时，后续行至少缩进四个空格。
这样你可以让后续的关键字垂直对齐，而不是用冒号对齐:
-（void）short:
（GTMFoo*）theFoo
longKeyword:
（NSRect）theRect
evenLongerKeyword:
（float）theInterval{
...
}
5.4.方法
方法调用的格式和方法声明时的格式时一致的，如果格式风格可选，遵从原有代码的风格。
调用应该将所有参数写在一行:
[myObjectdoFooWith:
arg1name:
arg2error:
arg3];
或者每个参数一行，用冒号对齐（对齐效果如前说明）：
[myObjectdoFooWith:
arg1
name:
arg2
error:
arg3];
不要使用如下风格的写法：
[myObjectdoFooWith:
arg1name:
arg2//somelineswith>1arg
error:
arg3];
[myObjectdoFooWith:
arg1
name:
arg2error:
arg3];
[myObjectdoFooWith:
arg1
name:
arg2//aligningkeywordsinsteadofcolons
error:
arg3];
在声明和定义时，如果因为关键字长度使就算有四个空格在前仍然无法用冒号对齐，那么就让后续行缩进四个空格而不是冒号对齐:
[myObjshort:
arg1
longKeyword:
arg2
evenLongerKeyword:
arg3];
5.5.@public和@private
权限控制符@public和@private缩进一个空格：
@interfaceMyClass:
NSObject{
@public
...
@private
...
}
@end
5.6.异常
每个异常标签的@和开括号（{）写在统一行，标签和开括号间隔一个空格，同样适用于@catch语句。
@interfaceMyClass:
NSObject{
@public
...
@private
...
}
@end
5.7.Protocols
在类型定义和被中括号括起来的Protocols名称之间不需要空格。
本规矩适用于类定义，变量声明和方法声明时使用。
参考代码：
@interfaceMyProtocoledClass:
NSObject{
@private
iddelegate_;
}
-（void）setDelegate:
（id）aDelegate;
@end
6.命名
所有类，类别，方法，以及变量如包括缩写，则缩写部分使用全大写的缩写（Initialisms）形式。
这遵守Apple的标准，比如URL，TIFF以及EXIF。
当写Objective-C++代码时，情况就不是那么单一了。
许多项目需要实现带一些Objective-C代码的跨平台的C++APIs或者连接后台的C++代码与前台的原生Cocoa代码，这会造成两种规范直接冲突。
解决方法是根据方法/函数风格来决定。
如果在@implementation块，就使用Objective-C的命名规则；如果在C++的方法实现块，就使用C++的命名规则。
避免了实体变量和本地变量在一个函数内命名规则冲突的情况，而这种情况是对可读性的极大损害。
6.1.文件命名
文件名反映了它所包含的实现类的名字，遵从你所在项目的习惯。
文件扩展名使用如下规则：
.h
C/C++/Objective-Cheaderfile
.m
Objective-Cimplementationfile
.mm
Objective-C++implementationfile
.cc
PureC++implementationfile
.c
Cimplementationfile
类别的文件名应该包含扩展类的名字，比如GTMNSString+Utils.horGTMNSTextView+Autocomplete.h。
6.2.Objective-C++
在一份源文件里，Objective-C++代码遵守当前方法/函数的风格
为了尽量减少不同命名风格间的冲突，使用当前方法的风格。
如果在@implementation块，使用Objective-C命名规则，如果在C++类的函数实现块，使用C++命名规则。
//file:
cross_platform_header.h
classCrossPlatformAPI{
public:
...
intDoSomethingPlatformSpecific（）;//imploneachplatform
private:
intan_instance_var_;
};
//file:
mac_implementation.mm
#include"cross_platform_header.h"
//AtypicalObjective-Cclass,usingObjective-Cnaming.
@interfaceMyDelegate:
NSObject{
@private
intinstanceVar_;
CrossPlatformAPI*backEndObject_;
}
-（void）respondToSomething:
（id）something;
@end
@implementationMyDelegate
-（void）respondToSomething:
（id）something{
//bridgefromCocoathroughourC++backend
instanceVar_=backEndObject->DoSomethingPlatformSpecific（）;
NSString*tempString=[NSStringstringWithInt:
instanceVar_];
NSLog（@"%@",tempString）;
}
@end
//Theplatform-specificimplementationoftheC++class,using
//C++naming.
intCrossPlatformAPI:
:
DoSomethingPlatformSpecific（）{
NSString*temp_string=[NSStringstringWithInt:
an_instance_var_];
NSLog（@"%@",temp_string）;
return[temp_stringintValue];
}
6.3.类命名
类名（不包括类别和协议名）应该用大写开头的驼峰命名法。
在应用级别的代码里，尽量不要使用带前缀的类名。
每个类都有相同的前缀不能提高可读性。
不过如果是编写多个应用间的共享代码，前缀就是可接受并推荐的做法了（型如GTMSendMessage）。
6.4.类别命名
类别命名应该以两三个字符的分类前缀作为一个项目或通用的公用部分。
类别名应该包含类的扩展。
举个例子，如果我们想要创建一个基于NSString的类别用于解析，我们应该把类别放到名字是GTMNSString+Parsing.h的文件里，而类别本身的名字则是GTMStringParsingAdditions（是的，我们明白这个类别和其文件名字不匹配，但这个文件可能还包括其他用于解析相关的类别）。
类别的方法应该都使用一个前缀（型如gtm_myCategoryMethodOnAString），以防止Objective-C代码在单名空间里冲突。
如果代码本来就不考虑共享或在不同的地址空间（address-space），方法命名规则就没必要恪守了。
6.5.Objective-C方法命名
方法使用小写开头的驼峰法命名，每个参数都应该小写开头。
方法名应该尽可能读起来像一句话，参数名就相对方法名的补充说明（比如convertPoing:
fromRect:
或者replaceCharactersInRange:
withString:
）。
存取（Accessor）方法应该一致的在"取（getting）"的时候直接用变量名而不是在签名加"get"，如下:
-（id）getDelegate;//AVOID
-（id）delegate;//GOOD
不过这仅针对Objective-C代码，C++代码仍然遵循自己的代码规范。
6.6.变量命名
变量名使用小写开头的驼峰法，类成员变量名最后加一个下划线，比如:
myLovalVariable，myInstanceVariable_。
不要使用匈牙利命名法去标记语法，比如静态类型或变量类型（int或pointer之类的）。
使变量名尽量可以推测其用途属性具有描述性。
别一心想着少打几个字母，让你的代码可以迅速被理解更加重要。
比如:
intw;
intnerr;
intnCompConns;
tix=[[NSMutableArrayalloc]init];
obj=[someObjectobject];
p=[networkport];
intnumErrors;
intnumCompletedConnections;
tickets=[[NSMutableArrayalloc]init];
userInfo=[someObjectobject];
port=[networkport];
6.7.实体变量
实体变量用驼峰法命名并后缀下划线，就像usernameTextField_。
允许一种例外就是用KVO/KVC去绑定一个实体变量而Objective-C2.0不能用（因为操作系统的限制）的情况，此时也可用前缀下划线的方法给每个变量命名。
如果可以使用Objective-C2.0，@property和@synthesize提供了遵守命名规范的解决方法。
6.8.常量
常量（预定义，枚举，局部常量等）使用小写k开头的驼峰法，比如kInvalidHandle，kWritePerm。
7.注释
注释是使代码保持可读性的极端重要的方式。
下面的条款描述了你应该注释什么以及在哪里做注释。
但是记住:
即使注释是如此重要，最好的代码还是自说明式的。
起一个有意义的名字比起一个晦涩的名字然后在用注释去解释它好的多。
写注释的时候，记住注释是写给读者，即下一个要理解你的代码并继续开发的人。
"下一个"完全可能就是你自己。
同样，所有C++编程规范的条款仍然适用，只是增加了一些条款，如下：
文件注释：
每个文件的开头都是版权声明，接着是文件内容的描述。
法律声明和作者栏：
每个文件都必须包含如下信息:
本文件内容描述和作者栏
如果你把别人写的文件做了相当大的改动，就把自己添加到作者栏去。
这样别的开发者就方便联系这个文件的实际开发人员了。
7.1.声明注释
每个接口，类别，协议都必须伴随描述它的用途以及如何整合的注释。
//AdelegateforNSApplicationtohandlenotificationsaboutapp
//launchandshutdown.Ownedbythemainappcontroller.
@interfaceMyAppDelegate:
NSObject{
...
}
@end
如果已经在文件的顶部写了接口的详细描述，你也可以简单的写如"见文件顶部的完整描述"，当然要有这些注释的顺序安排。
此外public接口的每个方法都应该添加关于函数，参数，返回值以及副作用的注释。
文档默认类都是同步的，如果类实例可以多线程访问，必须要加上额外的说明。
7.2.注释内容
使用竖线引用变量或符号，而不是用引号。
这可以减少歧义，特别是当符号本身就是个常见的词时，可能使句子显得支离破碎，比如符号是"count":
//Sometimesweneed|count|tobelessthanzero.
或者是对于那些已经存在引号的情况：
//Remembertocall|StringWithoutSpaces（"foobarbaz"）|
8.Cocoa和Objective-C特性
8.1.成员变量应该定义为@private
参考代码：
@interfaceMyClass:
NSObject{
@private
idmyInstanceVariable_;
}
//publicaccessors,settertakesownership
-（id）myInstanceVariable;
-（void）setMyInstanceVariable:
（id）theVar;
@end
8.2.明确指定初始化
注释并说明指定的初始化。
明确指定初始化对想要子类化你的类的时候时很重要的。
那样，子类化时只需要做一个或多个初始化去保证初值即可。
这也有助于在以后调试你的类时明了初始化流程。
8.3.重写指定初始化
当重写一个子类并需要init...方法，注意要重写父类的指定初始化方法。
如果你没有正确重写父类的指定初始化方法，你的初始化方法可能不会被调用，这会导致很多微妙而难以排除的错误。
8.4.重写NSObject的方法
强烈建议在@implementation之后就立即重写NSObject 的方法。
建议重写 init...，copyWithZone:
和 dealloc 方法。
init...相关的方法写在一起，接下来是 copyWithZone:
，最后是 dealloc。
8.5.避免调用new方法
不要调用N
升级会员 