一個有節(jié)操的程序員會在乎自己的代碼的警告，就像在乎飯碗邊上有只死蟑螂那樣。 ——@onevcat

重視編譯警告

現(xiàn)在編譯器有時候會很吵，而編譯器給出的警告對開發(fā)者來說是很有用的信息。警告不會阻止繼續(xù)編譯和鏈接，也不會導(dǎo)致程序不能運行，但是很多時候編譯器會先你一步發(fā)現(xiàn)問題所在，對于Objective-C來說特別如此。Clang不僅對于明顯的錯誤能夠提出警告（比如某方法或者接口未實現(xiàn)），也能對很多潛在可能的問題做出提示（比如方法已經(jīng)廢棄或者有問題的轉(zhuǎn)換），而這些問題在很多時候都可能成為潛在的致命錯誤，必須加以重視。

像Ruby或者PHP這樣的動態(tài)語言沒有所謂的編譯警告，而C#或者Java這類語言的警告很多都是不得不照顧的廢棄方法什么的，很多開發(fā)者已經(jīng)習(xí) 慣于忽略警告進行開發(fā)。OC由于現(xiàn)在由蘋果負(fù)責(zé)維護，Clang的LLVM也同時是蘋果在做，可以說從語言到編譯器到SDK全局都在掌握之中，因此做OC 開發(fā)時的警告往往比其他語言的警告更有參考價值。打開盡可能多的警告提示，并且在程序開發(fā)中盡量避免生成警告，對于構(gòu)建一個健壯高效的程序來說，是必須 的。

在Xcode中開啟額外警告提示

Xcode的工程模板已經(jīng)為我們設(shè)置開啟了一些默認(rèn)和常用的警告提示，這些默認(rèn)設(shè)置為了兼容一些上年頭的項目，并沒有打開很多，僅是指對最危險和最 常見的部分進行了警告。這對于一個新項目來說這是不夠用的（至少對我來說是不夠用的），在無數(shù)前輩大牛的教導(dǎo)下，首先要做的事情就是打開盡可能多的警告提 示。

最簡單的方法是通過UI來打開警告。在Xcode中，Build Setting選項里為我們預(yù)留了一些打開警告的開關(guān)，找到并直接勾選相應(yīng)的選項就可以打開警告。大部分時間里選項本身已經(jīng)足夠能描述警告的作用和產(chǎn)生警 告的時機，如果不是很明白的話，在右側(cè)的Quick Help面板里有更詳細(xì)的說明。對于OC開發(fā)來說特有的警告都在Apple LLVM compiler 4.2 - Warnings - Objective C一欄中，不管您是不是決定打開它們，都是值得花時間看一看加以了解的，因為它們都是寫OC程序時最應(yīng)該避免的情況。另外幾個Apple LLVM compiler 4.2 - Warnings - …(All languages和C++)也包含了大量的選項，以方便控制警告產(chǎn)生。

當(dāng)然在UI里一個一個點擊激活警告雖然簡單，但每次都這樣來一回是一種一點也不有趣的做法，特別是在你已經(jīng)了解它們的內(nèi)容并決定打開它們的時候。在編譯選項中加入合適的flag能夠打開或者關(guān)閉警告：在Build Setting中的Other C Flags里添加形似-W...的編譯標(biāo)識。你可以在其中填寫任意多的-W...以開關(guān)某些警告，比如，填寫為-Wall -Wno-unused-variable即可打開“全部”警告（其實并不是全部，只是一大部分嚴(yán)重警告而已），但是不啟用“未使用變量”的警告。使用-W...的形式，而不是在UI上勾選的一大好處是，在編譯器版本更新時，新加入的警告如果包含在-Wall中的話，不需要對工程做任何修改，新的警告即可以生效。這樣立即可以察覺到同一個工程由于編譯器版本更新時可能帶來的隱患。另外一個更重要的原因是..Xcode的UI并沒有提供所有的警告 =_=||..

剛才提到的，需要注意的是，-Wall的名字雖然是all，但是這真的只是一個迷惑人的詞語，實際上-Wall涵蓋的僅只是所有警告中的一個子集。在StackExchange上有一個在Google工作的Clang開發(fā)者進行的回答，其中解釋了有一些重要的警告組：

