iOS编码规范 iOS编码规范

本文档旨在总结出一份通用的编码规范，欢迎随时探讨补充。

喜欢我的可以关注收藏我的个人博客：Ro.bber
代码格式
空格

不要在工程里使用Tab键，使用空格来进行缩进。在Xcode > Preferences > Text Editing将Tab和自动缩进都设置为4个空格。（Google的标准是使用两个空格来缩进，但这里还是推荐使用Xcode默认的设置。）
方法之间应该要有一个空行来帮助代码看起来清晰且有组织。方法内的空行应该用来分离功能，但是通常不同的功能应该用新的方法来定义。

方法的书写一个典型的Objective-C函数应该是这样的：

- (void)writeVideoFrameWithData:(NSData *)frameData timeStamp:(int)timeStamp { ... }

在-和(void)之间应该有一个空格，第一个大括号{的位置在函数所在行的末尾，同样应该有一个空格。

在使用{的位置都遵循Egyptian风格 (又称 K&R 风格，代码段括号的开始位于一行的末尾，而不是另外起一行的风格。)，比如，控制语句 (if-else, for, switch)。

如果一个函数有特别多的参数或者名称很长，应该将其按照:来对齐分行显示：

-(id)initWithModel:(IPCModle)model ConnectType:(IPCConnectType)connectType Resolution:(IPCResolution)resolution AuthName:(NSString *)authName Password:(NSString *)password MAC:(NSString *)mac AzIp:(NSString *)az_ip AzDns:(NSString *)az_dns Token:(NSString *)token Email:(NSString *)email Delegate:(id)delegate;

在分行时，如果第一段名称过短，后续名称可以以Tab的长度（4个空格）为单位进行缩进：

- (void)short:(GTMFoo *)theFoo longKeyword:(NSRect)theRect evenLongerKeyword:(float)theInterval error:(NSError **)theError { ... }

函数调用 【iOS编码规范】函数调用的格式和书写差不多，可以按照函数的长短来选择写在一行或者分成多行：

//写在一行 [myObject doFooWith:arg1 name:arg2 error:arg3]; //分行写，按照':'对齐 [myObject doFooWith:arg1 name:arg2 error:arg3]; //第一段名称过短的话后续可以进行缩进 [myObj short:arg1 longKeyword:arg2 evenLongerKeyword:arg3 error:arg4];

@public和@private标记符 @public和@private标记符应该以一个空格来进行缩进：

@interface MyClass : NSObject { @public ... @private ... } @end

协议（Protocols）在书写协议的时候注意用<>括起来的协议和类型名之间是没有空格的，比如IPCConnectHandler(),这个规则适用所有书写协议的地方，包括函数声明、类声明、实例变量等等：

@interface MyProtocoledClass : NSObject { @private id _delegate; }- (void)setDelegate:(id)aDelegate; @end

闭包（Blocks）根据block的长度，有不同的书写规则：

较短的block可以写在一行内。
如果分行显示的话，block的右括号}应该和调用block那行代码的第一个非空字符对齐。
block内的代码采用4个空格的缩进。
如果block过于庞大，应该单独声明成一个变量来使用。
^和(之间，^和{之间都没有空格，参数列表的右括号)和{之间有一个空格。

//较短的block写在一行内 [operation setCompletionBlock:^{ [self onOperationDone]; }]; //分行书写的block，内部使用4空格缩进 [operation setCompletionBlock:^{ [self.delegate newDataAvailable]; }]; //使用C语言API调用的block遵循同样的书写规则 dispatch_async(_fileIOQueue, ^{ NSString* path = [self sessionFilePath]; if (path) { // ... } }); //较长的block关键字可以缩进后在新行书写，注意block的右括号'}'和调用block那行代码的第一个非空字符对齐 [[SessionService sharedService] loadWindowWithCompletionBlock:^(SessionWindow *window) { if (window) { [self windowDidLoad:window]; } else { [self errorLoadingWindow]; } }]; //较长的block参数列表同样可以缩进后在新行书写 [[SessionService sharedService] loadWindowWithCompletionBlock: ^(SessionWindow *window) { if (window) { [self windowDidLoad:window]; } else { [self errorLoadingWindow]; } }]; //庞大的block应该单独定义成变量使用 void (^largeBlock)(void) = ^{ // ... }; [_operationQueue addOperationWithBlock:largeBlock]; //在一个调用中使用多个block，注意到他们不是像函数那样通过':'对齐的，而是同时进行了4个空格的缩进 [myObject doSomethingWith:arg1 firstBlock:^(Foo *a) { // ... } secondBlock:^(Bar *b) { // ... }];

数据结构的语法糖应该使用可读性更好的语法糖来构造NSArray，NSDictionary等数据结构，避免使用冗长的alloc,init方法。
如果构造代码写在一行，需要在括号两端留有一个空格，使得被构造的元素于与构造语法区分开来：

//正确，在语法糖的"[]"或者"{}"两端留有空格 NSArray *array = @[ [foo description], @"Another String", [bar description] ]; NSDictionary *dict = @{ NSForegroundColorAttributeName : [NSColor redColor] }; //不正确，不留有空格降低了可读性 NSArray* array = @[[foo description], [bar description]]; NSDictionary* dict = @{NSForegroundColorAttributeName: [NSColor redColor]};

如果构造代码不写在一行内，构造元素需要使用两个空格来进行缩进，右括号]或者}写在新的一行，并且与调用语法糖那行代码的第一个非空字符对齐：

NSArray *array = @[ @"This", @"is", @"an", @"array" ]; NSDictionary *dictionary = @{ NSFontAttributeName : [NSFont fontWithName:@"Helvetica-Bold" size:12], NSForegroundColorAttributeName : fontColor };

构造字典时，字典的Key和Value与中间的冒号:都要留有一个空格，多行书写时，也可以将Value对齐：

//正确，冒号':'前后留有一个空格 NSDictionary *option1 = @{ NSFontAttributeName : [NSFont fontWithName:@"Helvetica-Bold" size:12], NSForegroundColorAttributeName : fontColor }; //正确，按照Value来对齐 NSDictionary *option2 = @{ NSFontAttributeName :[NSFont fontWithName:@"Arial" size:12], NSForegroundColorAttributeName : fontColor }; //错误，冒号前应该有一个空格 NSDictionary *wrong = @{ AKey:@"b", BLongerKey: @"c", }; //错误，每一个元素要么单独成为一行，要么全部写在一行内 NSDictionary *alsoWrong= @{ AKey : @"a", BLongerKey : @"b" }; //错误，在冒号前只能有一个空格，冒号后才可以考虑按照Value对齐 NSDictionary *stillWrong = @{ AKey: @"b", BLongerKey : @"c", };

命名规范
基本原则

清晰

命名应该尽可能的清晰和简洁，但在Objective-C中，清晰比简洁更重要。由于Xcode强大的自动补全功能，我们不必担心名称过长的问题。

//清晰 insertObject:atIndex://不清晰，insert的对象类型和at的位置属性没有说明 insert:at://清晰 removeObjectAtIndex://不清晰，remove的对象类型没有说明，参数的作用没有说明 remove:

不要使用单词的简写，拼写出完整的单词：

//清晰 destinationSelection setBackgroundColor://不清晰，不要使用简写 destSel setBkgdColor:

然而，有部分单词简写在Objective-C编码过程中是非常常用的，以至于成为了一种规范，这些简写可以在代码中直接使用，下面列举了部分：

alloc== Allocatemax== Maximum alt== Alternatemin== Minimum app== Applicationmsg== Message calc== Calculatenib== Interface Builder archive dealloc == Deallocatepboard == Pasteboard func== Functionrect== Rectangle horiz== HorizontalRep== Representation (used in class name such as NSBitmapImageRep). info== Informationtemp== Temporary init== Initializevert== Vertical int== Integer

命名方法或者函数时要避免歧义

//有歧义，是返回sendPort还是send一个Port？ sendPort//有歧义，是返回一个名字属性的值还是display一个name的动作？ displayName

一致性

整个工程的命名风格要保持一致性，最好和苹果SDK的代码保持统一。不同类中完成相似功能的方法应该叫一样的名字，比如我们总是用count来返回集合的个数，不能在A类中使用count而在B类中使用getNumber。

使用前缀

如果代码需要打包成Framework给别的工程使用，或者工程项目非常庞大，需要拆分成不同的模块，使用命名前缀是非常有用的。

前缀由大写的字母缩写组成，比如Cocoa中NS前缀代表Founation框架中的类，IB则代表Interface Builder框架。
可以在为类、协议、函数、常量以及typedef宏命名的时候使用前缀，但注意不要为成员变量或者方法使用前缀，因为他们本身就包含在类的命名空间内。
命名前缀的时候不要和苹果SDK框架冲突。

命名类和协议(Class & Protocol) 类名以大写字母开头，应该包含一个名词来表示它代表的对象类型，同时可以加上必要的前缀，比如NSString, NSDate, NSScanner, NSApplication等等。
而协议名称应该清晰地表示它所执行的行为，而且要和类名区别开来，所以通常使用ing词尾来命名一个协议，比如NSCopying,NSLocking。
有些协议本身包含了很多不相关的功能，主要用来为某一特定类服务，这时候可以直接用类名来命名这个协议，比如NSObject协议，它包含了id对象在生存周期内的一系列方法。
命名头文件（Headers）源码的头文件名应该清晰地暗示它的功能和包含的内容：

如果头文件内只定义了单个类或者协议，直接用类名或者协议名来命名头文件，比如NSLocale.h定义了NSLocale类。
如果头文件内定义了一系列的类、协议、类别，使用其中最主要的类名来命名头文件，比如NSString.h定义了NSString和NSMutableString。
每一个Framework都应该有一个和框架同名的头文件，包含了框架中所有公共类头文件的引用，比如Foundation.h
Framework中有时候会实现在别的框架中类的类别扩展，这样的文件通常使用被扩展的框架名+Additions的方式来命名，比如NSBundleAdditions.h。

命名方法（Methods） Objective-C的方法名通常都比较长，这是为了让程序有更好地可读性，按苹果的说法“好的方法名应当可以以一个句子的形式朗读出来”。
方法一般以小写字母打头，每一个后续的单词首字母大写，方法名中不应该有标点符号（包括下划线），有两个例外：

可以用一些通用的大写字母缩写打头方法，比如PDF,TIFF等。
可以用带下划线的前缀来命名私有方法或者类别中的方法。

如果方法表示让对象执行一个动作，使用动词打头来命名，注意不要使用do，does这种多余的关键字，动词本身的暗示就足够了：

//动词打头的方法表示让对象执行一个动作 - (void)invokeWithTarget:(id)target; - (void)selectTabViewItem:(NSTabViewItem *)tabViewItem;

如果方法是为了获取对象的一个属性值，直接用属性名称来命名这个方法，注意不要添加get或者其他的动词前缀：

//正确，使用属性名来命名方法 - (NSSize)cellSize; //错误，添加了多余的动词前缀 - (NSSize)calcCellSize; - (NSSize)getCellSize;

对于有多个参数的方法，务必在每一个参数前都添加关键词，关键词应当清晰说明参数的作用：

//正确，保证每个参数都有关键词修饰 - (void)sendAction:(SEL)aSelector toObject:(id)anObject forAllCells:(BOOL)flag; //错误，遗漏关键词 - (void)sendAction:(SEL)aSelector :(id)anObject :(BOOL)flag; //正确 - (id)viewWithTag:(NSInteger)aTag; //错误，关键词的作用不清晰 - (id)taggedView:(int)aTag;

不要用and来连接两个参数，通常and用来表示方法执行了两个相对独立的操作（从设计上来说，这时候应该拆分成两个独立的方法）：

//错误，不要使用"and"来连接参数 - (int)runModalForDirectory:(NSString *)path andFile:(NSString *)name andTypes:(NSArray *)fileTypes; //正确，使用"and"来表示两个相对独立的操作 - (BOOL)openFile:(NSString *)fullPath withApplication:(NSString *)appName andDeactivate:(BOOL)flag;

方法的参数命名也有一些需要注意的地方:

和方法名类似，参数的第一个字母小写，后面的每一个单词首字母大写
不要再方法名中使用类似pointer,ptr这样的字眼去表示指针，参数本身的类型足以说明
不要使用只有一两个字母的参数名
不要使用简写，拼出完整的单词

下面列举了一些常用参数名：

...action:(SEL)aSelector ...alignment:(int)mode ...atIndex:(int)index ...content:(NSRect)aRect ...doubleValue:(double)aDouble ...floatValue:(float)aFloat ...font:(NSFont *)fontObj ...frame:(NSRect)frameRect ...intValue:(int)anInt ...keyEquivalent:(NSString *)charCode ...length:(int)numBytes ...point:(NSPoint)aPoint ...stringValue:(NSString *)aString ...tag:(int)anInt ...target:(id)anObject ...title:(NSString *)aString

存取方法（Accessor Methods）存取方法是指用来获取和设置类属性值的方法，属性的不同类型，对应着不同的存取方法规范：

//属性是一个名词时的存取方法范式 - (type)noun; - (void)setNoun:(type)aNoun; //栗子 - (NSString *)title; - (void)setTitle:(NSString *)aTitle; //属性是一个形容词时存取方法的范式 - (BOOL)isAdjective; - (void)setAdjective:(BOOL)flag; //栗子 - (BOOL)isEditable; - (void)setEditable:(BOOL)flag; //属性是一个动词时存取方法的范式 - (BOOL)verbObject; - (void)setVerbObject:(BOOL)flag; //栗子 - (BOOL)showsAlpha; - (void)setShowsAlpha:(BOOL)flag;

命名存取方法时不要将动词转化为被动形式来使用：

//正确 - (void)setAcceptsGlyphInfo:(BOOL)flag; - (BOOL)acceptsGlyphInfo; //错误，不要使用动词的被动形式 - (void)setGlyphInfoAccepted:(BOOL)flag; - (BOOL)glyphInfoAccepted;

可以使用can,should,will等词来协助表达存取方法的意思，但不要使用do,和does：

//正确 - (void)setCanHide:(BOOL)flag; - (BOOL)canHide; - (void)setShouldCloseDocument:(BOOL)flag; - (BOOL)shouldCloseDocument; //错误，不要使用"do"或者"does" - (void)setDoesAcceptGlyphInfo:(BOOL)flag; - (BOOL)doesAcceptGlyphInfo;

为什么Objective-C中不适用get前缀来表示属性获取方法？因为get在Objective-C中通常只用来表示从函数指针返回值的函数：

//三个参数都是作为函数的返回值来使用的，这样的函数名可以使用"get"前缀 - (void)getLineDash:(float *)pattern count:(int *)count phase:(float *)phase;

命名委托（Delegate）当特定的事件发生时，对象会触发它注册的委托方法。委托是Objective-C中常用的传递消息的方式。委托有它固定的命名范式。
一个委托方法的第一个参数是触发它的对象，第一个关键词是触发对象的类名，除非委托方法只有一个名为sender的参数：

//第一个关键词为触发委托的类名 - (BOOL)tableView:(NSTableView *)tableView shouldSelectRow:(int)row; - (BOOL)application:(NSApplication *)sender openFile:(NSString *)filename; //当只有一个"sender"参数时可以省略类名 - (BOOL)applicationOpenUntitledFile:(NSApplication *)sender;

根据委托方法触发的时机和目的，使用should,will,did等关键词

- (void)browserDidScroll:(NSBrowser *)sender; - (NSUndoManager *)windowWillReturnUndoManager:(NSWindow *)window; 、- (BOOL)windowShouldClose:(id)sender;

集合操作类方法（Collection Methods）有些对象管理着一系列其它对象或者元素的集合，需要使用类似“增删查改”的方法来对集合进行操作，这些方法的命名范式一般为：

//集合操作范式 - (void)addElement:(elementType)anObj; - (void)removeElement:(elementType)anObj; - (NSArray *)elements; //栗子 - (void)addLayoutManager:(NSLayoutManager *)obj; - (void)removeLayoutManager:(NSLayoutManager *)obj; - (NSArray *)layoutManagers;

注意，如果返回的集合是无序的，使用NSSet来代替NSArray。如果需要将元素插入到特定的位置，使用类似于这样的命名：

- (void)insertLayoutManager:(NSLayoutManager *)obj atIndex:(int)index; - (void)removeLayoutManagerAtIndex:(int)index;

如果管理的集合元素中有指向管理对象的指针，要设置成weak类型以防止引用循环。
下面是SDK中NSWindow类的集合操作方法：

- (void)addChildWindow:(NSWindow *)childWin ordered:(NSWindowOrderingMode)place; - (void)removeChildWindow:(NSWindow *)childWin; - (NSArray *)childWindows; - (NSWindow *)parentWindow; - (void)setParentWindow:(NSWindow *)window;

命名函数（Functions）在很多场合仍然需要用到函数，比如说如果一个对象是一个单例，那么应该使用函数来代替类方法执行相关操作。
函数的命名和方法有一些不同，主要是：

函数名称一般带有缩写前缀，表示方法所在的框架。
前缀后的单词以“驼峰”表示法显示，第一个单词首字母大写。

函数名的第一个单词通常是一个动词，表示方法执行的操作：

NSHighlightRect NSDeallocateObject

如果函数返回其参数的某个属性，省略动词：

unsigned int NSEventMaskFromType(NSEventType type) float NSHeight(NSRect aRect)

如果函数通过指针参数来返回值，需要在函数名中使用Get：

const char *NSGetSizeAndAlignment(const char *typePtr, unsigned int *sizep, unsigned int *alignp)

函数的返回类型是BOOL时的命名：

BOOL NSDecimalIsNotANumber(const NSDecimal *decimal)

命名属性和实例变量（Properties&Instance Variables）属性和对象的存取方法相关联，属性的第一个字母小写，后续单词首字母大写，不必添加前缀。属性按功能命名成名词或者动词：

//名词属性 @property (strong) NSString *title; //动词属性 @property (assign) BOOL showsAlpha;

属性也可以命名成形容词，这时候通常会指定一个带有is前缀的get方法来提高可读性：

@property (assign, getter=isEditable) BOOL editable;

命名实例变量，在变量名前加上_前缀（有些有历史的代码会将_放在后面），其它和命名属性一样：

@implementation MyClass { BOOL _showsTitle; }

一般来说，类需要对使用者隐藏数据存储的细节，所以不要将实例方法定义成公共可访问的接口，可以使用@private，@protected前缀。
按苹果的说法，不建议在除了init和dealloc方法以外的地方直接访问实例变量，但很多人认为直接访问会让代码更加清晰可读，只在需要计算或者执行操作的时候才使用存取方法访问，我就是这种习惯，所以这里不作要求。
命名常量（Constants）如果要定义一组相关的常量，尽量使用枚举类型（enumerations），枚举类型的命名规则和函数的命名规则相同。
建议使用 NS_ENUM 和 NS_OPTIONS 宏来定义枚举类型，参见官方的 Adopting Modern Objective-C 一文：

//定义一个枚举 typedef NS_ENUM(NSInteger, NSMatrixMode) { NSRadioModeMatrix, NSHighlightModeMatrix, NSListModeMatrix, NSTrackModeMatrix };

定义bit map：

typedef NS_OPTIONS(NSUInteger, NSWindowMask) { NSBorderlessWindowMask= 0, NSTitledWindowMask= 1 << 0, NSClosableWindowMask= 1 << 1, NSMiniaturizableWindowMask= 1 << 2, NSResizableWindowMask= 1 << 3 };

使用const定义浮点型或者单个的整数型常量，如果要定义一组相关的整数常量，应该优先使用枚举。常量的命名规范和函数相同：

const float NSLightGray;

不要使用#define宏来定义常量，如果是整型常量，尽量使用枚举，浮点型常量，使用const定义。#define通常用来给编译器决定是否编译某块代码，比如常用的：

#ifdef DEBUG

注意到一般由编译器定义的宏会在前后都有一个__，比如__MACH__。
命名通知（Notifications）通知常用于在模块间传递消息，所以通知要尽可能地表示出发生的事件，通知的命名范式是：

[触发通知的类名] + [Did | Will] + [动作] + Notification

栗子：

NSApplicationDidBecomeActiveNotification NSWindowDidMiniaturizeNotification NSTextViewDidChangeSelectionNotification NSColorPanelColorDidChangeNotification

命名类别（Categories）虽然我们知道这样写很丑, 但是我们应该要在我们的 category 方法前加上自己的小写前缀以及下划线，比如- (id)zoc_myCategoryMethod。这种实践同样被苹果推荐。
一个好的实践是在 category 名中使用前缀。
例子

@interface NSDate (ZOCTimeExtensions) - (NSString *)zoc_timeAgoShort; @end

注释
读没有注释代码的痛苦你我都体会过，好的注释不仅能让人轻松读懂你的程序，还能提升代码的逼格。注意注释是为了让别人看懂，而不是仅仅你自己。
文件注释每一个文件都必须写文件注释，文件注释通常包含

文件所在模块
作者信息
历史版本信息
版权信息
文件包含的内容，作用

一段良好文件注释的栗子：

/******************************************************************************* Copyright (C), 2011-2013, Andrew Min ChangFile name:AMCCommonLib.h Author:Andrew Chang (Zhang Min) E-mail:LaplaceZhang@126.comDescription: This file provide some covenient tool in calling library tools. One can easily include library headers he wants by declaring the corresponding macros. I hope this file is not only a header, but also a useful Linux library note.History: 2012-??-??: On about come date around middle of Year 2012, file created as "commonLib.h" 2012-08-20: Add shared memory library; add message queue. 2012-08-21: Add socket library (local) 2012-08-22: Add math library 2012-08-23: Add socket library (internet) 2012-08-24: Add daemon function 2012-10-10: Change file name as "AMCCommonLib.h" 2012-12-04: Add UDP support in AMC socket library 2013-01-07: Add basic data type such as "sint8_t" 2013-01-18: Add CFG_LIB_STR_NUM. 2013-01-22: Add CFG_LIB_TIMER. 2013-01-22: Remove CFG_LIB_DATA_TYPE because there is already AMCDataTypes.hCopyright information: This file was intended to be under GPL protocol. However, I may use this library in my work as I am an employee. And my company may require me to keep it secret. Therefore, this file is neither open source nor under GPL control. ********************************************************************************/

文件注释的格式通常不作要求，能清晰易读就可以了，但在整个工程中风格要统一。
代码注释好的代码应该是“自解释”（self-documenting）的，但仍然需要详细的注释来说明参数的意义、返回值、功能以及可能的副作用。
方法、函数、类、协议、类别的定义都需要注释，推荐采用Apple的标准注释风格，好处是可以在引用的地方alt+点击自动弹出注释，非常方便。
有很多可以自动生成注释格式的插件，推荐使用系统自带方法注释功能（Cmd + Alt + /）：

文章图片
Screenshot 一些良好的注释：

/** *Create a new preconnector to replace the old one with given mac address. *NOTICE: We DO NOT stop the old preconnector, so handle it by yourself. * *@param typeConnect type the preconnector use. *@param macAddress Preconnector's mac address. */ - (void)refreshConnectorWithConnectType:(IPCConnectType)typeMac:(NSString *)macAddress; /** *Stop current preconnecting when application is going to background. */ -(void)stopRunning; /** *Get the COPY of cloud device with a given mac address. * *@param macAddress Mac address of the device. * *@return Instance of IPCCloudDevice. */ -(IPCCloudDevice *)getCloudDeviceWithMac:(NSString *)macAddress; // A delegate for NSApplication to handle notifications about app // launch and shutdown. Owned by the main app controller. @interface MyAppDelegate : NSObject { ... } @end

协议、委托的注释要明确说明其被触发的条件：

/** Delegate - Sent when failed to init connection, like p2p failed. */ -(void)initConnectionDidFailed:(IPCConnectHandler *)handler;

如果在注释中要引用参数名或者方法函数名，使用||将参数或者方法括起来以避免歧义：

// Sometimes we need |count| to be less than zero.// Remember to call |StringWithoutSpaces("foo bar baz")|

定义在头文件里的接口方法、属性必须要有注释！
编码风格
每个人都有自己的编码风格，这里总结了一些比较好的Cocoa编程风格和注意点。
不要使用尤达表达式尤达表达式是指，拿一个常量去和变量比较而不是拿变量去和常量比较。它就像是在表达 “蓝色是不是天空的颜色” 或者 “高个是不是这个男人的属性” 而不是 “天空是不是蓝的” 或者 “这个男人是不是高个子的”
推荐:

if ([myValue isEqual:@42]) { ...

不推荐:

if ([@42 isEqual:myValue]) { ...

黄金大道在使用条件语句编程时，代码的左边距应该是一条“黄金”或者“快乐”的大道。也就是说，不要嵌套 if 语句。使用多个 return 可以避免增加循环的复杂度，并提高代码的可读性。因为方法的重要部分没有嵌套在分支里面，并且你可以很清楚地找到相关的代码。
推荐:

- (void)someMethod { if (![someOther boolValue]) { return; }//Do something important }

不推荐:

- (void)someMethod { if ([someOther boolValue]) { //Do something important } }

复杂的表达式当你有一个复杂的 if 子句的时候，你应该把它们提取出来赋给一个 BOOL 变量，这样可以让逻辑更清楚，而且让每个子句的意义体现出来。

BOOL nameContainsSwift= [sessionName containsString:@"Swift"]; BOOL isCurrentYear= [sessionDateCompontents year] == 2014; BOOL isSwiftSession= nameContainsSwift && isCurrentYear; if (isSwiftSession) { // Do something very cool }

三元运算符三元运算符 ? 应该只用在它能让代码更加清楚的地方。一个条件语句的所有的变量应该是已经被求值了的。类似 if 语句，计算多个条件子句通常会让语句更加难以理解。或者可以把它们重构到实例变量里面。
推荐:

result = a > b ? x : y;

不推荐:

result = a > b ? x = c > d ? c : d : y;

当三元运算符的第二个参数（if 分支）返回和条件语句中已经检查的对象一样的对象的时候，下面的表达方式更灵巧：
推荐:

result = object ? : [self createObject];

不推荐:

result = object ? object : [self createObject];

Pragma Pragma Mark #pragma mark - 是一个在类内部组织代码并且帮助你分组方法实现的好办法。我们建议使用 #pragma mark - 来分离:

不同功能组的方法
protocols 的实现
对父类方法的重写

- (void)dealloc { /* ... */ } - (instancetype)init { /* ... */ }#pragma mark - View Lifecycle （View 的生命周期）- (void)viewDidLoad { /* ... */ } - (void)viewWillAppear:(BOOL)animated { /* ... */ } - (void)didReceiveMemoryWarning { /* ... */ }#pragma mark - Custom Accessors （自定义访问器）- (void)setCustomProperty:(id)value { /* ... */ } - (id)customProperty { /* ... */ }#pragma mark - IBActions- (IBAction)submitData:(id)sender { /* ... */ }#pragma mark - Public - (void)publicMethod { /* ... */ }#pragma mark - Private- (void)zoc_privateMethod { /* ... */ }#pragma mark - UITableViewDataSource- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { /* ... */ }#pragma mark - ZOCSuperclass// ... 重载来自 ZOCSuperclass 的方法#pragma mark - NSObject- (NSString *)description { /* ... */ }

上面的标记能明显分离和组织代码。你还可以用 cmd+Click 来快速跳转到符号定义地方。但是小心，即使 paragma mark 是一门手艺，但是它不是让你类里面方法数量增加的一个理由：类里面有太多方法说明类做了太多事情，需要考虑重构了。
关于 pragma 在 http://raptureinvenice.com/pragmas-arent-just-for-marks 有很好的关于 pragma 的讨论了，在这边我们再做部分说明。
大多数 iOS 开发者平时并没有和很多编译器选项打交道。一些选项是对控制严格检查（或者不检查）你的代码或者错误的。有时候，你想要用 pragma 直接产生一个异常，临时打断编译器的行为。
当你使用ARC的时候，编译器帮你插入了内存管理相关的调用。但是这样可能产生一些烦人的事情。比如你使用 NSSelectorFromString 来动态地产生一个 selector 调用的时候，ARC不知道这个方法是哪个并且不知道应该用那种内存管理方法，你会被提示

performSelector may cause a leak because its selector is unknown（执行 selector 可能导致泄漏，因为这个 selector 是未知的）

.
如果你知道你的代码不会导致内存泄露，你可以通过加入这些代码忽略这些警告

#pragma clang diagnostic push #pragma clang diagnostic ignored "-Warc-performSelector-leaks"[myObj performSelector:mySelector withObject:name]; #pragma clang diagnostic pop

注意我们是如何在相关代码上下文中用 pragma 停用 -Warc-performSelector-leaks 检查的。这确保我们没有全局禁用。如果全局禁用，可能会导致错误。
全部的选项可以在 The Clang User's Manual 找到并且学习。
忽略没用使用变量的编译警告告诉你申明的变量它将不会被使用，这种做法很有用。大多数情况下，你希望移除这些引用来（稍微地）提高性能，但是有时候你希望保留它们。为什么？或许它们以后有用，或者有些特性只是暂时移除。无论如何，一个消除这些警告的好方法是用相关语句进行注解，使用 #pragma unused():

- (NSInteger)giveMeFive { NSString *foo; #pragma unused (foo)return 5; }

现在你的代码不用任何编译警告了。注意你的 pragma 需要标记到问题代码之下。
明确编译器警告和错误编译器是一个机器人，它会标记你代码中被 Clang 规则定义为错误的地方。但是，你总是比 Clang 更聪明。通常，你会发现一些讨厌的代码会导致这个问题，但是暂时却解决不了。你可以这样明确一个错误：

- (NSInteger)divide:(NSInteger)dividend by:(NSInteger)divisor { #error Whoa, buddy, you need to check for zero here! return (dividend / divisor); }

类似的，你可以这样标明一个警告

- (float)divide:(float)dividend by:(float)divisor { #warning Dude, don't compare floating point numbers like this! if (divisor != 0.0) { return (dividend / divisor); } else { return NAN; } }

NSCache

构建缓存时选用NSCache 而非NSDictionary

如果我们缓存使用得当，那么应用程序的响应速度就会提高。只有那种“重新计算起来很费事的数据，才值得放入缓存”，比如那些需要从网络获取或从磁盘读取的数据。
在构建缓存的时候很多人习惯用NSDictionary或者NSMutableDictionary，但是作者建议大家使用NSCache，它作为管理缓存的类，有很多特点要优于字典，因为它本来就是为了管理缓存而设计的。

NSCache优于NSDictionary的几点：
- 当系统资源将要耗尽时，NSCache具备自动删减缓冲的功能。并且还会先删减“最久未使用”的对象。
- NSCache不拷贝键，而是保留键。因为并不是所有的键都遵从拷贝协议（字典的键是必须要支持拷贝协议的，有局限性）。
- NSCache是线程安全的：不编写加锁代码的前提下，多个线程可以同时访问NSCache。

不要使用new方法尽管很多时候能用new代替alloc init方法，但这可能会导致调试内存时出现不可预料的问题。Cocoa的规范就是使用alloc init方法，使用new会让一些读者困惑。
#import和#include #import是Cocoa中常用的引用头文件的方式，它能自动防止重复引用文件，什么时候使用#import，什么时候使用#include呢？

当引用的是一个Objective-C或者Objective-C++的头文件时，使用#import
当引用的是一个C或者C++的头文件时，使用#include，这时必须要保证被引用的文件提供了保护域（#define guard）。

栗子：

#import #include #import "GTMFoo.h" #include "base/basictypes.h"

为什么不全部使用#import呢？主要是为了保证代码在不同平台间共享时不出现问题。
引用框架的根头文件上面提到过，每一个框架都会有一个和框架同名的头文件，它包含了框架内接口的所有引用，在使用框架的时候，应该直接引用这个根头文件，而不是其它子模块的头文件，即使是你只用到了其中的一小部分，编译器会自动完成优化的。

//正确，引用根头文件 #import //错误，不要单独引用框架内的其它头文件 #import #import

BOOL的使用 BOOL在Objective-C中被定义为signed char类型，这意味着一个BOOL类型的变量不仅仅可以表示YES(1)和NO(0)两个值，所以永远不要将BOOL类型变量直接和YES比较：

//错误，无法确定|great|的值是否是YES(1)，不要将BOOL值直接与YES比较 BOOL great = [foo isGreat]; if (great == YES) // ...be great!//正确 BOOL great = [foo isGreat]; if (great) // ...be great!

同样的，也不要将其它类型的值作为BOOL来返回，这种情况下，BOOL变量只会取值的最后一个字节来赋值，这样很可能会取到0（NO）。但是，一些逻辑操作符比如&&,||,!的返回是可以直接赋给BOOL的：

//错误，不要将其它类型转化为BOOL返回 - (BOOL)isBold { return [self fontTraits] & NSFontBoldTrait; } - (BOOL)isValid { return [self stringValue]; }//正确 - (BOOL)isBold { return ([self fontTraits] & NSFontBoldTrait) ? YES : NO; }//正确，逻辑操作符可以直接转化为BOOL - (BOOL)isValid { return [self stringValue] != nil; } - (BOOL)isEnabled { return [self isValid] && [self isBold]; }

另外BOOL类型可以和_Bool,bool相互转化，但是不能和Boolean转化。
在init和dealloc中不要用存取方法访问实例变量当init``dealloc方法被执行时，类的运行时环境不是处于正常状态的，使用存取方法访问变量可能会导致不可预料的结果，因此应当在这两个方法内直接访问实例变量。

//正确，直接访问实例变量 - (instancetype)init { self = [super init]; if (self) { _bar = [[NSMutableString alloc] init]; } return self; } - (void)dealloc { [_bar release]; [super dealloc]; }//错误，不要通过存取方法访问 - (instancetype)init { self = [super init]; if (self) { self.bar = [NSMutableString string]; } return self; } - (void)dealloc { self.bar = nil; [super dealloc]; }

保证NSString在赋值时被复制 NSString非常常用，在它被传递或者赋值时应当保证是以复制（copy）的方式进行的，这样可以防止在不知情的情况下String的值被其它对象修改。

- (void)setFoo:(NSString *)aFoo { _foo = [aFoo copy]; }

使用NSNumber的语法糖使用带有@符号的语法糖来生成NSNumber对象能使代码更简洁：

NSNumber *fortyTwo = @42; NSNumber *piOverTwo = @(M_PI / 2); enum { kMyEnum = 2; }; NSNumber *myEnum = @(kMyEnum);

nil检查因为在Objective-C中向nil对象发送命令是不会抛出异常或者导致崩溃的，只是完全的“什么都不干”，所以，只在程序中使用nil来做逻辑上的检查。
另外，不要使用诸如nil == Object或者Object == nil的形式来判断。

//正确，直接判断 if (!objc) { ... }//错误，不要使用nil == Object的形式 if (nil == objc) { ... }

Delegate要使用弱引用一个类的Delegate对象通常还引用着类本身，这样很容易造成引用循环的问题，所以类的Delegate属性要设置为弱引用。

/** delegate */ @property (nonatomic, weak) id delegate;

单例使用dispatch_once来生成单例，建议单例类方法名命名保持一致。
推荐这样写：

+ (instancetype)sharedInstance { static id sharedInstance = nil; static dispatch_once_t onceToken = 0; dispatch_once(&onceToken, ^{ sharedInstance = [[self alloc] init]; }); return sharedInstance; }

Block循环引用问题当使用代码块和异步分发的时候，要注意避免引用循环。总是使用 weak 来引用对象，避免引用循环。（译者注：这里更为优雅的方式是采用影子变量@weakify/@strongify 这里有更为详细的说明）此外，把持有 block 的属性设置为 nil (比如 self.completionBlock = nil) 是一个好的实践。它会打破 block 捕获的作用域带来的引用循环。
例子:

__weak __typeof(self) weakSelf = self; [self executeBlock:^(NSData *data, NSError *error) { [weakSelf doSomethingWithData:data]; }];

不要这样:

[self executeBlock:^(NSData *data, NSError *error) { [self doSomethingWithData:data]; }];

多个语句的例子:

__weak __typeof(self)weakSelf = self; [self executeBlock:^(NSData *data, NSError *error) { __strong __typeof(weakSelf) strongSelf = weakSelf; if (strongSelf) { [strongSelf doSomethingWithData:data]; [strongSelf doSomethingWithData:data]; } }];

不要这样:

__weak __typeof(self)weakSelf = self; [self executeBlock:^(NSData *data, NSError *error) { [weakSelf doSomethingWithData:data]; [weakSelf doSomethingWithData:data]; }];

你应该把这两行代码作为 snippet 加到 Xcode 里面并且总是这样使用它们。

__weak __typeof(self)weakSelf = self; __strong __typeof(weakSelf)strongSelf = weakSelf;

这里我们来讨论下 block 里面的 self 的 __weak 和 __strong 限定词的一些微妙的地方。简而言之，我们可以参考 self 在 block 里面的三种不同情况。

直接在 block 里面使用关键词 self
在 block 外定义一个 __weak 的引用到 self，并且在 block 里面使用这个弱引用
在 block 外定义一个 __weak 的引用到 self，并在在 block 内部通过这个弱引用定义一个 __strong的引用。

方案 1. 直接在 block 里面使用关键词 self
如果我们直接在 block 里面用 self 关键字，对象会在 block 的定义时候被 retain，（实际上 block 是 copied但是为了简单我们可以忽略这个）。
一个 const 的对 self 的引用在 block 里面有自己的位置并且它会影响对象的引用计数。
如果这个block被其他的类使用并且(或者)彼此间传来传去，我们可能想要在 block 中保留 self，就像其他在 block 中使用的对象一样. 因为他们是block执行所需要的.

dispatch_block_t completionBlock = ^{ NSLog(@"%@", self); }MyViewController *myController = [[MyViewController alloc] init...]; [self presentViewController:myController animated:YES completion:completionHandler];

没啥大不了。但是如果通过一个属性中的 self 保留了这个 block（就像下面的例程一样）,对象( self )保留了 block 会怎么样呢？

self.completionHandler = ^{ NSLog(@"%@", self); }MyViewController *myController = [[MyViewController alloc] init...]; [self presentViewController:myController animated:YES completion:self.completionHandler];

这就是有名的 retain cycle, 并且我们通常应该避免它。这种情况下我们收到 CLANG 的警告：

Capturing 'self' strongly in this block is likely to lead to a retain cycle （在 block 里面发现了 `self` 的强引用，可能会导致循环引用）

所以 __weak 就有用武之地了。
方案 2. 在 block 外定义一个 __weak 的引用到 self，并且在 block 里面使用这个弱引用
这样会避免循坏引用，也是通常情况下我们的block作为类的属性被self retain 的时候会做的。

__weak typeof(self) weakSelf = self; self.completionHandler = ^{ NSLog(@"%@", weakSelf); }; MyViewController *myController = [[MyViewController alloc] init...]; [self presentViewController:myController animated:YES completion:self.completionHandler];

这个情况下 block 没有 retain 对象并且对象在属性里面 retain 了 block 。所以这样我们能保证了安全的访问 self。不过糟糕的是，它可能被设置成 nil 的。问题是：如何让 self 在 block 里面安全地被销毁。
考虑这么个情况：block 作为属性(property)赋值的结果，从一个对象被复制到另一个对象(如 myController)，在这个复制的 block 执行之前，前者（即之前的那个对象）已经被解除分配。
下面的更有意思。
方案 3. 在 block 外定义一个 __weak 的引用到 self，并在在 block 内部通过这个弱引用定义一个__strong 的引用
你可能会想，首先，这是避免 retain cycle 警告的一个技巧。这不是重点，这个 self 的强引用是在block 执行时被创建的，但是否使用 self 在 block 定义时就已经定下来了，因此self (在block执行时) 会被 retain。
Apple 文档中表示 "为了 non-trivial cycles ，你应该这样" ：

MyViewController *myController = [[MyViewController alloc] init...]; // ... MyViewController * __weak weakMyController = myController; myController.completionHandler =^(NSInteger result) { MyViewController *strongMyController = weakMyController; if (strongMyController) { // ... [strongMyController dismissViewControllerAnimated:YES completion:nil]; // ... } else { // Probably nothing... } };

首先，我觉得这个例子看起来是错误的。如果 block 本身在 completionHandler 属性中被 retain 了，那么 self 如何被 delloc 和在 block 之外赋值为 nil 呢? completionHandler 属性可以被声明为 assign 或者 unsafe_unretained 的，来允许对象在 block 被传递之后被销毁。
我不能理解这样做的理由，如果其他对象需要这个对象（self），block 被传递的时候应该 retain 对象，所以 block 应该不被作为属性存储。这种情况下不应该用 __weak/__strong
总之，其他情况下，希望 weakSelf 变成 nil 的话，就像第二种情况解释那么写（在 block 之外定义一个弱应用并且在 block 里面使用）。
还有，Apple的 "trivial block" 是什么呢。我们的理解是 trivial block 是一个不被传送的 block ，它在一个良好定义和控制的作用域里面，weak 修饰只是为了避免循环引用。
虽然有 Kazuki Sakamoto 和 Tomohiko Furumoto) 讨论的一些的在线参考, Matt Galloway 的 (Effective Objective-C 2.0 和 Pro Multithreading and Memory Management for iOS and OS X ，大多数开发者始终没有弄清楚概念。
在 block 内用强引用的优点是，抢占执行的时候的鲁棒性。在 block 执行的时候, 再次温故下上面的三个例子：
方案 1. 直接在 block 里面使用关键词 self
如果 block 被属性 retain，self 和 block 之间会有一个循环引用并且它们不会再被释放。如果 block 被传送并且被其他的对象 copy 了，self 在每一个 copy 里面被 retain
方案 2. 在 block 外定义一个 __weak 的引用到 self，并且在 block 里面使用这个弱引用
不管 block 是否通过属性被 retain ，这里都不会发生循环引用。如果 block 被传递或者 copy 了，在执行的时候，weakSelf 可能已经变成 nil。
block 的执行可以抢占，而且对 weakSelf 指针的调用时序不同可以导致不同的结果(如：在一个特定的时序下 weakSelf 可能会变成 nil )。

__weak typeof(self) weakSelf = self; dispatch_block_t block =^{ [weakSelf doSomething]; // weakSelf != nil // preemption, weakSelf turned nil [weakSelf doSomethingElse]; // weakSelf == nil };

方案 3. 在 block 外定义一个 __weak 的引用到 self，并在在 block 内部通过这个弱引用定义一个__strong 的引用。
不管 block 是否通过属性被 retain ，这里也不会发生循环引用。如果 block 被传递到其他对象并且被复制了，执行的时候，weakSelf 可能被nil，因为强引用被赋值并且不会变成nil的时候，我们确保对象在 block 调用的完整周期里面被 retain了，如果抢占发生了，随后的对 strongSelf 的执行会继续并且会产生一样的值。如果 strongSelf 的执行到 nil，那么在 block 不能正确执行前已经返回了。

__weak typeof(self) weakSelf = self; myObj.myBlock =^{ __strong typeof(self) strongSelf = weakSelf; if (strongSelf) { [strongSelf doSomething]; // strongSelf != nil // preemption, strongSelf still not nil（抢占的时候，strongSelf 还是非 nil 的) [strongSelf doSomethingElse]; // strongSelf != nil } else { // Probably nothing... return; } };

在ARC条件中，如果尝试用 -> 符号访问一个实例变量，编译器会给出非常清晰的错误信息：

Dereferencing a __weak pointer is not allowed due to possible null value caused by race condition, assign it to a strong variable first. (对一个 __weak 指针的解引用不允许的，因为可能在竞态条件里面变成 null, 所以先把他定义成 strong 的属性)

可以用下面的代码展示