一、代码组织
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);
13. 空行的使用
1、 方法实现内部，原则上不以空行分隔，如有需要使用方法封装来区分不同功能实现。
三、其他注意点
1、多语言
1）目前产品的本地化策略为，如果有对应语言的翻译，则使用中文，如果没有则显示英文。故在新增多语言字段时，对未提供多语言的语言项，需要使用英文代替，不能不添加此字段。
2）为了防止字段遗漏，在使用release方式编译时，会使用脚本对所有多语言字段进行检查，如果对多语言有改动，建议在修改完成后，使用release模式进行编译，对多语言进行检查。
2、Xib、Storyborad中leading/trailing的处理
由于目前的leading/trailing约束对于阿拉伯文等从右到左语言习惯的显示会有一定问题，故所有相关约束需要使用left/right来替代。
与上面多语言处理类似，在使用release方式进行编译时，也会进行此项检查，建议控件改动较多时进行检查。
