警告是否重要？

編輯：我已經修復了除了兩個警告之外，所以謝謝大家的建議和鼓勵。我已經離開了兩個警告要求我更改數據庫：警告是否重要？

/Locations.xcdatamodel:tiles.Map：警告：tiles.Map - 關係不具有逆

/Locations.xcdatamodel： Waypoint.description：警告：Waypoint.description - 屬性名稱與已經在NSObject或NSManagedObject上的方法衝突

我有一個iPhone應用程序在編譯時會拋出超過100個警告，但它是經過時間測試的。

我應該關心警告嗎？

EDIT因爲受訪者問，這裏是我的一些警告：

 
Warning: Multiple build commands for output file /Users/andrewljohnson/Desktop/thetrailbehind/TrailTracker/build/Debug-iphonesimulator/Gaia Places.app/wrench.png 

/Locations.xcdatamodel:tiles.Map: warning: tiles.Map -- relationship does not have an inverse 

/Locations.xcdatamodel:Waypoint.description: warning: Waypoint.description -- property name conflicts with a method already on NSObject or NSManagedObject 

/TrailTrackerAppDelegate.m:58: warning: passing argument 1 of 'initWithViewController:withTitle:' from distinct Objective-C type 
/Users/andrewljohnson/Desktop/thetrailbehind/TrailTracker/Classes/TrailTrackerAppDelegate.m: In function '-[TrailTrackerAppDelegate applicationDidFinishLaunching:]': 

