Re: Use of declare blocks

["Randy Brukardt" <randy@rrsoftware.com>]

<adaworks@sbcglobal.net> wrote in message
news:%CIMh.1791$rj1.394@newssvr23.news.prodigy.net...
>
> "Randy Brukardt" <randy@rrsoftware.com> wrote in message
> news:etveau$g29$1@jacob-sparre.dk...
> >
> > Anyway, I do understand the readability concerns, but I think they're
> > overblown. If you have to look 5 pages away to find a variable
declaration,
> > the readability of the code it is used in isn't necessarily enhanced:
you're
> > still flipping back and forth. Moreover, trying to come up with good
names
> > for code that are made into subprograms just to keep the code "short" is
> > hard, and I know I'm not good at it. These supposed helpers are a real
> > headache during maintenance, because its rarely obvious what they do!
How do
> > that help readability??
> >
> Actually, you make my point for me.  We certainly do not want to look
> all over the place for the name of a variable.   On reason I like to use
> in-lined procedures instead of declare blocks is the ease of grouping
> like things together.   Consider this contrived example:
>
>           case X is
>               when C1  =>  declare
>                                            xxxxxx
>                                      begin
>                                             -- fifty lines of code
>                                      end;
>               when C2 =>   declare
>                                              zzzzzzzz
>                                      begin
>                                             - twenty lines of code
>                                      end;
>               when ...
>           end case;
>
> Even when we label the declare blocks, which I tend to do,
> this can get to be difficult to read and difficult to maintain.  I
> might do this:
>
>            procedure some_unit_name is
>                  procedure C1_Process is ... end C1_Process;
>                  pragma Inline (C1_Process);
>                  procedure C2_Process is ... end C2_Process;
>                  pragma Inline (C2_Process);
>                  -- more procedures as needed
>           begin
>                  -- set up stuff
>
>                  case X is
>                       when C1  =>  C1_Process;
>                       when C2 =>   C2_Process;
>                       when ...
>                  end case;
>            end some_unit_name;

Ahhh, but this is unrealistic, for a couple of reasons.

First, you have to access the local variables and parameters of
Some_Unit_Name from the xx_Process routines. (I don't want to think about
routines that only use global variables!) Those necessarily will be far
away, and not even in the same scope (especially if you succeed in compiling
these separately - in which case they'll be in a different file. You can
pass them all as parameters, but then you're adding to the clutter that
you're supposedly reducing.

Second, you're not taking into account the likelyhood that some of the
processing is the same in several of these branches. That argues for making
that similar processing into a subprogram, too, and pretty soon you have
dozens of subprograms doing small parts of the processing.

And I'm not even going to point out that naming these "sub" routines is very
hard, because they tend to be only part of the processing (especially if
some action for all of the cases happens afterwards, which is common). You
can make it a bit easier sometimes by splitting the code into even more
subprograms, but all of the "noise" of a subprogram isn't going to
necessarily improve the readability.

...
> In your case, you and the small number of programmers who work
> with you are intimately familiar with the code.

That's no excuse for using a bad organization. I know how hard it is to go
back to code you haven't touched in a couple of years. It doesn't matter if
you wrote it originally: you won't remember much about it.

> One of the benefits of
> Ada is that it makes it easier to manage turnover, reassignments, and
> all the other personnel movements that occur in a large software
> organization.   I have seen declare blocks used in an ad hoc manner
> where the lack of documentation created difficulties for newcomers
> to a project.  Giving something a specific, meaningful name can help,
> especially when it is the name of a procedure along with good names
> for the local variables used to make it work.

True enough; but good names are very hard to come up with. (We never
succeeded at that for maybe 50% of the routines in Janus/Ada. Quick: tell me
the difference between "Base_Type" and "Formal_Base_Type" and
"Almost_Base_Type" and "Matching_Base_Type"! :-)

And it's almost a waste of effort to come up with names for throw-aways,
much less good names. I still often use the Fortran "I" for the loop
parameter of a for loop. The name is nearly irrelevant a lot of the time
(and the need for it is really a deficiency of the language -- I want to do
something to all of the components of an array; naming each one in turn is
not really necessary for that purpose). [I do try to use a better name if
the loop is going to longer than a few lines.]

Anyway, declare blocks are so close to subprograms that there isn't that
much difference between them. Surely naming is more important than that??

> I suppose we simply use the coding style most appropriate to the context
> in which we are working.   As I noted, I am not opposed to declare blocks,
> but I am uncomfortable when large systems are designed so they rely
heavily
> on them.   Most organizations don't have the luxury of a stable workforce.

I don't find small blocks to matter much at all - they just serve to narrow
the scope of objects as much as possible, which is important if you're not
going to use something anymore (let it get cleaned up).

I also use locks extensively in some code; those are always controlled
objects so they work properly when an exception propagates. The only way to
control the locking time is with a declare block, and it provides a nice
visual bracket for this use.

                                        Randy.