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

[John Miles]

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

When you're working on something, you tend to build it 30-50 times a day or
more.  If you leave a bunch of warnings in the code, you learn to ignore
them as they scroll by.  Eventually you will overlook a new warning that
indicates a genuine problem.

Same reason pilots go through the same checklist before taking off in the
same plane they've flown a thousand times.  Surprises waste time, or worse.
You want to avoid them.

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

In a professional environment, "works" means more than "compiles and seems
to run OK on my machine."

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

Compilers are used in a wide variety of applications to build code from a
wide variety of sources (some not even human).  So there are a lot of
configuration options that govern how the compiler deals with the code it's
given.

-- jm