iOS之代码规范

一直觉得自己的代码写的渣，所以最近一直在看代码规范方面的知识，自己做了一个总结，顺便View层的结构也yy一下，让后来者易于阅读和维护：

重要性：

（1）提高UI层代码的可读性和可维护性

（2）防止UI层代码对整个框架产生腐蚀

（3）确保传承，让后来人更加容易上手

（4）解耦，让模块更加容易分离

一、代码规范，苹果官方文档有一套规范，链接在这：Coding Guidelines，大概写一下里面的规范姿势，以后慢慢翻译。记得以前自己看的一篇博客，写的非常nice，关于代码规范的，大概说一下其中的要点，对提升自己的代码可读性和逻辑的清晰度是非常有帮助的。原博客在这里：https://github.com/objc-zen/objc-zen-book#conditionals

条件

条件的主体部分应该写在｛｝里，来预防一些错误的发生，即使这个条件语句只有一行代码。因为有时候可能我们没有注意到，如果这个条件语句有两行代码，但是我们大意了，以为只有一行代码，这个时候就会出错，

所以，条件语句我们应该这样写：

if (!error) {
    return success;
}

而不是这样写：

if (!error)
    return success;

或者这样：

if (!error) return success;

2014年著名的goto语言bug就是因为这个原因出现的，下面重现一下：

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
                                 uint8_t *signature, UInt16 signatureLen)
{
  OSStatus        err;
  ...

  if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
    goto fail;
  if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;
  if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
    goto fail;
  ...

fail:
  SSLFreeBuffer(&signedHashes);
  SSLFreeBuffer(&hashCtx);
  return err;
}

待续。。。

二、UI层代码结构，先是lifecycle，然后是Delegate方法的实现，然后是event response

，最后是getters和setters，当然还有私有方法private method（比如日期换算，图片裁剪什么的），最好把它另外放到一个类里面或者category里，这样的话别人的阅读代码就会非常清晰，逻辑一目了然

1、首先lifecycle放在一块，这个是view的生命周期

2、然后delegate放在一块，每一个delegate的对应protocol名字也要带上，那么我们处理delegate时只要在那一块找就可以了

3、event response放在一块，比如所有的button、gestureRecognizer的响应事件都放在一起，处理方便，别人也方便阅读

4、getter和setter全部都放在最后，包括所有的值初始化，可以用一个或者多个函数，然后在life cycle里面的响应位置调用就行了

5、private methods 这个最好是另开一个类或者category写进去，因为这样的话controller就会非常的简洁，逻辑清晰，方便自己维护和他人阅读

大概如下：

#pragma mark - life cycle
- (void)viewDidLoad
- (void)viewWillAppear:(BOOL)animated
...
#pragma mark - XXXXdelegate
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
...
#pragma mark - event response
- (void)didTappedConfirmButton:(UIButton *)confirmButton
...
#pragma mark - getters and setters
- (UILabel *)label
- (UITableView *)tableView
...

三、UI层什么鬼？自己yy

1、除非必要，尽量减少继承

因为继承是强耦合，如果这个模块需要修改或者独立的话，解耦麻烦，还有就是用了继承的话，最好父类的不要涉及子类的逻辑，因为如果是父类有一部分逻辑，然后子类有一部分逻辑，这样可读性太差了，（看得我头好晕，一会跳到父类看一个逻辑，一会又要跳回来，好吧如果习惯了就没事），所以最好可以用组合模式代替继承，比如一个cell1由（A，B）组成，cell2由（A，C）组成，也就是说cell1和cell2只有一点点不同，如果看到这样需求，一般想到的都是cell2继承cell1，（A，B->C）,但是如果A也变成D的话，那么cell2就变成（A->D,B->C），如果ABCD的逻辑都不相同的话，cell2是不是就非常混乱了；用组合模式的话，就不会有这样的问题

2、给controller减压，能不放在controller里面的事情就尽量不要放在里面

因为controller是UI层主要的逻辑承载者，所以尽量能够逻辑清晰（比如日期计算，数据处理，图片裁剪什么的，放到工具类里面去）

3、不够清楚的地方或者是重要的逻辑最好用注释

未完待续。。。