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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7d1a6bfc6489c17b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2000-09-05 23:59:07 PST Path: supernews.google.com!sn-xit-02!sn-east!supernews.com!news-feed.riddles.org.uk!arclight.uoregon.edu!hammer.uoregon.edu!newsfeed.direct.ca!look.ca!newsfeed.bc.tac.net!news.bc.tac.net!not-for-mail Sender: blaak@ns45.infomatch.bc.ca Newsgroups: comp.lang.ada Subject: Re: exiting a bloc References: <39B15EA8.88DB58AB@netcourrier.com> <8orprn$b46$1@nnrp1.deja.com> <39B532CB.73D359F8@ix.netcom.com> From: Ray Blaak Message-ID: X-Newsreader: Gnus v5.6.42/Emacs 20.3 Date: 06 Sep 2000 00:00:30 -0700 NNTP-Posting-Host: 207.34.170.109 X-Complaints-To: news@bctel.net X-Trace: news.bc.tac.net 968223527 207.34.170.109 (Tue, 05 Sep 2000 23:58:47 PDT) NNTP-Posting-Date: Tue, 05 Sep 2000 23:58:47 PDT Xref: supernews.google.com comp.lang.ada:516 Date: 2000-09-06T00:00:30-07:00 List-Id: Richard Riehle writes: > I know of one manager with responsibility for embedded Ada software who > prohibits declare blocks in the code [...nested procedures are better...] His > point-of-view evolved over many years of watching declare blocks grow to > cover several pages, become more convulted with the nesting of additional > declare blocks during program maintenance, and transmogrify into long > passages of increasingly unreadable code. This doesn't make sense to me. If the problem is large blocks of code, then the solution is to break the large blocks into smaller blocks. Declare blocks themselves are not the problem, and banning them doesn't fix the problem. After all, nested procedures can also grow as well, until the over all routine is simply huge and unwieldy. The rule should simply be: "do things right!". Use the right language language features for the situation, so that the result is beautiful crystaline code. Other stupid rules: no recursion, no instantiations in procedures, no nested procedures, no access types... I once saw someone, in accordance to the no access types rule, implement an abstract string referencing scheme using private integers to index into a pool of string "chunks". Basically he reimplemented pointers all over again, with the same lost and dangling reference bugs being possible. Using access types directly would have been much much simpler, faster, easier to understand and maintain, as well as more amenable to the automated detection of memory leaks by system tools. The moral of the story is that banning language features by fiat is stupid. One should instead understand why a feature should not be used in certain situations, and what is the right feature to use instead, or at least what can be done to use the feature in the right way. > So, are declare blocks, echoing the ancient Jeremiad of Dijkstra, > "considered dangerous" ? I don't see how, any more than routines in general can be dangerous. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul.