iOS客户端代码规范内部1.0(Objective-C)

2020-02-15 本文已影响0人 Mr_xuy

前言

在一个开发团队中，大家各有各的代码规范，长此以往项目将变得越来越难以维护，下面我结合自己的日常规范同时参考同行的一些规范整理 Objective-C 版iOS客户端代码规范如下：
参考：Apple OC 编码规范
 搜狐

整个工程的命名风格要保持一致性，最好和苹果SDK的代码保持统一。不同类中完成相似功能的方法应该叫一样的名字，比如我们总是用count来返回集合的个数，不能在A类中使用count而在B类中使用getNumber。
如果代码需要打包成Framework给别的工程使用，或者工程项目非常庞大，需要拆分成不同的模块，使用命名前缀是非常有用的。

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

通常我们整个项目应有统一的前缀，比如用公司英文名：AS(aerospace)、HT(hangtian)，若提供给外部一些Framework可相应在统一前缀后加相应前缀如：ASC(航天通勤 Aerospace commuter)、AST(航天差旅 Aerospace travel)

命名类和协议

类名以大写字母开头，应该包含一个名词来表示它代表的对象类型，同时可以加上必要的前缀，比如NSString, NSDate, NSScanner, NSApplication等等。

协议名称应该清晰地表示它所执行的行为，而且要和类名区别开来，所以通常使用ing词尾来命名一个协议，比如NSCopying、NSLocking。

在我们实际项目中，通常使用很多协议-委托模式，此时应以Delegate、DataSource词尾来命名一个协议，比如UITableViewDelegate、UITableViewDataSource，delegate偏重于用户交互的回调协议，datasource偏重于数据的回调协议。

命名头文件

如果头文件内只定义了单个类或者协议，直接用类名或者协议名来命名头文件，比如NSLocale.h定义了NSLocale类。
如果头文件内定义了一系列的类、协议、类别，使用其中最主要的类名来命名头文件，比如NSString.h定义了NSString和NSMutableString。
每一个Framework都应该有一个和框架同名的头文件，包含了框架中所有公共类头文件的引用，比如Foundation.h
在我们的项目中，我们可以使用PCH文件来包含项目中所有公共类文件的引用，但公共类文件最好有分类（区分），比如逻辑处理相关、UI相关、日期相关、校验相关、加密相关等。

命名方法

Objective-C的方法名通常都比较长，这是为了让程序有更好地可读性，按苹果的说法“好的方法名应当可以以一个句子的形式朗读出来”。

方法一般以小写字母打头，每一个后续的单词首字母大写，方法名中不应该有标点符号（包括下划线），有两个例外：

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

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

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

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

反对：

// 添加了多余的动词前缀
- (NSSize)calcCellSize;
- (NSSize)getCellSize;

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

反对：

// 遗漏关键词
- (void)sendAction:(SEL)aSelector :(id)anObject :(BOOL)flag;
// 关键词的作用不清晰
- (id)taggedView:(int)aTag;

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

反对：

// 不要使用"and"来连接参数
- (int)runModalForDirectory:(NSString *)path andFile:(NSString *)name andTypes:(NSArray *)fileTypes;

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

和方法名类似，参数的第一个字母小写，后面的每一个单词首字母大写
不要在方法名中使用类似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

命名委托

当特定的事件发生时，对象会触发它注册的委托方法。委托是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;

集合操作类方法

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

