Robert Eachus wrote,

> I've actually had to convince projects to accept guidelines...
> (More than six withs on a package spec, or fifteen on a package body
> indicates that there is restructuring that should be considered.  There are
> good arguments for having more withs on the main program, but a with on a
> subunit is almost always an indication of a design problem.)

The above numbers intrigued me because some time ago we had noticed
similar thresholds. In particular, we noticed that when interfacing to a
binding for some subsystem written in C (such as for X-Windows), a more
generous allotment needed to be permitted for bodies (about 20 or so).

However, your observation regarding subunits is unclear to me: are you
suggesting that subunits should ideally have *no* WITHs? Moving such
WITHs up to the parent body would meet the criterion, even though it
would still be the same design.

Here is some other data: In a recent review of several independent Ada
projects, we noticed the following pattern of typical numbers:

# WITHable specs   avg WITHs/spec   avg WITHs/body   max WITHs/body
         164            2 or 3           2               20
         340            2 or 3           4               28
        1450            2 or 3          13              118
        7006            2 or 3          20              983

(Yes, that's 983 WITHs for a single body unit: it was a memory resident
database that correlated data of all TYPEs across the whole system.)

These numbers count subunits as bodies, and include unused WITHs, if
any; bear in mind that a spec's WITHs need not be repeated in a
body/subunit. It's an interesting pattern that invites speculation:
The architecture (ie, inter-spec dependencies) is fairly constant
regardless of program size, whereas the implementation inexorably
grows in complexity as the system size grows; and it's nonlinear.
Is this an intrinsic property or just weak design? A human limitation
or state-of-the-art? Has anyone else observed such a pattern?

--

C. Daniel Cooper ==========v=================v=======================v
Adv Computing Technologist | processes       | All opinions are mine |
206-655-3519               | + architectures | and may not represent |
[log in to unmask]  |   = systems     | those of my employer. |
===========================^=================^=======================^