• -Wall 并不是所有警告。這一個警告組開啟的是編譯器開發(fā)者對于“你所寫的代碼中有問題”這一命題有著很 高的自信的那些警告。要是在這一組設(shè)定下你的代碼出現(xiàn)了警告，那基本上就是你的代碼真的存在嚴(yán)重問題了。但是同時，并不是說打開Wall就萬事大吉了，因 為Wall所針對的僅僅只是經(jīng)典代碼庫中的為數(shù)不多的問題，因此有一些致命的警告并不能被其捕捉到。但是不論如何，因為Wall的警告提供的都是可信度和 優(yōu)先級很高的警告，所以為所有項目（至少是所有新項目）打開這組警告，應(yīng)該成為一種良好的習(xí)慣。
• -Wextra 如其所名，-Wextra組提供“額外的”警告。這個組和-Wall組幾乎一樣有用，但是有些情況下對于代碼相對過于嚴(yán)苛。一個很常見的例子是，-Wextra中包含了-Wsign-compare， 這個警告標(biāo)識會開啟比較時候?qū)igned和unsigned的類型檢查，當(dāng)比較符兩邊一邊是signed一邊是unsigned時，產(chǎn)生警告。其實很多 代碼并沒有特別在意這樣的比較，而且絕大多數(shù)時候，比較signed和unsigned也是沒有太大問題的（當(dāng)然不排除會有致命錯誤出現(xiàn)的情況）。需要注 意，-Wextra和-Wall是相互獨立的兩個警告組，雖然里面打開的警告標(biāo)識有個別是重復(fù)的，但是兩組并沒有包含的關(guān)系。想要同時使用的話必須在Other C Flags中都加上
• -Weverything 這個是真正的所有警告。但是一般開發(fā)者不會選擇使用這個標(biāo)識，因為它包含了那些還正在開發(fā)中的可能尚存bug的警告提示。這個標(biāo)識一般是編譯器開發(fā)者用來調(diào)試時使用的，如果你想在自己的項目里開啟的話，警告一定會爆棚導(dǎo)致你想開始撞墻..

關(guān)于某個組開啟了哪些警告的說明，在GCC的手冊中有一個參考。雖然蘋果現(xiàn)在用的都是LLVM了，但是這部分內(nèi)容應(yīng)該是繼承了GCC的設(shè)定。

控制警告，局部加入或關(guān)閉

Clang提供了我們自己加入警告或者暫時關(guān)閉警告的辦法。

強制加入一個警告：

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

兩種強制警告的方法在視覺效果上結(jié)果是一樣的，但是警告類型略有不同，一個是-W#pragma-messages，另一個是-W#warnings。對于第二種寫法，把warning換成error，可以強制使編譯失敗。比如在發(fā)布一些需要API Key之類的類庫時，可以使用這個方法來提示別的開發(fā)者別忘了輸入必要的信息。

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

對于關(guān)閉某個警告，如果需要全局關(guān)閉的話，直接在Other C Flags里寫-Wno-...就行了，比如-Wextra -Wno-sign-compare就是一個常見的組合。如果相對某幾個文件開啟或禁用警告，在Build Phases的Compile Source相應(yīng)的文件中加入對應(yīng)的編譯標(biāo)識即可。如果只是想在某幾行關(guān)閉某個警告的話，可以通過臨時改變診斷編譯標(biāo)記來抑制指定類型的警告，具體如下：

#pragma clang diagnostic push 
#pragma clang diagnostic ignored "-Wunused-variable" 
 
int a; 
 
#pragma clang diagnostic pop 

如果a之后沒有被使用，也不會出未使用變量的警告了。對于想要抑制的警告類型的標(biāo)識名，可以在build產(chǎn)生該警告后的build log中看到。Xcode中的話，快捷鍵Cmd+7然后點擊最近的build log中，進入詳細(xì)信息中就能看到了。

我應(yīng)該開啟哪些警告提示

個人喜好（代碼潔癖）不同，會有不同的需求。我的建議是對于所有項目，特別是新開的項目，首先開啟-Wall和-Wextra， 然后在此基礎(chǔ)上構(gòu)建項目并且避免一切警告。如果在開發(fā)過程中遇到了某些確實無法解決或者確信自己的做法是正確的話（其實這種情況，你的做法一般即使不是錯 誤的，也會是不那么正確的），可以有選擇性地關(guān)閉某些警告。一般來說，關(guān)閉的警告項目不應(yīng)該超過一只手能數(shù)出來的數(shù)字，否則一定哪兒出問題了..

是否要讓警告等于錯誤

一種很常見的做法和代碼潔癖是將警告標(biāo)識為錯誤，從而中斷編譯過程。這讓開發(fā)者不得不去修復(fù)這些警告，從而保持代碼干凈整潔。在Xcode中，可以通過勾選相應(yīng)的Treat Warnings as Errors來開啟，或者加入-Werror標(biāo) 識。我個人來說不喜歡使用這個設(shè)定，因為它總是打斷開發(fā)流程。很多時候并不可能把代碼全寫完再編譯調(diào)試，相反地，我更喜歡寫一點就編譯運行一下看看結(jié)果， 這樣在中間debug編譯的時候會出現(xiàn)警告也不足為奇。另外，如果做TDD開發(fā)時，也可能會有大量正常的警告出現(xiàn)，如果有警告就不讓編譯的話，開發(fā)效率可 能會打折扣。一個比較好的做法是只在Release Build時將警告視為錯誤，因為Xcode中是可以為Debug和Release分別指定標(biāo)識的，所以這很容易做到。

另外也可以只把某些警告當(dāng)作錯誤，-Werror=...即可，同樣地，也可以在-Werror被激活時使用-Wno-error=...來使某些警告不成為錯誤。結(jié)合使用這些編譯標(biāo)識可以達到很好的控制。