/Users/andrewljohnson/Desktop/thetrailbehind/TrailTracker/Classes/TrailTrackerAppDelegate.m:202: warning: no '-initWithFrame:forHelpScreen:' method found 
/Users/andrewljohnson/Desktop/thetrailbehind/TrailTracker/Classes/TrailTrackerAppDelegate.m:202: warning: (Messages without a matching method signature 

/TrailTrackerAppDelegate.m:329: warning: 'gpsController' may not respond to '-setAccuracy:' 
/Users/andrewljohnson/Desktop/thetrailbehind/TrailTracker/Classes 

/TrailTrackerAppDelegate.m:411: warning: local declaration of 'tabBarController' hides instance variable 

/TrailTrackerAppDelegate.m:422: warning: 'TrailTrackerAppDelegate' may not respond to '-getAudioPlayer:' 

/Users/andrewljohnson/Desktop/thetrailbehind/TrailTracker/Classes/TrailTrackerAppDelegate.m:633: warning: 'Reachability' may not respond to '-isHostReachable:' 

/Users/andrewljohnson/Desktop/thetrailbehind/TrailTracker/Classes/TrailTrackerMapView.h:18: warning: 'myTopoMapSource' defined but not used 

warning: 'dbCache' defined but not used 

/TrailTrackerAppDelegate.m:58: warning: passing argument 1 of 'initWithViewController:withTitle:' from distinct Objective-C type 
    /Users/andrewljohnson/Desktop/thetrailbehind/TrailTracker/Classes 

/Users/andrewljohnson/Desktop/thetrailbehind/TrailTracker/Classes/TripViewController.m:68: warning: 'TripViewController' may not respond to '-checkForNullImages' 

/Users/andrewljohnson/Desktop/thetrailbehind/TrailTracker/Classes/TripViewController.m:94: warning: 'TrailTrackerAppDelegate' may not respond to '-blamblamblam' 

/Users/andrewljohnson/Desktop/thetrailbehind/TrailTracker/Classes/MapViewController.m:406: warning: passing argument 1 of 'initWithData:' from distinct Objective-C type

來源

2009-09-05 Andrew Johnson

是。一些警告可能很重要。

最好的做法是將編譯器的警告級別設置爲最高設置，並嘗試消除所有警告。

如果通過重構代碼無法刪除警告，並且已經檢查並認爲它是安全的，那麼許多語言都會使用「雜注」來使警告消失。

更新大約在2014年：打開一個將所有警告視爲錯誤的編譯器選項的情況越來越普遍。我親自做這個。

來源

2009-09-05 00:13:22

因此，對我來說是一種折衷。我花費每秒修復警告是第二次我不花費改進應用程序。所以，即使這是最佳實踐，對於擁有如此有限資源的人來說，最好的做法是什麼？ – 2009-09-05 00:48:08

有人在其他答案之一的註釋中註釋（http://stackoverflow.com/questions/1382024/do-warnings-matter/1382040#1382040）可以得到的更嚴重警告之一，「X可能不會迴應給Y留言「。你似乎有不止一些，所以我會說你的警告可能是嚴重的。要判斷它們有多重要，你應該閱讀它們並理解它們的含義，以便即使你不需要修復它們，你至少也知道它們爲什麼會發生。 – 2009-09-05 00:54:09

通常，修復警告*是爲了改進應用程序，至少從未來維護者的角度來看。如果代碼在現在簽入時編譯清理警告，那麼在維護期間任何新警告都會大聲突出。 – RBerteig 2009-09-05 00:56:00

大聲笑我想這取決於警告是什麼！

如果你有超過100個，但它運行得很好，我猜它們可能是類型「對象xxx可能不響應消息yyy」的警告 - 即你在應用程序中創建的新方法尚未在頭文件中設置適當的聲明，因此您的編譯器無法檢查它們是否是有效的方法調用（或者更確切地說是發送到您的自定義類的消息）。

Objective-C中的許多警告實際上會警告您會導致應用程序崩潰的錯誤 - 事實上，XCode中甚至有一個選項將「將所有警告視爲錯誤」。你的應用程序運行的事實表明你沒有遭受這個問題（或者至少還沒有）。

但是，即使您的所有警告都是良性的（我懷疑），但仍有充分的理由修復它們。如果其關於類的方法，您將能夠在之前找出，無論您是否向其發送有效的消息，您都會遇到崩潰。而對於大多數其他類型的警告，你最好知道它。

我想最後一個例外是如果你使用了很多廢棄的方法。那麼你可能會決定放棄它們，雖然這是一個危險的策略。

所以我們回到了開始 - 它取決於它們是什麼！不過，我99％確定這將是一項有價值的練習來修復它們。他們在那裏幫助你，而不是！

來源

2009-09-05 00:16:33 h4xxr

「對象xxx可能不響應消息yyy」是表示實際錯誤的最常見警告之一。由於ObjC是動態的，如果你實際運行引起這個警告的代碼行，你只會遇到麻煩。那時你會在iPhone上崩潰。事實上，您的程序在開發環境下運行並不意味着您可以通過可能爆炸的代碼獲得代碼覆蓋率。添加標題很簡單，並且可以爲您節省非常令人沮喪的問題。 – 2009-09-05 00:25:07

Rob - 如果他沒有設置他的頭文件來匹配他的.m文件，那麼他會得到這個警告，但是這個消息實際上會被髮送到類實例併成功執行。我同意我的代碼（也許是你的？）它會崩潰，因爲我特別確保我的.h和.m文件匹配！但如果他們沒有，你會得到警告，但它會運行。無論如何，我們都同意主要觀點 - 他應該花時間將信息放入.h文件，因爲這非常值得。 – h4xxr 2009-09-05 01:03:25

：我們去了，就像我說的 - 現在OP已經發布了他的一些警告，其中很多都是「可能不會迴應」的警告。它們運行正常，因爲所討論的類* do *實際上有一個實現的方法，但.h文件與.m文件不同步，所以它被標記爲警告。他需要解決這個問題！ - 因爲否則它隱藏真正的問題... – h4xxr 2009-09-05 01:09:10

我的直覺答案絕對是全心全意的。

編譯器警告在那裏幫助你寫清晰，易於維護的代碼，減少引入以後或者在運行時突然出現錯誤的可能性。

編譯器通常會捕獲到像未使用的變量，訪問未初始化的變量，不從函數返回正確等，這些東西可能不是一個問題，現在還是測試，但後來很容易出現並擰你。

我會去通過這些警告，並試圖立即解決它們。這將花費時間。

來源

2009-09-05 00:20:50 Jamie314

是

來源

2009-09-05 00:24:07

肯定是的。否則，爲什麼它會被稱爲警告？

來源

2009-09-05 00:45:57 Langali

如果我可以給ObjC開發一個忠告，那就是「使用存取，永遠。」但是如果我能給他們兩條建議，第二條將會「開啓」，將警告視爲錯誤。「

保持可可零預警政策也許是最好的成本/收益權衡，我知道的。很少有警告在Cocoa中很難修復。在編寫可移植的C++時，避免警告往往非常具有挑戰性（有時幾乎不可能），但Cocoa在兩個非常相似的平臺上有單個編譯器。 Cocoa中幾乎沒有什麼需要做的事情，它應該跳過默認的警告集。

警告產生警告。當你說「好吧，我知道那些121警告，他們沒事」，當它變成122警告並且新的警告很重要時，很容易錯過。如果您有一個警告，確實需要解決該問題，請禁止警告，但不要在構建輸出中忽略它們。

我的團隊變成了警告非常高，而且隨着時間的推移，我們已經不得不調整他們背下來一點點，但我們仍然建立在以下警告標誌在Mac和iPhone主要的Objective-C++項目。其中有一些可以肯定會出現在某個特定的項目中，但這是我的團隊的默認設置，我們不會拿出很多。我在討論project templates時多談了一會兒。那裏的zip文件包括Shared.xcconfig，它記錄了這些文件的作用以及它爲什麼打開或關閉。但是Xcode給出的默認設置是最小的。

GCC_TREAT_WARNINGS_AS_ERRORS = YES 
WARNING_CFLAGS = -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wno-unknown-pragmas -Wextra-tokens -Wformat-nonliteral -Wformat-security -Winit-self -Wswitch-enum -Wswitch-default -Wfloat-equal -Wpointer-arith -Wredundant-decls -Winvalid-pch -Wlong-long -Wdisabled-optimization 
OTHER_CFLAGS = -Wnested-externs -Wold-style-definition -Wstrict-prototypes -Wundeclared-selector 
OTHER_CPLUSPLUSFLAGS = -Wsign-promo -Wundeclared-selector 
GCC_WARN_CHECK_SWITCH_STATEMENTS = YES 
GCC_WARN_FOUR_CHARACTER_CONSTANTS = YES 
GCC_WARN_64_TO_32_BIT_CONVERSION = YES 
GCC_WARN_INITIALIZER_NOT_FULLY_BRACKETED = YES 
GCC_WARN_ABOUT_RETURN_TYPE = YES 
GCC_WARN_MISSING_PARENTHESES = YES 
GCC_WARN_NON_VIRTUAL_DESTRUCTOR = YES 
GCC_WARN_HIDDEN_VIRTUAL_FUNCTIONS = YES 
GCC_WARN_SIGN_COMPARE = YES 
GCC_TREAT_IMPLICIT_FUNCTION_DECLARATIONS_AS_ERRORS = YES 
GCC_WARN_TYPECHECK_CALLS_TO_PRINTF = YES 
GCC_WARN_UNUSED_FUNCTION = YES 
GCC_WARN_UNUSED_LABEL = YES 
GCC_WARN_UNUSED_VALUE = YES 
GCC_WARN_UNUSED_VARIABLE = YES 
GCC_WARN_UNINITIALIZED_AUTOS = YES

來源

2009-09-05 00:52:22

許多這些警告在程序中看起來像無關的東西，是無害的。然而，當你有100個警告時，你知道並不重要（我並不是說所有這些都沒有關係，我只是在說明），並且警告101這是非常真實的 - 顯示出來的機率是 - 你不是去看看它。

我不會容忍任何警告。偶爾，這意味着添加無用的行或兩個代碼，因爲編譯器無法看到條件必須執行等。（在我寫這個的時候，前面有一個例子：4個路徑在一個隨機數的開關中，4個必須執行1個，並且每個變量賦值給一個變量，編譯器不知道它必須有一個值點，所以我說的外來分配給掩上了。）

來源

2009-09-05 00:56:56

這種情況幾乎總是可以通過在聲明變量時提供默認值來解決。即使您稍後重新安排了代碼，並且爲讀者提供了更高的清晰度，這種方法仍然很安全。但在大多數情況下不需要額外的線路。我發現很多錯誤都是這樣的。最好的解決方案通常具有可讀性方面的其他好處，且開銷最小。如果編譯器無法弄清楚你的代碼，它很可能是下一個維護者（即使它是你）也不會。調試代碼是個例外，我發現它有時候很難避免警告（比如強制執行異常的代碼）。 – 2009-09-05 03:35:24

絕對。你應該總是解決你的警告。如果你不能，你至少應該知道爲什麼警告在那裏，爲什麼你可以忽略它。要忽略所有的編譯器消息，（不管它們看起來是無害的），只是一種災難。

來源

2009-09-05 02:24:01

警告是否重要？

回答

相關問題