RE: Bad coding standards

RE: Bad coding standards

[Beard, Frank]

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

RE: Bad coding standards

[Robert Dewar]

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/

OT ae [was Re: Bad coding standards]

[Philip Anderson]

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

Re: Bad coding standards

[Ken Garlington]

"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.

Re: OT ae [was Re: Bad coding standards]

[Ken Garlington]

"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).

Re: American English (was: Bad coding standards)

[John English]

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
-----------------------------------------------------------------

Re: American English (was: Bad coding standards)

[Graeme]

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

Re: American English (was: Bad coding standards)

[Marin David Condic]

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
======================================================================

Re: American English (was: Bad coding standards)

[Brian Rogoff]

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

Re: Bad coding standards

[Robert Dewar]

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/

Re: Bad coding standards

[Georg Bauhaus]

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.

Re: Bad coding standards

[Ken Garlington]

"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!

The Design Zone (was Re: American English)

[Marc A. Criley]

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

Re: American English (was: Bad coding standards)

[John English]

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
-----------------------------------------------------------------

Re: Bad coding standards

[Tucker Taft]

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

Re: Bad coding standards

[Marin David Condic]

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
======================================================================

Re: Bad coding standards

[Georg Bauhaus]

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

Re: Bad coding standards

[Robert Dewar]

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/

Re: Bad coding standards

[Robert Dewar]

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/

Re: Bad coding standards

[Tucker Taft]

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

Re: Bad coding standards

[Robert Dewar]

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/

Re: Bad coding standards

[Marin David Condic]

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
======================================================================

Re: Bad coding standards

[Marin David Condic]

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
======================================================================

Re: Bad coding standards

[Larry Kilgallen]

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.

:-)

RE: American English (was: Bad coding standards)

[Beard, Frank]

-----Original Message-----
From: Graeme [mailto:bitstorm@bigpond.com]

> 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.

Finally, someone who grasps what I was trying to say.

> 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 ?

So long as it readable ;-)  Thanks for expounding.

> 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....

Sounds like you do know.  I would hire you.

Frank

Re: American English (was: Bad coding standards)

[Ronald Cole]

"Beard, Frank" <beardf@spawar.navy.mil> writes:
> From: Graeme [mailto:bitstorm@bigpond.com]
> > 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....
> 
> Sounds like you do know.  I would hire you.

It takes a human mind to percieve order in chaos...  Value is
inversely proportional to the effort it takes, however.  ;)

-- 
Forte International, P.O. Box 1412, Ridgecrest, CA  93556-1412
Ronald Cole <ronald@forte-intl.com>      Phone: (760) 499-9142
President, CEO                             Fax: (760) 499-9152
My GPG fingerprint: C3AF 4BE9 BEA6 F1C2 B084  4A88 8851 E6C8 69E3 B00B

Re: Bad coding standards

[Ken Garlington]

"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.

Re: Bad coding standards

[Mario Amado Alves]

> 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

Re: Bad coding standards

[Marin David Condic]

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
======================================================================

Re: Bad coding standards

[Ken Garlington]

"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
: ======================================================================
:
:

Re: Bad coding standards

[Marin David Condic]

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
======================================================================

Re: Bad coding standards

[Wes Groleau]

> 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

Re: Bad coding standards

[Lao Xiao Hai]

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