One thing I learned early in my career, which is related to this
subject, is, as much as it pains you to see spelling errors in method
names and variable names (for example, coders using "principal" when
they meant "principle", and vice versa, or "similiar" instead of the
correct "similar"), don't take advantage of your IDE's refactoring
capability to correct everything. :-) It's amazing how badly this can
bite you.

In the larger sense I agree with Patricia. Once a piece of code is
baselined, you can see an obvious error staring you right in the face
while working on something else, but you have to resist the temptation
to fix it. Code somewhere else may rely on that error. You need to have
permission to make the fix, after explaining why you should fix it.

AHS

What you suggest is valid and certainly not using "sheer quantity of code" as
a justification.  However, the attitude that "mere" warnings are acceptable
does lead to real bugs that cause trouble in production.  Where did Kevin's "1
in 600 chance" assessment come from?  Statistical analysis?  I feel certain
not, rather, it was pulled from a particular posterior region.

99% (another posteriorily postulated probability) of the time someone
recommends simply not fixing warnings they are ignoring real bugs.

I've seen this in my current large-team project and in past such projects,
where a request for customer A's data resulted in data from customer B's
records because people ignored "trivial" warnings, or merely left out simple
code analysis that would have revealed trouble that didn't raise a compiler
warning.

A professional programmer should step beyond purely arbitrary (and specious)
characterizations of risk and cost associated with a change to understand that
*every* failure to change code that has warnings carries a risk of
perpetuating a bug.  I agree that risk cannot be reduced to zero, but leaving
known warnings in code increases that risk.

Code should not be released into the code base in the first place with
warnings showing.  If that's done, then the question of the risk of change
becomes moot, because there's nothing to change.  When that principle is
ignored, the technical debt mounts until people can aver that the "risk of
cleaning up" is too high to shoulder.  In practice, I've seen much more
failure to perform correctly arise from leaving known bugs in than from
cleaning them up.

Once they're in, then the cost of repair is high, but there are mitigation
strategies even so.  Again using my current project as an example, where we
have multiple warnings (from the compiler and from Findbugs, a /sine qua non/
for robust code) the reviewers recommend to management a strategy that cleans
up the most critical bugs right away, but defers others to a refactoring
timetable that also improves fundamental algorithms or updates to later
features (e.g., JPA over old-style ORM code).  Combination strategies like
fixing the algorithm often reap much larger benefits than simple patches for
similar cost, including simplification of the code to reduce the risk of
introducing new bugs.

Just because one maintainer was careless with a fix doesn't mean that the fix
itself was a bad idea.  Zero defects should be the goal rather than
resignation to poor quality.  You can't use "it's impossible" as an excuse not
to aim for it.  And you most certainly can't use arbitrary and unsupported
fake statistics to support a cost/benefit analysis.