iOS 代码规范

命名规范

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

1). 常量的命名

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

static const NSTimeInterval kAnimationDuration = 0.5;

Tips:

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

    II.全局常量(通知或者关键字等)尽量用const来定义. 因为如果使用宏定义, 一来宏可能被重定义. 二来引用不同的文件可能会导致宏的不同.

2). 枚举的命名

    对于枚举类型, 经常会看到之前的C的,对与oc来说是可以兼容c 的所以不会有问题定义方式:

typedef enum : {

     CameraModeFront,

     CameraModeLeft,

     CameraModeRight,

} CameraMode;

    上面定义枚举的方法不能指定底层数据类型,所以没有办法向前声明枚举类型,因为编译器不清楚底层数据类型的大小,用到枚举类型时,页就不知道究竟该给变量分配多少空间。 那Objective-C定义枚举如下:

typedef NS_ENUM(NSInteger, UIViewAnimationTransition) {

      UIViewAnimationTransitionNone,

      UIViewAnimationTransitionFlipFromLeft,

      UIViewAnimationTransitionFlipFromRight,

      UIViewAnimationTransitionCurlUp,

      UIViewAnimationTransitionCurlDown,

};

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

3). 变量和对象的命名

    给一个对象命名时建议采用修饰+类型的方式. 如果只用修饰命名会引起歧义, 比如title ,不能看出来这个是什么样的类型,可读性极差. 正确的命名方式为:

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

    cancelButton //表示取消的button, 是UIButton类型

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

Tip:如果某个命名已经很明确了, 为了简洁可以省去类型名. 比如scores, 很明显是个array了, 就不必命名成scoreArray了

编码规范

    编码规范简单来说就是为了保证写出来的代码具备三个原则:可复用, 易维护, 可扩展. 这其实也是面向对象的基本原则. 可复用, 简单来说就是不要写重复的代码, 有重复的部分要尽量封装起来重用. 易维护, 就是不要把代码复杂化, 不要去写巨复杂逻辑的代码, 而是把复杂的逻辑代码拆分开一个个小的模块, 每个模块(或者函数)职责要单一, 这样的代码会易于维护, 也不容易出错. 可扩展则是要求写代码时要考虑后面的扩展需求, 这个属于架构层面的东西, 利用对应的设计模式来保证。

1). 判断nil或者YES/NO

正确写法:

if (someObject) { ... }

if (!someObject) { ... }

错误写法:

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

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

if (someObject == YES)容易误写成赋值语句if (someObject = YES)这样在开发的过程中不好被发现,造成时间的浪费

2). 条件赋值

正确写法

result = object ? : [self createObject];

错误写法:

result = object ? object : [self createObject];

    如果是存在就赋值本身, 那就可以这样

3). 初始化方法

正确写法:

NSArray *animals = @[@"cat", @"dog", @"mouse", @"badger"];

NSDictionary *personData = @{@"Matt" : @"firstName", @"Galloway" : @"lastName"};

错误写法:

NSArray *names =  [NSArray arrayWithObjects:@"cat", @"dog", @"mouse", @"badger",nil];

NSDictionary *personData = [NSDictionarydictionaryWithObjectsAndKeys:@"Matt" : @"firstName", @"Galloway" : @"lastName",nil];

    第一个好处还是简洁, 第二个好处是可以防止初始化进去nil值造成crash,所以要多用字面量语法,虽然字面量语法有个小小的限制,就是除了字符串以外,所创建出来的对象必须属于Foundation框架才行,如果自定义了这些类的子类,就无法用字面量语法实例化,但是一般也用不到自定义这种类的子类,整体还是有点大于缺点。

4). 定义属性

正确写法:

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

    苹果官网上说atomic可以保证线程的安全,因为在内部实现了锁的机制,但是并没有什么用,并不能保证线程安全,还消耗了性能,所以应该用nonatomic。
在.h文件中应该将属性定义成readonly,然后将这个属性在.m文件中再次定义成readwrite,这样外部只能通过set和get方法进行操作属性,使其更加安全。
对于拥有Mutable子类型的对象(e.g. NSString, NSArray, NSDictionary)一定要定义成copy属性. Why? 示例: NSArray的array = NSMutableArray的mArray; 如果mArray在某个地方改变了, 那array也会跟着改变.
尽量不要暴露mutable类型的对象在public interface, 建议在.h定义一个Inmutable类型的属性, 然后在.m的get函数里面返回一个内部定义的mutable变量.

5). BOOL赋值

正确写法:

BOOL isAdult = age > 18;

错误写法:

BOOL isAdult;

if (age > 18)

{

      isAdult = YES;

}

else

{

      isAdult = NO;

}

    明显的可以看出第一种的写法简练,易读,逻辑性强

6) 拒绝死值

正确写法:

if (car == Car.Nissan)

or

const int adultAge = 18; if (age > adultAge) { ... }

错误写法:

if (carName == "Nissan")

or

if (age > 18) { ... }

    应该将这种值都提出去,每次要改变其值,只要改变定义的就可以了,降低了出现难以寻找,忘记更改造成的错误。

7). 复杂的条件判断

正确写法:

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;

}

错误写法:

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

{

//....

}

8). 嵌套判断

正确写法:

if (!user.UserName) return NO;

if (!user.Password) return NO;

if (!user.Email) return NO;

return YES;

错误写法:

BOOL isValid = NO;

if (user.UserName)

{

      if (user.Password)

      {

            if (user.Email) isValid = YES;

      }

}

return isValid;

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

9). 参数过多

正确写法:

- (void)registerUser(User *user)

{

// to do...

}

错误写法:

- (void)registerUserName:(NSString *)userName password:(NSString *)password

email:(NSString *)email

{

// to do...

}

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

10). 回调方法

Preferred:

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

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

    Block的循环引用问题

    Block确实是个好东西, 但是用起来一定要注意循环引用的问题,我们基本上都是通过weak-strong dancing方法来解决循环引用问题

__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,

__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

      }

};

    那些年遇到的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静态分析一下。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,723评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,080评论 2 379
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,604评论 0 335
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,440评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,431评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,499评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,893评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,541评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,751评论 1 296
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,547评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,619评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,320评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,890评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,896评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,137评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,796评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,335评论 2 342

推荐阅读更多精彩内容

  • iOS编程规范0规范 0.1前言 为􏰀高产品代码质量,指导广大软件开发人员编写出简洁、可维护、可靠、可 测试、高效...
    iOS行者阅读 4,428评论 21 35
  • 概要 Objective-C是一门面向对象的动态编程语言,主要用于编写iOS和Mac应用程序。关于Objectiv...
    DreamMmMmM阅读 1,146评论 0 7
  • 一、命名规范 1、统一要求含义清楚,尽量做到不需要注释也能了解其作用,若做不到,就加注释,使用全称,不使用缩写。 ...
    Untils阅读 544评论 0 0
  • 课堂上我看到老师在黑板上写了黄刺枚三个字,我在想:它是不是一种开黄色玫瑰 的植物呢?上面应该还有刺,要不然怎么叫黄...
    小小的晴阅读 916评论 0 1