谈谈Objective-C的警告(转载)

一个有节操的程序员会在乎自己的代码的警告，就像在乎饭碗边上有只死蟑螂那样。——@onevcat

重视编译警告

现在编译器有时候会很吵，而编译器给出的警告对开发者来说是很有用的信息。警告不会阻止继续编译和链接，也不会导致程序不能运行，但是很多时候编译器会先你一步发现问题所在，对于Objective-C来说特别如此。Clang不仅对于明显的错误能够提出警告（比如某方法或者接口未实现），也能对很多潜在可能的问题做出提示（比如方法已经废弃或者有问题的转换），而这些问题在很多时候都可能成为潜在的致命错误，必须加以重视。

像Ruby或者PHP这样的动态语言没有所谓的编译警告，而C#或者Java这类语言的警告很多都是不得不照顾的废弃方法什么的，很多开发者已经习惯于忽略警告进行开发。OC由于现在由苹果负责维护，Clang的LLVM也同时是苹果在做，可以说从语言到编译器到SDK全局都在掌握之中，因此做OC开发时的警告往往比其他语言的警告更有参考价值。打开尽可能多的警告提示，并且在程序开发中尽量避免生成警告，对于构建一个健壮高效的程序来说，是必须的。

在Xcode中开启额外警告提示

Xcode的工程模板已经为我们设置开启了一些默认和常用的警告提示，这些默认设置为了兼容一些上年头的项目，并没有打开很多，仅是指对最危险和最常见的部分进行了警告。这对于一个新项目来说这是不够用的（至少对我来说是不够用的），在无数前辈大牛的教导下，首先要做的事情就是打开尽可能多的警告提示。

最简单的方法是通过UI来打开警告。在Xcode中，Build Setting选项里为我们预留了一些打开警告的开关，找到并直接勾选相应的选项就可以打开警告。大部分时间里选项本身已经足够能描述警告的作用和产生警告的时机，如果不是很明白的话，在右侧的Quick Help面板里有更详细的说明。对于OC开发来说特有的警告都在Apple LLVM compiler 4.2 - Warnings - Objective C一栏中，不管您是不是决定打开它们，都是值得花时间看一看加以了解的，因为它们都是写OC程序时最应该避免的情况。另外几个Apple LLVM compiler 4.2 - Warnings - …(All languages和C++)也包含了大量的选项，以方便控制警告产生。

Xcode设置中的警告选项

当然在UI里一个一个点击激活警告虽然简单，但每次都这样来一回是一种一点也不有趣的做法，特别是在你已经了解它们的内容并决定打开它们的时候。在编译选项中加入合适的flag能够打开或者关闭警告：在Build Setting中的Other C Flags里添加形似-W...的编译标识。你可以在其中填写任意多的-W...以开关某些警告，比如，填写为-Wall -Wno-unused-variable即可打开“全部”警告（其实并不是全部，只是一大部分严重警告而已），但是不启用“未使用变量”的警告。使用-W...的形式，而不是在UI上勾选的一大好处是，在编译器版本更新时，新加入的警告如果包含在-Wall中的话，不需要对工程做任何修改，新的警告即可以生效。这样立即可以察觉到同一个工程由于编译器版本更新时可能带来的隐患。另外一个更重要的原因是..Xcode的UI并没有提供所有的警告 =_=||..

刚才提到的，需要注意的是，-Wall的名字虽然是all，但是这真的只是一个迷惑人的词语，实际上-Wall涵盖的仅只是所有警告中的一个子集。在StackExchange上有一个在Google工作的Clang开发者进行的回答，其中解释了有一些重要的警告组：

-Wall 并不是所有警告。这一个警告组开启的是编译器开发者对于“你所写的代码中有问题”这一命题有着很高的自信的那些警告。要是在这一组设定下你的代码出现了警告，那基本上就是你的代码真的存在严重问题了。但是同时，并不是说打开Wall就万事大吉了，因为Wall所针对的仅仅只是经典代码库中的为数不多的问题，因此有一些致命的警告并不能被其捕捉到。但是不论如何，因为Wall的警告提供的都是可信度和优先级很高的警告，所以为所有项目（至少是所有新项目）打开这组警告，应该成为一种良好的习惯。

