Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Compiler Warnings for Objective-C Developers

oleb.net

Post reply on HN
Print view View original

21–30 of 31 posts

Re: Compiler Warnings for Objective-C Developers

#21

Post by redshirtrob »

kstenerud wrote: post #3

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 ot…

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.

Re: Compiler Warnings for Objective-C Developers

#22

Post by gizmo686 »

redshirtrob wrote: post #15
DrJokepu wrote: post #11

Earlier quoted context omitted.

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.

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 d…

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.

Re: Compiler Warnings for Objective-C Developers

#23

Post by to3m »

redshirtrob wrote: post #20
chrisdevereux wrote: post #13

Earlier quoted context omitted.

> Regarding the author's specific complaint--unused variables--I find that it's quite simple to comment out the declaration But then you have commented out code potentially forgotten about and checked in and no warning. That's the problem with universally enforcing a rule. Circumventing the rule is usually messier than just breaking it.

I guess I don't understand your complaint. I'm not talking about commenting out huge swaths of code to avoid warnings. And I'm certainly not advocating committing such code. (Or, let me be more clear, I'm not advocating publishing such code. I think it's fine to commit it to a local branch, but the code should be clean by the time it's merged to a public branch.) But, if you've prematurely declared a variable and fin…

I've had this sort of problem quite a bit, but it probably does depend on programming style. If you use a lot of temporary variables rather than anonymous subexpressions (this is somewhat common among people who use a debugger a lot, and some compilers seem to prefer SIMD code to look like this) then it's very easy for one commented-out line to turn into a whole pile of unused variable warnings that slowly fan out as you "fix" each one in turn (because many expressions simply combine two variables that themselves only exist to be inputs for that expression, and so on in turn). This is terribly galling if you're only commenting something out as a quick (or not, as it turns out...) sanity check while you're trying to debug something.

All in all, warnings-as-errors seemed to me like a bum deal. People who don't fix their warnings without warnings-as-errors can't generally be relied on to fix them properly; people who do fix their warnings would have fixed them anyway; everybody is annoyed at some point.

In fact, I am actually becoming annoyed just thinking about it again ;)

Re: Compiler Warnings for Objective-C Developers

#24

Post by demallien »

redshirtrob wrote: post #15
DrJokepu wrote: post #11

Earlier quoted context omitted.

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.

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 d…

Warnings are output to stderr. Personally I just do this: make > /dev/null

All that you see after that are warnings and errors.

Re: Compiler Warnings for Objective-C Developers

#25

Post by redshirtrob »

gizmo686 wrote: post #22
redshirtrob wrote: post #15

Earlier quoted context omitted.

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 d…

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.

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.

Re: Compiler Warnings for Objective-C Developers

#27

Post by chrisdevereux »

redshirtrob wrote: post #20
chrisdevereux wrote: post #13

Earlier quoted context omitted.

> Regarding the author's specific complaint--unused variables--I find that it's quite simple to comment out the declaration But then you have commented out code potentially forgotten about and checked in and no warning. That's the problem with universally enforcing a rule. Circumventing the rule is usually messier than just breaking it.

I guess I don't understand your complaint. I'm not talking about commenting out huge swaths of code to avoid warnings. And I'm certainly not advocating committing such code. (Or, let me be more clear, I'm not advocating publishing such code. I think it's fine to commit it to a local branch, but the code should be clean by the time it's merged to a public branch.) But, if you've prematurely declared a variable and fin…

> The only downside I can think of is someone accidentally commits a single-line, commented out variable declaration.

Yeah, that's the sort of thing I was thinking of. Or empty method implementations, or dummy return values, or whatever.

I guess my point is just that if it's more convenient to do something else before fixing an issue, then it's better to have a warning reminding you to fix it than to not. And if you're not going to circumvent the error, you're probably not going to ignore the warnings either.

Reading your other comment, you mentioned working with make. The advantage I mentioned only really applies in IDEs.

Re: Compiler Warnings for Objective-C Developers

#28

Post by chrisdevereux »

DrJokepu wrote: post #11
redshirtrob wrote: post #6

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

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.

I'd compare it to disabling the snooze button.

Re: Compiler Warnings for Objective-C Developers

#30

Post by redshirtrob »

to3m wrote: post #23
redshirtrob wrote: post #20

Earlier quoted context omitted.

I guess I don't understand your complaint. I'm not talking about commenting out huge swaths of code to avoid warnings. And I'm certainly not advocating committing such code. (Or, let me be more clear, I'm not advocating publishing such code. I think it's fine to commit it to a local branch, but the code should be clean by the time it's merged to a public branch.) But, if you've prematurely declared a variable and fin…

I've had this sort of problem quite a bit, but it probably does depend on programming style. If you use a lot of temporary variables rather than anonymous subexpressions (this is somewhat common among people who use a debugger a lot, and some compilers seem to prefer SIMD code to look like this) then it's very easy for one commented-out line to turn into a whole pile of unused variable warnings that slowly fan out as…

And I'm annoyed when there are hundreds of innocuous warnings. In that case I have to mentally track the warning count so I know when I've incremented it.

Someone who can't fix a warning properly probably isn't a very good coder to begin with. I'd say you're hosed no matter what. :P

I understand you problem with lots of temporary variables. It's not a situation I've encountered. It's certainly something that might make me reassess my position should I encounter it.

Post reply on HN