iOS编程规范(V0.1)

一、代码组织

1. 方法分布

在函数分组和protocol/delegate实现中使用#pragma mark 来分类方法，要遵循以下一般结构：

#pragma mark- Life Cycle                 //类的生命周期相关的方法，如viewWillAppear等。
#pragma mark- Public Method          //对外的接口，公有方法。
#pragma mark- Delegate                  //代理方法；在下面用 #pragma mark UITableViewDelegate 等来区分不同控件的代理方法，这里建议，自己控件的代码方法写在前面，系统控件的代码方法写在靠后的位置
#pragma mark- Event Response      //按钮响应事件、通知方法、定时器方法等。
#pragma mark- Getters and Setters //Get 和 Set 方法
#pragma mark- Private Method        //私有方法，方法封装等。

Tips：

• 总体的原则是方法/代码量可能比较多的块放在后面，如私有方法一般都最多的。
• 使用Snippets来保证一致
  替换地址：~/Library/Developer/Xcode/UserData/CodeSnippets

2. 一些原则

<1> 行数限制：一个方法最多不能超过50行， 一个文件原则上不能超过1000行，超过行数要考虑封装。
<2> Storyboard/纯代码：建议比较复杂的视图使用纯代码来进行创建和布局，比较简单的视图使用Storyboard或Xib来进行布局。这样做的原因是复杂视图使用Storyboard看起来会很复杂，而且修改维护起来也不方便。
Tips: 在使用autoLayout布局时，可以把布局代码写在viewDidLoad里面，但是如果是用frame 布局，在viewDidLoad里面布局就很容易出问题。一般是放在viewWillAppear里面。
<3> 视图初始化：尽量使用getter的方法来进行视图的初始化，而是都集中在initView中。
<4> 尽量少的写private method,尽量把一些通用的代码，用类目或者工具类的方式独立出来，方便后面的修改和调试。
<5> 不要在 init 和 dealloc 及getter 和setter方法中使用 self.property 的方式来访问成员变量。

3. XCode 工程

物理文件应该与Xcode工程文件保持同步，任何Xcode分组的创建应该在文件系统的文件体现。

二、命名规范

总的来说, iOS命名两大原则是:可读性高和防止命名冲突. Objective-C 的命名通常都比较长, 名称遵循驼峰式命名法. 一个好的命名标准很简单, 就是做到在开发者一看到名字时, 就能够懂得它的含义和使用方法.

1. 常量的命名

常量是容易重复被使用和无需通过查找和代替就能快速修改值。常量应该使用static来声明而不是使用#define，除非显式地使用宏。

对于常量的命名最好在前面加上字母k作为标记. 如:

static const NSTimeInterval kAnimationDuration = 0.3;

定义作为NSDictionary或者Notification等的Key值字符串时加上const关键字, 以防止被修改. 如:

NSString *const UIApplicationDidEnterBackgroundNotification

Tips:

I. 若常量作用域超出编译单元(实现文件), 需要在类外可见时, 使用extern关键字, 并加上该类名作为前缀. 如 extern NSString *const PGThumbnailSize

II. 全局常量(通知或者关键字等)尽量用const来定义. 因为如果使用宏定义, 一来宏可能被重定义. 二来引用不同的文件可能会导致宏的不同. 另外，对于＃define也添加一下前缀k

2. 枚举的命名

对于枚举类型, 经常会看到下面的定义方式:

typedef enum : NSUInteger {
    NSEnumScanQRCodeManul = 1, //手动添加页面打开二维码扫描页面
    NSEnumScanQRCodeDeviceList = 2, //直接打开二维码扫描页面
    NSEnumScanQRCodePasswd = 3, //设备找回密码显示密码界面
} NSEnumScanQRCodeType;

typedef enum {
    PTZ_CONTROL_STYLE_None,                   //默认值：正常
    PTZ_CONTROL_STYLE_Zoom,                   //变倍
    PTZ_CONTROL_STYLE_Focus,                  //聚焦
    PTZ_CONTROL_STYLE_Preset,                 //预置位
    PTZ_CONTROL_STYLE_Unknown,                //未知
} PTZ_CONTROL_STYLE;

首先，两种都用的是C的定义方法。在命名上，第一种方法，使用NS做为前缀，容易被误解为系统的定义，而且Enum这个单词我觉得没有必要；第二种，感觉怪怪的，像是一个宏定义一样。
作为一个正宗的iOS开发者，当然要以Objective-C的方式来定义，看下系统是怎么定义的:

