iOS开发代码规范

命名规范

---

总的来讲, iOS命名两大原则是:可读性高和防止命名冲突(经过加前缀来保证). Objective-C 的命名一般都比较长, 名称遵循驼峰式命名法. 一个好的命名标准很简单, 就是作到在开发者一看到名字时, 就可以懂得它的含义和使用方法. 另外, 每一个模块都要加上本身的前缀, 前缀在编程接口中很是重要, 能够区分软件的功能范畴并防止不一样文件或者类之间命名发生冲突, 好比相册模块(PhotoGallery)的代码都以PG做为前缀: PGAlbumViewController, PGDataManager.

1). 常量的命名

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

1	static const NSTimeInterval kAnimationDuration = 0.3;

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

1	NSString *const UIApplicationDidEnterBackgroundNotification

Tips:

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

II.全局常量(通知或者关键字等)尽可能用const来定义. 由于若是使用宏定义, 一来宏可能被重定义. 二来引用不一样的文件可能会致使宏的不一样. P.S. 对于＃define也添加一下前缀k(强迫症, 哈哈...)

2). 枚举的命名

对于枚举类型, 常常会看到以前的C的定义方式:

 

1 2 3 4 5

typedef enum : {      CameraModeFront,      CameraModeLeft,      CameraModeRight, } CameraMode;

不知道是肿么了, 每次看到这种定义方式老是感受怪怪的, 做为一个正宗的iOS开发者固然要以Objective-C的方式来定义啦, 哈哈... 那Objective-C是怎么定义的呢? 很简单, 到SDK里面看看Apple是怎么作滴:

 

1 2 3 4 5 6 7

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

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

3). 变量和对象的命名

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

 

1 2	titleLabel     //表示标题的label,  是UILabel类型 confirmButton  //表示确认的button, 是UIButton类型

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

Tip: 若是某个命名已经很明确了, 为了简洁能够省去类型名. 好比scores, 很明显是个array了, 就没必要命名成scoreArray了

编码规范

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

编码规范直接经过示例来介绍, 毕竟对于程序员来讲一个Demo赛过千行文字(有同感的小伙伴让我看到大家的双手, 哈哈O(∩_∩)O~~). 下面的部分示例选自richieyang博文, 写的很好的一篇文章, 推荐你们看一下, 我本身也是受益不浅.

1). 判断nil或者YES/NO

Preferred:

 

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

Not preferred:

 

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

if (someObject == YES)容易误写成赋值语句, 本身给本身挖坑了...并且if (someObject)写法很简洁, 何乐而不为呢?

2). 条件赋值

Preferred:

1	result = object ? : [self createObject];

Not preferred:

1	result = object ? object : [self createObject];

若是是存在就赋值自己, 那就能够这样简写, 多简洁啊, 哈哈...

3). 初始化方法

Preferred:

 

1 2 3 4

NSArray *names = @[@ "Brian" , @ "Matt" , @ "Chris" , @ "Alex" , @ "Steve" ]; NSDictionary *productManagers = @{@ "iPhone"  : @ "Kate" , @ "iPad"  : @ "Kamal" }; NSNumber *shouldUseLiterals = @YES; NSNumber *buildingZIPCode = @10018;

第一个好处仍是简洁, 第二个好处是能够防止初始化进去nil值形成crash

4). 定义属性

Preferred:

1	@property (nonatomic, readwrite, copy) NSString *name;

建议定义属性的时候把全部的参数写全, 尤为是若是想定义成只读的(防止外面修改)那必定要加上readonly, 这也是代码安全性的一个习惯.

若是是内部使用的属性, 那么就定义成私有的属性(定义到.m的class extension里面)

对于拥有Mutable子类型的对象(e.g. NSString, NSArray, NSDictionary)必定要定义成copy属性. Why? 示例: NSArray的array = NSMutableArray的mArray; 若是mArray在某个地方改变了, 那array也会跟着改变. So, make sense?

尽可能不要暴露mutable类型的对象在public interface, 建议在.h定义一个Inmutable类型的属性, 而后在.m的get函数里面返回一个内部定义的mutable变量. Why? For security as well!

5). BOOL赋值

Preferred:

1	BOOL isAdult = age > 18;

Not preferred:

 

1 2 3 4 5 6 7 8 9

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

为何要这么写呢, 我不告诉你, 哈哈哈...

6) 拒绝死值

Preferred:

 

1 2 3

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

Not preferred:

 

1 2 3

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

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

7). 复杂的条件判断

Preferred:

 

1 2 3 4 5 6 7 8 9 10 11

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:

 

1 2 3 4 5 6 7

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

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

8). 嵌套判断

Preferred:

 

1 2 3 4 5

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

Not preferred:

 

1 2 3 4 5 6 7 8 9 10 11 12

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

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

9). 参数过多

Preferred:

 

1 2 3 4 5 6

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

Not preferred:

 

1 2 3 4 5 6

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

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

10). 回调方法

Preferred:

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

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

Well, 不知不觉已经整理了10个了, 额, 太多了, 不知道童鞋们还有木有耐心看了, 好吧, 这一段就到此为止吧, 下面写一下block的编码规范, 各位看官, 预知后事如何, 且继续look look, 哈哈...

Block的循环引用问题

---

Block确实是个好东西, 可是用起来必定要注意循环引用的问题, 不然一不当心你就会发现, Oh My God, 个人dealloc肿木不走了...

 

1 2 3 4 5 6

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

如此在上面定义一个weakSelf, 而后在block体里面使用该weakSelf就能够避免循环引用的问题. 那么问题来了...是否是这样就彻底木有问题了? 很不幸, 答案是NO, 仍是有问题。问题是block体里面的self是weak的, 因此就有可能在某一个时段self已经被释放了, 这时block体里面再使用self那就是nil, 而后...而后就悲剧了...那么肿么办呢?

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14

__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或抛出异常.

什么状况下会出现block里面self循环引用的问题? 这个问题问的好, 哈哈...简单来讲就是双边引用, 若是block是self类的property (此时self已经retain了block), 而后在block内又引用了self, 这个状况下就确定会循环引用了...

P.S. RAC里面有定义好的@weakify(self)和@strongify(self), 用起来灰常灰常的方便, 劝君尝试一下^_^

那些年遇到的Crash

---

• 多线程同步问题形成的Crash

这个其实还蛮常见的, 尤为是在多线程泛滥使用的今天...你可使用多线程, 但你要知道保护它呀, 哈哈. 对于数据源或model类必定要注意多线程同时访问的状况, 我我的比较喜欢用GCD的串行队列来同步线程.

• Observer的移除

如今的代码里面不少须要用到Observer, 根据被观察对象的状态来相应的Update UI或者执行某个操做. 注册observer很简单, 可是移除的时候就出问题了, 要么是忘记移除observer了, 要么是移除的时机不对. 若是某个被观察对象已经被释放了, observer还在, 那结果只能是crash了, 因此切记至少在dealloc里面移除一下observer...

• NSArray, NSDictionary成员的判空保护

在addObject或insertObject到NSArray或者NSDictionary时最好加一下判空保护, 尤为是网络相关的逻辑, 若是网络返回为空(jason解析出来为空), 但你仍是毅然决然的add到array里面, 那么...

最后一点就是commit代码以前必定要保证木有warning, 木有内存泄露, 确保都OK以后再上传代码. 其实很简单, 上传代码以前Command + Shift + B静态分析一下, 看看有木有什么issue...就先写这么多吧, 之后遇到更多的坑后, 我必定会爬出来再过来补充的, to be continued...