Switch and break

[H. S. Teoh]

On Thu, Jan 19, 2012 at 07:19:07PM -0500, Jonathan M Davis wrote:
[...]
> Personally, I always compile with -w and have increasingly come to
> agree with Walter's thinking on this. I've long believed that
> responsible programmers don't commit code with warnings in it. And if
> warnings are never acceptable, then why are they warnings instead of
> errors? The only case where I think that warnings can be useful is if
> it's for something that you know needs to be fixed but which you don't
> need to fix right away as you're editing code. But considering how
> many programmers leave warnings in (I've never understood why aside
> from laziness), having them just creates problems IMHO.
[...]

The root cause of it is probably laziness, or being forced to check in
code at 5am for a deadline mandated by things beyond your control. And
once this happens, it just perpetuates itself. The poor sods who inherit
the initial bad code say, well this code generates warnings, but we
don't know what it does and we don't dare to touch it 'cos we don't
wanna break stuff that isn't our responsibility in the first place. And
then people get used to it: "This project always compiles with warnings,
it still works (sortof) so we don't care anymore". Which leads to the
sad state that many (most?) commercial projects find themselves in -
warnings everywhere and nobody bats an eyelid.

I have to say I like Walter's approach. If something is serious enough
to be a warning, it should really be an error. The programmer should be
made to fix it. If he *wants* to do something dangerous, give him a way
to *explicitly* override the error. Potentially dangerous things should
never be implicit. The default behaviour should always err on the safe
side---as Andrei so poignantly points out in his book.


T

-- 
The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- Anonymous