iOS命名规范(转载)

转载地址:http://www.cnblogs.com/qiqibo/archive/2012/09/05/2671553.html

正文: 
• 格式化代码 
◦ 指针“*”号的位置 
如:NSString *varName; 
◦ 空格 VS tabs 
只允许使用空格,将编辑器设置为1个TAB = 2个字符缩进 
◦ 每行的长度 
每行最多不得超过100个字符 
以15寸Macbook Pro的大小,每行100个字符时能最大化地同时容下编辑器和iPhone模拟器 
Google的80字符的标准有点少,这导致过于频繁的换行(Objectve-C的代码一般都很长) 
通过 “Xcode => Preferences => TextEditing => 勾选Show Page Guide / 输入 
100 => OK” 来设置提醒 
◦ 方法的声明和定义 
在 - OR + 和返回值之间留1个空格,方法名和第一个参数间不留空格。如: 
- (void)doSomethingWithString:(NSString *)theString { 
... 

当参数过长时,每个参数占用一行,以冒号对齐。如: 
- (void)doSomethingWith:(GTMFoo *)theFoo 
rect:(NSRect)theRect 
interval:(float)theInterval { 
... 

如果方法名比参数名短,每个参数占用一行,至少缩进4个字符,且为垂直对齐(而非使用冒号 
对齐)。如: 
- (void)short:(GTMFoo *)theFoo 
longKeyword:(NSRect)theRect 
evenLongerKeyword:(float)theInterval { 
... 

◦ 方法的调用 
调用方法沿用声明方法的习惯。例外:如果给定源文件已经遵从某种习惯,继续遵从那种习惯。 
所有参数应在同一行中,或者每个参数占用一行且使用冒号对齐。如: 
[myObject doFooWith:arg1 name:arg2 error:arg3]; 
或 
[myObject doFooWith:arg1 
name:arg2 
error:arg3]; 
和方法的声明一样,如果无法使用冒号对齐时,每个参数一行、缩进4个字符、垂直对其(而非 
使用冒号对齐)。如: 
[myObj short:arg1 
longKeyword:arg2 
evenLongerKeyword:arg3]; 
◦ @public 和 @private 
@public 和 @private使用单独一行,且缩进1个字符 
◦ Protocals 
类型标示符、代理名称、尖括号间不留空格。 
该规则同样适用于:类声明、实例变量和方法声明。如: 
@interface MyProtocoledClass : NSObject<NSWindowDelegate> { 
@private 
id<MyFancyDelegate> _delegate; 

- (void)setDelegate:(id<MyFancyDelegate>)aDelegate; 
@end 
如果类声明中包含多个protocal,每个protocal占用一行,缩进2个字符。如: 
@interface CustomViewController : ViewController< 
AbcDelegate, 
DefDelegate 
> { 
... 

• 命名 
◦ 类名 
类名(及其category name 和 protocal name)的首字母大写,写使用首字母大写的形式 
分割单词 
在面向特定应用的代码中,类名应尽量避免使用前缀,每个类都使用相同的前缀影响可读性。 
在面向多应用的代码中,推荐使用前缀。如:GTMSendMessage 
◦ Category Name 
待完善 
◦ 方法名 
方法名的首字母小写,且使用首字母大写的形式分割单词。方法的参数使用相同的规则。 
方法名+参数应尽量读起来像一句话(如:)。在这里查看苹果对方法命名的规范。 
getter的方法名和变量名应相同。不允许使用“get”前缀。如: 
- (id) getDelegate; // 禁止 
- (id)delegate; // 对头 
本规则仅针对Objective-C代码,C++代码使用C++的习惯 
◦ 变量名 
变量名应使用容易意会的应用全称,且首字母小写,且使用首字母大写的形式分割单词 
成员变量使用“_”作为前缀(如:“NSString *_varName;”。虽然这与苹果的标准(使 
用“_”作为后缀)相冲突,但基于以下原因,仍使用“_”作为前缀。 
使用“_”作为前缀,更容易在有代码自动补全功能的IDE中区分“属性 
(self.userInfo)”和“成员变量(_userInfo)” 
常量(#define, enums, const等)使用小写“k”作为前缀,首字母大写来分割单词。如: 
kInvalidHandle 
• 注释 
◦ 待完善 
• Cocoa 和 Objective-C特有的规则 
◦ 成员变量使用 @private。如: 
@interface MyClass : NSObject { 
@private 
id _myInstanceVariable; 

// public accessors, setter takes ownership 
- (id)myInstanceVariable; 
- (void)setMyInstanceVariable:(id)theVar; 
@end 
◦ Indentify Designated Initializer 
待完善 
◦ Override Desingated Initializer 
待完善 
◦ 初始化 
在初始化方法中,不要将变量初始化为“0”或“nil”,那是多余的 
内存中所有的新创建的对象(isa除外)都是0,所以不需要重复初始化为“0”或“nil” 
◦ 避免显式的调用 +new 方法 
禁止直接调用 NSObject 的类方法 +new,也不要在子类中重载它。使用alloc和init方法 
◦ 保持公共API的简洁性 
待完善 
◦ #import VS #include 
使用 #import 引入Ojbective-C和Ojbective-C++头文件,使用 #include 引入C和C++头 
文件 
◦ import根框架(root frameworks),而非各单个文件 
虽然有时我们仅需要框架(如Cocoa 或 Foundation)的某几个头文件,但引入根文件编译 
器会运行的更快。因为根框架(root frameworks)一般会预编译,所以加载会更快。再次强 
调:使用 #import 而非 #include 来引入Objective-C框架。如: 
#import <Foundation/NSArray.h> // 禁止 
#import <Foundation/NSString.h> 
... 
#import <Foundation/Foundation.h> // 对头 
◦ 创建对象时尽量使用autorelease 
创建临时对象时,尽量同时在同一行中 autorelease 掉,而非使用单独的 release 语句 
虽然这样会稍微有点慢,但这样可以阻止因为提前 return 或其他意外情况导致的内存泄露。 
通盘来看这是值得的。如: 
// 避免这样使用(除非有性能的考虑) 
MyController* controller = [[MyController alloc] init]; 
// ... 这里的代码可能会提前return ... 
[controller release]; 
// 这样更好 
MyController* controller = [[[MyController alloc] init] autorelease]; 
◦ 先autorelease,再retain 
在为对象赋值时,遵从“先autorelease,再retain” 
在将一个新创建的对象赋给变量时,要先将旧对象release掉,否则会内存泄露。市面上有很 
多方法来handle这种情况,这里选择“先autorelease,再retain”的方法,这种方法不易引 
入error。注意:在循环中这种方法会“填满”autorelease pool,稍稍影响效率,但是 
Google和我( :P )认为这个代价是可以接受的。如: 
- (void)setFoo:(GMFoo *)aFoo { 
[foo_ autorelease]; // 如果foo_和aFoo是同一个对象(foo_ == aFoo), 
dealloc不会被调用 
foo_ = [aFoo retain]; 

◦ dealloc的顺序要与变量声明的顺序相同 
这有利于review代码 
如果dealloc中调用其他方法来release变量,将被release的变量以注释的形式标注清楚 
◦ NSString的属性的setter使用“copy” 
禁止使用retain,以防止意外的修改了NSString变量的值。如: 
- (void)setFoo:(NSString *)aFoo { 
[foo_ autorelease]; 
foo_ = [aFoo copy]; 

或 
@property (nonatomic, copy) NSString *aString; 
◦ 避免抛出异常(Throwing Exceptions) 
待完善 
◦ 对 nil 的检查 
仅在有业务逻辑需求时检查 nil,而非为了防止崩溃 
向 nil 发送消息不会导致系统崩溃,Objective-C运行时负责处理。 
◦ BOOL陷阱 
将int值转换为BOOL时应特别小心。避免直接和YES比较 
Objective-C中,BOOL被定义为unsigned char,这意味着除了 YES (1) 和 NO (0)外它 
还可以是其他值。禁止将int直接转换(cast or convert)为BOOL。 
常见的错误包括:将数组的大小、指针值或位运算符的结果转换(cast or convert)为 
BOOL,因为该BOOL值的结果取决于整型值的最后一位 
将整型值转换为BOOL的方法:使用三元运算符返回YES / NO,或使用位运算符(&&, ||, !) 
BOOL、_Bool和bool之间的转换是安全的,但是BOOL和Boolean间的转换不是安全的,所以 
将Boolean看成整型值。 
在Objective-C中,只允许使用BOOL 
如: 
// 禁止 
- (BOOL)isBold { 
return [self fontTraits] & NSFontBoldTrait; 

- (BOOL)isValid { 
return [self stringValue]; 

// 对头 
- (BOOL)isBold { 
return ([self fontTraits] & NSFontBoldTrait) ? YES : NO; 

- (BOOL)isValid { 
return [self stringValue] != nil; 

- (BOOL)isEnabled { 
return [self isValid] && [self isBold]; 

禁止直接将BOOL和YES/NO比较,如: 
// 禁止 
BOOL great = [foo isGreat]; 
if (great == YES) 
... 
// 对头 
BOOL great = [foo isGreat]; 
if (great) 
... 
◦ 属性 
命名:与去掉“_”前缀的成员变量相同,使用@synthesize将二者联系起来。如: 
// abcd.h 
@interface MyClass : NSObject { 
@private 
NSString *_name; 

@property (copy, nonatomic) NSString *name; 
@end 
// abcd.m 
@implementation MyClass 
@synthesize name = _name; 
@end 
位置:属性的声明紧随成员变量块之后,中间空一行,无缩进。如上例所示 
严把权限:对不需要外部修改的属性使用readonly 
NSString使用copy而非retain 
CFType使用@dynamic, 禁止使用@synthesize 
除非必须,使用nonatomic 
• Cocoa Pattern 
◦ Delegate Pattern(委托) 
delegate对象使用assign,禁止使用retain。因为retain会导致循环索引导致内存泄露, 
并且此类型的内存泄露无法被Instrument发现,极难调试 
成员变量命名为_delegate,属性名为delegate 
◦ Model/View/Controller 
Model和View分离 
不多解释 
Controller独立于View和Controller 
不要在与view相关的类中添加过多的业务逻辑代码,这让代码的可重用性很差 
Controller负责业务逻辑代码,且Controller的代码与view尽量无关 
使用 @protocal 定义回调APIs,如果并非所有方法都是必须的,使用 @optional 标示 
• 其他 
◦ init方法和dealloc方法是是最常用的方法,所以将他们放在类实现的开始位置 
◦ 使用空格将相同的变量、属性对齐,使用换行分组

时间: 2024-10-31 13:04:39

iOS命名规范(转载)的相关文章

Swift常量和变量以及命名规范

我们在上一章中介绍了如何使用Swift编写一个HelloWorld小程序,其中就用到了变量.常量和变量是构成表达式的重要组成部分.常量在声明和初始化变量时,在标识符的前面加上关键字let,就可以把该变量指定为一个常量.顾名思义,常量是其值在使用过程中不会发生变化的量,实例代码如下:let_Hello = "Hello"_Hello标识符就是常量,只能在初始化的时候被赋值,如果我们再次给_Hello赋值,代码如下:_Hello = "Hello, World"则程序会

【转】.net 命名规范(转)

基于.Net框架的Web应用的开发 者,相信没有不使用Visal studio.(有人在使记事本吗?)   如果命名,遵循一个什么什么样的命名声名规范,是Coder特别是初学者很烦恼的问题,因为网上以及身边的五花八门的命名方法让你取舍不定.   命名规范,无论是何种语言,无论是何种时代,没有最优秀的,只有最合适的.只要是便于开发的,便于开发后阅读修改的,便于共享的,便可以称为合适的命名规范.   我在网上查了一些资料,总结出以下一套命名规范.基于.Net框架,适用于c#(VB.Net)语言,用V

C语言项目开发-项目架构和编程命名规范

一个项目的流程: 1.公司市场人员与客户交流,了解客户.引导客户使用公司最优资源并产出一份市场需求文档 2.公司需求人员(BA)与客户交流,了解客户需求并产出一个软件需求文档 3.项目经理.开发小组成员.需求人员(BA)一起开一个需求评审会议,对不合理的地方,    打回给BA,再由BA与客户沟通 4.程序员接到和充分了解软件需求文档后产生软件设计文档(包括概要设计文档和详细设计文档,    涉及到数据库的还需要进行数据库的设计) 5.程序员根据设计文档进行编码.调试.打包发布.如果编写的函数库

iOS编码规范精简版-根据apple、google等规范总结而来

目录 1.格式和换行 2.命名 3.oc下的cocoa编码规范 4.注释要求 5.其他 6.参考文档 附:ARC下编码注意事项 序 此文档根据apple.google以及其他一些业界知名的oc编码规范整理而成,并作了大量精简,旨在为大家的iOS开发规范提供一份简单.清晰.统一的参考指南. 1.格式和换行 1.1 只使用2个空格来缩进,不使用tab. 1.2 方法长度不超过100行,建议不超过80行. 1.3 方法- 和 + 和返回值之前为1个空格:方法参数之间有一个空格,其他地方不出现多余的空格

软件命名规范(版本号)

软件命名规范 软件版本阶段说明 Base版: 此版本表示该软件仅仅是一个假页面链接,通常包括所有的功能和页面布局,但是页面中的功能都没有做完整的实现,只是做为整体网站的一个基础架构. Alpha版: 此版本表示该软件在此阶段主要是以实现软件功能为主,通常只在软件开发者内部交流,一般而言,该版本软件的Bug较多,需要继续修改. Beta版: 该版本相对于α版已有了很大的改进,消除了严重的错误,但还是存在着一些缺陷,需要经过多次测试来进一步消除,此版本主要的修改对像是软件的UI. RC版: (Rel

第2章番外 Java的命名规范

Java开发者对Java的代码风格有自己的规范,良好的代码风格是非常重要的.下面来说下各种命名规范: 包命名(全小写,反写域名) Java引入包的机制很大程度是为了解决重名问题,这有点想C++的命名空间的作用. 包实际上提供了一种命名机制和可见性机制. 为了最大程度地防止重名,包名必须具有唯一性. Java包的名字都是由小写单词组成.但是由于Java面向对象编程的特性,每一名Java程序员都可以编写属于自己的Java包,为了保障每个Java包命名的唯一性,在最新的Java编程规范中,要求程序员在

网站文件命名规范

规范  · 文件命名的原则:以最少的字母达到最容易理解的意义.· 索引文件统一使用index.html文件名(小写) index.html文件统一作为"桥页",不制作具体内容,仅仅作为跳转页和meta标签页.主内容页为main.html · 按菜单名的英语翻译取单一单词为名称.例如: 关于我们 \aboutus 信息反馈 \feedback 产 品 \product 所有单英文单词文件名都必须为小写,所有组合英文单词文件名第二个起第一个字母大写: 所有文件名字母间连线都为下划线 · 图

CSS布局命名规范

CSS布局命名规范 说明:均为class,需要扩展,则在当前命名内以"_"(下划线)后缀自定名称.我习惯称列表页为list,新闻列表则为newslist,图片列表为piclist,内容页为view,/**/整体大框架:#wrapper大框架内:#inwrapper/////////////////////////////////////////////////////////////////////////////////////////////////////////顶部及banne

网页制作 谈谈CSS样式表的命名规范

css|规范|网页|样式表 最近和一程序员合作项目.弄的我头都大了~埋怨我的CSS命名看不懂~得按照他的来.结果我打开他的页面,看了看,从头第一个开始就是contentCommon,下面全部是content****. 我说明了我的理由,过了半会,似乎是接受了,却突然来一句:"不要用H标签嘛!还有不要用UL来定义导航等".对于很多合作过的程序员,大多都是这样,命名规范大多是自成一派.对于制作标准更是视而不见.抱着只照顾IE正常浏览的态度叫嚣着"让FIREFOX和SAFARI见鬼