-Wextra 如其所名，-Wextra组提供“额外的”警告。这个组和-Wall组几乎一样有用，但是有些情况下对于代码相对过于严苛。一个很常见的例子是，-Wextra中包含了-Wsign-compare，这个警告标识会开启比较时候对signed和unsigned的类型检查，当比较符两边一边是signed一边是unsigned时，产生警告。其实很多代码并没有特别在意这样的比较，而且绝大多数时候，比较signed和unsigned也是没有太大问题的（当然不排除会有致命错误出现的情况）。需要注意，-Wextra和-Wall是相互独立的两个警告组，虽然里面打开的警告标识有个别是重复的，但是两组并没有包含的关系。想要同时使用的话必须在Other C Flags中都加上.

-Weverything 这个是真正的所有警告。但是一般开发者不会选择使用这个标识，因为它包含了那些还正在开发中的可能尚存bug的警告提示。这个标识一般是编译器开发者用来调试时使用的，如果你想在自己的项目里开启的话，警告一定会爆棚导致你想开始撞墙..

-Wall和-Wextra下0警告的工程，在-Weverything下的表现，可以用惨不忍睹来形容

关于某个组开启了哪些警告的说明，在GCC的手册中有一个参考。虽然苹果现在用的都是LLVM了，但是这部分内容应该是继承了GCC的设定。

控制警告，局部加入或关闭

Clang提供了我们自己加入警告或者暂时关闭警告的办法。

强制加入一个警告：

  1. //Generate a warning
  2. #pragma message "Warning 1"
  3. //Another way to generate a warning
  4. #warning "Warning 2"

两种强制警告的方法在视觉效果上结果是一样的，但是警告类型略有不同，一个是-W#pragma-messages，另一个是-W#warnings。对于第二种写法，把warning换成error，可以强制使编译失败。比如在发布一些需要API Key之类的类库时，可以使用这个方法来提示别的开发者别忘了输入必要的信息。

  1. //Generate an error to fail the build.
  2. #error "Something wrong"

对于关闭某个警告，如果需要全局关闭的话，直接在Other C Flags里写-Wno-...就行了，比如-Wextra -Wno-sign-compare就是一个常见的组合。如果相对某几个文件开启或禁用警告，在Build Phases的Compile Source相应的文件中加入对应的编译标识即可。如果只是想在某几行关闭某个警告的话，可以通过临时改变诊断编译标记来抑制指定类型的警告，具体如下：

  1. #pragma clang diagnostic push
  2. #pragma clang diagnostic ignored "-Wunused-variable"
  3. int a;
  4. #pragma clang diagnostic pop

如果a之后没有被使用，也不会出未使用变量的警告了。对于想要抑制的警告类型的标识名，可以在build产生该警告后的build log中看到。Xcode中的话，快捷键Cmd+7然后点击最近的build log中，进入详细信息中就能看到了。

警告的详细信息，可以找到标识符

我应该开启哪些警告提示

个人喜好（代码洁癖）不同，会有不同的需求。我的建议是对于所有项目，特别是新开的项目，首先开启-Wall和-Wextra，然后在此基础上构建项目并且避免一切警告。如果在开发过程中遇到了某些确实无法解决或者确信自己的做法是正确的话（其实这种情况，你的做法一般即使不是错误的，也会是不那么正确的），可以有选择性地关闭某些警告。一般来说，关闭的警告项目不应该超过一只手能数出来的数字，否则一定哪儿出问题了..

是否要让警告等于错误

