Re: [Ann] AdaControl 1.18r8 released

[Jacob Sparre Andersen <jacob@jacob-sparre.dk>]

artium@nihamkin.com writes:

> Sometimes a developer decides to try these tools on an already
> existing codebase. This will lead to thouthands of violations.

If you're very kind to the existing code base. ;-)

> Fixing them is not acceptable in a field tested code.

A reasonable view. - As Jean-Pierre indicates; once you touch a
component, it may be time to fix observed problems in it.

We're fixing violations in field-tested components, where we estimate
that it is plain luck that we haven't registered a failure due to the
violation.

Cost is another argument for not fixing all violations immediately.

> The developer would like to know only about the violations in the
> newly added code.

Just like with compiler warnings.  But how can you easily keep track?
You could of course simply count the number of violations of each kind,
and make sure the numbers aren't growing.  How would you integrate that
in a version control system?  (It requires that you log analysis results
for every commit, and I haven't found a nice way to do that in any of
the version control systems I have used so far.)

Jean-Pierre's suggestion (to fix a file when you touch it) is tempting -
until you have to change 2 lines in a 5000 line source file (with ~5000
violations).  Then you quickly redefine "component" to something smaller
than the whole source file - and live with not having automated checking
of the rule.

Greetings,

Jacob
-- 
Rent-a-Minion Inc. Because good help is so hard to find.