你可能不知道的iOS冷知识——#pragma

　　　　　　　　　　　　　　　　Mattt Thompson撰写、 Zihan Xu翻译、 发布于2012年10月1日

　　#pragma 声明是彰显 Objective-C 工艺的标志之一。虽然 #pragma 最初的目的是为了使得源代码在不同的编译器下兼容的，但精明的Xcode编码器将 #pragma 使用到了极致。

　　在现在的背景下，#pragma 避开了注释和代码之间的界限。作为预处理指令，#pragma 在编译时进行计算。但它并不像如 #ifdef...#endif 之类的宏，#pragma 的使用方式不会改变你的应用运行时的行为。相反的，#pragma 声明主要由 Xcode 用来完成两个主要任务：整理代码和防止编译器警告。

整理你的代码

　　代码整理是一个卫生的问题。你如何组织你的代码反映的是你和你的工作。缺少惯性和内部一致性的代码表明要么有疏忽要么无能－－更糟的是，使得一个项目难以维持和协作。

　　好的习惯从#pragma mark开始。就像这样：

　　Objective-C

 

@implementation ViewController

- (id)init {
  ...
}

#pragma mark - UIViewController

- (void)viewDidLoad {
  ...
}

#pragma mark - IBAction

- (IBAction)cancel:(id)sender {
  ...
}

#pragma mark - UITableViewDataSource

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
  ...
}

#pragma mark - UITableViewDelegate

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
  ...
}

　　在你的 @implementation 中使用 #pragma mark 来将代码分割成逻辑区块。这些逻辑区块不仅仅使得阅读代码本身容易许多，也为Xcode源导航增加了视觉线索（#pragma mark 声明前有一个水平分割并由破折号（－）开始）。

　　如果你的类符合任何@protocols，先将各协议的方法放在一起，并添加#pragma mark以及协议的名称。另一个好的惯例是将各子类方法根据它们的超类组合放在一起。比如，一个NSInputStream子类应该放在NSStream的组里。如IBAction的出口，或者对应于目标／动作，通知，或者KVO选择器之类的方法也值得拥有它们各自的区块。

　　你的代码应该干净到你可以吃掉它。所以花点时间整理你的.m文件让它们比你生成它们时还干净。

防止警告

　　#pragma mark十分主流。另一方面，用#pragma声明来防止来自编译器或者静态分析器的警告现在还是很新鲜的。

　　你知道有什么是比有糟糕的格式的代码更烦人的吗？生成警告的代码。 尤其是第三方的代码。一个供应库要花很长时间来编译，终于成功编译时却生成了200+警告这种事实在很烦人。即使传送有一个警告的代码也很不好。

小提示：试试设置-Weverything标志，并在你的build setting里选择“Treat Warnings as Errors”。这将会开启Xcode的困难模式。

　　可是有的时候并没有办法避免编译器警告。弃用通知和保留周期误报是这个情况可能发生的常见情况。在这些罕见的，你绝对肯定一个特定的编译器或者稳态分析器警告需要被抑制时，#pragma就派上用场了：

Objective-C

 

// completionBlock在AFURLConnectionOperation中被手动的设置为nil来打破保留周期。
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Warc-retain-cycles"
    self.completionBlock = ^ {
        ...
    };
#pragma clang diagnostic pop

　　这个来自于AFNetworking (contributed by Peter Steinberger)的代码是一个不可避免的静态分析器警告的例子。Clang注意到块中指向self的强引用，并警告可能的保留周期。然而，setCompletionBlock的super实现通过在块结束时将强引用设置为nil来解决这个问题。

　　幸运的是，Clang提供了一个方便的方法来解决这一切。通过使用#pragma clang diagnostic push/pop，你可以告诉编译器仅仅为某一特定部分的代码（最初的诊断设置在最后的pop被恢复）来忽视特定警告。

你可以在Clang Compiler User's Manual读到更多关于#pragma的LLVM用法的知识。

　　只是不要用这种方法来清扫地毯下的合法的警告－－这将会给你带来麻烦。

原文地址：http://nshipster.cn/pragma/