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

11–20 of 31 posts

Re: Compiler Warnings for Objective-C Developers

#11

Post by DrJokepu »

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.

Re: Compiler Warnings for Objective-C Developers

#12

Post by scott_s »

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.

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.

Re: Compiler Warnings for Objective-C Developers

#13

Post by chrisdevereux »

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…

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

Re: Compiler Warnings for Objective-C Developers

#14

Post by millstone »

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…

Have you ever worked on a project that has to build on diverse systems that you may not control, like most open source projects?

Inflicting -Werror on yourself is fine, but inflicting it on others is onerous, because there's no way you can guarantee that your code produces no warnings on their compiler with their library and header versions.

Re: Compiler Warnings for Objective-C Developers

#15

Post by redshirtrob »

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.

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

Re: Compiler Warnings for Objective-C Developers

#16

Post by coherentpony »

millstone wrote: post #14
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…

Have you ever worked on a project that has to build on diverse systems that you may not control, like most open source projects? Inflicting -Werror on yourself is fine, but inflicting it on others is onerous, because there's no way you can guarantee that your code produces no warnings on their compiler with their library and header versions.

>Inflicting -Werror on yourself is fine, but inflicting it on others is onerous, because there's no way you can guarantee that your code produces no warnings on their compiler with their library and header versions.

This is precisely the reason it is in fact necessary.

When writing code that is intended to be portable and is expected to generate reproducible floating-point calculations in numerically intensive calculations, warnings on different platforms and header versions is a godsend.

When I receive a bug report that says, "I am using operating system distribution X, version Y, with library version Z, and specific test W produces warnings when I type `make check`," it makes me happy.

Re: Compiler Warnings for Objective-C Developers

#17

Post by [deleted] »

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…

[deleted]

Re: Compiler Warnings for Objective-C Developers

#18

Post by redshirtrob »

millstone wrote: post #14
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…

Have you ever worked on a project that has to build on diverse systems that you may not control, like most open source projects? Inflicting -Werror on yourself is fine, but inflicting it on others is onerous, because there's no way you can guarantee that your code produces no warnings on their compiler with their library and header versions.

I think I would deal with this on a case-by-case basis. If the project was primarily for Objective-C/Apple I think I would use -Werror against the most recent set of tools. My experience writing software for the iOS platform indicates this wouldn't be an onerous initial constraint. And, there's nothing to stop others from changing the build settings.

I would absolutely relax the constraint if I was maintaining a large cross-platform OSS project. In that case, I think your criticism is on point. I hadn't considered this situation as I've not been the maintainer of such a system.

Re: Compiler Warnings for Objective-C Developers

#19

Post by to3m »

coherentpony wrote: post #16
millstone wrote: post #14

Earlier quoted context omitted.

Have you ever worked on a project that has to build on diverse systems that you may not control, like most open source projects? Inflicting -Werror on yourself is fine, but inflicting it on others is onerous, because there's no way you can guarantee that your code produces no warnings on their compiler with their library and header versions.

>Inflicting -Werror on yourself is fine, but inflicting it on others is onerous, because there's no way you can guarantee that your code produces no warnings on their compiler with their library and header versions. This is precisely the reason it is in fact necessary. When writing code that is intended to be portable and is expected to generate reproducible floating-point calculations in numerically intensive calcul…

Why not just use #error? Then the build will crap out in any event. I've found #error to work on a wider range of compilers anyway (I'm not sure #warning is standardized).

Re: Compiler Warnings for Objective-C Developers

#20

Post by redshirtrob »

chrisdevereux wrote: post #13
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…

> 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 find it's throwing a warning, I see no issue with temporarily commenting out the declaration. The only downside I can think of is someone accidentally commits a single-line, commented out variable declaration.

I can say I rarely run into this specific problem. I tend to use variables once they're declared. It's possible my development style is just different. If I found this to be a big problem, I probably would disable the warning for debug builds.

Post reply on HN