ansaurus

Question

Do warnings matter?

Answer 1

+7 A:

Yes. Some Warnings can be important.

It's best practice to turn a compiler's warning level to the highest setting, and to try to eliminate all warnings.

If a warning cannot be removed through refactoring code, and it has been checked and deemed safe, then many languages have 'pragmas' to silence the warning.

Mitch Wheat 2009-09-05 00:13:22

So, for me there is a trade off. Every second I spend fixing warnings is a second I don't spend improving the app. So, even if it's best practice, is it best practice for someone with such limited resources?

Andrew Johnson 2009-09-05 00:48:08

Someone notes in the comments to one of the other answers (http://stackoverflow.com/questions/1382024/do-warnings-matter/1382040#1382040) one of the more serious warnings you can get, "X may not respond to message Y." You seem to have more than a few of those, so I would say your warnings are probably serious. To judge how important they are, you should read them and understand what all of them mean, so that even if you don't need fix them, you at least know why they're happening.

Chris Lutz 2009-09-05 00:54:09

Often, fixing a warning *is* improving the app, at least from the point of view of the future maintainer. If the code compiles clean of warnings when checked in now, then any new warning stands out loudly during maintenance.

RBerteig 2009-09-05 00:56:00

You get rid of warnings because they save you time. Warnings are an automatic bug-finding tool. Turning it off is trading a short bit of fixing your code for a long debugging session finding what the compiler told you was broken. For instance, your implementation of -description above can create undefined results; the resulting bugs will be very hard to understand. Your 'hides instance variable' warning is another common one that can lead to a long, hair-pulling debugging session. Your 'does not respond' warnings can easily lead to crashes for your customers as you maintain the product.

Rob Napier 2009-09-05 00:58:06

Thanks for the comments. I have fixed all but two warnings now - two warnings which would require me to change the database.

Andrew Johnson 2009-09-05 08:49:11

Answer 2

A:

lol I guess it depends what the warnings are!!

If you have over 100 and yet it runs just fine, I'd guess that they are probably warnings of the type "Object xxx may not respond to message yyy" - i.e. the new methods you've created within your app have not been set up with an appropriate declaration in the header so your compiler isn't able to check whether they are valid method calls for (or more accurately, messages to send to) your custom classes.

Many warnings in objective-C actually warn you of an error that will crash the application - in fact, there is even an option within XCode to "treat all warnings as errors". The fact that your app runs shows that you are not suffering from this problem (or at least, have not yet).

However, even if all your warnings are benign (which I doubt), there is good reason for fixing them. If its regarding class methods, you'll be able to find out before you experience a crash whether or not your sending a valid message to it. And for most of the other types of warnings, you're better off knowing about it.

I guess the final exception is if you're using a lot of deprecated methods. Then you might decide to leave them be, although again that's a risky strategy.

So we're back to the beginning point - it depends what they are! However, I'm 99% sure that it will be a worthwhile exercise fixing them. They're there to help you, not it!

h4xxr 2009-09-05 00:16:33

"Object xxx may not respond to message yyy" is one of the most common warnings that indicates an actual bug. Since ObjC is dynamic, you'll only have trouble if you actually run the line of code causing this warning. At that point you will crash on iPhone. The fact that your program runs under development situations doesn't mean you're getting code coverage over the lines that are likely to blow up. Adding the header is trivial, and will save you very frustrating issues in the field.

Rob Napier 2009-09-05 00:25:07

Rob - if he hasn't set up his header files to match his .m files, then he will get this warning but the message will actually get sent to the class instance and execute successfully. I agree in my code (and perhaps yours?) it would crash, as I specifically make sure my .h and .m files match up! But if they didn't, you'd get the warnings but it would run. The main point we agree on anyway - he should take the time to put the info into the .h file as it's well worth the time!!

h4xxr 2009-09-05 01:03:25

:-D there we go, as I said - the OP has now posted some of his warnings, and many many of them are "may not respond to" ones. They run ok because the classes in question *do* actually have a method implemented, but the .h file is out of sync with the .m file so it's flagged as a warning. He needs to fix this! - because otherwise it hides real problems...

h4xxr 2009-09-05 01:09:10

Answer 3

+4 A:

My gut answer would be absolutely, wholeheartedly yes.

Compiler warnings are there to help you write clear and maintainable code, reducing the likelihood of bugs being introduced later on or cropping up at runtime.

The compiler will generally catch things like unused variables, access to uninitialised variables, failure to return correctly from a function, etc. These things may not be an issue now or in testing, but could easily come along and screw you later.

I would be going through those warnings and trying to fix them now. It will be time well spent.

Jamie314 2009-09-05 00:20:50

Answer 4

+1 A:

YES

Harald Scheirich 2009-09-05 00:24:07

Answer 5

+1 A:

Definitely Yes. Otherwise why would it be called a Warning?

Langali 2009-09-05 00:45:57

Answer 6

A:

If I could give ObjC developers one piece of advice, it would be "use accessors, always." But if I could give them two pieces of advice, the second piece would be "turn on 'treat warnings as errors'."

Maintaining a zero warning policy in Cocoa is perhaps the best cost/benefit trade-off I know of. There are very few warnings that cannot be fixed easily in Cocoa. When writing portable C++, it is often very challenging (sometimes nearly impossible) to avoid warnings, but Cocoa has a single compiler on two very similar platforms. There's almost nothing you need to be doing in Cocoa that should be tripping the default warning set.

Warnings breed warnings. When you say "well, I know about those 121 warnings and they're ok," it's very easy to miss when it becomes 122 warnings and that new one does matter. If you have a warning that you really need to work around, then suppress the warning, but don't ignore them in the build output.

My team turns up warnings very high, and over time we've had to tune them back down a little bit, but we still build major Objective-C++ projects on Mac and iPhone under the following warning flags. There are a few of them that could certainly come out for a particular project, but this is my team's default set, and we don't take many out. I talk about it a little more in my discussion of project templates. The zip file there includes Shared.xcconfig which documents what each of these does and why it's turned on or off. But the default set that Xcode gives is a minimum.

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

Rob Napier 2009-09-05 00:52:22

Answer 7

+2 A:

Many of those warnings look like extraneous stuff in your program that's harmless. However, when you have 100 warnings you know don't matter (I'm not saying all of those don't matter, I'm just illustrating) and warning 101 that's very real shows up--the odds are you aren't going to see it.

I do not tolerate any warnings whatsoever. Occasionally this means adding a useless line or two of code because the compiler can't see that a conditional must execute or the like. (A case in front of me as I write this: 4 paths in a switch on a random number. 1 of the 4 must execute and each assigns a value to a variable. The compiler doesn't know it must have a value at that point so I added an extraneous assignment to shut it up.)

Loren Pechtel 2009-09-05 00:56:56

This case can almost always be addressed by providing a default value when you declare the variable. This remains safe even when you later rearrange the code, and provides greater clarity to the reader. But no extra line is needed in most cases. I find that many errors are like this. The best fix often has other benefits in readability with minimal overhead. If the compiler can't figure out your code, it's likely the next maintainer (even if it's you) won't either. The exception is debug code, which I do find sometimes challenging to avoid warnings (like code to force an exception).

Rob Napier 2009-09-05 03:35:24

Answer 8

A:

Absolutely. You should always resolve your warnings. If you can't, you should at least know why the warning is there and why you can ignore it. To just ignore all compiler messages, (however innocuous as they may seem), is just a recipe for disaster.

Leachy Peachy 2009-09-05 02:24:01

ansaurus

tags:

views:

answers:

Do warnings matter?

related questions