typedef NS_ENUM(NSInteger, UIViewAnimationTransition) {
    UIViewAnimationTransitionNone,
    UIViewAnimationTransitionFlipFromLeft,
    UIViewAnimationTransitionFlipFromRight,
    UIViewAnimationTransitionCurlUp,
    UIViewAnimationTransitionCurlDown,
};

这边需要注意的是: 枚举类型命名要加相关类名前缀并且枚举值命名要加枚举类型前缀.

3. 变量和对象的命名

给一个对象命名时建议采用修饰+类型的方式. 如果只用修饰命名会引起歧义, 比如title (这个到底是个NSString还是UILabel?). 同样的, 如果只用类型来命名则会缺失作用信息, 比如label (好吧, 我知道你是个UILabel, 但是我不知道它是用来做什么的呀?). So, 正确的命名方式为:

titleLabel //表示标题的label, 是UILabel类型

confirmButton //表示确认的button, 是UIButton类型

对于BOOL类型, 应加上is前缀, 比如- (BOOL)isEqualToString:(NSString *)aString这样会更加清晰. 如果某方法返回非属性的 BOOL 值, 那么应根据其功能, 选用 has/is/should 当前缀, 如- (BOOL)hasPrefix:(NSString *)aString

4. 下划线

当使用属性时，实例变量应该使用self.来访问和改变。这就意味着所有属性将会视觉效果不同，因为它们前面都有self.。

私有变量应该尽可能代替实例变量的使用。尽管使用实例变量是一种有效的方式，但更偏向于使用属性来保持代码一致性。

局部变量不应该包含下划线。

不应该使用下划线访问属性的位置:
<1> getter 和 setter方法中
<2> init 和 dealloc方法，原因可以参考：文章

三、编码规范

编码规范简单来说就是为了保证写出来的代码具备三个原则:可复用, 易维护, 可扩展. 这其实也是面向对象的基本原则. 可复用, 简单来说就是不要写重复的代码, 有重复的部分要尽量封装起来重用. 否则修改文件的时候得满地找相同逻辑的地方...这个就用no zuo no die来描述吧, 哈哈...易维护, 就是不要把代码复杂化, 不要去写巨复杂逻辑的代码, 而是把复杂的逻辑代码拆分开一个个小的模块, 这也是Do one thing的概念, 每个模块(或者函数)职责要单一, 这样的代码会易于维护, 也不容易出错. 可扩展则是要求写代码时要考虑后面的扩展需求。

编码规范直接通过示例来介绍, “Talk is cheap, show me the code”.

1. 判断nil或者YES/NO

Preferred:

if (someObject) { ... }
if (!someObject) { ... }

Not preferred:

if (someObject == YES) { ...}
if (someObject != nil) { ...}

if (someObject == YES)容易误写成赋值语句, 自己给自己挖坑了...而且if (someObject)写法很简洁, 何乐而不为呢?
OC中BOOL定义

2. BOOL赋值

Preferred:

BOOL isAdult = (age > 18);

Not preferred:

BOOL isAdult;
if (age > 18) {
    isAdult = YES;
} else{
    isAdult = NO;
}

3. 魔鬼数字

Preferred:

if (car == Car.Nissan)
or
const int adultAge = 18; if (age > adultAge) { ... }

Not preferred:

if (carName == "Nissan")
or
if (age > 18) { ... }

魔鬼数字每次修改的时候容易被遗忘, 地方多了找起来就悲剧了. 而且定义成枚举或者static可以让错误发生在编译阶段. 另外仅仅看到一个数字, 完全不知道这个数字代表的意义. 纳尼?

4. 复杂的条件判断

Preferred:

if ([self canDeleteJob:job]) { ... }       
- (BOOL)canDeleteJob:(Job *)job {
    BOOL invalidJobState = (job.JobState == JobState.New
                          || job.JobState == JobState.Submitted
                          || job.JobState == JobState.Expired);
    BOOL invalidJob = (job.JobTitle && job.JobTitle.length);
    return invalidJobState || invalidJob;
}

Not preferred:

if (job.JobState == JobState.New
    || job.JobState == JobState.Submitted
    || job.JobState == JobState.Expired
    || (job.JobTitle && job.JobTitle.length)) {
    //....
}

清晰明了, 每个函数DO ONE THING!

5. 嵌套判断

Preferred:

if (!user.UserName) return NO;
if (!user.Password) return NO;
if (!user.Email) return NO;
return YES;

