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

[DjArcas]

Well, if you two can just stop arguing for a moment...

Compiler warnings are there to WARN you that you should really have a look
at that piece of code. Also, if you go committing code in a commercial
workplace that's peppered with warnings, you're going to end up with your
lead programmer having 'words' with you.

But, yes, compiler warnings should really be gotten rid of, via whatever
methods.

----- Original Message -----
From: "Gary R. Van Sickle" <g.r.vansickle at worldnet.att.net>
To: <ode at q12.org>
Sent: Sunday, September 26, 2004 10:26 AM
Subject: RE: [ODE] Making it build again (WHY WARNINGS MUST BE
TREATEDASERRORS)


> > I don't understand why this is so difficult to comprehend.
>
> It's not: you're wrong.
>
> > It is this
> > simple:
> > a) Warning in ODE MUST be ASSUMED to be errors until they are
> > determined to be otherwise.
>
> No, they musn't.  They must be assumed to be warnings, because they are
> warnings, and no amount of CAPITAL LETTERS changes that.
>
> > In the example I posted before,
> > some of the warnings in my friends code were superfluous, but
> > some were not.
>
> And were some compiler-dependent, some not?  Some warning-level dependent,
> some 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.
> >
>
> Bingo: sift through them.  Don't break the build just because there's an
> unused variable hanging around that the compiler optimized away anyway.
>
> > 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.
>
> Yep.  Hence: inexperienced and/or incompetent developers.
>
> > Almost every single warning CAN be removed by
> > changing code around.
>
> Can they?  Every one?  Even if you're right, should they?
>
> > Go back to my highway overpass example.
>
> No.  It is not a valid analogy.
>
> > Why do we have clearance signs on the over passes?
>
> To indicate the maximum height a vehicle can have without losing its roof
> when going under it.
>
> > 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.
>
> True.  Yet you suggest we do exactly that: Assume all briges with
clearance
> signs ("warnings" in your book) actually have zero clearance and all
> vehicles will fail to pass under ("errors"), then we simply rebuild the
> bridges ("change code around") to eliminate the "warning" signs.  Kinda
> makes no sense when you analyze it, doesn't it?
>
> > It is also impossible to build all
> > trucks short enough such that they will all fit under all
> > underpasses.
>
> Well, you only have two choices here to eliminate these signs: lower the
> trucks or raise the bridges.  Pick a lane guy.
>
> > 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.
> >
>
> Not all warnings are eliminatable in software.  Some warnings are, but
> shouldn't be (e.g casting the bool).  And again, the warnings are in no
way
> standardized and you're at the mercy of the compiler's judgement as to
what
> is and what isn't a warning.
>
> > 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....
>
> If project managers are employing developers that are so sloppy that
> warnings=errors is *required* for their code to work, then they deserve
some
> of the blame.
>
> But let me ask you something: Why do you think there are separate
"warnings"
> and "errors" issued by compilers (all compilers), instead of only
"errors"?
> If it is as accepted in the industry as you claim that "WARNINGS ARE
> ERRORS", why have "WARNINGS" at all, and just call everything an "ERROR"?
>
> --
> Gary R. Van Sickle
>
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>