码迷,mamicode.com
首页 > 其他好文 > 详细

#pragma

时间:2015-04-07 11:16:24      阅读:133      评论:0      收藏:0      [点我收藏+]

标签:

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

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

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

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


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

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

 

 

转载http://nshipster.cn/pragma/

#pragma

标签:

原文地址:http://www.cnblogs.com/liuguanlei/p/4397496.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!