原文發佈於http://onevcat.com/2013/05/talk-about-warning/?utm_source=tuicool&utm_medium=referral
一個有節操的程序員會在乎自己的代碼的警告，就像在乎飯碗邊上有隻死蟑螂那樣。 ——@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++)也包含了大量的選項，以方便控制警告產生。
當然在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的警告提示。這個標識一般是編譯器開發者用來調試時使用的，如果你想在自己的項目裏開啓的話，警告一定會爆棚導致你想開始撞牆..
關於某個組開啓了哪些警告的說明，在GCC的手冊中有一個參考。雖然蘋果現在用的都是LLVM了，但是這部分內容應該是繼承了GCC的設定。
控制警告，局部加入或關閉
Clang提供了我們自己加入警告或者暫時關閉警告的辦法。
強制加入一個警告：
//Generate a warning
#pragma message "Warning 1"
//Another way to generate a warning
#warning "Warning 2"
兩種強制警告的方法在視覺效果上結果是一樣的，但是警告類型略有不同，一個是-W#pragma-messages，另一個是-W#warnings。對於第二種寫法，把warning換成error，可以強制使編譯失敗。比如在發佈一些需要API
Key之類的類庫時，可以使用這個方法來提示別的開發者別忘了輸入必要的信息。
//Generate an error to fail the build.
#error "Something wrong"
對於關閉某個警告，如果需要全局關閉的話，直接在Other C Flags裏寫-Wno-...就行了，比如-Wextra
-Wno-sign-compare就是一個常見的組合。如果相對某幾個文件開啓或禁用警告，在Build Phases的Compile Source相應的文件中加入對應的編譯標識即可。如果只是想在某幾行關閉某個警告的話，可以通過臨時改變診斷編譯標記來抑制指定類型的警告，具體如下：
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wunused-variable"
int a;
#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=...來使某些警告不成爲錯誤。結合使用這些編譯標識可以達到很好的控制。