一种很常见的做法和代码洁癖是将警告标识为错误，从而中断编译过程。这让开发者不得不去修复这些警告，从而保持代码干净整洁。在Xcode中，可以通过勾选相应的Treat Warnings as Errors来开启，或者加入-Werror标识。我个人来说不喜欢使用这个设定，因为它总是打断开发流程。很多时候并不可能把代码全写完再编译调试，相反地，我更喜欢写一点就编译运行一下看看结果，这样在中间debug编译的时候会出现警告也不足为奇。另外，如果做TDD开发时，也可能会有大量正常的警告出现，如果有警告就不让编译的话，开发效率可能会打折扣。一个比较好的做法是只在Release Build时将警告视为错误，因为Xcode中是可以为Debug和Release分别指定标识的，所以这很容易做到。

另外也可以只把某些警告当作错误，-Werror=...即可，同样地，也可以在-Werror被激活时使用-Wno-error=...来使某些警告不成为错误。结合使用这些编译标识可以达到很好的控制。

首先, #pragma 本质上也是声明，一般常用的功能就是打注释、尤其是分段注释

但是#pragma 另外一个强大的功能就是处理编译器警告，用的时候可能就没上一个

功能用的那么多，在代码中处理警告却是极其高效的方法。

其中 clang diagnostic 便是#pragma 第一个功能常用的命令，步骤如下


1

2

3

4

#pragma clang diagnostic push

#pragma clang diagnostic ignored "-相关命令"

    // 你自己的代码

#pragma clang diagnostic pop

常见用法

1.方法弃用告警


1

2

3

4

5

6

#pragma clang diagnostic push 

  

#pragma clang diagnostic ignored "-Wdeprecated-declarations"

[TestFlight setDeviceIdentifier:[[UIDevice currentDevice] uniqueIdentifier]]; 

  

#pragma clang diagnostic pop

2.不兼容指针类型


1

2

3

4

#pragma clang diagnostic push  

#pragma clang diagnostic ignored "-Wincompatible-pointer-types"

// 

#pragma clang diagnostic pop

3.循环引用


1

2

3

4

5

6

7

// completionBlock is manually nilled out in AFURLConnectionOperation to break the retain cycle. 

#pragma clang diagnostic push 

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

    self.completionBlock = ^ { 

        ... 

    }; 

#pragma clang diagnostic pop

4.未使用变量


1

2

3

4

#pragma clang diagnostic push  

#pragma clang diagnostic ignored "-Wunused-variable"

  int a;  

#pragma clang diagnostic pop

 

#pargma 用法详情：

http://nshipster.cn/pragma/

http://nshipster.com/clang-diagnostics/

相关的命令列表

http://fuckingclangwarnings.com/

进阶：

http://clang.llvm.org/docs/UsersManual.html#diagnostics_pragmas

时间： 2024-08-30 04:08:15

谈谈Objective-C的警告(转载)的相关文章

Spring中的事务与数据库中的锁关系

本文只先简单的介绍下Spring中的事务与DB中锁的关系. 首先总结:Spring事务的实现本质上是使用的DB中的事务,而DB中的事务实现又主要依靠DB中的锁.所以spring事务本质上使用数据库锁,开启spring事务意味着使用数据库锁. 所以大家一定要厘清DB事务与DB各种锁的原理与概念.后续我也研究一下DB锁,并结合具体的生产环境监控数据来谈谈. <以下是转载部分内容.主要是Spring事务的使用方式.隔离级别之类的> 那么事务的隔离级别与锁有什么关系呢?本人认为事务的隔离级别是通过锁的

谈谈Objective-C的警告 (转)

原文地址:http://onevcat.com/2013/05/talk-about-warning/ 一个有节操的程序员会在乎自己的代码的警告,就像在乎饭碗边上有只死蟑螂那样. ——@onevcat 重视编译警告 现在编译器有时候会很吵,而编译器给出的警告对开发者来说是很有用的信息.警告不会阻止继续编译和链接,也不会导致程序不能运行,但是很多时候编译器会先你一步发现问题所在,对于Objective-C来说特别如此.Clang不仅对于明显的错误能够提出警告(比如某方法或者接口未实现),也能对很多

转载---谈谈redis,memcache的区别和具体应用场景

