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=0.6 required=5.0 tests=BAYES_00,FROM_WORDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,577df5d4a0e88785 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2000-12-15 06:14:35 PST Path: supernews.google.com!sn-xit-02!supernews.com!nntp-relay.ihug.net!ihug.co.nz!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp.flash.net!news.flash.net!not-for-mail From: "Ken Garlington" Newsgroups: comp.lang.ada References: Subject: Re: Bad coding standards X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: Date: Fri, 15 Dec 2000 14:14:34 GMT NNTP-Posting-Host: 216.215.69.233 X-Complaints-To: abuse@flash.net X-Trace: news.flash.net 976889674 216.215.69.233 (Fri, 15 Dec 2000 08:14:34 CST) NNTP-Posting-Date: Fri, 15 Dec 2000 08:14:34 CST Organization: FlashNet Communications, http://www.flash.net Xref: supernews.google.com comp.lang.ada:3168 Date: 2000-12-15T14:14:34+00:00 List-Id: "Beard, Frank" wrote in message news:B6A1A9B09E52D31183ED00A0C9E0888C469959@nctswashxchg.nctswash.navy.mil.. . : -----Original Message----- : From: Ken Garlington [mailto:Ken.Garlington@computer.org] : : > Because (a) that's not what it's intended to do, and (b) there are other : > document that *are* intended for that purpose. Since Ada attempts to : > discourage the "copy principle," it's not surprising that the ARM does not : > choose to be redundant with available style guides ;) : : Why not? Seeing how the Ada Reference Manual is the "bible" of the Ada : language, written by the founders (or "pillars") of the language. Wouldn't : it be reasonable to assume that the examples given in the reference : manual would be written in a "good" style? No. In fact, this practice is not limited to Ada *reference* documents. "This quick reference guide for the Standard C programming language provides all of the information you need to read and write programs in Standard C. It describes all aspects of Standard C that are the same on all implementations that conform to the standard for C. This is not a tutorial on Standard C nor a lesson on how to write computer programs." -- Plauger and Brodie, "Standard C." Microsoft Prcess, 1989. And as such, worthy of : emulation, : something to be followed? You know, a reasonable guide. What's that : phrase? : Oh yeah, a "style guide". : : Because I think it's ludicrous to assume those using the language manual, : especially new users, wouldn't assume that the "examples" weren't a : good style to follow. I suppose "new users" may make all sorts of mistakes. For myself, when I want to learn a new language, I don't normally start with the ISO standard (assuming it exists). I get a textbook, or use an on-line resource. For example: http://www.adahome.com/Tutorials/Lovelace/lovelace.html : I know later they could learn about style guides, : but if it were another part of the standard, maybe the "Style Guide : Annex", then we would have universal approach. Why not? I think your next sentence provides one reason -- why add additional work to a process that already takes significant effort? The second reason relates to what I would call "separation of concerns." Why mix a style guide in with something that, within the limits of reasonableness, is supposed to accurately specify a language? Finally, it's not clear that a style guide is (or should be) intended to force a "universal approach." As noted in the SPC guide: "Other guidelines presented in this book are intentionally phrased in terms of design choices to consider. These guidelines cannot be instantiated as hard-and-fast rules that a project must follow. For example, you should not interpret Guidelines 6.1.1 and 6.1.2 to mean that a project is forbidden to use tasks. Rather, these guidelines are intended to help the designer make the tradeoffs between using protected objects and tasks, thus leading the designer to make a more informed choice between these features." : Many in the : beginning didn't think we could get this many people, from different : countries, to agree, within reason, on a programming language. I don't know why "many" people would have felt that way. Certainly, Ada is not the first internationally standardized language to be used widely. It's not easy, but it's far from impossible. : I'm not sure about the "Since Ada attempts to discourage the "copy : principle,"" : part. I'm not sure where that comes from. IIRC, I first heard it in a speech given by Jean Ichbiah in Dallas in the early 1980s. The idea is that doing manual "cut-and-paste" operations is highly error prone. Therefore, you want a language that encourages modularization and controlled parameterization (e.g. generics) as a more reliable alternative. : But, it seems to me reuse is the : ultimate in the "copy principle" (more like condoned plagiarism), and the : main point of the style guides (and by that I mean the style guide says this : is what we think is "good", do it this way). : : >> "it has no impact on the operation or performance of the software, just : >> aesthetics." : > : > I might assume that the word "just" implies that aesthetics are less : > important than operation or performance. As the ARM points out, the design : > of Ada is predicated in part on the idea that aesthetics are very : important. : : Well, I can see where that could possibly happen. Maybe I should : have said "just the aesthetics". If you look at the whole sentence: : : "Unless your talking about style guide issues that specify : using "for loops" as opposed to a "slices", or using "case" : statements instead of an "if" statements, then it has no : impact on the operation or performance of the software, just : aesthetics." : : The "just" in the sentence meant that outside the part of style : guide that deals with structural issues, such as data structures, : then your are left with just the aesthetic part. I didn't mean : to imply that I didn't think aesthetics were important, just : subject to opinion. If you didn't get my point in previous e-mails, : I consider it an integral part of readability. Unlike some who : think readability and aesthetics form some type of dichotomy, or : at least don't see the connection. : : Frank : : :