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

Mike Reinstein web_fella at hotmail.com
Sat Sep 25 02:54:01 MST 2004


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




>From: "Jon Watte" <hplus-ode at mindcontrol.org>
>To: "Gary R. Van Sickle" 
<g.r.vansickle at worldnet.att.net>,   "'Ode at Q12. Org'" 
<ode at q12.org>
>Subject: RE: [ODE] Making it build again
>Date: Fri, 24 Sep 2004 21:53:27 -0700
>
>
> > 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.
>
>You and I clearly disagree on this. Clearly, there are others on
>the list that agree with me. Clearly, the guy who added the new
>warnings agrees with you. Fact remains: build breaks for some of
>us when new warnings are introduces.
>
>As for the warnings you suggested, all of them are fixable. For
>example, instead of casting bool to int, you can write bool ? 1 : 0.
>For the while(1) case, you can write for(;;){} (which is the
>original idiom, anyway).
>
>Just getting into the habit of fixing warnings BEFORE you run
>your code is about the same as getting into the habit of commenting
>your code: you're better off for doing it. That's my opinion; you
>may disagree. I really don't want an argument on this list; I said
>my piece.
>
>Cheers,
>
>		/ h+
>
>
>_______________________________________________
>ODE mailing list
>ODE at q12.org
>http://q12.org/mailman/listinfo/ode

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/



More information about the ODE mailing list