[ODE] Making it build again (WHY WARNINGS MUST BE TREATEDASERRORS)

[Mike Reinstein]

I don't understand why this is so difficult to comprehend. It is this 
simple:
a) Warning in ODE MUST be ASSUMED to be errors until they are determined to 
be otherwise. In the example I posted before, some of the warnings in my 
friends code were superfluous, but some were not. But we only care about 
finding the warnings that truly are errors correct? The only way to do this 
is to START BY ASSUMING ALL OF THEM are errors and sift through them.

b) Something I didnt mention in my last post but h+ touched on heavily is 
the fact that warnings often come from poorly written code. Almost every 
single warning CAN be removed by changing code around. Go back to my highway 
overpass example. Why do we have clearance signs on the over passes? Because 
it is way too time consuming and expensive to rebuild every overpass to be 
high enough such that every truck can roll underneath it safely. It is also 
impossible to build all trucks short enough such that they will all fit 
under all underpasses. We can't get rid of some warnings in real life 
because of constraints we can't change. Not true in software. The warnings 
are entirely fixable and they should be.

btw, what do project managers have to do with taking any of this so called 
blame? Sure as an engineer I like passing the blame to management whenever I 
can, but come on...that's a bit silly....

-Mike


>From: "Gary R. Van Sickle" 
<g.r.vansickle at worldnet.att.net>
>To: <ode at q12.org>
>Subject: RE: [ODE] Making it build again (WHY WARNINGS MUST BE 
TREATEDASERRORS)
>Date: Sat, 25 Sep 2004 19:00:15 -0500
>
> > 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,
>
>No, I think you've both missed two critical sentences:
>
>"Warnings are not errors, that's why they've been allocated a 
different
>name.  Warnings are to be
>minimized and ideally eliminated if possible"
>
>If you have pass the compiler a "don't print any warnings" 
switch because
>you have so many warnings you can't tell what's what, that's a prime 
example
>of inexperenced (or simply incompetent) developers and poor project
>management.  Please note that nowhere did I claim that warnings should 
be
>ignored, either by watching them scroll by or by sending them to 
/dev/null,
>either by policy or by individual developer decision.  What I said is 
that
>warnings should not be treated in the same way errors are.  Again, if 
they
>were the same thing, they'd have the same name.  They don't.
>
>--
>Gary R. Van Sickle
>
>_______________________________________________
>ODE mailing list
>ODE at q12.org
>http://q12.org/mailman/listinfo/ode

_________________________________________________________________
Get ready for school! Find articles, homework help and more in the Back to 
School Guide! http://special.msn.com/network/04backtoschool.armx