Re: Use of declare blocks

[<adaworks@sbcglobal.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;

In the aerospace example, cited earlier, this is exactly how the code
was rewritten to make it easier to read as well as easier to keep
current.   Originally, when I did not know better, we considered
trying to make the nested procedures separate, but that did not
work under the rules of Ada.  I did hear that someone later worked
this up into a package body and was able to do something using
separate at the library level.   I am not sure about that since I did
not get to see the subsequent code.

In your case, you and the small number of programmers who work
with you are intimately familiar with the code.  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.

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.

Richard Riehle