* RE: Bad coding standards @ 2000-12-14 2:32 Beard, Frank 2000-12-14 12:19 ` Robert Dewar ` (2 more replies) 0 siblings, 3 replies; 31+ messages in thread From: Beard, Frank @ 2000-12-14 2:32 UTC (permalink / raw) To: 'comp.lang.ada@ada.eu.org' I'm not saying coding standards/style guides are just aesthetics. Listen to me now. I'm saying that "outside" of coding standards that specify "which constructs to use" for given situations, you are now in the realm of aesthetics. I'm saying that: if success then runs no differently that if SUCCESS then or IF SUCCESS THEN It has no structural or runtime impact whatsoever. If you're talking about something like using a slice from an array as opposed to a "for loop", then it can have a structural and runtime impact. On VAX Ada it was faster to use a "for loop" than to use a slice because of the way they did range checking on the elements of the array. Readability (aesthetics) is a different issue. And I'm not saying readability is only aesthetics. To quote my American Heritage Dictionary: aesthetic - "In accordance with accepted notions of good taste or style". I may be taking some liberties with what they mean by style, but to say something is more readable, to me usually means it is more aesthetically pleasing. If it's not readable, it's not aesthetically pleasing. I don't care how artistic you make it. Nothing in ARM paragraphs 7-8 contradicts what I said. I agree with the paragraphs. I agree with the principle of readability and maintainability, but readability is subject to interpretation, preference, what is pleasing to read (dare I say it again - aesthetics), etc. Our style guide is very similar to the Ada LRM (you say ARM I say LRM. Which is more readably? Neither, their both cryptic.). Why don't you type out Ada Reference Manual? Doesn't ARM violate your style guide? Hmmm, another exception (ARM renames Ada_Reference_Manual). Why did the Ada95 LRM style change from the Ada83 LRM style? Hmmm, yet another exception. Is suddenly the Ada83 LRM style "bad"? Oh, the poor souls who got trapped under the Ada83 style. Have they yet to see the salvation of the Ada95 style? Will Ada0x change yet again? Who's right, who's wrong? Why doesn't the Ada standard specify the style as well, so that we're all writing to the same coding standard, if it is that crucial and people have such poignant opinions about it? Frank -----Original Message----- From: Ken Garlington [mailto:Ken.Garlington@computer.org] : : Ouch! "Just aesthetics?" See ARM, Introduction, paragraphs 7-8 for a : contrary position. : : _______________________________________________ comp.lang.ada mailing list comp.lang.ada@ada.eu.org http://ada.eu.org/mailman/listinfo/comp.lang.ada ^ permalink raw reply [flat|nested] 31+ messages in thread
* RE: Bad coding standards 2000-12-14 2:32 Bad coding standards Beard, Frank @ 2000-12-14 12:19 ` Robert Dewar 2000-12-14 13:03 ` OT ae [was Re: Bad coding standards] Philip Anderson 2000-12-14 14:19 ` American English (was: Bad coding standards) John English 2000-12-14 14:03 ` Bad coding standards Ken Garlington 2000-12-15 0:52 ` Georg Bauhaus 2 siblings, 2 replies; 31+ messages in thread From: Robert Dewar @ 2000-12-14 12:19 UTC (permalink / raw) In article <B6A1A9B09E52D31183ED00A0C9E0888C469951@nctswashxchg. nctswash.navy.mil>, comp.lang.ada@ada.eu.org wrote: > I'm not saying coding standards/style guides are > just aesthetics. Listen to me now. I'm saying > that "outside" of coding standards that specify > "which constructs to use" for given situations, you > are now in the realm of aesthetics. This seems a mistaken attitude to me. Yes you can argue like Humpty-Dumpty that words mean anything you want them to mean, but using the word "esthetics" too easily implies to too many people that it is just a matter of prettiness and not important. In considering the entirety of software performance, aspects which contribute to maintainability are much more than just a matter of being pretty. For me, an error in a comment, or a violation of a coding standard for layout is a bug in the code, and should be regarded as such. Warning: non-Ada diversion P.S. is aesthetics an allowable spelling in American english? I don't have an American dictionary at hand. The OED only permits the use of "e" or the ae letter which I can't even write in this ASCII character set, but does not permit a separate a and e character. Of course one could take the position that the use of ae in this crippled character set is merely a short hand for the ae character. It is interesting that daemon spelled with the ae character is a quite a bit different from demon with an e. There are positive and negative meanings of the word demon, and the OED specifically notes that people often use the a/e form to emphasize the positive meaning of an agent that intervenes in a positive way (that's the meaning that Unix tries to catch, rather than the negative meaning). Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* OT ae [was Re: Bad coding standards] 2000-12-14 12:19 ` Robert Dewar @ 2000-12-14 13:03 ` Philip Anderson 2000-12-14 14:08 ` Ken Garlington 2000-12-14 14:19 ` American English (was: Bad coding standards) John English 1 sibling, 1 reply; 31+ messages in thread From: Philip Anderson @ 2000-12-14 13:03 UTC (permalink / raw) Robert Dewar wrote: <snip> > Warning: non-Ada diversion > > P.S. is aesthetics an allowable spelling in American > english? I don't have an American dictionary at hand. > The OED only permits the use of "e" or the ae letter > which I can't even write in this ASCII character set, > but does not permit a separate a and e character. I don't have an OED (or other Oxford dictionary) to hand, but Chambers (also) UK does not use the 'ae' ligature in aesthetics or any other 'ae' combination that I can see, with the exception of 'aesc', an Old English rune. This represented the sound also written as ligatured 'ae'in Old English, a vowel distinct from and further forward than 'a' (pronounced as in 'cat' in my speech), and hence was a distinct letter. Usually, 'ae' comes from Latin and in the middle of words often represents Greek 'ai'. In inscriptions, the Romans often ligatured letters together, not just AE; in Late and Church Latin, it tended to turn into plain 'e'. Do the uses cited by the OED for aesthetics etc use the ligature I wonder, or is it just the OED house-style? I rather doubt if there is a commonly-accepted rule, let lone a definitive one. Socrates talked about his 'daimon', and it's usually 'translated' like that to avoid the connotations of 'demon' I guess. -- hwyl/cheers, Philip Anderson Alenia Marconi Systems Cwmbr�n, Cymru/Wales ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: OT ae [was Re: Bad coding standards] 2000-12-14 13:03 ` OT ae [was Re: Bad coding standards] Philip Anderson @ 2000-12-14 14:08 ` Ken Garlington 0 siblings, 0 replies; 31+ messages in thread From: Ken Garlington @ 2000-12-14 14:08 UTC (permalink / raw) "Philip Anderson" <phil.anderson@amsjv.com> wrote in message news:3A38C51D.C7D15F8B@amsjv.com... : Robert Dewar wrote: : <snip> : : > Warning: non-Ada diversion : > : > P.S. is aesthetics an allowable spelling in American : > english? I don't have an American dictionary at hand. try http://www.m-w.com (and yes, it accepts aesthetics as an allowable spelling). ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: American English (was: Bad coding standards) 2000-12-14 12:19 ` Robert Dewar 2000-12-14 13:03 ` OT ae [was Re: Bad coding standards] Philip Anderson @ 2000-12-14 14:19 ` John English 2000-12-14 15:07 ` Graeme ` (2 more replies) 1 sibling, 3 replies; 31+ messages in thread From: John English @ 2000-12-14 14:19 UTC (permalink / raw) Robert Dewar wrote: > Warning: non-Ada diversion > > P.S. is aesthetics an allowable spelling in American > english? I don't have an American dictionary at hand. > The OED only permits the use of "e" or the ae letter > which I can't even write in this ASCII character set, > but does not permit a separate a and e character. "Aesthetic" is, of course, perfectly normal for English English, but I've got no idea about American English. My copy of Chambers says this: "aesthetic: orig. relating to perception by the senses: generally relating to possessing, or pretending to, a sense of beauty; artistic or affecting to be artistic." So I suppose aesthetic is the aesthetic spelling... ;-) "esthesia, esthesiogen, etc. US spellings of aesthesia, etc." I trust Chambers implicitly (it's one of the few dictionaries that includes that wonderful word "taghairm") so if they are happy with "ae" rather than a ligature, I'm happy too. The OED is a bit stuffy about these things sometimes. How do Americans spell "anaesthetic"? Is it "anesthetic" perchance? ----------------------------------------------------------------- John English | mailto:je@brighton.ac.uk Senior Lecturer | http://www.it.bton.ac.uk/staff/je Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS ** University of Brighton | -- see http://burks.bton.ac.uk ----------------------------------------------------------------- ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: American English (was: Bad coding standards) 2000-12-14 14:19 ` American English (was: Bad coding standards) John English @ 2000-12-14 15:07 ` Graeme 2000-12-15 13:16 ` The Design Zone (was Re: American English) Marc A. Criley 2000-12-14 15:14 ` American English (was: Bad coding standards) Marin David Condic 2000-12-14 17:38 ` Brian Rogoff 2 siblings, 1 reply; 31+ messages in thread From: Graeme @ 2000-12-14 15:07 UTC (permalink / raw) John English wrote: > Robert Dewar wrote: > > Warning: non-Ada diversion > > > > P.S. is aesthetics an allowable spelling in American > > english? I don't have an American dictionary at hand. > > The OED only permits the use of "e" or the ae letter > > which I can't even write in this ASCII character set, > > but does not permit a separate a and e character. > > "Aesthetic" is, of course, perfectly normal for English English, > but I've got no idea about American English. My copy of Chambers > says this: > "aesthetic: orig. relating to perception by the senses: generally > relating to possessing, or pretending to, a sense of beauty; > artistic or affecting to be artistic." > > So I suppose aesthetic is the aesthetic spelling... ;-) > > "esthesia, esthesiogen, etc. US spellings of aesthesia, etc." > > I trust Chambers implicitly (it's one of the few dictionaries that > includes that wonderful word "taghairm") so if they are happy > with "ae" rather than a ligature, I'm happy too. The OED is a > bit stuffy about these things sometimes. > > How do Americans spell "anaesthetic"? Is it "anesthetic" perchance? > > ----------------------------------------------------------------- > John English | mailto:je@brighton.ac.uk > Senior Lecturer | http://www.it.bton.ac.uk/staff/je > Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS ** > University of Brighton | -- see http://burks.bton.ac.uk > ----------------------------------------------------------------- Only half-off topic... off this topic anyway, but John - your burks resource for students (in the vernacular) rocks... it is very good... excellent... as is your Ada textbook... one or two dud links on the burks site though - the motorola emulator for PC comes to mind Aesthetics (like, wayyyy off topic) - in philosophy, aesthetics applies to the mind... in a round-about-way - so though we may say that something is beautiful as we perceive it... and attribute aesthetic merit to that entity or object... philosophy looks a lot into into the relationship between our perceptions and that which we believe we perceive... which has pretty well bugger-all to do with ada or programming... perhaps. Some mathematicians "know" when a theory (or solution to a theory, whatever) is correct by the innate beauty of that aesthetic entity they perceive in their mind's eye... I imagine that a (good) programmer also knows when their solution is on the right track because of some symmetry or harmony to the system under analysis or construction... perhaps Ada makes this mental visualisation/comprehension a little more intuitive by its architecture ? As a program under analysis or construction is itself an object of conscious (and unconscious ?) apprehension, perhaps you hard-core professionals intuit your way to the best solutions to a problem by the most "attractive" possible solution ? Which begs my question: "Is a symmetrical (in the sense of harmonious, well-ordered, coherent) design also an effective one ?" I don't know... I am just a lowly student.... drowning in technical documentation with no end in sight. I will be offline for a while... so - no more of my utter irrelevancies for a while... but i do enjoy reading the technical discussions... thanks, all... :-) :-) G ^ permalink raw reply [flat|nested] 31+ messages in thread
* The Design Zone (was Re: American English) 2000-12-14 15:07 ` Graeme @ 2000-12-15 13:16 ` Marc A. Criley 0 siblings, 0 replies; 31+ messages in thread From: Marc A. Criley @ 2000-12-15 13:16 UTC (permalink / raw) Graeme wrote: <snaepped> > Some > mathematicians "know" > when a theory (or solution to a theory, whatever) is correct by the > innate beauty of > that aesthetic entity they perceive in their mind's eye... I imagine > that a (good) programmer > also knows when their solution is on the right track because of some > symmetry or harmony to the system > under analysis or construction... perhaps Ada makes this mental > visualisation/comprehension a little > more intuitive by its architecture ? As a program under analysis or > construction is itself an object of conscious > (and unconscious ?) apprehension, perhaps you hard-core professionals > intuit your way to the best solutions to a problem > by the most "attractive" possible solution ? I've certainly gotten that sense from time to time that the specific design or implementation of some piece of software that I'm looking at is "perfect", that there is no better way to implement what that piece of software is to do. Call it intuition or what you will, but I can certainly feel when I'm "in the zone" doing some design or coding. And the way it happens when I'm working up a major design is to collect the information (requirements, whatever), mix in my experience and knowledge of software architecture and design, then let it turn over in my head for a few days. I poke, prod, draw pictures, explore possibilities; then, in the course of about five minutes, the entire architectural framework and design manifests itself. At this time I begin furiously making diagrams and notes to get it down on hardcopy. And that's how it works for me. Marc A. Criley Senior Staff Engineer Quadrus Corporation www.quadruscorp.com ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: American English (was: Bad coding standards) 2000-12-14 14:19 ` American English (was: Bad coding standards) John English 2000-12-14 15:07 ` Graeme @ 2000-12-14 15:14 ` Marin David Condic 2000-12-14 17:38 ` Brian Rogoff 2 siblings, 0 replies; 31+ messages in thread From: Marin David Condic @ 2000-12-14 15:14 UTC (permalink / raw) I just love when the Word Scientists get started! :-) Being something of an etymologist myself, I often find this interesting. Guess it can't be helped if you assemble a bunch of Language Lawyers into a room. Any way to wander this thread back to Ada? Or should it be AEda? (betcha thought I couldn't do it!) MDC John English wrote: > "Aesthetic" is, of course, perfectly normal for English English, > but I've got no idea about American English. My copy of Chambers > says this: > "aesthetic: orig. relating to perception by the senses: generally > relating to possessing, or pretending to, a sense of beauty; > artistic or affecting to be artistic." > > So I suppose aesthetic is the aesthetic spelling... ;-) > > "esthesia, esthesiogen, etc. US spellings of aesthesia, etc." > > I trust Chambers implicitly (it's one of the few dictionaries that > includes that wonderful word "taghairm") so if they are happy > with "ae" rather than a ligature, I'm happy too. The OED is a > bit stuffy about these things sometimes. > > How do Americans spell "anaesthetic"? Is it "anesthetic" perchance? > > ----------------------------------------------------------------- > John English | mailto:je@brighton.ac.uk > Senior Lecturer | http://www.it.bton.ac.uk/staff/je > Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS ** > University of Brighton | -- see http://burks.bton.ac.uk > ----------------------------------------------------------------- -- ====================================================================== Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "Giving money and power to Government is like giving whiskey and car keys to teenage boys." -- P. J. O'Rourke ====================================================================== ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: American English (was: Bad coding standards) 2000-12-14 14:19 ` American English (was: Bad coding standards) John English 2000-12-14 15:07 ` Graeme 2000-12-14 15:14 ` American English (was: Bad coding standards) Marin David Condic @ 2000-12-14 17:38 ` Brian Rogoff 2000-12-15 16:12 ` John English 2 siblings, 1 reply; 31+ messages in thread From: Brian Rogoff @ 2000-12-14 17:38 UTC (permalink / raw) On Thu, 14 Dec 2000, John English wrote: > How do Americans spell "anaesthetic"? Is it "anesthetic" perchance? Yes. Our wonderfully tolerant Merriam-Webster also accepts the UK variants. Swinging this back to ADA, I have no idea what the American Dental Association prefers. Next time I need novacaine I'll ask to see the label. :-) -- Brian ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: American English (was: Bad coding standards) 2000-12-14 17:38 ` Brian Rogoff @ 2000-12-15 16:12 ` John English 0 siblings, 0 replies; 31+ messages in thread From: John English @ 2000-12-15 16:12 UTC (permalink / raw) Brian Rogoff wrote: > > On Thu, 14 Dec 2000, John English wrote: > > How do Americans spell "anaesthetic"? Is it "anesthetic" perchance? > > Yes. Our wonderfully tolerant Merriam-Webster also accepts the UK variants. > Swinging this back to ADA, I have no idea what the American Dental Association > prefers. Next time I need novacaine I'll ask to see the label. :-) A nice segue back to a parallel-to-on-topic track... (applause!) ;-) ----------------------------------------------------------------- John English | mailto:je@brighton.ac.uk Senior Lecturer | http://www.it.bton.ac.uk/staff/je Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS ** University of Brighton | -- see http://burks.bton.ac.uk ----------------------------------------------------------------- ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Bad coding standards 2000-12-14 2:32 Bad coding standards Beard, Frank 2000-12-14 12:19 ` Robert Dewar @ 2000-12-14 14:03 ` Ken Garlington 2000-12-14 20:14 ` Robert Dewar 2000-12-15 0:52 ` Georg Bauhaus 2 siblings, 1 reply; 31+ messages in thread From: Ken Garlington @ 2000-12-14 14:03 UTC (permalink / raw) "Beard, Frank" <beardf@spawar.navy.mil> wrote in message news:B6A1A9B09E52D31183ED00A0C9E0888C469951@nctswashxchg.nctswash.navy.mil : Our style guide is very similar to the Ada LRM (you say : ARM I say LRM. Which is more readably? Neither, their : both cryptic.). Why don't you type out Ada Reference Manual? : Doesn't ARM violate your style guide? Sure - and as several people have pointed out in the past, the ARM isn't intended to be an easy-to-read explanation of the language for new users, nor a description of best practices. It's intended to be a technical reference for people who already understand the langauge. That's why there are both (a) highly readable textbooks for people learning the language and (b) the AARM, which provides even more arcane details for compiler writers, etc. So, this is a straw man argument. : Hmmm, another exception : (ARM renames Ada_Reference_Manual). Why did the Ada95 LRM : style change from the Ada83 LRM style? Hmmm, yet another : exception. Is suddenly the Ada83 LRM style "bad"? Not "suddenly" - It was _always_ bad :). The Ada95 manual is slightly better, but again someone who uses it as the basis for a project's style guide (instead of, for example, the SPC "Ada Quality and Style Guide"!) is probably making a mistake. : Oh, : the poor souls who got trapped under the Ada83 style. : Have they yet to see the salvation of the Ada95 style? : Will Ada0x change yet again? Who's right, who's wrong? : Why doesn't the Ada standard specify the style as well, : so that we're all writing to the same coding standard, : if it is that crucial and people have such poignant : opinions about it? 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 ;) Of course, my point had nothing to do with which style is _best_. People can reasonably differ on that question. My point is that readability, and aesthetics in general, matters a great deal if you're a professional software engineer. For example, if someone were to say: "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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Bad coding standards 2000-12-14 14:03 ` Bad coding standards Ken Garlington @ 2000-12-14 20:14 ` Robert Dewar 2000-12-15 1:10 ` Ken Garlington 2000-12-18 16:09 ` Tucker Taft 0 siblings, 2 replies; 31+ messages in thread From: Robert Dewar @ 2000-12-14 20:14 UTC (permalink / raw) In article <Vq4_5.7965$bw.729885@news.flash.net>, "Ken Garlington" <Ken.Garlington@computer.org> > wrote: > Not "suddenly" - It was _always_ bad :). The Ada95 > manual is slightly better The reason that the Ada95 RM changed from ALL UPPER CASE to Mixed Case for identifiers, had nothing to do with a judgment as to which was better (a case can me made for either convention), but rather just a reflection that in our experience the Mixed_Case convention was the most common one, so we might as well adopt as familiar as possible a syle of writing the examples. Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Bad coding standards 2000-12-14 20:14 ` Robert Dewar @ 2000-12-15 1:10 ` Ken Garlington 2000-12-18 16:09 ` Tucker Taft 1 sibling, 0 replies; 31+ messages in thread From: Ken Garlington @ 2000-12-15 1:10 UTC (permalink / raw) "Robert Dewar" <robert_dewar@my-deja.com> wrote in message news:91b9ma$bne$1@nnrp1.deja.com... : In article <Vq4_5.7965$bw.729885@news.flash.net>, : "Ken Garlington" <Ken.Garlington@computer.org> : > wrote: : > Not "suddenly" - It was _always_ bad :). The Ada95 : > manual is slightly better : : The reason that the Ada95 RM changed from ALL UPPER : CASE to Mixed Case for identifiers, had nothing to : do with a judgment as to which was better (a case : can me made for either convention), but rather just : a reflection that in our experience the Mixed_Case : convention was the most common one, so we might as : well adopt as familiar as possible a syle of writing : the examples. Of course, adopting a "familiar" style of writing could, in fact, be a case for claiming an improvement! ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Bad coding standards 2000-12-14 20:14 ` Robert Dewar 2000-12-15 1:10 ` Ken Garlington @ 2000-12-18 16:09 ` Tucker Taft 2000-12-18 18:59 ` Marin David Condic 2000-12-19 15:42 ` Robert Dewar 1 sibling, 2 replies; 31+ messages in thread From: Tucker Taft @ 2000-12-18 16:09 UTC (permalink / raw) Robert Dewar wrote: > ... > The reason that the Ada95 RM changed from ALL UPPER > CASE to Mixed Case for identifiers, had nothing to > do with a judgment as to which was better (a case > can me made for either convention), but rather just > a reflection that in our experience the Mixed_Case > convention was the most common one, so we might as > well adopt as familiar as possible a syle of writing > the examples. Well, as usual, we each have our own interpretation of history. For what it is worth, my memory is that the Ada 9X design team really hated the ALL CAPS convention of Ada 83. Perhaps Robert is giving the reason why the proposed change was accepted by the reviewers, rather than the reason why the change was proposed in the first place. -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Commercial Division, AverStar (formerly Intermetrics) (http://www.averstar.com/services/IT_consulting.html) Burlington, MA USA ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Bad coding standards 2000-12-18 16:09 ` Tucker Taft @ 2000-12-18 18:59 ` Marin David Condic 2000-12-18 22:20 ` Georg Bauhaus 2000-12-19 15:49 ` Robert Dewar 2000-12-19 15:42 ` Robert Dewar 1 sibling, 2 replies; 31+ messages in thread From: Marin David Condic @ 2000-12-18 18:59 UTC (permalink / raw) In any case (pun intended :-) this seems to be basically a non-issue. If you like all upper case, you're free to use it. If you like C++ coding conventions, you're free to do that too. Consistency within a project is probably more important than specifically what style you choose. Consistency means that someone reading your code within a project will more immediately recognize what they are looking at. People who look at my code may not always like the way I have done things, but it at least looks like it was done in a very mechanistic style, with very consistent rules that help them recognize what is going on. (Anyone can visit my web site and look over code I have made available there if they are curious about my style...) This is much superior to code that looks like it was "Organically Grown". I started out with Ada using all upper case for identifiers, following the convention of the standard (Ada83). I think maybe I did so because of ancient history. Slowly, I was persuaded to use mixed case. I think I've grown to like the appearance of mixed case because it just looks nicer. But its a matter of taste and if someone uses all upper case or the C/C++ convention of mixed case with no underscores, I can live with it and work with it. Make the code look like the rest of the code in the project (unless it is hopelessly messy!) and you're doing a favor to those that come after you. If the code is started from bottom-dead-center, then establish a style and stick to it. The visual consistency will help those that come later recognize what is happening more quickly. MDC Tucker Taft wrote: > Well, as usual, we each have our own interpretation of history. > For what it is worth, my memory is that the Ada 9X design team really > hated the ALL CAPS convention of Ada 83. Perhaps Robert is giving > the reason why the proposed change was accepted by the > reviewers, rather than the reason why the change was > proposed in the first place. -- ====================================================================== Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "Giving money and power to Government is like giving whiskey and car keys to teenage boys." -- P. J. O'Rourke ====================================================================== ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Bad coding standards 2000-12-18 18:59 ` Marin David Condic @ 2000-12-18 22:20 ` Georg Bauhaus 2000-12-19 15:51 ` Tucker Taft 2000-12-19 16:01 ` Robert Dewar 2000-12-19 15:49 ` Robert Dewar 1 sibling, 2 replies; 31+ messages in thread From: Georg Bauhaus @ 2000-12-18 22:20 UTC (permalink / raw) Marin David Condic (mcondic.nospam@acm.org) wrote: : Consistency : means that someone reading your code within a project will more immediately : recognize what they are looking at. Having to live in a world with several styles in a set of files belonging together, or even in the same files, I've come to think of these not-easy-to-maintain but still usable files as plays, not monographs. The perspective of watching many actors is a helpful relief when one has to adapt ones code recognition apparatus to others' ways of writing their code. I understand that Robert Dewar prefers strict stylistic unification, for reasons that he has restated in this thread, namely being advantageous for maintanablility, and fostering egoless programming. What is missing in this argument however, is, I think, on what particular view this is based. Is it true that egoless programming is a good thing, _economically_? The argument is incomplete if it does not show why it is preferable, if programmers don't see who wrote what, and if programmers are (possibly) forced to write to that effect. I'm reminded of the "Motivation" article in the Emacs distribution. If you care about your Ego and connect a reason to be proud or satisfied or motivated with your name appearing and your style showing up, with the idea in mind, that people will be noting this, then Egos programming could be an economically relevant factor. Are there measurements? Are there arguments that are stronger? (Well, I think so ;-) : Slowly, I was persuaded to use mixed case. I think I've grown to like : the appearance of mixed case because it just looks nicer. But its a matter of : taste (...) : like the rest of the code in the project (unless it is hopelessly messy!) and : you're doing a favor to those that come after you. Now there are some things that need to be noted when it comes to chosing upper and lower case characters, as is known to typesetters. Everything depends largely on the font! As an analog, count the books not using letters with serifs for the main text, this is not just a matter of taste, but of readability, there are very few fonts granting readabilyty without serifs. Same for all upper case: The font (plus kerning) chosen has a strong influence on whether or not most readers will have difficulties reading a longer passage. (There is a note concerning this in N. Cohens book.) Try formatting some mixed case Ada program in ALGOL 60 style ("Description" book, reserved words bold sans serifs, identifiers in italics, all lower case, operators, parens upright symbols) (i.e. one deviation: mixed case) and see if you still think you are reading the same source code. Try some letter combinations in upper and lower case with a left parenthesis somewhere in between. Have you ever seen a typeset math book leaving a space between f(x)'s f and (? This is not an argument for forcing no space between subprogram identifiers and parameter lists in monospaced source code, say. Rather, it shows that an italic f, a roman (, and an italic x make the paren stand out in these fonts. This is not always guaranteed in monospaced fonts. So, aesthetics (there is no one character th in either American or British (or Irish?) English, after all ;-) is not just prettyness or beauty or looking nice, in the sense that these have effects. Before trying variations, and measuring the effects (or trying to do so), the perspective may be considered incomplete. Georg Bauhaus ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Bad coding standards 2000-12-18 22:20 ` Georg Bauhaus @ 2000-12-19 15:51 ` Tucker Taft 2000-12-19 16:12 ` Marin David Condic 2000-12-19 16:01 ` Robert Dewar 1 sibling, 1 reply; 31+ messages in thread From: Tucker Taft @ 2000-12-19 15:51 UTC (permalink / raw) Georg Bauhaus wrote: > ... > I understand that Robert Dewar prefers strict stylistic > unification, for reasons that he has restated in this > thread, namely being advantageous for maintanablility, > and fostering egoless programming. What is missing in > this argument however, is, I think, on what particular > view this is based. Is it true that egoless > programming is a good thing, _economically_? For what it is worth, rather than using the term "egoless" programming I would opt for "team-oriented programming." That is, by working together, sharing code and moving about in the code for the system as necessary to make things better, everyone benefits. And based on anecdotal evidence, those who cannot follow the project coding standards tend to be the loners who lack a team-oriented view in other ways as well, and end up contributing less to the overall success of the project, even if in the short term they "cut" more code. > ... > Georg Bauhaus -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Commercial Division, AverStar (formerly Intermetrics) (http://www.averstar.com/services/IT_consulting.html) Burlington, MA USA ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Bad coding standards 2000-12-19 15:51 ` Tucker Taft @ 2000-12-19 16:12 ` Marin David Condic 0 siblings, 0 replies; 31+ messages in thread From: Marin David Condic @ 2000-12-19 16:12 UTC (permalink / raw) And this is why they say that Managing Programmers Is Like Herding Cats. :-) MDC Tucker Taft wrote: > And based on anecdotal evidence, those who cannot follow the > project coding standards tend to be the loners who lack a team-oriented > view in other ways as well, and end up contributing less to the > overall success of the project, even if in the short term they > "cut" more code. -- ====================================================================== Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "Giving money and power to Government is like giving whiskey and car keys to teenage boys." -- P. J. O'Rourke ====================================================================== ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Bad coding standards 2000-12-18 22:20 ` Georg Bauhaus 2000-12-19 15:51 ` Tucker Taft @ 2000-12-19 16:01 ` Robert Dewar 1 sibling, 0 replies; 31+ messages in thread From: Robert Dewar @ 2000-12-19 16:01 UTC (permalink / raw) In article <91m2j2$bkn$1@news-hrz.uni-duisburg.de>, sb463ba@l1-hrz.uni-duisburg.de (Georg Bauhaus) wrote: > I understand that Robert Dewar prefers strict stylistic > unification, for reasons that he has restated in this > thread, namely being advantageous for maintanablility, > and fostering egoless programming. > What is missing in > this argument however, is, I think, on what particular > view this is based. Is it true that egoless > programming is a good thing, _economically_? > The argument is incomplete if it does not show why > it is preferable Indeed the argument IS economic: 1. Ease of maintenance is definitely an economic argument. It is also good for morale. People are going to be forced to maintain code written by someone else no matter what you do. It is easier and pleasanter to do this task if the code is written in a familiar style, which is the style that the programmer likes to work with. 2. Avoidance of code ownership is most definitely an economic argument. It is a very dangerous situation for a chunk of code to be owned by one person. I have time and time again encountered a situation where even in a large company there is an important chunk of code which no one can touch, because only Joe knew the code and Joe left. > if programmers don't see who wrote what, > and if programmers are (possibly) forced to write to that > effect. I'm reminded of the "Motivation" article in the > Emacs distribution. If you care about your Ego and connect > a reason to be proud or satisfied or motivated with your name > appearing and your style showing up, with the idea in mind. Pride in code is a very important factor, but that pride can be shared pride in a team effort. Indeed it is very important for programmers to be proud of what they create. Within a team, of course people do know who does what, but from the point of the external world, it is just fine for the appreciation to be on the team level. That has certainly worked well for GNAT, and it is rather remarkable that at ACT, which has been around for five years, so far, apart from one person who left to work on GNAT at a customer site after working for ACT only a few weeks, no engineer has left ACT. That's unusual in a high tech company like ours. Of course there are many reasons for this, but certainly I don't see at all a situation where individuals are frustrated by being forced to follow a common style. Quite the opposite. > that people will be noting this, then Egos programming could > be an economically relevant factor. Are there measurements? Well it is very hard to measure this sort of thing, since other factors are never equal. All I can say is that it works well for us (Ada Core Technologies). Note that there are two separate issues here. 1. Common style, I do not see ANY advantage at all economically or otherwise, in permitting gratuitous variations in coding style. Anyone who adamantly refuses to follow a common style is likely to be less than fully cooperative with the team effort in any case, and the economic disadvantages of not following a common style are considerable. I know of one Ada vendor where the binder had a different identifier capitalization stlye than the rest of the company. The result was that no one would work on the binder except this one person, and that was a continual problem. 2. Avoiding code ownership and attribution. This is a different issue. Common style is necessary to achieve this, but you can have a common coding style, and still have clear code ownership. For the reasons I have stated, I think this is a bad idea, but please don't assume that this is the same issue as forcing a common coding style -- it is a quite separate issue. Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Bad coding standards 2000-12-18 18:59 ` Marin David Condic 2000-12-18 22:20 ` Georg Bauhaus @ 2000-12-19 15:49 ` Robert Dewar 2000-12-19 16:36 ` Marin David Condic 2000-12-19 18:05 ` Larry Kilgallen 1 sibling, 2 replies; 31+ messages in thread From: Robert Dewar @ 2000-12-19 15:49 UTC (permalink / raw) In article <3A3E5E7E.67817482@acm.org>, Marin David Condic <mcondic.nospam@acm.org> wrote: > In any case (pun intended :-) this seems to be basically a non-issue. If you > like all upper case, you're free to use it. If you like C++ coding > conventions, you're free to do that too. Consistency within a project is > probably more important than specifically what style you choose. Yes, that is of course true, nevertheless it is an advantage if everyone, or at least most folks, agree on a consistent style, as it makes discussion easier (it has for example been a consistent annoyance in C that there are several conventions for the use of {} The fact that indentation is strongly suggested by the RM has meant that pretty much everyone uses the same indentation style, which is an advantage. You certainly get used to anything you use a lot. At first I found the mixed case style of identifiers annoying (mainly because they are not well enough distinguished in comments), but now I am completely used to it, and find anything else annoying, e.g. I really dislike Mike Feldman's style in his book, and find this a disadvantage of the book, he uses FOR VariableRef in Typ LOOP .... which to me has the keywords yelling at me :-) So my recommendation is follow the RM style for keyword and identifier capitalization unless there is good reason not to. Robert Dewar P.S. A neat feature of GNAT is that it learns your style for error message purposes, so it will tell me: "end Try;" expected and it will tell Mike "END Try;" expected and it may tell someone else "end TRY;" expected Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Bad coding standards 2000-12-19 15:49 ` Robert Dewar @ 2000-12-19 16:36 ` Marin David Condic 2000-12-20 1:52 ` Ken Garlington 2000-12-20 11:56 ` Mario Amado Alves 2000-12-19 18:05 ` Larry Kilgallen 1 sibling, 2 replies; 31+ messages in thread From: Marin David Condic @ 2000-12-19 16:36 UTC (permalink / raw) Robert Dewar wrote: > Yes, that is of course true, nevertheless it is an advantage > if everyone, or at least most folks, agree on a consistent > style, as it makes discussion easier (it has for example > been a consistent annoyance in C that there are several > conventions for the use of {} > Oh sure. If there was a well defined and accepted standard for Ada programming in general, it is better for people to stick with that than go off inventing something of their own for every given project. I recall looking at the Software Productivity Consortium's efforts in this area and adopted many of the style guides in my efforts. However, my comment to my boss at that time was: "Nice standard. I'd really hate to get audited against it though." That pretty much burried it for our projects. Just way too much detail for being enforceable. I circulated it with other developers and strongly recommended that they look it over and try to utilize it. I just didn't want an internal or external auditor to start going through reams of our code and ding us at every violation. That can get very costly and all you're doing is dealing with cosmetic things that don't impact The Bottom Line as much as a slipped delivery date would. IMHO, if you have a style guide that can be written in - say - oh... ten pages or less? - then you probably have something that can reasonably be utilized and enforced on a project. The SPC's style guide was well over this page limit. > > The fact that indentation is strongly suggested by the RM > has meant that pretty much everyone uses the same indentation > style, which is an advantage. > Definitely. Syntactically, Ada tends to indent better than C/C++ - especially when you look at the kinds of "tricks" that your garden variety C programmer likes to pull. (Doing all the work of a loop in the iteration scheme, for example) The standard sets an example which generally tends to get followed. But I've seen programs where indentation may vary from 2..3..4 spaces. No clear agreement about how many are required. Does it matter? Maybe a little. Are other ARM conventions important - such as character case or where to break long statements or parameter lists, etc? I think that most Ada code I've seen tends to at least be reminicent of the ARM, but some of the code examples there are not to my liking and I wouldn't blame developers for establishing different ones. We may never get full agreement on what style looks best, so I'd still go with at least having a consistent standard on a project by project basis. And the standard should not be long or rigid or it simply won't get followed. (Remember "The Mandate"... :-) MDC -- ====================================================================== Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "Giving money and power to Government is like giving whiskey and car keys to teenage boys." -- P. J. O'Rourke ====================================================================== ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Bad coding standards 2000-12-19 16:36 ` Marin David Condic @ 2000-12-20 1:52 ` Ken Garlington 2000-12-20 12:58 ` Marin David Condic 2000-12-20 11:56 ` Mario Amado Alves 1 sibling, 1 reply; 31+ messages in thread From: Ken Garlington @ 2000-12-20 1:52 UTC (permalink / raw) "Marin David Condic" <mcondic.nospam@acm.org> wrote in message news:3A3F8E88.317C9FDB@acm.org... : Robert Dewar wrote: : : > Yes, that is of course true, nevertheless it is an advantage : > if everyone, or at least most folks, agree on a consistent : > style, as it makes discussion easier (it has for example : > been a consistent annoyance in C that there are several : > conventions for the use of {} : > : : Oh sure. If there was a well defined and accepted standard for Ada : programming in general, it is better for people to stick with that than : go off inventing something of their own for every given project. I : recall looking at the Software Productivity Consortium's efforts in this : area and adopted many of the style guides in my efforts. However, my : comment to my boss at that time was: "Nice standard. I'd really hate to : get audited against it though." That pretty much burried it for our : projects. Just way too much detail for being enforceable. I circulated : it with other developers and strongly recommended that they look it over : and try to utilize it. I just didn't want an internal or external : auditor to start going through reams of our code and ding us at every : violation. That can get very costly and all you're doing is dealing with : cosmetic things that don't impact The Bottom Line as much as a slipped : delivery date would. My recommendation is to fire the auditors -- or at least, pull the rotten teeth. Worked for us. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Bad coding standards 2000-12-20 1:52 ` Ken Garlington @ 2000-12-20 12:58 ` Marin David Condic 2000-12-20 14:27 ` Ken Garlington 0 siblings, 1 reply; 31+ messages in thread From: Marin David Condic @ 2000-12-20 12:58 UTC (permalink / raw) Ken Garlington wrote: > My recommendation is to fire the auditors -- or at least, pull the rotten > teeth. Worked for us. Well you don't always have a choice. Either the government is providing them or maybe you hired a CMM audit firm, etc. The point is, you *said* you were going to do X and here is a spot where you *didn't* do X and why is that? The easiest answer is to never *say* you will live up to some specific style guide. That is why I would opt for a simpler style guide that is easier to live up to and maybe use something more complex as just a "recommended reading" and "suggested practices" for developers. I don't know if anybody uses the SPC style guide as part of their standard work procedures. I think it is useful, but like I said - its just too much detail to want to use it as something you may get audited against. MDC -- ====================================================================== Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "Giving money and power to Government is like giving whiskey and car keys to teenage boys." -- P. J. O'Rourke ====================================================================== ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Bad coding standards 2000-12-20 12:58 ` Marin David Condic @ 2000-12-20 14:27 ` Ken Garlington 2000-12-21 23:19 ` Marin David Condic 0 siblings, 1 reply; 31+ messages in thread From: Ken Garlington @ 2000-12-20 14:27 UTC (permalink / raw) "Marin David Condic" <mcondic.nospam@acm.org> wrote in message news:3A40ACF8.9A35BAB8@acm.org... : Ken Garlington wrote: : : > My recommendation is to fire the auditors -- or at least, pull the rotten : > teeth. Worked for us. : : Well you don't always have a choice. Either the government is providing them : or maybe you hired a CMM audit firm, etc. We have never had a CMM audit firm do an audit against our coding standards, AFAIK, and I can't think of a KPA that would require that kind of detail. You may want to consider another audit firm. If you have a customer that requires it, that's a different matter -- although, if it's the U.S. Government, and it's a new project, you might want to remind them of their stated policy related to acquisition reform... : The point is, you *said* you were : going to do X and here is a spot where you *didn't* do X and why is that? The : easiest answer is to never *say* you will live up to some specific style : guide. Or to write a style guide saying "choose one of the following, using these criteria as suggestions...", which is exactly what SPC did in some cases. : That is why I would opt for a simpler style guide that is easier to live up to : and maybe use something more complex as just a "recommended reading" and : "suggested practices" for developers. Personally, I think that perverts the idea of the word "guide," but I understand what you're saying. : I don't know if anybody uses the SPC style guide as part of their standard : work procedures. I think it is useful, but like I said - its just too much : detail to want to use it as something you may get audited against. : : MDC : -- : ====================================================================== : Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ : Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m : Visit my web site at: http://www.mcondic.com/ : : "Giving money and power to Government is like giving whiskey : and car keys to teenage boys." : : -- P. J. O'Rourke : ====================================================================== : : ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Bad coding standards 2000-12-20 14:27 ` Ken Garlington @ 2000-12-21 23:19 ` Marin David Condic 2001-01-03 19:49 ` Wes Groleau 0 siblings, 1 reply; 31+ messages in thread From: Marin David Condic @ 2000-12-21 23:19 UTC (permalink / raw) Ken Garlington wrote: > We have never had a CMM audit firm do an audit against our coding standards, > AFAIK, and I can't think of a KPA that would require that kind of detail. > You may want to consider another audit firm. If you have a customer that > requires it, that's a different matter -- although, if it's the U.S. > Government, and it's a new project, you might want to remind them of their > stated policy related to acquisition reform... > Well, it obviously depends on your organization and what is required internally and externally. I've just personally encountered (internal) auditors who have dinged us on even fairly lax style requirements. Somebody put in the guide that "A module shall not exceed 200 lines of code without an explanation in the banner..." (Good rule or not - it was in the coding standards.) So the auditor found one module (out of hundreds!) over the limit (barely) without a sufficient explanation and there was a significant unpleasantness over it for several days. The point being that the minute you write down a rule, someone sees it as their job to enforce the rule. Hence, the more detailed and exacting the rules are, the more misery you are asking for later. That's why I'd prefer a coding standard that is relatively short and doesn't demand too many precise details. There are people in the world who are "Control Freaks" or who demand that "The Law Is The Law!" and you often have to be careful about how they are going to look at what you write down. Style *should* be something that is consistent and details help, but you also want a lot of leeway to wiggle if there are reasons to do so. IMHO, a reliable and properly functioning piece of software that is delivered on time is more important than a really pretty piece of software that doesn't work right and/or is late. Strict adherence to style does not necessarily move the mission forward. > > : That is why I would opt for a simpler style guide that is easier to live > up to > : and maybe use something more complex as just a "recommended reading" and > : "suggested practices" for developers. > > Personally, I think that perverts the idea of the word "guide," but I > understand what you're saying. > Well, I guess it depends on the "authority" given to the style guide. If all you do is have it there as the stated style within the team and the team inspects code against it in a review and only looks for gross violations, then fine. If its something that is given more weight by, say, your Software Quality Assurance organization, it can start inter-organization fights, turf wars, etc. that take time to resolve. That's where I'd prefer a shorter and less precise style guide. MDC -- ====================================================================== Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "Giving money and power to Government is like giving whiskey and car keys to teenage boys." -- P. J. O'Rourke ====================================================================== ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Bad coding standards 2000-12-21 23:19 ` Marin David Condic @ 2001-01-03 19:49 ` Wes Groleau 2001-01-06 19:45 ` Lao Xiao Hai 0 siblings, 1 reply; 31+ messages in thread From: Wes Groleau @ 2001-01-03 19:49 UTC (permalink / raw) > There are people in the world who are "Control Freaks" or who demand that "The > Law Is The Law!" and you often have to be careful about how they are going to > look at what you write down. Style *should* be something that is consistent and > details help, but you also want a lot of leeway to wiggle if there are reasons > to do so. IMHO, a reliable and properly functioning piece of software that is > delivered on time is more important than a really pretty piece of software that > doesn't work right and/or is late. Strict adherence to style does not > necessarily move the mission forward. The problem is when allowing "wiggle room" results in difficult-to-read-and-maintain software because certain people will not apply common sense--it has to be applied by force from outside. Our solution: Move a few of the "guidelines" bullets in AQS into "standards" bullets. Then define "standard" or "shall" as "non-compliance requires a waiver signed by _____" and define "guideline" or "should" as "non-compliance requires approval from a peer review team." We also significantly revised AQS. Some things we didn't agree with, others we thought unclear, and it was surprising how many examples were non-compliant. (Principle of technical writing--given an unambiguous requirement in prose and a non-binding example, if they disagree, the example will be followed.) -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Bad coding standards 2001-01-03 19:49 ` Wes Groleau @ 2001-01-06 19:45 ` Lao Xiao Hai 0 siblings, 0 replies; 31+ messages in thread From: Lao Xiao Hai @ 2001-01-06 19:45 UTC (permalink / raw) Has anyoe ever noticed that the people who no longer write code are often the ones most compelled to make up rules for those who do? IBM used to have a little monthly publication called THINK. In a 1964 article in THINK, some writer, whose name is now lost in the obscure recesses of my faltering synapses, wrote, "The last act of a dying organization is to enlarge the rulebook." I have witnessed this in action over the years. For example, when a company is in financial trouble, the Human Resources Department begins to enforce a "dress code." When we run out of ideas for new software products, we often allow an organization to coagulate into a tangle of well-intentioned standards that serve to inhibit rather than stimulate creativity. Then we set up a standards group that intimidates everyone else into a lock-step process that ensures nothing interesting will ever be accomplished. I am not opposed to standards, per se. However, I sometimes think that Bill Joy of Sun Microsystems is correct when he observes that those organizations that depend too much on standards often become less innovative and consequently, less competitive. There has to be some happy medium between regulation and anarchy in the pursuit of effective software practice. Richard Riehle Wes Groleau wrote: > > There are people in the world who are "Control Freaks" or who demand that "The > > Law Is The Law!" and you often have to be careful about how they are going to > > look at what you write down. Style *should* be something that is consistent and > > details help, but you also want a lot of leeway to wiggle if there are reasons > > to do so. IMHO, a reliable and properly functioning piece of software that is > > delivered on time is more important than a really pretty piece of software that > > doesn't work right and/or is late. Strict adherence to style does not > > necessarily move the mission forward. > > The problem is when allowing "wiggle room" results in > difficult-to-read-and-maintain software because certain > people will not apply common sense--it has to be applied > by force from outside. > > Our solution: Move a few of the "guidelines" bullets in AQS > into "standards" bullets. Then define "standard" or "shall" > as "non-compliance requires a waiver signed by _____" and > define "guideline" or "should" as "non-compliance requires > approval from a peer review team." > > We also significantly revised AQS. Some things we didn't > agree with, others we thought unclear, and it was surprising > how many examples were non-compliant. (Principle of technical > writing--given an unambiguous requirement in prose and a > non-binding example, if they disagree, the example will be followed.) > > -- > Wes Groleau > http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Bad coding standards 2000-12-19 16:36 ` Marin David Condic 2000-12-20 1:52 ` Ken Garlington @ 2000-12-20 11:56 ` Mario Amado Alves 1 sibling, 0 replies; 31+ messages in thread From: Mario Amado Alves @ 2000-12-20 11:56 UTC (permalink / raw) To: comp.lang.ada > I've seen programs where indentation may vary from 2..3..4 spaces. No > clear agreement about how many are required. The most "standard" is 3 but "real programmers" use only 2 ;-) | |,| | | |RuaFranciscoTaborda24RcD 2815-249CharnecaCaparica 351+939354005 |M|A|R|I|O| |A|M|A|D|O|DepartmentoDeInformaticaFCT/UNL 2825-114 Caparica 351+212958536 |A|L|V|E|S| fax 212948541 | | | | | | maa@di.fct.unl.pt FCT 212948300 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Bad coding standards 2000-12-19 15:49 ` Robert Dewar 2000-12-19 16:36 ` Marin David Condic @ 2000-12-19 18:05 ` Larry Kilgallen 1 sibling, 0 replies; 31+ messages in thread From: Larry Kilgallen @ 2000-12-19 18:05 UTC (permalink / raw) In article <91o028$vp2$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes: > P.S. A neat feature of GNAT is that it learns your style for > error message purposes, so it will tell me: > > "end Try;" expected > > and it will tell Mike > > "END Try;" expected > > and it may tell someone else > > "end TRY;" expected Presumably on a sufficiently botched program GNAT gives up and tells the user: End Any_Hope_of_a_Programming_Career. :-) ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Bad coding standards 2000-12-18 16:09 ` Tucker Taft 2000-12-18 18:59 ` Marin David Condic @ 2000-12-19 15:42 ` Robert Dewar 1 sibling, 0 replies; 31+ messages in thread From: Robert Dewar @ 2000-12-19 15:42 UTC (permalink / raw) In article <3A3E36C4.3466A19C@averstar.com>, Tucker Taft <stt@averstar.com> wrote: > Well, as usual, we each have our own interpretation of > history. For what it is worth, my memory is that the Ada 9X > design team really hated the ALL CAPS convention of Ada 83. > Perhaps Robert is giving the reason why the proposed change > was accepted by the reviewers, rather than the reason why the > change was proposed in the first place. Indeed, I was discussing the standardization effort (the reviewers and WG9). The mere fact that the language design hated something is not enough to include it in the standard. For instance, it is quite possible that the design team hated MTV, but that did not generate a clause in the RM :-) :-) Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Bad coding standards 2000-12-14 2:32 Bad coding standards Beard, Frank 2000-12-14 12:19 ` Robert Dewar 2000-12-14 14:03 ` Bad coding standards Ken Garlington @ 2000-12-15 0:52 ` Georg Bauhaus 2 siblings, 0 replies; 31+ messages in thread From: Georg Bauhaus @ 2000-12-15 0:52 UTC (permalink / raw) Beard, Frank (beardf@spawar.navy.mil) wrote: : aesthetic - "In accordance with accepted notions of : good taste or style". And thats why there is no use discussing :-) If all your programmers use one style consistently and all your subprograms are neat and small and if you use enough and regular whitespace to make the code easily inspectable by the "program-physician's" pattern matching eyes (like the doctor looks at x-rays), yet you write like procedure Inacceptable is begin if A > B then Work_With (A); A := B; else Work_With (B); B := A; end if; end Inacceptable; because you and the others have been brought up on LISP, I'm pretty sure there will be Ada peoble pointing at you. ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2001-01-06 19:45 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-12-14 2:32 Bad coding standards Beard, Frank 2000-12-14 12:19 ` Robert Dewar 2000-12-14 13:03 ` OT ae [was Re: Bad coding standards] Philip Anderson 2000-12-14 14:08 ` Ken Garlington 2000-12-14 14:19 ` American English (was: Bad coding standards) John English 2000-12-14 15:07 ` Graeme 2000-12-15 13:16 ` The Design Zone (was Re: American English) Marc A. Criley 2000-12-14 15:14 ` American English (was: Bad coding standards) Marin David Condic 2000-12-14 17:38 ` Brian Rogoff 2000-12-15 16:12 ` John English 2000-12-14 14:03 ` Bad coding standards Ken Garlington 2000-12-14 20:14 ` Robert Dewar 2000-12-15 1:10 ` Ken Garlington 2000-12-18 16:09 ` Tucker Taft 2000-12-18 18:59 ` Marin David Condic 2000-12-18 22:20 ` Georg Bauhaus 2000-12-19 15:51 ` Tucker Taft 2000-12-19 16:12 ` Marin David Condic 2000-12-19 16:01 ` Robert Dewar 2000-12-19 15:49 ` Robert Dewar 2000-12-19 16:36 ` Marin David Condic 2000-12-20 1:52 ` Ken Garlington 2000-12-20 12:58 ` Marin David Condic 2000-12-20 14:27 ` Ken Garlington 2000-12-21 23:19 ` Marin David Condic 2001-01-03 19:49 ` Wes Groleau 2001-01-06 19:45 ` Lao Xiao Hai 2000-12-20 11:56 ` Mario Amado Alves 2000-12-19 18:05 ` Larry Kilgallen 2000-12-19 15:42 ` Robert Dewar 2000-12-15 0:52 ` Georg Bauhaus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox