[ODE] Making it build again (WHY WARNINGS MUST BE TREATED AS ERRORS)

[Nicolas Quijano]

Hear, hear : that one was a prime example of why ignoring warnings 
shouldn't ever be a development policy, and that's without going into 
certain platforms were to get certification your code must be devoid of 
all warnings :)
they are warnings, as in "this is not something I can't compile, but it 
might bite you in the arse at runtime"...
To pick up on Mike's highway underpass imagery : you know, some 
cleaning products have skull logos on them to indicate that they're 
unfit for human consumption, if not downright lethal. Would you ignore 
such a warning ?

If you know what you're doing Gary, as you seem to imply, you can 
certainly ignore them, as an individual, but to say that they should be 
ignored as a policy, well, that's nonsense : to lump all warnings 
together because of the exceptions (e.g dumb warnings on code you know 
won't pose a problem) is just plain wrong.
They're not there to aggravate, they're there to signal potential 
problems that you should deal with and not the compiler.
We're actually very lucky to have such tools to our disposal in helping 
us make better software...

I know that in my day job, we work with platforms with the recommended 
usage while developing on windows is to use level 4 warnings throughout 
development, and turn them on as errors before even trying to put it on 
the devices.
This gets rids of all sorts of annoying problems...

Have a nice weekend,
Nicolas


On Samedi, sept 25, 2004, at 02:54 America/Montreal, Mike Reinstein 
wrote:

> > > 2.  Any project which requires warnings to be treated as 
> errors to improve
> > > product quality lacks experienced, skilled developers, 
> proper management,
> > > and proper quality control systems.
>
> This reminds me of something that happened in a software engineering 
> course a few years back. I was working on a team with 2 other 
> developers to build a robotic car capable of some semi autonomous 
> behavior, and one of my colleagues came to me with some source to 
> modify. Well, I made several dozen modifications to the code, and 
> compiled/linked it. Perhaps I am a bit pessimistic, but I was 
> immediately scared that it built ok. I tried running it and sure 
> enough, ka-boom..multiple problems, segment faulting in various 
> states, etc...I was banging my head against the wall for days as to 
> why it wouldn't work, to no avail. Then I opened up the makefile and 
> found that my dear friend had turned off ALL warnings! He was so 
> confident that warning were superfluous that he foolishly discounted 
> their purpose and did not consider them to be the source of troubles. 
> I added the famous gcc -wall parameter to view all errors, and got an 
> absolute PILE...going through those and fixing them, I found nearly 
> every problem went away.
>
> Hope I haven't bored you to death with my long, mildly amusing, dry 
> anecdote. :P  Warnings are there for a reason. They must to be treated 
> as errors because they potentially can be.
> For example, when you drive under a highway underpass, there is almost 
> always a clearance sign that dictates the maximum height of a vehicle 
> that may safely pass underneath it. Granted, most people can ignore 
> these signs because we drive typical consumer vehicles. Commercial 
> truck drivers cannot. It is an example of how many warning do not 
> generate fatal errors, but some do. You need to be aware of all 
> warnings so that you as a programmer (as well as a person) can 
> determine what warnings are potentially fatal in a given contect, and 
> what ones are not.
>
>
> best,
>
> nekoflux


Nicolas Quijano, Programmer @ Gameloft Montreal
nquijano at gameloft.com
"Be kind, everyone you meet is fighting a hard battle"
My friend, Steve Linberg