From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,fc52c633190162e0 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!news.karotte.org!news2.arglkargh.de!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Use of declare blocks Date: Fri, 23 Mar 2007 00:15:57 -0500 Organization: Jacob's private Usenet server Message-ID: References: <1172144043.746296.44680@m58g2000cwm.googlegroups.com> <1172161751.573558.24140@h3g2000cwc.googlegroups.com> <546qkhF1tr7dtU1@mid.individual.net> <5ZULh.48$YL5.40@newssvr29.news.prodigy.net> <4eeMh.16400$bb1.2557@newssvr17.news.prodigy.net> <%CIMh.1791$rj1.394@newssvr23.news.prodigy.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1174626868 22536 69.95.181.76 (23 Mar 2007 05:14:28 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 23 Mar 2007 05:14:28 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Xref: g2news1.google.com comp.lang.ada:14604 Date: 2007-03-23T00:15:57-05:00 List-Id: wrote in message news:%CIMh.1791$rj1.394@newssvr23.news.prodigy.net... > > "Randy Brukardt" 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.