5 ms·

Compiler Warnings for Objective-C Developers

58 points by Garthex 13y ago

deleted 13y ago
[deleted]
kstenerud 13y ago
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!
- brodney 13y ago
  You can set the warnings to only appear on debug builds. Would that fix the CI issue?
- pjmlp 13y ago
  Whenever I am involved in build setups for C or C++ projects, -Wall, -Werror and static analysis are always part of the build. It is the only sane way to give C and C++ the same strong typing that other languages enjoy since birth. Quite useful in projects where due costs, most developers are not that experienced. I am yet to do a Objective-C project, but I would use the same approach.
- mikeash 13y ago
  "I can never remember what it's called, but it's very annoying when you need to find it to disable it." These days, clang will tell you what a warning is called any time it gives you one. If you ever need to disable a warning, make it happen (which you probably already did, otherwise why would you need to disable it?) and then just read the error message to see what flag to use to disable it.
- octo_t 13y ago
  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-may-cause-a-leak-because-its-selector-is-unknown http://stackoverflow.com/questions/7017281/performselector-m...) 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!
- redshirtrob 13y ago
  What is wrong with breaking the build when the underlying assumptions change? I consider this a good thing. My initial assertion that many warnings are latent errors (bugs) implies that the most inconvenient time is when the product is in the hands of users. I have another guideline that I frequently apply: Don't update your tools if you're close to cutting a new release. This mitigates the risk of unexpected build issues a the worst possible time.
julien_p 13y ago
The author just retweeted a link to this header file to enable Clang warnings using #pragma's https://github.com/macmade/SeriousCode https://github.com/macmade/SeriousCode https://twitter.com/macmade/status/328219581879558144 https://twitter.com/macmade/status/328219581879558144
redshirtrob 13y ago
'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.
- forrestthewoods 13y ago
  The build machine should treat warnings as errors but for local builds warnings are acceptable. You know they can't be checked in but they don't get in your way and slow you down while writing new code.
- DrJokepu 13y ago
  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.
  - scott_s 13y ago
    There are two scenarios. In one, you control the build process yourself, in which case nothing is physically stopping you. There is still value in doing it, because we are irrational creatures. We may be more likely to let a "warning" slide, rather than an "error," even though it is only classified as an error because we told it to do so. Being irrational creatures, we are loathe to go back on past decisions, and turning an "error" back into a "warning" requires action on our part that implies we were wrong before. We're more likely to just fix the "error." The second situation is when you don't control the build process, in which case someone or someones are keeping you honest.
SeoxyS 13y ago
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.
tomwilson 13y ago
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).
interpol_p 13y ago
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.

58 points by Garthex 13y ago

deleted 13y ago

[deleted]

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!

brodney 13y ago
You can set the warnings to only appear on debug builds. Would that fix the CI issue?
pjmlp 13y ago
Whenever I am involved in build setups for C or C++ projects, -Wall, -Werror and static analysis are always part of the build. It is the only sane way to give C and C++ the same strong typing that other languages enjoy since birth. Quite useful in projects where due costs, most developers are not that experienced. I am yet to do a Objective-C project, but I would use the same approach.
mikeash 13y ago
"I can never remember what it's called, but it's very annoying when you need to find it to disable it." These days, clang will tell you what a warning is called any time it gives you one. If you ever need to disable a warning, make it happen (which you probably already did, otherwise why would you need to disable it?) and then just read the error message to see what flag to use to disable it.
octo_t 13y ago
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-may-cause-a-leak-because-its-selector-is-unknown http://stackoverflow.com/questions/7017281/performselector-m...) 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!
redshirtrob 13y ago
What is wrong with breaking the build when the underlying assumptions change? I consider this a good thing. My initial assertion that many warnings are latent errors (bugs) implies that the most inconvenient time is when the product is in the hands of users. I have another guideline that I frequently apply: Don't update your tools if you're close to cutting a new release. This mitigates the risk of unexpected build issues a the worst possible time.

julien_p 13y ago

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

redshirtrob 13y ago

'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.

forrestthewoods 13y ago
The build machine should treat warnings as errors but for local builds warnings are acceptable. You know they can't be checked in but they don't get in your way and slow you down while writing new code.
DrJokepu 13y ago
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.
- scott_s 13y ago
  There are two scenarios. In one, you control the build process yourself, in which case nothing is physically stopping you. There is still value in doing it, because we are irrational creatures. We may be more likely to let a "warning" slide, rather than an "error," even though it is only classified as an error because we told it to do so. Being irrational creatures, we are loathe to go back on past decisions, and turning an "error" back into a "warning" requires action on our part that implies we were wrong before. We're more likely to just fix the "error." The second situation is when you don't control the build process, in which case someone or someones are keeping you honest.

SeoxyS 13y ago

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.

tomwilson 13y ago

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).

interpol_p 13y ago

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.