[ODE] RE: Making it build again (WHY WARNINGS MUST BE

[Nicolas Quijano]

Nice going, as Gary has said both very to the point things, and some 
things just to be right : you approve all of it just to give moral 
support ?
So basically, you agree that warnings should be ignored ? 'Cause that's 
the point : don't get hung up on the treating warnings as errors.
And I think the people who brought it up, did so because in real life, 
there is no workplace, whatever its size where people are all of the 
same level of skill and know how, without going into issues of 
competence.
Which you should know first hand, having 20 years of experience in the 
game industry, which has more than its fair share of sloppy programming 
practices (we've all seen and experienced it first hand, and most 
likely will again ;))
And since the two sides of this real life debate are not the ones here 
(since Gary is not preaching about ignoring warnings, afai understand 
him) : they're really the "ignore warnings" and "don't ignore 
warnings". So what do you do as a generalization to deal with the fact 
that a lot of programmers simply ignore warnings ?
Well, you put in place a policy of treating them as "errors", e.g you 
"listen" to your compiler's and linker's verbose output, period.
Now, if the "treating warnings as errors" label irks you that much, use 
another one.

To use the warnings analogy, which has been nicely twisted : we all 
agree ignoring a warning, be it on a road sign, medication, whatever,  
is an error ? e.g drinking that solvent bottle with the skull on it 
after reading the warning is an error and might cost you your life in 
the worst case ?
Well, ignoring warnings could cost you your job, simple as that. And in 
that sense, ignoring warnings is an error. I'll let you do the next 
logical step :)

The analogy is valid, and no amount of twisting won't make it so : 
that's the reason the term warning was chosen in the first place, 
rather than error.
Don't forget we're talking generalizations here, which are what 
development policies are, however specific they can be.

To me, looks like some of us have a problem with the "Warnings as 
errors" , but are still in agreement with the fact they shouldn't be 
ignored.
Whether your approach is by systematically using the warnings as errors 
compiler switch, or not, is not all that important (and if that's what 
was meant by Treating all warnings as errors, well, then I might even 
be more in the middle than I thought ;)) : what is important is that 
you have a policy in place for a team to deal with it.
Although, having the compiler switch will force the programmers who 
ignore warnings to take heed, so is it that worthless ?
( we only use that switch before starting testing on the actual 
devices, but we certainly deal with warnings as they come, as much as 
possible, because, as has been pointed out, some of them can't be 
ridden of for all sorts of reasons (working across different compilers 
and platforms being one case : workarounds around a compiler's 
limitations will pop up warnings on another, which if you get rid off, 
will break the other build, etc.)

How do you allow interns and junior programmers to learn the "Right 
Way" (which doesn't exist, but that's another can of worms ;)), if you 
don't have mechanisms in place to help them better themselves ? Or do 
you work in the ideal workplace where every senior programmer and lead 
can take half their day to guide the less experienced ?

Again, imho, treating all warnings as errors, doesn't imply having the 
compiler switch that does just that on at all time, although I can 
certainly see the point of doing so. It does imply doing something 
about the warnings, systematically, and immediately (the latter in 
context, of course).
If that makes me part of the "Gary camp", so be it. That won't change 
the fact that the analogies used are valid, since they're obviously the 
source of the differentiation in compiler messages : errors are 
obviously things the compiler knows at errors as far as it's concerned 
: definitely bad/wrong code.
Warnings are meant for us to do something about them. Ignore them at 
your own risks : however good a programmer or developer anyone can be, 
we're still human and still make mistakes, it's that simple.
Compiler and linker warnings, as I said before, are yet another tool to 
help us catch them before they snowball and have more important 
ramifications.

I certainly deplore the personal, and "me right, you wrong" tone taken 
in this debate, as well as the implied commentaries about people's 
qualifications made by some.
I hope what I said and am saying hasn't been construed as such, but 
then again, English is not my native language.
Still, I wish you all a nice weekend (for what's left of it anyhow), 
and happy coding,
Nicolas

On Dimanche, sept 26, 2004, at 13:24 America/Montreal, Pete Baron wrote:

> Sorry to all of you who don't care about this on-going dispute and 
> just want
> it to end, however with several voices against, I feel obligated to 
> weigh in
> with Gary and say "warnings are not errors and should definitely not be
> treated as such".  Nearly 20 years of professional video games design 
> (it
> will be 20 years in June 2005) has taught me this much at least, and 
> quite
> frankly I can't be bothered to reiterate the already extremely 
> well-stated
> arguments on this side of the discussion.  This email is not intended 
> to be
> an argument, I'm just lending a little moral support to what is to me
> clearly the correct side of a heated discussion.
>
> Well said Gary,
>
> Pete Baron
> Senior Programmer,
> Minds Eye Productions Ltd
> sibaroni at hotmail.com
>
> ps. when replying to a message on a thread, please take 5 seconds and 
> delete
> the irrelevant portion of the thread... no-one really needs the whole 
> thing
> repeated.
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>
>
Nicolas Quijano, Programmer @ Gameloft Montreal
nquijano at gameloft.com

"Be kind. Everyone you meet is fighting a hard battle."
My friend, Steve Linberg