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

[Gary R. Van Sickle]

> 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