Not preferred:

BOOL isValid = NO;
if (user.UserName) {
    if (user.Password) {
        if (user.Email) isValid = YES;
    }
}
return isValid;

一旦发现某个条件不符合, 立即返回, 条理更清晰

6. 参数过多

Preferred:

- (void)registerUser(User *user) {
    // to do...
}

Not preferred:

- (void)registerUserName:(NSString *)userName
    password:(NSString *)password
    email:(NSString *)email {
    // to do...
}

当发现实现某一功能需要传递的参数太多时, 就预示着你应该聚合成一个model类了...这样代码更整洁, 也不容易因为参数太多导致出错

7. 回调方法

Preferred:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath;

函数调用的可知性, 回调时被调用者要知道其调用者, 方便信息的传递, 所以建议在回调方法中第一个参数中加上调用者

8. Block的循环引用问题

Block确实是个好东西, 但是用起来一定要注意循环引用的问题, 否则可能会引起内存泄露。

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

可以用下面这种方式：

__weak typeof(self) weakSelf = self;
myObj.myBlock =  ^{
    __strong typeof(self) strongSelf = weakSelf;
    if (strongSelf) {
       [strongSelf doSomething]; // strongSelf != nil
       // preemption, strongSelf still not nil
       [strongSelf doSomethingElse]; // strongSelf != nil
    }else {
        // Probably nothing...
        return;
    }
};

解决方法就是在block体内define一个strong的self, 然后执行的时候判断下self是否还在, 如果在就继续执行下面的操作, 否则return或抛出异常.这样可能有点麻烦，所以可以自定义一个宏：

@weakify(object)
@strongify(object)

#ifndef weakify
#if DEBUG
#if __has_feature(objc_arc)
#define weakify(object) autoreleasepool{} __weak __typeof__(object) weak##_##object = object;
#else
#define weakify(object) autoreleasepool{} __block __typeof__(object) block##_##object = object;
#endif
#else
#if __has_feature(objc_arc)
#define weakify(object) try{} @finally{} {} __weak __typeof__(object) weak##_##object = object;
#else
#define weakify(object) try{} @finally{} {} __block __typeof__(object) block##_##object = object;
#endif
#endif
#endif

#ifndef strongify
#if DEBUG
#if __has_feature(objc_arc)
#define strongify(object) autoreleasepool{} __typeof__(object) object = weak##_##object;
#else
#define strongify(object) autoreleasepool{} __typeof__(object) object = block##_##object;
#endif
#else
#if __has_feature(objc_arc)
#define strongify(object) try{} @finally{} __typeof__(object) object = weak##_##object;
#else
#define strongify(object) try{} @finally{} __typeof__(object) object = block##_##object;
#endif
#endif
#endif

9. 方法大括号和其他大括号(if/else/switch/while 等.)总是在同一行语句打开但在新行中关闭。

Prefered:

if (user.isHappy) {
    //Do something
} else {
    //Do something else
}

Noet Prefered:

if (user.isHappy) {
  //Do something
}else {
  //Do something else
}

10. 注释

当需要注释时，注释应该用来解释这段特殊代码为什么要这样做。任何被使用的注释都必须保持最新或被删除。

11. 日志

日志的主要作用是帮助我们快速定位问题，特别是网上问题。
打印日志时的一些规范：
1> 分级
Debug (在线上环境不会打印) ELYTDLog
可以打印任何自己觉得有帮助的内容。
Info ELYTILog
业务关键节点打印。如调用接口（关键参数也要打印），请求成功、请求失败等。
Error ELYTELog
错误日志，严重或会导致业务不能正常使用的异常；

2> 注意点

• 后续在代码中不要再出现NSLog、printf，所有日志都要归到某一级中。
• 频繁打印一般情况下只能使用 Debug 级别。

12. 断言的使用

使用断言主要是为了保持代码的健壮性，在发生绝对不应该出现的错误时能够及时发现和处理。
断言为真，则表明程序运行正常；断言为假，则意味着它已经在代码中发现意料之外的错误。
NSAssert(condition, desc, ...)

断言使用的原则

• 用错误处理代码来处理预期会发生的状况，用断言来处理绝不应该发生的状况
• 断言在发布环境中不会被执行，要避免把执行的代码放到断言中
  如
  NSAssert([self performAction], @"could't perform);
  这样写就很危险，应该这样写：

Bool performed=[self performAction];
NSAssert(performed, @"could't perform);