#pragma

Mattt Thompson撰写、 Zihan Xu翻译、 发布于

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

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

整理你的代码

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

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

@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 声明前有一个水平分割并由破折号()开始)。

Xcode Sections

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

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

防止警告

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

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

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

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

// 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的强引用,并警告可能的保留周期。然而,setCompletionBlocksuper实现通过在块结束时将强引用设置为nil来解决这个问题。

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

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

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


这就是本篇的内容了:你可以使用#pragma声明来显著提升你的代码。

就像被你变成门厅里的台灯的旧货店里淘来的八轨播放器,#pragma保留了过去痕迹:编译器的神秘语言现在被重新利用以和其它程序员更好的沟通。多么美好的复古!