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,21bbcb8deeeab673 X-Google-Attributes: gid103376,public From: "Jeff Burns" Subject: Re: Ada95 Pretty-Printers/Coding styles Date: 1997/06/25 Message-ID: <5orld5$5r8@client2.news.psi.net> X-Deja-AN: 252515610 References: <33A54D07.4E14@aisf.com> Organization: GrammaTech, Inc. Newsgroups: comp.lang.ada Date: 1997-06-25T00:00:00+00:00 List-Id: In article , dewar@merv.cs.nyu.edu (Robert Dewar) wrote: >In an advertisement for Ada Assured . . . Hmm, seems I have seen ACT mentioned here once or twice, too. ;-) That's okay. Tool support is one of the major criticisms of Ada, so it's worthwhile letting engineers know what good Ada tools are available. Got your point, however, and will try not to stray too far over to the dark side of commercialism. >I suspect you have not read any of the material here and are just guessing. >In fact the kind of mechanical rule that Ada Assured can enforce IS enforced >by a mechanical tool at ACT, namely the -gnatg switch, and the documentation >of these requirements is very precise, it can be found in the files style.ads >and style.adb. I have read a fair amount of material here and noted that when someone asked you for your specific coding style, you listed three items, two of which you described as undocumented or vague. The other item you mention above is a mechanical check of 31 GNAT style rules using the -gnatg switch with the GNAT compiler. I have looked at these rules and they are an extremely small subset of a typical set of style guidelines and do not begin to address many of the SPC's Ada Quality and Style Guidelines enforced by Ada-ASSURED. === Software Productivity Consortium AQ&S http://sw-eng.falls-church.va.us/AdaIC/docs/style-guide/95style/html/cover.h tml === > >These rules [style.ads and style.adb] are by no means trivial, >they include things like > >a) specs required for all procedures >b) capitalization in a use of an identifier must match the declaration This is interesting because the second example you give IS trivial, at least for Ada-ASSURED, and not to just monitor this style but to actually automate compliance. In fact, all but two of the 31 rules in your style files are trivial for Ada-ASSURED. And then, of course, it goes much further to automate many more rules and guidelines from the AQ&S and the LRM. The other two rules, including the first example above are good uses for a compiler. >So, yes, I agree that tools like Ada Assured are useful, however, for maximum >utility I think it is important that they be embedded into the compiler Here's where we differ. Our approach is that AA takes care of formatting and style checking while the code is being written (or just after it's written or received, in the case of Ada-Utilities), so fewer style errors (and no syntax errors) ever reach the compiler. This helps reduce compile/correction/recompile cycles. Your approach delays this kind of error checking until code reaches the compiler. It seems to me it would add a lot of overhead to the compiler. And, of course, a compiler wouldn't actively correct style and formatting errors, it would just check for errors. >1. For some of the more subtle stuff, you need the full power of an Ada >compiler anyway. Agreed, some of the more subtle stuff is best handled by the compiler. >2. That way [embedding style checking into the compiler], it is easy to insist >on its absolutely systematic use. In our >environment it is simply not possible to check in code that has not been >checked out by this tool, and that comes not from some barrier at the >checkin stage, but because EVERY compilation ALWAYS checks. While I understand the appeal of this hypothetical approach for universal checking of code, it is a passive solution that adds unnecessary additional work. The compiler finds errors and then the original engineer (or worse yet, someone else) has to manually go back through the code and make corrections. Furthermore, the 31 GNAT rules are hardly comprehensive. Certainly you aren't suggesting that every compiler should be burdened with a complete set of style checks and a multitude of formatting checks (such as colon and identifier alignment). These items are more easily handled by a tool designed for checking and correcting style. >The points in my note that you identified as vague go FAR beyond anything >that can be done automatically by a tool. But how would we know if, as you said, they are not documented? The very best of objectives don't mean much in most organizations if they're not documented -- how important can they be if they're not written down? [Granted, you run a tight shop where this informal approach works well among your small number of engineers.] I don't know which of your undocumented style guidelines can be automated, but so far you seem to have underestimated what can be done automatically by a tool (ironic, coming from a compiler vendor). >And yes, I agree, it is probably impossible to get a large company to >apply this kind of consistency company wide This is where a tool like Ada-ASSURED comes in: it can apply a consistent style company wide. It may not ensure compliance with every nuance your group has informally selected, but it will ensure consistent conformance with a customizable and reasonably comprehensive set of style guidelines. We agree that following a consistent coding style contributes to quality: code will be easier to read and understand, and therefore easier to maintain and reuse. We differ in practical approaches for getting there. ----------------------------- Jeff Burns, Director of Marketing GrammaTech, Inc. One Hopkins Place Ithaca, NY 14850 ph: 607-273-7340 fax: 607-273-8752 e-mail: jeff@grammatech.com www: http://www.grammatech.com Team Ada ==============================