Re: Self-referential types

["Robert I. Eachus" <eachus@mitre.org>]

Richard D Riehle wrote:
>                                        As you so carefully note in your
> message, this does require some planning.   In a large-scale development
> effort, planning at this level of detail is often absent from the
> process.

    I think that this really sums it all up.  Fortunately less often
recently, I get put on "Red Teams" to decide if some project can be
saved, and if so how.  (And for how much, or whether it is better to
cancel it anyway.)

    So from my experience, too many nested procedures is an indication
of (very) bad design.  As I also said, nested functions, usually small,
don't seem to imply bad design, but nested procedures do.  If I were to
make this a serious metric by itself, I would use something like, for
each procedure start with zero.  Climb to the root, and for each
nesting, if inside another subprogram or task entry add one.  Sum over
all procedures and divide by the number of procedures to normalize.

    I could then set up a scale: 0.1 or less very good,...0.5
acceptable, >1.5
reject.  I don't for two reasons.  First I have some coupling measures
which do a better job, and second, you don't need a scale.  Most code is
either near zero, around one, or over three...

    In fact, MITRE did do a lot of work on coupling and cohesion
measures using DIANA a few years ago--I would lie to update the tools to
use ASIS.
But in reality, these tools were of no use at all.  The results were
either, "Gee, this is just short of perfection, can you do anything
about package XXX?" or "This code sucks, but you knew that just from the
effort to get it processed by the front-end of the tool.  There is no
reason to tell you where it sucks or how to fix it.  But if you care the
answers are 'everywhere' and 'don't'."

    Incidently, I took a look at some of the GNAT library packages.  For
almost all of them, the count as expressed above would be zero.  The
exceptions?  Explicit finite state such as in GNAT.Regexp, where such
structure is completely justified.  But while Robert Dewar and I may
write such code, most programmers never do.

-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...