From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 required=3.0 tests=BAYES_00,FROM_ADDR_WS
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: 3 Dec 92 15:59:35 GMT
From: olivea!news.bbn.com!noc.near.net!inmet!spock!stt@ames.arc.nasa.gov  (Tuck
er Taft)
Subject: Re: (none)
Message-ID: <1992Dec3.155935.8187@inmet.camb.inmet.com>
List-Id: <comp.lang.ada>

In article <1992Dec3.094334.20038@sei.cmu.edu> 
  firth@sei.cmu.edu (Robert Firth) writes:

>In article <9212022347.AA03025@s405.dseg.ti.com> 
  fmoore@sun405.dseg.ti.com (Freeman Moore) writes:

>>We have a programming standard that limits the number of
>>executable statements in a compilation unit.
>
>There's the answer: change the standard.  Presumably, this standard
>is meant to enhance code readability, testability, maintainability
>&c.  Simply hacking out a chunk of code as "is separate" will not
>enhance any of the above, so the standard is defeating itself.

I agree completely with Robert Firth on this one, and would go further.  
Arbitrary limits on the size of a compilation unit are a mistake.  
On the other hand, limiting the size of an individual subprogram 
makes at least some sense.

Many of these standards were written before the concepts of
"packages" were understood.  The appropriate limit for the size
of a package is much larger than the appropriate limit for
the size of a single subprogram.  If you must have limits,
make these two separate limits.  In our experience, replacing
a bunch of subprograms in a package with stubs and separately
compiled subunits makes it much *harder* to read and maintain
such code.  

If you need numbers, make them reasonably
generous, and rely on programmers and code reviewers
to police readability and maintainability.  
For example, you might (if you must) limit
packages to 4000 SLOC, and subprograms to 200 SLOC.
And as Robert Firth points out, at least large case statements 
need to be handled as a special "case" ;-), or good luck
implementing an LR parser or high-speed lexer.

S. Tucker Taft  stt@inmet.com
Intermetrics, Inc.
Cambridge, MA  02138