Re: Clause "with and use"

["Robert I. Eachus" <rieachus@comcast.net>]

Russ wrote:

> I think that's a very good analogy to what you are saying. The
> "context" section at the beginning of nearly every Ada file is like
> the front yard of a home. It's the first thing anyone who reads the
> file sees. If it's unnecessarily cluttered, people may not complain
> about it, but it will leave a lasting first impression.

I think again you are missing the entire point.  Why is all that stuff 
you call junk in the front yard in the first place?  Because a lot of 
effort when into developing a set of requirements that specified where 
that "junk" goes.  Some of it doesn't look pretty, but burying it in the 
back yard to conceal it results in disaster.

The solution, as you point out, is to get someone to haul the junk away, 
to give your code better "curb appeal."  In C you can use nested 
includes to accomplish that.  In Ada, it takes a effort devoted to 
coherence and information hiding.  A package spec that has more than 
three or four with clauses is a clue that problems exist in the code. 
Ada was designed that way.

Package bodies often have as many as a dozen with clauses on large 
projects, but again, beyond that you have to wonder if it indicates a 
problem with the coherence of the package body.  Often use of generics, 
child packages, and separate bodies can reduce the clutter.  Sometimes 
the only way to "fix" the problem is to start the design over and 
refactor the problem differently.  (Note: putting an absolute maximum 
limit on the number of with clauses in the software coding standards 
fixes nothing.  If there is a problem it is in the design not the code, 
and it can't be fixed by coding standards.  Also the average number of 
with clauses will go up with the size of the project.

Don't say that too many with and use clauses produce clutter that 
reduces the appeal of Ada as a programming language.  Say instead that 
bad design in Ada results in cluttered looking with and use clauses.

If you want a single number to measure the "goodness" of the design, I 
have been comfortable with (2S + B)/(N * ln(N)) where N is the total 
number of compilation units and subunits, S is the number of with 
clauses on package specs (including generic package specs) and B is the 
number of with clauses on other units.  Some people may disagree with 
including separate subunits in N, but I seldom find designs abusing 
that.  There is a problem though is some compilation units are too 
small, so I get concerned when the average size of compilation units is 
outside the 100 to 1000 NCSLOC (non-comment source lines of code) range.

-- 
                                           Robert I. Eachus

100% Ada, no bugs--the only way to create software.