zoukankan      html  css  js  c++  java
  • #pragma

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

    Xcode Sections

    如果你的类符合任何@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/

  • 相关阅读:
    oracle客户端连接服务器基本教程
    java中字符串处理、串联和转换的几个常用方法,以及如果需要自己编程实现的具体实施步骤。
    面试相关
    java中byte是什么类型,和int有什么区别
    (华为机试大备战)java。多了解了解最常用的那个类库的方法对处理字符串的方法
    (华为)以下代码片段将创建一个仅保存大写字符的字段。
    (华为)以下代码片段将创建一个仅保存大写字符的字段。
    每个程序中只有一个public类,主类?
    我的第一个长程序,虽然是直接抄了书上,可是还是出现了两次拼写错误,最终还是找到异常的答案,改过来了。
    实践证明:当类想实现两个监听接口的时候,必须把两个都设置成内部类,不可能一个是外部类实现,一个是内部类实现。这样容易捕获错误,出现异常。
  • 原文地址:https://www.cnblogs.com/liuguanlei/p/4397496.html
Copyright © 2011-2022 走看看