警告是否重要？

编辑：我已经修复了除了两个警告之外，所以谢谢大家的建议和鼓励。我已经离开了两个警告要求我更改数据库：警告是否重要？

/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

警告是否重要？

回答

相关问题