From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: Jacob Sparre Andersen <jacob@jacob-sparre.dk>
Newsgroups: comp.lang.ada
Subject: Re: [Ann] AdaControl 1.18r8 released
Date: Mon, 07 Nov 2016 09:02:13 +0100
Organization: JSA Research & Innovation
Message-ID: <87vavzsooq.fsf@adaheads.consafe1.org>
References: <nvflgf$b00$1@dont-email.me>
	<0ff97519-ae71-4c27-8654-b6eab0ca4f96@googlegroups.com>
NNTP-Posting-Host: 109.56.54.248.mobile.3.dk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: franka.jacob-sparre.dk 1478505689 8000 109.56.54.248 (7 Nov 2016
 08:01:29 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Mon, 7 Nov 2016 08:01:29 +0000 (UTC)
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
Cancel-Lock: sha1:GFQ+/dTS3nXJjCA4ek7GpFn5irE=
Xref: news.eternal-september.org comp.lang.ada:32254
Date: 2016-11-07T09:02:13+01:00
List-Id: <comp.lang.ada>

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.