At 04:16 PM 12/10/98 -0500, W. Wesley Groleau x4923 wrote:
>I agree with this point. However, I would not be likely to use this
>nesting method if there was the remotest chance one of my subprograms
>could ever be a candidate for re-use. It is just in contrast to the
>method some people use of writing 4,000 SLOC straight line procedures.
>It's kind of like making the parent procedure a table of contents to the
>substeps--only it's at the end. Or like the parent is the "what" and the
>nested routines are the "how". In other words, it's not a modularity or
>factoring technique, it's just a way of avoiding the alternate example
>I generally use this technique only when it's obvious that there will
>never be any need to "lift" a routine to a higher nesting level. As for
>lifting variables, it's just as easy to lift a variable from a nested
>routine to the parent routine.
The technique of using subroutines expository purposes is fine,
whether or not you expect the code to be reused is fine, and is almost
orthogonal to the nesting question. (Acutally when I use the subroutines
like that, the decision as to whether or not to use nesting usually depends
on whether there are several parameters to the enclosing that need to be
used in the inner routines.)
The nesting issue really involves nested variable declarations.
Sometimes variables do need to be nested:
function Get_Matrix return Matrix is
Number_of_Rows, Number_of_Columns: Integer;
Result: Matrix(Number_of_Rows, Number_of_Columns) := (others => 0);
for I in 1..Number_of_Rows loop
for J in 1..Number_of_Columns loop
But, and this is the key, such nesting almost always involves delcare
blocks, not subprograms, or not just subprograms.
Robert I. Eachus
function Message (Text: in Clever_Ideas) return Better_Ideas is...