转载地址:http://www.cnblogs.com/Hondsome/p/5962144.html 1. Memcached简介 Memcached是以LiveJurnal旗下Danga Interactive公司的Bard Fitzpatric为首开发的高性能分布式内存缓存服务器.其本质上就是一个内存key-value数据库,但是不支持数据的持久化,服务器关闭之后数据全部丢失.Memcached使用C语言开发,在大多数像Linux.BSD和Solaris等POSIX系统上,只要安装了lib

谈谈对程序员的培养（转载），或许我们可以停下来思考思考

申明:本文转载来自原创:http://raychase.iteye.com/blog/1450079 这篇文字是我好久以来的想法,有一些感悟,有一些激烈的言辞,我很自豪我就是一名程序员,我希望给程序员或者前程序员们带来一点启发.也许你认可我的言辞,也许你不屑我的观点,无论如何,欢迎谈谈你的看法. 让程序员做更多种类的事 为什么有人说小公司锻炼人?在小公司,条件并不那么齐备,很多事情都需要程序员自己做,自己去澄清需求.自己做设计.自己搭建环境.自己测试,甚至自己上线.自己维护(这件事情在我们团队被

谈谈C++的三大特性之一：封装性 （转载）

引言 对象的C++语言与以往的模块化程序语言的不同点在于:数据与操作数据的函数连接起来(即:封装性),结构紧凑,数据安全.正是由于这种封装性,大大强化了C++语言的可移植性及数据的安全性.类封装的形式很简单,本文主要谈谈封装的内部结构. 实例问题 类的内部数据存储地址仅表示相对对象首地址的地址偏移量.实例(引自:疯狂学习ING<作者网名>)如下: #include <iostream.h> class base { // 假定有很多成员 //..... //..... }; cla

【转载】谈谈Cookie

0×00 引言 在Web技术的发展史上,Cookie技术的出现是一次重大的 变革.但是, Cookie技术又是一项非常有争议的技术,从它诞生之日起就成了广大网络用户和Web开发人员的一个争论焦点,原因不是Cookie的功能太弱,而是认为Cookie的使用会对网络用户的隐私信息构成危害. Cookie技术最先被Netscape公司引入到Navigator浏览器中.之后,WoridWideWeb协会支持并采纳了Cookie标准,微软也在InternetExpiorer浏览器中使用了Cookie.现在

[转载]什么是“成功的项目”：谈谈软件的价值

题外话: 由于职业规划的需要,开始职场新挑战,加入一家新公司,开始项目管理工作,感谢新东家的信任和支持,给我这个机会,我将投入更多的精力把接下来的工作做到尽善尽美,为公司创造更大的价值. 为项目管理工作做好,需思考什么是成功的项目?什么是成功的项目经理?如何做才能更好的保障项目成功?如何制度化.体系化.流程化.信息化搭建企业管理? 其实会发现项目管理是个永恒的话题,中小型公司都存在不一样的项目管理困惑,大型公司比较系统化的项目管理方法不太适合,探索适应“国情”的项目管理之法. 原文如下: 在开始

谈谈类之间的关联关系与依赖关系(转载)

(转载自:http://www.cnblogs.com/iyangyuan/archive/2013/06/16/3138463.html) 对于很多刚刚接触UML的童鞋,可能会对类之间的关联与依赖关系不太理解,今天小菜就浅薄的讲一下. 这块的确是有点乱,不过小菜突然找到了一个比较好的切入点,拿出来分享一下. 接触过设计模式的读者,会经常看到这样的场景:在实例化A类的时候,需要B类作为构造方法的参数,这说明A类需要持有一个B类的引用.比如代理模式.装饰模式等,都会这样做.例如Java中的IO流采

Hardcoded string &quot;下一步&quot;, should use @string resource警告 （转载）

转自:http://blog.csdn.net/iqv520/article/details/7579513 在布局文件中,文本的设置使用如下写法时会有警告:Hardcoded string "下一步", should use @string resource <Button android:id="@+id/button1" android:layout_width="118dp" android:layout_height="