Objective-C #pragma

原著链接：http://nshipster.com/pragma/

Writteb by Mattt Thompson

  在OC语言中，#pragma声明是一种技术标识。尽管最初用于不同的编译器使源代码兼容，Xcode-savvy编码器由于不同的目的而使用#pragma声明。

  而到了现在，#pragma位于注释和代码之间的界限。作为一种预处理器指令，#pragma在编译时赋值。却又与其他的（例如，#ifdef...#endif）宏命令不一样，#pragma在应用程序运行时不会改变状态。反而，#pragma声明被Xcode用于完成两个主要的任务：组织代码和抑制编译器警告。

组织代码：

  代码组织是很重要的，代码的组建是你个人和工作的一种映射，缺乏习惯和内部一致性显示出，要么粗心大意或者更糟糕的没有能力，使工程继续协作存在困难。

  使用#pragma标识开始代码，是好的习惯。就像：

@implementation ViewController

-(id)init {

  ...
}

#pragma mark - UIViewConreoller

-(void)viewDidLoad {

  ...

}

#pragma mark -IBAction

-(IBAction)cancel:(id)sender {

  ...

}

  在@implementation的逻辑部分使用#pragma来分开代码，不仅方便阅读，而且添加Xcode的资源浏览的视觉线索（#pragma标识的声明，使用分隔栏来分开以破折号开头的方法）

  如果你的方法符合协议，首先按照不同的协议把全部的方法分组，在头部添加使用协议名字的#pragma标识。另一个好的习惯就是根据各自的超类来对子类进行分组。例如，一个NSInputStream的子类应该有一个NSInputStream标志的组，这是继承NSStream组的。一些好像IBAction,或者是响应机制，通知，KVO，选择器会选择最合适的方法。

  你的代码应该保持整洁，把时间用在看代码上而不是找代码。

抑制警告：

  #pragma标识已经成为了主流。在一个方面，#pragma声明，抑制编译器警告和静态分析都是很新的一种方法。

  你知道有什么比格式乱的代码更烦人的吗？那就是代码生成的警告。特别是第三方代码，和一个需要永远编译和拥有很多警告的数据库一样令人讨厌。甚至运行的代码有一个错误都会被淹没。

  但是有时候会有一些不可避免的编译错误，反通知和循环使用错误状态时比较常见的。这些比较少见的事例，绝对肯定是相惜编译或者静态分析错误应该抑制，#pragma会涉及到多次使用：

#pragma clang diagnostic push

#pragma clang diagnostic ignored "-Warc-retain-cycles"

  self.completionBlock = ^ {

    ...

  };

#pragma clang diagnostic pop

  这个代码实例是来自AFNetwork，这个案例是在静态分析中一个不可避免的错误。Clang通知是自身的block的强参，警告保留周期。然而，实现这个完成后通过nil-ing出强引用块完成。

  幸运的是，Clang提供了一种方便的方法来解决。#pragma clang diagnostic push/pop可以告诉编译器忽略某些特殊地方代码的警告，

  但是不要用这个来忽略某些合法的警告，否则到了后面就很麻烦。

  归纳：现在有两种＃pragma标识的方法可以明显的提高你的代码水平。#pragma仍然带着过去的痕迹：曾经是编译器的密语，而今重新用于程序员之间的交流。