

Compiler Warnings for Objective-C Developers - Garthex
http://oleb.net/blog/2013/04/compiler-warnings-for-objective-c-developers/

======
redshirtrob
'Treat warnings as errors' is the greatest thing since shirt pockets. I've
found that most warnings are really latent errors. I've been using this
setting for as long as I've been compiling with GCC/LLVM, going back to gcc
2.x.

Whenever I take over a new project I immediately endeavor to fix all the
warnings. The reason is simple: I've spent too much time chasing bugs that
were directly related to a specific warning in a sea of them. Once you get a
project warning-free it's quite easy to keep it that way.

Regarding the author's specific complaint--unused variables--I find that it's
quite simple to comment out the declaration. There's no need to resort to
pragmas in this instance.

~~~
DrJokepu
I never really understood this, what's stopping you from resolving those
warnings even if they won't make the build fail? I mean, you still get a list
of all the warnings and you can still have a zero-warnings rule (which is
something you should really do)? This is, in my opinion, exactly as pointless
as my wife setting her alarm clock seven minutes forward in order to stop
herself from being late.

~~~
redshirtrob
Have you ever tried to spot a warning in a large project with hundreds of
files? It's nearly impossible as all those build commands fly by. Note that
I'm speaking to a more traditional Unix Make environment. Therefore, it's
easier to fail on that specific file than to let the build continue.

Certainly building with a tool like Xcode makes the warnings more conspicuous,
and you can just choose to fix all warnings. I don't see anything wrong with
that approach, but I still prefer to just treat the warnings as errors. I
guess it's just how I'm built.:)

~~~
gizmo686
When I build a program with make, the warnings are very easy to spot. While
you do, without warnings, see a bunch of text fly through the screen, all of
that text looks incredibly simmilar. Warnings (and errors) stick out in the
wall of text.

~~~
redshirtrob
I guess we've just had different experiences. I can say from experience,
without a doubt, that I could not possibly pick out a warning among hundreds
of compile/link commands.

Now, if dependencies were in order, and I'd just made a small change to a
single file, and had previously built the project successfully, I'm sure I
could probably catch a single warning. That's a lot of assumptions to work
from. I prefer to let the build fail.

------
SeoxyS
I find it horrifying how many developers are perfectly happy having warnings
in their code.

On the projects I manage, warnings are unacceptable, and treated as errors. We
will not release an update until it builds without warnings.

------
interpol_p
This post has made me visit one of my large project's warnings. There are two
that I can't seem to be rid of:

Using NS_REQUIRES_NIL_TERMINATION on a var args Objective-C method seems to
cause a warning "Attributes on method implementation and its declaration must
match" — despite both the declaration and implementation being exactly the
same.

Using uniqueIdentifier in debug builds (for TestFlight) triggers an API
deprecation warning. Despite being OK to use for non-App Store iOS apps.

------
julien_p
The author just retweeted a link to this header file to enable Clang warnings
using #pragma's <https://github.com/macmade/SeriousCode>
<https://twitter.com/macmade/status/328219581879558144>

------
tomwilson
I find apples compiler seems to change its mind on what is a warning with
every single version, which in turn made me less interest in removing every
single one of them (especially when you use third party stuff - unity3d seems
to spit out a bunch of warnings right now).

------
kstenerud
I never do -Wall and -Wextra. Why? Because too many of clang's warning
switches have names that have little to do with what they actually warn about.
One in particular has to do with it finding duplicate selectors in different
classes. I can never remember what it's called, but it's very annoying when
you need to find it to disable it. Even worse, when you disable that
particular flag, it disables a whole bunch of other actually useful warnings
as well!

You also DON'T want to do -Wall and -Wextra along with -Werror. Why? Because
when a later version of the compiler gets smarter and puts in more warnings,
suddenly your (working) code won't compile anymore! That would go over very
poorly in a CI system or an open source library! Your "future proofing" has
just ensured that sometime down the road (and likely at an inconvenient time),
your project is guaranteed to break!

~~~
octo_t
This is so horribly wrong.

Firstly, when clang warns you of an error, it tells you the switch it uses to
highlight that error, the disabling flag is then "-Wno-$switch" (or simply use
a clang pragma to disable the warning:
[http://stackoverflow.com/questions/7017281/performselector-m...](http://stackoverflow.com/questions/7017281/performselector-
may-cause-a-leak-because-its-selector-is-unknown))

Secondly, the errors reported by -Wall and -Wextra are likely to be program
bugs / bugs further down the line.

Thirdly: I upgraded my compiler on my CI system, I'd damn well want to know
about new errors!