// 集合操作范式
- (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类型以防止引用循环。

比如项目中有很多使用 UIWindow 的场景，为了避免多人合作开发对 UIWindow 使用的随意性，我么可以封装一些常用的 UIWindow 使用方法：

// 注意，下面是参考 macOS 开发里常用的 NSWindow类的集合操作方法
- (void)addChildWindow:(NSWindow *)childWin ordered:(NSWindowOrderingMode)place;
- (void)removeChildWindow:(NSWindow *)childWin;
- (NSArray *)childWindows;
- (NSWindow *)parentWindow;
- (void)setParentWindow:(NSWindow *)window;

命名属性和成员变量

属性和对象的存取方法相关联，属性的第一个字母小写，后续单词首字母大写，不必添加前缀。属性按功能命名成名词或者动词，也可以命名成形容词，这时候通常会指定一个带有is前缀的get方法来提高可读性：

// 名词属性
@property (strong) NSString *title;
// 动词属性
@property (assign) BOOL showsAlpha;
// 形容词属性
@property (assign, getter=isEditable) BOOL editable;

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

@implementation MyClass {
    BOOL _showsTitle;
}

一般来说，类需要对使用者隐藏数据存储的细节，所以不要将实例方法定义成公共可访问的接口。

注意：

针对我们的项目，我建议减少对成员变量的使用，多使用属性。
关于使用属性与成员变量，参考：iOS巩基之不再纠结实例变量&属性

命名常量

如果要定义一组相关的常量，尽量使用枚举类型（enumerations），枚举类型的命名规则和函数的命名规则相同。
建议使用 NS_ENUM 和 NS_OPTIONS 宏来定义枚举类型，参见官方的 Adopting Modern Objective-C 一文：

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

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

// 在 OC 中，通常常量定义加一个前缀 k
const float kLightGray;

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

#ifdef DEBUG

注意到一般由编译器定义的宏会在前后都有一个__，比如MACH。

命名通知

通知常用于在模块间传递消息，所以通知要尽可能地表示出发生的事件，通知的命名范式是：

[触发通知的类名] + [Did | Will] + [动作] + Notification
// 例如：
NSApplicationDidBecomeActiveNotification
NSWindowDidMiniaturizeNotification
NSTextViewDidChangeSelectionNotification
NSColorPanelColorDidChangeNotification

图片命名

1.用英文命名，尽量不用拼音；
2.每一部分用'-'分隔。分割的第一个首字母大写；
3.尽量表现内容+使用类型；
4.尽量同一页面放置在同一个文件夹下。

注释

读没有注释代码的痛苦我们应该都体会过，好的注释不仅能让人轻松读懂你的程序，还能提升代码的逼格。注意注释是为了让别人看懂，而不是仅仅你自己。

文件注释

当我们需要对外提供 framework 的时候，每一个文件都必须写文件注释，文件注释通常包含

文件所在模块
作者信息
历史版本信息
版权信息
文件包含的内容，作用
一段良好文件注释的例子：

/*******************************************************************************
    Copyright (C), 2011-2013, Andrew Min Chang

    File name:  AMCCommonLib.h
    Author:     Andrew Chang (Zhang Min) 
    E-mail:     LaplaceZhang@126.com
    
    Description:    
            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.h

    Copyright 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的标准注释风格，好处是可以在引用的地方 option + 点击自动弹出注释，非常方便。

当前 Xcode 已经集成了某大神写的自动生成注释的插件。（快捷键，光标放在方法或属性等需要添加注释的代码上一行，点击 option + command + /，剩下的就是我们需要写好注释了）。

下面是我封装的个别接口的注释（方法名已修改）

/// 差旅和通勤登录接口
/// @param username 用户手机号
/// @param busType 业务类型 ：a 是差旅 b 是通勤
/// @param success 成功回调
/// @param failure 失败回调
+ (void)requestXXXType:(NSString *)username busType:(NSString *)busType success:(success)success failure:(failure)failure;

协议、委托的注释要明确说明其被触发的条件。
定义在头文件里的接口方法、属性必须要有注释！

普通注释，切记双斜线（//）与注释文字之间应有空格！

// 注释和双斜线间要有空格！

代码格式

每一行的最大长度（不做硬性要求）

同样的，在Xcode > Preferences > Text Editing > Page guide at column:中将最大行长设置为80，过长的一行代码将会导致可读性问题。

空格

类方法声明在方法类型与返回类型之间要有空格。

反对：

-(void)methodName:(NSString *)string;

条件判断的括号内侧不应有空格。

反对：

if ( a < b ) {
    // something
}

关系运算符（如 >=、!=）和逻辑运算符（如 &&、||）两边要有空格。

方法的书写

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

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

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

.m 文件中，两个方法的实现之间应留有一行空行，代码应该紧凑，增加可读性，方法内的代码块不应该都空一或多行写。

反对：

// 不易复用
- (UIButton *)loginButton {
    if (!_loginButton) {
        _loginButton = [UIButton buttonWithType:UIButtonTypeCustom];
        [_loginButton setTitle:@"登录" forState:UIControlStateNormal];
        _loginButton.backgroundColor = [UIColor cyanColor];
        _loginButton.layer.cornerRadius = 4;
        _loginButton.clipsToBounds = YES;
        [self.view addSubview:_loginButton];
    }
    return _loginButton;
}

// 考虑下屏幕的大小及可读性，当一个方法占了一个屏幕，读起来真的很闹心。
- (UIButton *)loginButton {

    if (!_loginButton) {

        UIButton * button = [UIButton buttonWithType:UIButtonTypeCustom];

        [button setTitle:@"登录" forState:UIControlStateNormal];

        button.backgroundColor = [UIColor cyanColor];

        button.layer.cornerRadius = 4;

        button.clipsToBounds = YES;
        
        [self.view addSubview:button];

        _loginButton = button;

    }

    return _loginButton;

}

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

- (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<IPCConnectHandlerDelegate>)delegate;

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

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

方法调用

方法调用的格式和书写差不多，可以按照方法的长短来选择写在一行或者分成多行：

反对：

//错误，要么写在一行，要么全部分行
[myObject doFooWith:arg1 name:arg2
              error:arg3];
[myObject doFooWith:arg1
               name:arg2 error:arg3];

//错误，按照':'来对齐，而不是关键字
[myObject doFooWith:arg1
          name:arg2
          error:arg3];

协议（Protocols）

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

// 参考 iOS SDK
@interface MyProtocoledClass : NSObject<NSWindowDelegate>

闭包（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) = ^{
    // ...
};
typedef void(^someBlock)(NSString *someParam);
[_operationQueue addOperationWithBlock:largeBlock];

// 在一个调用中使用多个block，注意到他们不是像函数那样通过':'对齐的，而是同时进行了4个空格的缩进
[myObject doSomethingWith:arg1
    firstBlock:^(Foo *a) {
        // ...
    }
    secondBlock:^(Bar *b) {
        // ...
    }];

字面量语法糖

应该使用可读性更好的语法糖来构造NSArray，NSDictionary等数据结构，避免使用冗长的alloc,init方法。

如果构造代码写在一行，需要在括号两端留有一个空格，使得被构造的元素于与构造语法区分开来：

反对：

// 不留有空格降低了代码可读性
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 *wrong = @{
  AKey:       @"b",
  BLongerKey: @"c",
};

// 每一个元素要么单独成为一行，要么全部写在一行内
NSDictionary *alsoWrong= @{ AKey : @"a",
                            BLongerKey : @"b" };

// 在冒号前只能有一个空格，冒号后才可以考虑按照Value对齐
NSDictionary *stillWrong = @{
  AKey       : @"b",
  BLongerKey : @"c",
};

代码组织

函数、方法长度（行数）不应超过2/3屏幕，通常我们建议不超过30行，当你的一个方法行数过多，意味着这个方法可以优化了。（我们的老项目中一个方法五六十行甚至过百行都不奇怪）
单个文件方法数不应超过30个，单个文件的总行数也不应超过500行，当你的一个类文件总行数过千了，意味着这个类一定有很多的冗余代码。
一个文件中的代码，通常我们应该按一定类别排序（如 api 请求放在一起，push 放在一起）。
当一个文件中代码不是单一功能，我们可以考虑不按类别排序（如把IBAction放在一块），而按任务把相关的组合在一起。
禁止出现超过两层循环的代码，用方法其他方式替代。

反对：

// 为了简化示例，没有错误处理，并使用了伪代码
- (Task *)createTaskWithPath:(NSString *)path {
    Task *aTask;
    if ([path isURL]) {
        if ([fileManager isWritableFileAtPath:path]) {
            if (![taskManager hasTaskWithPath:path]) {
                aTask = [[Task alloc] initWithPath:path];
            }
            else {
                return nil;
            }
        }
        else {
            return nil;
        }
    }
    else {
        return nil;
    }
    return aTask;
}

编码风格

每个人都有自己的编码风格，这里总结了一些比较好的 Cocoa 编程风格和注意点。

不要使用 new 方法

我在我们当前的项目中发现很多地方使用 new 方法去实例化一个对象，尽管很多时候能用new代替alloc init方法，但这可能会导致调试内存时出现不可预料的问题。Cocoa的规范就是使用alloc init方法。

Public Api 要尽量简洁

共有接口要设计的简洁，满足核心的功能需求就可以了。不要设计很少会被用到，但是参数极其复杂的API。如果要定义复杂的方法，使用类别或者类扩展。

#import 和 #include

import是Cocoa中常用的引用头文件的方式，它能自动防止重复引用文件，什么时候使用#import，什么时候使用#include呢？

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

为什么不全部使用#import呢？主要是为了保证代码在不同平台间共享时不出现问题。

引用框架的根头文件

每一个框架都会有一个和框架同名的头文件，它包含了框架内接口的所有引用，在使用框架的时候，应该直接引用这个根头文件，而不是其它子模块的头文件，即使是你只用到了其中的一小部分，编译器会自动完成优化的。

反对：

// 不要单独引用框架内的其它头文件
#import <Foundation/NSArray.h>
#import <Foundation/NSString.h>

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来返回，这种情况下，BOOL变量只会取值的最后一个字节来赋值，这样很可能会取到0（NO）。但是，一些逻辑操作符比如&&,||,!的返回是可以直接赋给BOOL的：

反对：

// 不要将其它类型转化为BOOL返回
- (BOOL)isBold {
  return [self fontTraits] & NSFontBoldTrait;
}
- (BOOL)isValid {
  return [self stringValue];
}

init和dealloc

建议将 init 和 dealloc 方法放在类文件的最前面，紧挨着。

当init、dealloc方法被执行时，类的运行时环境不是处于正常状态的，使用存取方法访问变量可能会导致不可预料的结果，因此应当在这两个方法内直接访问实例变量（当我们创建一个属性 school 时，编译器会自动生成一个对应的成员变量 _school）。

反对：

// 不要通过存取方法访问
- (instancetype)init {
  self = [super init];
  if (self) {
    self.bar = [NSMutableString string];
  }
  return self;
}
- (void)dealloc {
  self.bar = nil;
  [super dealloc];
}

按照顺序释放资源

在类或者Controller的生命周期结束时，往往需要做一些扫尾工作，比如释放资源，停止线程等，这些扫尾工作的释放顺序应当与它们的初始化或者定义的顺序保持一致。这样做是为了方便调试时寻找错误，也能防止遗漏。

保证 NSString 在赋值时被复制

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

// 使用 copy 而不是 retain或strong 修饰字符串类型
@property (nonatomic, copy) NSString *text;

使用NSNumber的语法糖

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

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

nil 检查

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

另外，不要使用诸如nil == Object或者Object == nil的形式来判断。

反对：

//不要使用nil == Object的形式
if (nil == objc) {
    ... 
}

“==” 判断

建议常量值在表达式的左侧。

反对：

if ( var == constant )
if ( pointer == NULL )

点语法的使用

不要用点分语法来调用方法，只用来访问属性。这样是为了防止代码可读性问题。

反对：

// 不要用点分语法调用方法
NSArray *array = [NSArray arrayWithObject:@"hello"];
NSUInteger numberOfItems = array.count;
array.release;

Delegate要使用弱引用

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

@property (nonatomic, weak) id <ASXXXDelegate> delegate;

单例

如果可能，请尽量避免使用单例。如果一定要用，请使用一个线程安全的模式来创建共享的实例。对于 GCD，用 dispatch_once() 函数就可以。

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

pragma mark

#pragma mark是一个在类内部组织代码并且帮助你分组方法实现的好办法。
我们建议使用 #pragma mark - 来分离不同功能的代码。
该语句上下各保留一个换行，这是一个分割线的效果。

@implementation ASXXXController

#pragma mark - public

+ (instancetype)playerWithUrl:(NSURL *)url {}
+ (void)play:(NSURL *)url {}

#pragma mark - life cycle

- (void)viewDidLoad {}
- (void)dealloc {}

// 这个模块应该是对页面的一些配置方法（刷新、UI 组件加载等）
#pragma mark - configs

/// 当前页面的唯一刷新方法
- (void)refreshView {}
- (void)preparePlayer {}
- (void)initPlayerView {}

// 当前页面对相关接口的调用模块
#pragma mark - call api

- (void)callXXXApi {}

// 代理相关模块
#pragma mark - delegate

// 具体的某一个代理
#pragma mark ASXXXDelegate

- (void)controlDidPaused {}
- (void)controlDidStarted {}
- (void)controlDidClose {}

#pragma mark - actions

- (void)longPress:(UILongPressGestureRecognizer *)gesture {}

// 页面逻辑处理模块
#pragma mark - logical processing

- (void)showNoWifiToast {}
- (void)saveToAlbum {}

#pragma mark - overide

- (BOOL)prefersStatusBarHidden {}

// 属性的 set、get 方法
#pragma mark - properties

- (UIView *)playerView {}
- (void)setUrl:(NSURL *)url {}

@end

属性的线程安全

定义一个属性时，编译器会自动生成线程安全的存取方法（Atomic），但这样会大大降低性能，特别是对于那些需要频繁存取的属性来说，是极大的浪费。所以如果定义的属性不需要线程保护，记得手动添加属性关键字 nonatomic 来取消编译器的优化。

设计模式

我们应该始终对新技术保持浓厚的兴趣，当它成熟且我们已掌握时，便应当尝试应用。

ReactiveCocoa+MVVM

ReactiveCocoa+MVVM 模式应当是让我们心潮澎湃的一种架构模式，但是只有当我们现有项目架构清晰合理时才能锦上添花。

参考：ReactiveCocoa 和 MVVM 入门
 MVVM With ReactiveCocoa

关于这个规范的未尽事项，请参考 Apple 的文档：
Cocoa 编程指南
 iOS 应用编程指南