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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no 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/18 Message-ID: <5o9f0s$it2@client2.news.psi.net>#1/1 X-Deja-AN: 249406982 References: <33A54D07.4E14@aisf.com> <33A68335.44FDDAC6@elca-matrix.ch> Organization: GrammaTech, Inc. Newsgroups: comp.lang.ada Date: 1997-06-18T00:00:00+00:00 List-Id: In article , dewar@merv.cs.nyu.edu (Robert Dewar) wrote: >Mats asks >If you have an internal style guide for GNAT code, I'd be interested in >reading it (unless it's a secret recipe, of course :-)>> > >The style we use has three parts > >a) mechanically enforced rules -- for these see the source files style.ads >and style.adb (which incidentally you can hack to make your own style rules >enforced). > >b) rules that are pretty definite, but not enforced, and could be written >down, but never have been. Yes, it would be nice to write these down, but >it is not a high priority task for us. > >c) rules that are quite vague, having to do with an aesthetic feeling of >which is the nicer way of doing things in a particular situation. These >cannot easily be written down, but they are a detectable part of the style >of code -- the sort of thing that can give clues as to who wrote the code. > >What is remarkable at ACT is that we have a high degree of agreement between >ourselves even at level c). Well, the more vague a standard is, the easier it is to have agreement, right? ;-) No offense intended Robert, but this sounds very subjective to be much of a style guide. It may work at a small company like ACT, and I understand your code is beautiful, so it does work for you. But this model doesn't sound very reasonable for large defense and aerospace companies where thousands of engineers are working on hundreds of projects (and where staffing is inconsistent and people work in multiple languages). Vague aesthetics and individual interpretation of good style are not consistent with an engineering approach to large scale complex manufacturing (which is what they're doing). Their code needs to be understandable, not just internally, but to their customers and to other contractors who may have to maintain or update their code. We at GrammaTech work with a lot of engineers who have to work with code they've inherited from other contractors. You'd be amazed at how inconsistent and difficult to read this code often is. It seems to be a fairly universal problem. At tradeshows we bring one of the worst examples of source code we've found and use it for a "before and after" demo of how Ada-ASSURED can pretty print, clean up style problems, and help standardize multiple source files. Nine times out of ten the engineers we demo it to tell us they've had to work with code that's as bad or worse than our "before" example. I'm confident that there are internal style guidelines at the organizations that produce code like our "before" example. But for whatever reason, style guidelines are not always enforced, people seem to go in their own directions, and the results are not the consistent quality that ACT is able to produce. With Ada-ASSURED we're trying to help engineers to follow consistent style guidelines across group, project, and company boundaries so their code will be easier for anyone to read. As you have mentioned, consistency is a key objective. However, I understand from your past postings that you often find tools that enforce a consistent coding style too restrictive. Ada-ASSURED helps monitor, enforce, and correct code according to very specific style guidelines based on the AQ&S, the LRM, and common correct usage we learn from our customers. We balance standardization with flexibility where we can. A lot of the guidelines can be turned on/off or parameterized for a project's preference or interpretation, but others are less flexible and may be considered restrictive (it is the nature of standards to be specific and this is can be restrictive). Ada-ASSURED takes care of style, automatically much of the time, so engineers can concentrate on more challenging and important things, like content. This approach may not be for everyone, but the alternative, from what I've seen, is often not very pretty and costs extra time and money down the road. ----------------------------- 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 ==============================