RE: Bad coding standards

RE: Bad coding standards

[Beard, Frank]

(was Re: constant string array)


Ken Garlington wrote:

> I say, why stop at one set? I think a nice rule would be to encode tests
in
> double parentheses, similar to label constructs, i.e.
> 
> if ((a * b + c)) then
>   ...
> end if;
> 
> so that, if you're doing structural test coverage analysis, you can find
the
> essential elements easily. Wouldn't that just be a lovely standard?

Well, I suppose they had to stop somewhere, as all standards do.

Assuming you're being facetious, I assume no-one is under the
delusion that everyone out there in the Ada world, or even
everyone on CLA, uses the same style guide, or even likes
everything about the coding standards they're using.  After
all, style guides are subjective.  It's not science.  If it
were, there would probably be only one style guide (maybe two).
But instead it is subject to preference.  Using upper case
or lower case has no bearing on how the code runs.
Unless your talking about style guide issues that specify
using "for loops" as opposed to a "slices", or using "case"
statements instead of an "if" statements, then it has no
impact on the operation or performance of the software, just
aesthetics.

Is there supposed to be an "official" style guide all Ada
developers are to be using (the implied LRM standard, Ada
Quality and Style, ...)?

All I was saying in the very beginning was I wasn't willing
to fight over the paren issue in conditional statements, but
when they said you couldn't use "use" and you also couldn't
use "renames", we went to war.  There was no way I was going
to use full path names on the operators.  Fortunately, no-one
seems to object to "use type".

Fortunately, none of coding standards I've used have been as
bad as the one's Marc described.

Frank

Re: Bad coding standards

[Ken Garlington]

"Beard, Frank" <beardf@spawar.navy.mil> wrote in message
news:B6A1A9B09E52D31183ED00A0C9E0888C469949@nctswashxchg.nctswash.navy.mil..
.

: Unless your talking about style guide issues that specify
: using "for loops" as opposed to a "slices", or using "case"
: statements instead of an "if" statements, then it has no
: impact on the operation or performance of the software, just
: aesthetics.

Ouch! "Just aesthetics?" See ARM, Introduction, paragraphs 7-8 for a
contrary position.

Re: Bad coding standards

[Ken Garlington]

I just found an interesting consequence of my news reader (Microsoft
Outlook) doing line wrapping. If you look at the message below, it has a dot
(".") by itself on the fourth line. My hazy recollection of Internet e-mail
standards is that this originally signalled the end of the message. Has
anyone other than Mr. Beard seen one of these messages truncated at this
point?

"Ken Garlington" <Ken.Garlington@computer.org> wrote in message
news:e1UZ5.7722$bw.685896@news.flash.net.....
: "Beard, Frank" <beardf@spawar.navy.mil> wrote in message
:
news:B6A1A9B09E52D31183ED00A0C9E0888C469949@nctswashxchg.nctswash.navy.mil..
: .
:
: : Unless your talking about style guide issues that specify
: : using "for loops" as opposed to a "slices", or using "case"
: : statements instead of an "if" statements, then it has no
: : impact on the operation or performance of the software, just
: : aesthetics.
:
: Ouch! "Just aesthetics?" See ARM, Introduction, paragraphs 7-8 for a
: contrary position.
:
:

RE: Bad coding standards

[Robert Dewar]

In article
<B6A1A9B09E52D31183ED00A0C9E0888C469949@nctswashxchg.
nctswash.navy.mil>,
  comp.lang.ada@ada.eu.org wrote:
> (was Re: constant string array)
>
> Ken Garlington wrote:
>
> then it has on impact on the operation or
> performance of the software, just
> aesthetics.

I disagree with this. Part of performance of software
is maintainability, and part of maintainability is
about readability, and well chosen coding standards,
and in particular consistent adherence to such
standards definitely promotes readability.

Coding standards are also important in encouraging
egoless programming in a team, where everyone owns
all the code. That's must easier in practice if the
code is in a common style.



Sent via Deja.com
http://www.deja.com/

Re: Bad coding standards

[Ken Garlington]

"Robert Dewar" <robert_dewar@my-deja.com> wrote in message
news:919h4g$tos$1@nnrp1.deja.com...
: In article
: <B6A1A9B09E52D31183ED00A0C9E0888C469949@nctswashxchg.
: nctswash.navy.mil>,
:   comp.lang.ada@ada.eu.org wrote:
: > (was Re: constant string array)
: >
: > Ken Garlington wrote:
: >
: > then it has on impact on the operation or
: > performance of the software, just
: > aesthetics.
:
: I disagree with this.

Me too... which is why I didn't write it!

Re: Bad coding standards

[Robert Dewar]

In article <Wt4_5.7966$bw.730094@news.flash.net>,
  "Ken Garlington" <Ken.Garlington@computer.org>
wrote:
>
> "Robert Dewar" <robert_dewar@my-deja.com> wrote in
message
> news:919h4g$tos$1@nnrp1.deja.com...
> : In article
> :
<B6A1A9B09E52D31183ED00A0C9E0888C469949@nctswashxchg.
> : nctswash.navy.mil>,
> :   comp.lang.ada@ada.eu.org wrote:
> : > (was Re: constant string array)
> : >
> : > Ken Garlington wrote:
> : >
> : > then it has on impact on the operation or
> : > performance of the software, just
> : > aesthetics.
> :
> : I disagree with this.
>
> Me too... which is why I didn't write it!


Oops sorry, confusing elision (of course you can
tell that if you read carefully since the level of
quoting was the same in the two lines, but I can
see how someone might get confused :-)


Sent via Deja.com
http://www.deja.com/

Re: Bad coding standards

[Keith]

Are there any software QA orgs out there that try to enforce the non
aesthetics rules of the Quality and Style guide?

"Beard, Frank" <beardf@spawar.navy.mil> wrote in message
news:B6A1A9B09E52D31183ED00A0C9E0888C469949@nctswashxchg.nctswash.navy.mil..
.
> (was Re: constant string array)
>
>
> Ken Garlington wrote:
>
> > I say, why stop at one set? I think a nice rule would be to encode tests
> in
> > double parentheses, similar to label constructs, i.e.
> >
> > if ((a * b + c)) then
> >   ...
> > end if;
> >
> > so that, if you're doing structural test coverage analysis, you can find
> the
> > essential elements easily. Wouldn't that just be a lovely standard?
>
> Well, I suppose they had to stop somewhere, as all standards do.
>
> Assuming you're being facetious, I assume no-one is under the
> delusion that everyone out there in the Ada world, or even
> everyone on CLA, uses the same style guide, or even likes
> everything about the coding standards they're using.  After
> all, style guides are subjective.  It's not science.  If it
> were, there would probably be only one style guide (maybe two).
> But instead it is subject to preference.  Using upper case
> or lower case has no bearing on how the code runs.
> Unless your talking about style guide issues that specify
> using "for loops" as opposed to a "slices", or using "case"
> statements instead of an "if" statements, then it has no
> impact on the operation or performance of the software, just
> aesthetics.
>
> Is there supposed to be an "official" style guide all Ada
> developers are to be using (the implied LRM standard, Ada
> Quality and Style, ...)?
>
> All I was saying in the very beginning was I wasn't willing
> to fight over the paren issue in conditional statements, but
> when they said you couldn't use "use" and you also couldn't
> use "renames", we went to war.  There was no way I was going
> to use full path names on the operators.  Fortunately, no-one
> seems to object to "use type".
>
> Fortunately, none of coding standards I've used have been as
> bad as the one's Marc described.
>
> Frank
>

RE: Bad coding standards

[Beard, Frank]

-----Original Message-----
From: Robert Dewar [mailto:robert_dewar@my-deja.com]

> So my recommendation is follow the RM style for keyword and
> identifier capitalization unless there is good reason not to.

But this was exactly my point for using the RM as a style guide.
"Style" being the optimal word.  Of course you can't use the RM
for content issues, such as choice of data structure, because the
RM can't guess what type of platform, or type of application, 
you're working with.  I assumed this was a given, but considering
the diversity of the list I guess I shouldn't make these kinds of
assumptions.

Frank

RE: Bad coding standards

[Beard, Frank]

-----Original Message-----
From: Ken Garlington [mailto:Ken.Garlington@computer.org]

> Because (a) that's not what it's intended to do, and (b) there are other
> document that *are* intended for that purpose. Since Ada attempts to
> discourage the "copy principle," it's not surprising that the ARM does not
> choose to be redundant with available style guides ;)

Why not?   Seeing how the Ada Reference Manual is the "bible" of the Ada
language, written by the founders (or "pillars") of the language.  Wouldn't
it be reasonable to assume that the examples given in the reference
manual would be written in a "good" style?  And as such, worthy of
emulation,
something to be followed?  You know, a reasonable guide.  What's that
phrase?
Oh yeah, a "style guide".

Because I think it's ludicrous to assume those using the language manual,
especially new users, wouldn't assume that the "examples" weren't a
good style to follow.  I know later they could learn about style guides,
but if it were another part of the standard, maybe the "Style Guide
Annex", then we would have universal approach.  Why not?  Many in the 
beginning didn't think we could get this many people, from different
countries, to agree, within reason, on a programming language.

I'm not sure about the "Since Ada attempts to discourage the "copy
principle,""
part.  I'm not sure where that comes from.  But, it seems to me reuse is the
ultimate in the "copy principle" (more like condoned plagiarism), and the
main point of the style guides (and by that I mean the style guide says this
is what we think is "good", do it this way).


>>   "it has no impact on the operation or performance of the software, just
>> aesthetics."
>
> I might assume that the word "just" implies that aesthetics are less
> important than operation or performance. As the ARM points out, the design
> of Ada is predicated in part on the idea that aesthetics are very
important.

Well, I can see where that could possibly happen.  Maybe I should
have said "just the aesthetics".  If you look at the whole sentence:

"Unless your talking about style guide issues that specify
using "for loops" as opposed to a "slices", or using "case"
statements instead of an "if" statements, then it has no
impact on the operation or performance of the software, just
aesthetics."

The "just" in the sentence meant that outside the part of style
guide that deals with structural issues, such as data structures,
then your are left with just the aesthetic part.  I didn't mean
to imply that I didn't think aesthetics were important, just
subject to opinion.  If you didn't get my point in previous e-mails,
I consider it an integral part of readability.  Unlike some who
think readability and aesthetics form some type of dichotomy, or
at least don't see the connection.

Frank

Re: Bad coding standards

[Ken Garlington]

"Beard, Frank" <beardf@spawar.navy.mil> wrote in message
news:B6A1A9B09E52D31183ED00A0C9E0888C469959@nctswashxchg.nctswash.navy.mil..
.
: -----Original Message-----
: From: Ken Garlington [mailto:Ken.Garlington@computer.org]
:
: > Because (a) that's not what it's intended to do, and (b) there are other
: > document that *are* intended for that purpose. Since Ada attempts to
: > discourage the "copy principle," it's not surprising that the ARM does
not
: > choose to be redundant with available style guides ;)
:
: Why not?   Seeing how the Ada Reference Manual is the "bible" of the Ada
: language, written by the founders (or "pillars") of the language.
Wouldn't
: it be reasonable to assume that the examples given in the reference
: manual would be written in a "good" style?

No. In fact, this practice is not limited to Ada *reference* documents.

"This quick reference guide for the Standard C programming language provides
all of the information you need to read and write programs in Standard C. It
describes all aspects of Standard C that are the same on all implementations
that conform to the standard for C. This is not a tutorial on Standard C nor
a lesson on how to write computer programs."

-- Plauger and Brodie, "Standard C." Microsoft Prcess, 1989.

 And as such, worthy of
: emulation,
: something to be followed?  You know, a reasonable guide.  What's that
: phrase?
: Oh yeah, a "style guide".
:
: Because I think it's ludicrous to assume those using the language manual,
: especially new users, wouldn't assume that the "examples" weren't a
: good style to follow.

I suppose "new users" may make all sorts of mistakes. For myself, when I
want to learn a new language, I don't normally start with the ISO standard
(assuming it exists). I get a textbook, or use an on-line resource. For
example:

http://www.adahome.com/Tutorials/Lovelace/lovelace.html

: I know later they could learn about style guides,
: but if it were another part of the standard, maybe the "Style Guide
: Annex", then we would have universal approach.  Why not?

I think your next sentence provides one reason -- why add additional work to
a process that already takes significant effort? The second reason relates
to what I would call "separation of concerns." Why mix a style guide in with
something that, within the limits of reasonableness, is supposed to
accurately specify a language? Finally, it's not clear that a style guide is
(or should be) intended to force a "universal approach." As noted in the SPC
guide: "Other guidelines presented in this book are intentionally phrased in
terms of design choices to consider. These guidelines cannot be instantiated
as hard-and-fast rules that a project must follow. For example, you should
not interpret Guidelines 6.1.1 and 6.1.2 to mean that a project is forbidden
to use tasks. Rather, these guidelines are intended to help the designer
make the tradeoffs between using protected objects and tasks, thus leading
the designer to make a more informed choice between these features."

: Many in the
: beginning didn't think we could get this many people, from different
: countries, to agree, within reason, on a programming language.

I don't know why "many" people would have felt that way. Certainly, Ada is
not the first internationally standardized language to be used widely. It's
not easy, but it's far from impossible.

: I'm not sure about the "Since Ada attempts to discourage the "copy
: principle,""
: part.  I'm not sure where that comes from.

IIRC, I first heard it in a speech given by Jean Ichbiah in Dallas in the
early 1980s. The idea is that doing manual "cut-and-paste" operations is
highly error prone. Therefore, you want a language that encourages
modularization and controlled parameterization (e.g. generics) as a more
reliable alternative.

: But, it seems to me reuse is the
: ultimate in the "copy principle" (more like condoned plagiarism), and the
: main point of the style guides (and by that I mean the style guide says
this
: is what we think is "good", do it this way).
:
: >>   "it has no impact on the operation or performance of the software,
just
: >> aesthetics."
: >
: > I might assume that the word "just" implies that aesthetics are less
: > important than operation or performance. As the ARM points out, the
design
: > of Ada is predicated in part on the idea that aesthetics are very
: important.
:
: Well, I can see where that could possibly happen.  Maybe I should
: have said "just the aesthetics".  If you look at the whole sentence:
:
: "Unless your talking about style guide issues that specify
: using "for loops" as opposed to a "slices", or using "case"
: statements instead of an "if" statements, then it has no
: impact on the operation or performance of the software, just
: aesthetics."
:
: The "just" in the sentence meant that outside the part of style
: guide that deals with structural issues, such as data structures,
: then your are left with just the aesthetic part.  I didn't mean
: to imply that I didn't think aesthetics were important, just
: subject to opinion.  If you didn't get my point in previous e-mails,
: I consider it an integral part of readability.  Unlike some who
: think readability and aesthetics form some type of dichotomy, or
: at least don't see the connection.
:
: Frank
:
:
:

RE: Bad coding standards

[Robert Dewar]

In article
<B6A1A9B09E52D31183ED00A0C9E0888C469959@nctswashxchg.
nctswash.navy.mil>,
> Why not?   Seeing how the Ada Reference Manual is
> the "bible" of the Ada language, written by the
> founders (or "pillars") of the language.

No, that's a peculiar description. It is a formal
standard.

>  Wouldn't it be reasonable to assume that the
> examples given in the reference manual would be
> written in a "good" style?

No it would be unreasonable. The examples are
supposed to illustrate the semantics, and the
purpose of illustrations is to show the semantics,
not to suggest how Ada should be written. The
semaphore done as a protected type is a good
example, everyone knows the semantics of semaphores,
so this example nicely illustrates how protected
types work, but it is not intended to suggest that
you should use semaphores for synchronization. There
are other such examples in the RM.

> You know, a reasonable guide.  What's that
> phrase? Oh yeah, a "style guide".

No it is an international standard for the language.
Not a style guide at all.

> Because I think it's ludicrous to assume those
> using the language manual, especially new users,
> wouldn't assume that the "examples" weren't a
> good style to follow.

Well new users coming the RM often form peculiar
conclusions because they do not understand the
nature of a language standard. Indeed, precisely
because the RM is (by comparison with some other
standards) quite readable, they may indeed make
the huge mistake of thinking it is something like
an Ada text book :-)

> I know later they could learn about style guides,
> but if it were another part of the standard, maybe
> the "Style Guide Annex"

Not completely out of the question if there was a
reasonable consensus on style, but there is not.
For example, a fair number of style guides contain
statements that "thou shalt not use feature XXXX
ever". Clearly no "standard" style guide could have
silly rules like that.

> then we would have universal approach.  Why not?
> Many in the  beginning didn't think we could get
> this many people, from different countries, to
> agree, within reason, on a programming language.

A very odd claim. Where does it come from? Many
programming languages have been standardized. The
fact that a language is standardized does not mean
that people agree it should be used for all purposes,
or even for any purposes. I was there throughout
the Ada standardization process, and I never heard
anyone suggest that they did not think it would be
possible to agree on a standard (after all it had
been done many times before for programming
languages).

> I'm not sure about the "Since Ada attempts to
> discourage the "copy principle,""
> part.  I'm not sure where that comes from.

From a fundamental design point of view that dislikes
redundancy in formal definitions.



Sent via Deja.com
http://www.deja.com/

Re: Bad coding standards

[Robert L. Spooner]

"Beard, Frank" wrote:
>  <snip>
> But, it seems to me reuse is the
> ultimate in the "copy principle" (more like condoned plagiarism),...
> 
> Frank

It is widely known in the academic world that copying from one source is
plagiarism, copying from multiple sources is research. :)

Bob
-- 
                            Robert L. Spooner
                     Registered Professional Engineer
                       Associate Research Engineer
                  Intelligent Control Systems Department

         Applied Research Laboratory        Phone: (814) 863-4120
         The Pennsylvania State University  FAX:   (814) 863-7841
         P. O. Box 30
         State College, PA 16804-0030       rls19@psu.edu

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/

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

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

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

[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

[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

[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

[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

[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

[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

[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

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

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

[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: constant string array

[Jeff Carter]

Robert Dewar wrote:
> There is a conceptual difference between using a boolean
> expression in a test, and using it as a general value (indeed
> it is this conceptual difference that leads ABC to allow
> "boolean" expressions ONLY in the context of a test.

ABC?

> I think the argument is even stronger in comparing:
> 
>    a := b > c;
> 
> with
> 
>    if b > c then
>       a := true;
>    else
>       a := false;
>    end if;
> 
> I always used to criticize students for the spelled out version
> giving the canonical advice to replace it with the use of a
> boolean expression. But in fact I think the spelled out version
> is often clearer in its intent.
> 
> You can get some feeling for this by supposing that someone
> looking at the above code decides to replace
> 
>    A : boolean;
> 
> by
> 
>    type motor_status is (on, off);
>    a : motor_status;
> 
> with a revision history saying
> 
>    use ON/OFF for motor status instead of True/False, makes
>    code clearer.

Hopefully your style checker will flag your inconsistent capitalization.

Obviously, I disagree with your premise. In all of your examples I find
the use of a Boolean expression as a value clearer than the version with
an if. If the type of a variable changes, you should expect to have to
make changes everywhere it is used. I certainly expect some of those
changes to be non-trivial.

What is important is to use a language that flags any places where the
use of the variable has been missed, rather than one that silently
compiles the meaningless code.

I have found that this kind of construct generally indicates a lack of
understanding of Booleans, frequently from people with experience with
languages that do not have a Boolean type. Such people frequently do
other irritating things, like putting unnecessary parentheses around the
condition of an if, and forgetting the "then". Learning that Boolean is
a type like any other enumeration type, and its values no different than
any other enumeration type, is often a major step in grasping the Ada
mind set.

-- 
Jeff Carter
"I blow my nose on you."
Monty Python & the Holy Grail

RE: constant string array

[Beard, Frank]

-----Original Message-----
From: Jeff Carter [mailto:jrcarter@acm.org]

I totally agree with you on the use of the 
boolean expression, as opposed to the "if" 
equivalent.  I find it more rare than not, that
the "if" version contributes anything significant
to the clarity.

> Such people frequently do other irritating things,
> like putting unnecessary parentheses around the
> condition of an if

To me this is a non-issue.  Use them, don't use
them.  Who cares?  I don't care so long as they don't
decrease readability.  But, definitely use them
if they increase readability, as in making precedence
clearer, or dealing with compound statements containing
multiple "or else" and "and then".  Or should I say
(or else) and (and then).  :-)

The powers that be that decided what style guide we
were to follow (turned out to be a combination plus
some of their own), decreed that for "if" statements,
"thou shalt use parenthesis" to enclose the statement.
As in "if () then", no matter what "()" contained.
They wanted consistency and it wasn't worth arguing,
because "if (success) then" is no harder to read than
"if success then".

Frank

RE: constant string array

[Robert Dewar]

In article
<B6A1A9B09E52D31183ED00A0C9E0888C469939@nctswashxchg.nctswash.na
vy.mil>,
  comp.lang.ada@ada.eu.org wrote:

> But, definitely use them
> if they increase readability, as in making precedence
> clearer, or dealing with compound statements containing
> multiple "or else" and "and then".  Or should I say
> (or else) and (and then).  :-)

That's a very entertaining confirmation that the thinking
here is imported from other languages, seeing as Ada
*requires* the use of parentheses in the latter case,
so there is no question of giving advice in this case :-)


Sent via Deja.com
http://www.deja.com/

RE: constant string array

[Beard, Frank]

-----Original Message-----
From: Robert Dewar [mailto:robert_dewar@my-deja.com]

> That's a very entertaining confirmation that the thinking
> here is imported from other languages,

Well, I don't know who imported them, or why.  And I don't
really care.  I'm just saying the parens don't bother me.
I've been doing Ada since 1986, and have had numerous
styles imposed on me.

> seeing as Ada
> *requires* the use of parentheses in the latter case,
> so there is no question of giving advice in this case

Yes, if you have an expression of "if a or else b and then c then".
What I had in mind was more "if a or else b or else c then".  Where
a, b, and c are complex expressions or function calls, not just
simple booleans.

Frank

RE: constant string array

[Robert Dewar]

In article
<B6A1A9B09E52D31183ED00A0C9E0888C469940@nctswashxchg.nctswash.na
vy.mil>,
  comp.lang.ada@ada.eu.org wrote:

> What I had in mind was more "if a or else b or else c then".
Where
> a, b, and c are complex expressions or function calls, not
just
> simple booleans.


if you are saying you would write

  if (a > b) or else (c > d) or else (e > f) then

I would find those parentheses unnecessary noise, and would
definitely prefer they not be present.



Sent via Deja.com
http://www.deja.com/

RE: constant string array

[Beard, Frank]

-----Original Message-----
From: Robert Dewar [mailto:robert_dewar@my-deja.com]

>> As in "if () then", no matter what "()" contained.

>Well the () are useless noise REGARDLESS of what they enclose
>since there is no precedence issues etc in this case.

What case?  You don't even know what case I'm talking 
about.  If () contains, "a * b + c", does it now deal
with precedence.  You seem to think I'm talking about
simple cases here.  I'm talking about all cases.
For consistency, the decision was made, not by me if I
haven't made that clear yet, to use parens in all cases.

>> They wanted consistency and it wasn't worth arguing,
>> because "if (success) then" is no harder to read than
>> "if success then"
>
>There is no more justification for this than a silly rule
>that requires all right hand sides to be in parentheses.
>The argument could equally well be that
>
>   a := (success);
>
>is no harder to read then
>
>   a := success;

Wrong!  Because we consistently code:

   a := success;

not 

   a:= (success);

>As for the use-them, don't-use-them, who-cares, philosophy,
>I find this a very sloppy view to the important issue of
>coding style consistency.

Consistency is exactly what I'm talking about.

I'm amazed how your focus goes narrow to broad in almost direct
contrast to the context I'm addressing.  Above you seem
to think I'm talking about the simple cases, and here you seem
to think I'm talking about all cases.  When I said "use-them,
don't-use them, who-cares", was in the specific context of the
specific "if success then" versus "if (success) then" case
that was discussed in that e-mail.

As far as consistency, it seems to me that you are the one being
inconsistent.  In one case you say don't use parens in an "if"
statement, and in another case you say do use parens in an "if"
statement.

If you always use parens in an "if" statement, you are being
consistent.  If you use them in some "if" statements and not
in others you are being inconsistent.  Unless of course you
extend the definition of consistency to "in these cases use
parens in "if" statements, but in these cases don't".  Then
you start hitting the gray areas as to when the statement
becomes complex enough to warrant parens, and who makes that
decision.  Who is it clear to, and who is it not.

And to make sure we're on the same plane, this entire e-mail is
in the context of conditional statements such as "if", "while",
"exit when", etc., not in assignment statements and such.
Assignment statements were miraculously left to "use parens
where they add clarity".

I understand what you are saying Robert, I really do.  But we
are talking about differences in style guides.  And we code
consistently to ours.  I don't even remember what composite
they used to come up with our style guide.  It's been seven
years now.  All I know is it goes to the specifics of what
the conditional statements of "if", "while", etc. should look
like.

The one constant over the years has been that each project
I've been on has a different Ada style guide.  I haven't
seen the Dewar Style Guide yet.

If you don't like it, take it up with the Navy.  Of course,
you can only take it up with my branch of the Navy.  Let's
not even talk about the differences between Army, Navy, 
Air Force, and Marines.

Frank

Re: constant string array

[Ken Garlington]

"Beard, Frank" <beardf@spawar.navy.mil> wrote in message
news:B6A1A9B09E52D31183ED00A0C9E0888C469941@nctswashxchg.nctswash.navy.mil..
.
: -----Original Message-----
: From: Robert Dewar [mailto:robert_dewar@my-deja.com]
:
: >> As in "if () then", no matter what "()" contained.
:
: >Well the () are useless noise REGARDLESS of what they enclose
: >since there is no precedence issues etc in this case.
:
: What case?  You don't even know what case I'm talking
: about.  If () contains, "a * b + c", does it now deal
: with precedence.  You seem to think I'm talking about
: simple cases here.  I'm talking about all cases.
: For consistency, the decision was made, not by me if I
: haven't made that clear yet, to use parens in all cases.
:
: >> They wanted consistency and it wasn't worth arguing,
: >> because "if (success) then" is no harder to read than
: >> "if success then"
: >
: >There is no more justification for this than a silly rule
: >that requires all right hand sides to be in parentheses.
: >The argument could equally well be that
: >
: >   a := (success);
: >
: >is no harder to read then
: >
: >   a := success;
:
: Wrong!  Because we consistently code:
:
:    a := success;
:
: not
:
:    a:= (success);

But, if you consistently coded a := (success); then it would by OK, right?

I say, why stop at one set? I think a nice rule would be to encode tests in
double parentheses, similar to label constructs, i.e.

if ((a * b + c)) then
  ...
end if;

so that, if you're doing structural test coverage analysis, you can find the
essential elements easily. Wouldn't that just be a lovely standard?

Bad coding standards

[Marc A. Criley]

(was Re: constant string array)


Ken Garlington wrote:

> I say, why stop at one set? I think a nice rule would be to encode tests in
> double parentheses, similar to label constructs, i.e.
> 
> if ((a * b + c)) then
>   ...
> end if;
> 
> so that, if you're doing structural test coverage analysis, you can find the
> essential elements easily. Wouldn't that just be a lovely standard?

I tried really, really hard to not start talking about bad coding
standards I've encountered, but I just can't stop myself!  :-)

Here's my top 3, in no particular order, thankfully each of which
occurred on a _different_ program:

- The first letter of each source line was to be capitalized, and _all_
  other words, reserved and user-defined, were to be lower-case.  One
  exception was permitted--for the "end xxx" construct, where "xxx" was
  "if" or "case" or the unit name, etc., "end" was also to be
lower-case.

  (The rationale for this practice was that it would "make the text more
  readable", since it conformed to the capitalization practice of
English
  language sentences.  I went round and round with the author for years
  on this one; he finally retired and I rewrote the standard.)

- No subtypes.  If there is a situation where a new type that is related
  to an existing type would be useful, _derive_ the new type and use
  explicit conversion when values of types in the derivation tree have
  to interact, do not use subtypes.

  (This, I believe, was a result of some rabid "type zealotry" that
  felt that subtypes allowed sloppiness and a way of working around
  strong typing.  Fortunately this program was being relocated and had
  lost most of its developers when I joined up, so we were able to
  ignore this standard until I had a chance to rewrite it.)

- No child packages.  No "aliased" objects.  Basically, no Ada 95
  language features, except for the new packages like the Strings
  and Interfaces ones.

  (This standard actually was more verbal than documented, and was
  caused by the project being ported to Ada 95--and a new compiler.
  The personnel had had no exposure to Ada 95, so it was simply
  decided to forbid the use of the new features.  I was able to bring
  in a lot of experience with the features, and so with some guidance
  the developers were permitted to start exercising Ada 95's
  capabilities.)

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com

Re: Bad coding standards

[Ken Garlington]

"Marc A. Criley" <mcquad@earthlink.net> wrote in message
news:3A376D69.A420D711@earthlink.net...
:   (The rationale for this practice was that it would "make the text more
:   readable", since it conformed to the capitalization practice of
: English

 ^ (obviously a typo, given the rule under discussion :)

:   language sentences.

Re: Bad coding standards

[David Emery]

For a while, I collected coding standards as a hobby.  I've
seen some dumb ideas, but here's my nomination for worst idea:

   package Long_Descriptive_Name is
      
      package LDN renames Long_Descriptive_Name
      
      type T is ...

   end Long_Descriptive_Name;

   with Long_Descriptive_Name;
   package A_Client_Package is
      package LDN renames Long_Descriptive_Name;
   
      procedure Proc (Param : LDN.T)...
   
   end A_Client_Package;

In this style, the existence and use of the rename was not
an option, but was mandatory.  Furthermore, there were no
rules for how a rename would be formed.  In some cases, the
abbreviation related to some previous name for the package.
I once sent out a "test" with 10 abbreviations for common
packages, asking how many people recognized the renames.  The
best score was 8 out of 10, and the average was about 5.

In my example, things don't look so bad.  But when you're
buried in the middle of the code, and you see things like

      Obj : Abbr.Object;

      ABC.Munge (XYZ.Func (Obj), QRS.Enum, ADX.Scalar);

you rapidly lose the redability of Ada, as you have to go find
the damn renames clause to remember what ABC and QRS were.

As one of the first "maintenance" programmers (I rewrote one
unit twice, the first for time and the second for space...), I
found this to be incredibly hard to read.  My first action was
to replace the abreviations with the long names, so I could
figure out what was actually going on.  And after I left, they
paid someone to go through my code, replacing my Nice_Long_Name
qualified expressions with their standard NLN renames.  Ugh!

         dave

Re: Bad coding standards

[Robert Dewar]

In article <131220001555268634%emery@mitre.org>,
  David Emery <emery@mitre.org> wrote:
> For a while, I collected coding standards as a
> hobby.  I've seen some dumb ideas, but here's my
> nomination for worst idea:
>
>    package Long_Descriptive_Name is
>
>       package LDN renames Long_Descriptive_Name

Interesting .. this does not seem so horrible to me.
If the routines in the package are basically designed
to be used without qualification, so that the
packages could be used with a USE statement, then
the use of

   LDN.useful_descriptive_name

is not so terrible. Given the choice of the following
three possibilities in the GNAT compiler context:

   Analyze_Type_Declaration;
   SC3.Analyze_Type_Declaration;
   Semantics_For_RM_Ch_3.Analyze_Type_Declaration;

I prefer the first one, since anyone who knows
anything about the structure of GNAT knows where
Analyze_Type_Declaration is declared, and if you
don't know, you can press the appropriate key in
GLIDE and be bounced to the right package (or use
gnatfind to quickly find the right package if you
are not using an IDE).

I really find the last one horrible. Lots of noise
here that would greatly increaes the length of the
code and add nothing.

THe middle one is a bit of an oddity. It adds nothing
to the readability, but I can see it being useful in
a junk environment which did NOT have good navigation
tools, since you can use the plain editor search
capability to locate the renaming statement.

So in context I do not think this usage is
necessarily a bad idea.

Robert Dewar


Sent via Deja.com
http://www.deja.com/

Re: Bad coding standards

[Ken Garlington]

"Robert Dewar" <robert_dewar@my-deja.com> wrote in message
news:91agll$kup$1@nnrp1.deja.com...
: In article <131220001555268634%emery@mitre.org>,
:   David Emery <emery@mitre.org> wrote:
: > For a while, I collected coding standards as a
: > hobby.  I've seen some dumb ideas, but here's my
: > nomination for worst idea:
: >
: >    package Long_Descriptive_Name is
: >
: >       package LDN renames Long_Descriptive_Name
:
: Interesting .. this does not seem so horrible to me.

I think the key is in Mr. Emery's later statement, that there wasn't a
common acronym list used to derive or track these abbreviations. Given that
the project didn't have a decent code navigation tool (also implied by his
description), I could see where this could be annoying  (although hardly the
worst idea...)

My vote for "worst idea" came from a development team who was transitioning
from the JOVIAL language to Ada. In JOVIAL, you could list all imported
items at the top of the routine. The team thought it would be great to do
this in Ada as well, so all over the place you got stuff like:

with Some_Package;
procedure Some_Procedure is

  subtype Some_Type is Some_Package.Some_Type;

  function "+" (Left, Right: Some_Type) return Some_Type renames
Some_Package."+";

  function "-" (Left, Right: Some_Type) return Some_Type renames
Some_Package."+";

  A: Some_Type renames Some_Package.A;

...

This was miserable for several reasons: (1) It didn't always work (e.g. if
the same name were used in different packages); (2) It completely cluttered
the top of all declarative units, making it very easy to miss important
declarations or comments; (3) It made it very easy to introduce subtle
errors that often could not be caught until run-time testing (see the "-"
renaming for an example), and (4) the extra complexity made it more likely
for our early Ada compilers to crash.

We did eventually get the code to work, though.

Re: Bad coding standards

[Wayne Magor]

Ken Garlington wrote:

>
>   function "+" (Left, Right: Some_Type) return Some_Type renames
> Some_Package."+";
>
>   function "-" (Left, Right: Some_Type) return Some_Type renames
> Some_Package."+";
>

This example illustrates why I consider the absolute worst coding standard ever
to have been the common Ada83 standard of "the use of the USE clause is
prohibited".  When you have this ridiculous coding standard, you are almost
forced into doing operator renaming, however, this is very dangerous in Ada.

Do you see the bug in the above code?  The minus operator renames the plus
operator.  If the code is not tested for proper operation through every single
line, it is possible for this to show up in released software (I have seen it).
When you consider the applications for which Ada was designed for (and is being
used in), it is possible that this stupid coding standard could result in
someone's death.

When you consider why is was ever adopted, which was simply to make it easier to
find items declared in other packages, it seems out of proportion to the (albeit
small) risk of catastrophic software failure.  I found 5 of these types of
errors in an avionics application that prohibited the "use" clause in their
coding standards (did not make it on a plane though).  After this, they STILL
did not change the coding standards...

Thank God the "use type" was added to Ada.  Before Ada95, I actually REQUIRED
people to include a "use" clause instead of using operator renaming because of
this very risk.

Wayne.

Re: Bad coding standards

[Ken Garlington]

"Wayne Magor" <none@nowhere.com> wrote in message
news:3A39610A.890470BF@nowhere.com...
:
:
: Ken Garlington wrote:
:
: >
: >   function "+" (Left, Right: Some_Type) return Some_Type renames
: > Some_Package."+";
: >
: >   function "-" (Left, Right: Some_Type) return Some_Type renames
: > Some_Package."+";
: >
:
: This example illustrates why I consider the absolute worst coding standard
ever
: to have been the common Ada83 standard of "the use of the USE clause is
: prohibited".  When you have this ridiculous coding standard, you are
almost
: forced into doing operator renaming, however, this is very dangerous in
Ada.
:
: Do you see the bug in the above code?

Not only did I see it - I referred to it in the same post!

Of course, the particular style I described is much worse than the "never
use USE" convention, because it propagates the problem well beyond
operators.

Re: Bad coding standards

[DuckE]

[snip]
> is not so terrible. Given the choice of the following
> three possibilities in the GNAT compiler context:
>
>    Analyze_Type_Declaration;
>    SC3.Analyze_Type_Declaration;
>    Semantics_For_RM_Ch_3.Analyze_Type_Declaration;
>
> I prefer the first one, since anyone who knows
> anything about the structure of GNAT knows where
> Analyze_Type_Declaration is declared, and if you
> don't know, you can press the appropriate key in
> GLIDE and be bounced to the right package (or use
> gnatfind to quickly find the right package if you
> are not using an IDE).
>
> I really find the last one horrible. Lots of noise
> here that would greatly increaes the length of the
> code and add nothing.
>
> THe middle one is a bit of an oddity. It adds nothing
> to the readability, but I can see it being useful in
> a junk environment which did NOT have good navigation
> tools, since you can use the plain editor search
> capability to locate the renaming statement.

This is the most common reaction we receive when someone new enters our
software group where we have standards that require a 3 character mnemonic
as a part of all identifiers that are defined in package specs.  Usually
within a week of using this convention, they don't know how they ever worked
without it.

If I am reading some code that includes (using from the example above):

  SC3.Analyze_Type_Declaration;

I immediately know that this is a procedure that is defined outside of the
current package in something that is abbreviated as "SC3".  If the code
contained just:

  Analyze_Type_Declaration;

Then I would know that this is a procedure that is either defined locally or
in another package.  To find out which, I'll have to do some investigation.

I have found that when these conventions are followed I can move through
unfamiliar code very quickly without having to research each identifier.

FWIW
SteveD

>
> So in context I do not think this usage is
> necessarily a bad idea.
>
> Robert Dewar
>
>
> Sent via Deja.com
> http://www.deja.com/

Re: Bad coding standards

[Ed Falis]

> This is the most common reaction we receive when someone new enters
> our
> software group where we have standards that require a 3 character
> mnemonic
> as a part of all identifiers that are defined in package specs.
> Usually
> within a week of using this convention, they don't know how they ever
> worked
> without it.

I've been running into it for years in customers' code, and still think
it's pretty bogus, given that most Ada development environments have
supported interactive cross-referencing for years.  It just adds noise,
but not as much as what Dewar pointed out with the fully-qualified
names.

- Ed

RE: Bad coding standards

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: SteveD et al.

A very simple solution to producing and using a name with a reasonable
length  is to do all the renames at the beginning of the Ada source. This
produces a Table of Contents. In fact, if one uses any but the most common
abbreviations for any purpose, the also should be listed together.  One of
the beauties of Ada is the source text can be organized as a readable
technical document.

--*********Table of Contents********
Package Analyze_Type_Declaration renames
  Semantics_For_RM_Ch_3.Analyze_Type_Declaration;
--*********End Table of Contents********
--I presumed Analyze_Type_Declaration was a package

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of DuckE
Sent: Thursday, December 14, 2000 7:19 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: Bad coding standards


[snip]
> is not so terrible. Given the choice of the following
> three possibilities in the GNAT compiler context:
>
>    Analyze_Type_Declaration;
>    SC3.Analyze_Type_Declaration;
>    Semantics_For_RM_Ch_3.Analyze_Type_Declaration;
>
> I prefer the first one, since anyone who knows
> anything about the structure of GNAT knows where
> Analyze_Type_Declaration is declared, and if you
> don't know, you can press the appropriate key in
> GLIDE and be bounced to the right package (or use
> gnatfind to quickly find the right package if you
> are not using an IDE).
>
> I really find the last one horrible. Lots of noise
> here that would greatly increaes the length of the
> code and add nothing.
>
> THe middle one is a bit of an oddity. It adds nothing
> to the readability, but I can see it being useful in
> a junk environment which did NOT have good navigation
> tools, since you can use the plain editor search
> capability to locate the renaming statement.

This is the most common reaction we receive when someone new enters our
software group where we have standards that require a 3 character mnemonic
as a part of all identifiers that are defined in package specs.  Usually
within a week of using this convention, they don't know how they ever worked
without it.

If I am reading some code that includes (using from the example above):

  SC3.Analyze_Type_Declaration;

I immediately know that this is a procedure that is defined outside of the
current package in something that is abbreviated as "SC3".  If the code
contained just:

  Analyze_Type_Declaration;

Then I would know that this is a procedure that is either defined locally or
in another package.  To find out which, I'll have to do some investigation.

I have found that when these conventions are followed I can move through
unfamiliar code very quickly without having to research each identifier.

FWIW
SteveD

>
> So in context I do not think this usage is
> necessarily a bad idea.
>
> Robert Dewar
>
>
> Sent via Deja.com
> http://www.deja.com/

RE: Bad coding standards

[Ted Dennison]

In article <NBBBJNOMKDIAJALCEFIJKECIEBAA.rleif@rleif.com>,
  comp.lang.ada@ada.eu.org wrote:

> A very simple solution to producing and using a name with a reasonable
> length  is to do all the renames at the beginning of the Ada source.
> This produces a Table of Contents. In fact, if one uses any but the
> most common abbreviations for any purpose, the also should be listed
> together.  One of the beauties of Ada is the source text can be
> organized as a readable technical document.

The problem with that approach is that often the old names *and* the new
names will be used in the body of that package. That's just gawd-awful.
This is particularly likely to happen if multiple people end up helping
to author the source file. Each tends to have their own favorite way of
naming things.

As we are rather fond of pointing out to C coders, just because some
feature *can* be used to make readable code doesn't mean it typically
*will* be used that way.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

RE: Bad coding standards

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Ted Dennison et al.

Although, "often the old names *and* the new names will be used in the body
of that package", is a possibility, locating the renames in one prominent
place will significantly reduce the probability of it occurring. I might
also note, that one should with packages that are specific to a body at the
level of the body not the specification. The renames in the body should also
be contained in a table of contents.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Ted Dennison
Sent: Friday, December 15, 2000 8:35 AM
To: comp.lang.ada@ada.eu.org
Subject: RE: Bad coding standards


In article <NBBBJNOMKDIAJALCEFIJKECIEBAA.rleif@rleif.com>,
  comp.lang.ada@ada.eu.org wrote:

> A very simple solution to producing and using a name with a reasonable
> length  is to do all the renames at the beginning of the Ada source.
> This produces a Table of Contents. In fact, if one uses any but the
> most common abbreviations for any purpose, the also should be listed
> together.  One of the beauties of Ada is the source text can be
> organized as a readable technical document.

The problem with that approach is that often the old names *and* the new
names will be used in the body of that package. That's just gawd-awful.
This is particularly likely to happen if multiple people end up helping
to author the source file. Each tends to have their own favorite way of
naming things.

As we are rather fond of pointing out to C coders, just because some
feature *can* be used to make readable code doesn't mean it typically
*will* be used that way.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

RE: Bad coding standards

[Robert Dewar]

In article
<NBBBJNOMKDIAJALCEFIJKECIEBAA.rleif@rleif.com>,
  comp.lang.ada@ada.eu.org wrote:
> From: Bob Leif
> To: SteveD et al.
> --*********Table of Contents********
> Package Analyze_Type_Declaration renames
>   Semantics_For_RM_Ch_3.Analyze_Type_Declaration;
> --*********End Table of Contents********
> --I presumed Analyze_Type_Declaration was a package


No, of course not, it is a procedure within the
package, so I think you missed the point here :-)


Sent via Deja.com
http://www.deja.com/

RE: Bad coding standards

[Robert Dewar]

In article
<NBBBJNOMKDIAJALCEFIJKECIEBAA.rleif@rleif.com>,
  comp.lang.ada@ada.eu.org wrote:
> --*********Table of Contents********
> Package Analyze_Type_Declaration renames
>   Semantics_For_RM_Ch_3.Analyze_Type_Declaration;
> --*********End Table of Contents********
> --I presumed Analyze_Type_Declaration was a package

This kind of garbage renaming might I suppose be
useful in a system where you have trouble telling
where an entity resides, but in a decent system
where this information is immediately at hand I
see no possible advantage in this kind of redundancy.
In particular, repeating parameters of procedures
in every unit using the procedure seems particularly
ugly to me. Imagine the impact if you added a default
parameter!


Sent via Deja.com
http://www.deja.com/

RE: Bad coding standards

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Robert Dewar et al.

"but in a decent system where this information is immediately at hand I
see no possible advantage in this kind of redundancy."
1) I was not using GNAT when I did this. 2)I have no guarantee that for
every place my source text is used that the above facilities will be
available. and 3) I do this mostly for package renames.

Very often, I will rename a subprogram from a withed package or a parent
library in a specification or body. However, that is almost entirely to make
it more readable in its present context.

A simple, portable solution would be to employ XML for the Ada source text
and include hypertext links to the withed packages and their components. I
see a good beginning of this with the present work on Ada to HTML. The
combination of XML and ASIS will provide a very large advantage for the
creation of Ada environments and tool-sets. The use of XML provides the
interesting possibility of including a time-stamp attribute in each XML
block. This might permit the development of an incremental compiler.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Robert Dewar
Sent: Friday, December 15, 2000 5:19 PM
To: comp.lang.ada@ada.eu.org
Subject: RE: Bad coding standards


In article
<NBBBJNOMKDIAJALCEFIJKECIEBAA.rleif@rleif.com>,
  comp.lang.ada@ada.eu.org wrote:
> --*********Table of Contents********
> Package Analyze_Type_Declaration renames
>   Semantics_For_RM_Ch_3.Analyze_Type_Declaration;
> --*********End Table of Contents********
> --I presumed Analyze_Type_Declaration was a package

This kind of garbage renaming might I suppose be
useful in a system where you have trouble telling
where an entity resides, but in a decent system
where this information is immediately at hand I
see no possible advantage in this kind of redundancy.
In particular, repeating parameters of procedures
in every unit using the procedure seems particularly
ugly to me. Imagine the impact if you added a default
parameter!


Sent via Deja.com
http://www.deja.com/

RE: Bad coding standards

[Robert Dewar]

In article <NBBBJNOMKDIAJALCEFIJCEDEEBAA.rleif@rleif.com>,
  comp.lang.ada@ada.eu.org wrote:
> This might permit the development of an incremental compiler.

I don't see how this would help in the development of an
incremental compiler, since the problems here are internal
to the entire processing of the compiler, where extra
complexity is required in maintaining the data structures.

Whether it is worth doing smart incremental recompilation
(beyond what GNAT does, which just takes care of simple
lexical things like comment changes and layout changes) is
an interesting matter of debate. Our view from the GNAT world
is that the extra complexity of an incremental compiler will
slow compilation down enough that overall the incremental
processing will leave you behind.

Of course you can always find individual cases (one declaration
added to a fundamental spec) where the incremental compilation
will be faster, but on the other hand take the case of adding
a single declaration that can NOT be handled incrementally.
That will likely be slower with an incremental compiler, other
things being equal.

In any case, incremental compilation involves a heck of a lot
more than just identifying what is new :-) Ask the folks
at Rational and DEC who have put a lot of effort into this kind
of technology :-)


Sent via Deja.com
http://www.deja.com/

Re: Bad coding standards

[Charles H. Sampson]

David Emery <emery@mitre.org> wrote:

> For a while, I collected coding standards as a hobby.  I've
> seen some dumb ideas, but here's my nomination for worst idea:
> 
>    package Long_Descriptive_Name is
>       
>       package LDN renames Long_Descriptive_Name
>       
>       type T is ...
> 
>    end Long_Descriptive_Name;
> 
>    with Long_Descriptive_Name;
>    package A_Client_Package is
>       package LDN renames Long_Descriptive_Name;
>    
>       procedure Proc (Param : LDN.T)...
>    
>    end A_Client_Package;
> 
> In this style, the existence and use of the rename was not
> an option, but was mandatory.  Furthermore, there were no
> rules for how a rename would be formed.  In some cases, the
> abbreviation related to some previous name for the package.
> I once sent out a "test" with 10 abbreviations for common
> packages, asking how many people recognized the renames.  The
> best score was 8 out of 10, and the average was about 5.
>
> ...

     Actually, I find this an acceptable compromise between my preferred
style of using the use clause and the usual style of requiring fully 
qualified names.  For me, qualifying everything with package names in-
troduces a tremendous amount of clutter, particularly if the package 
names are long, for the occasional payoff when looking up the name is 
necessary.  Using the two- or three-letter rename at least reduces that
clutter to manageable proportions.  If the abbreviations have some dis-
tinguishing characteristic, such as being all upper case, then your eye
can skip across them quite easily.  Standard, project-wide, renames are
helpful too, but that might not be practical in monstrous projects that
have hundreds of packages.

     As Robert has pointed out, if your environment has a good browser,
there's no need for these qualifications.  (Quibble to follow.)  I'll go
a step further.  If the design is good and identifiers are well chosen,
you usually know the package to look at to find a declaration, although
nothing tells you which lines to look at as a browser does.  Quibble: 
None of this helps much when porting code.  The browsers I'm familiar 
with don't work until something fully compilable is into the environ-
ment.   If you have compilation problem during the port, the search for
identifiers can be painful.

     I don't understand the point of the rename in the package specifi-
cation.

                                Charlie 


-- 
     To get my correct email address, replace the "claveman" by
"csampson" in my fake (anti-spam) address.

Re: Bad coding standards

[Wayne Lydecker]

"Charles H. Sampson" wrote:
> 
> David Emery <emery@mitre.org> wrote:
> 
>      Actually, I find this an acceptable compromise between my preferred
> style of using the use clause and the usual style of requiring fully
> qualified names.  For me, qualifying everything with package names in-
> troduces a tremendous amount of clutter, particularly if the package
> names are long, for the occasional payoff when looking up the name is
> necessary.  Using the two- or three-letter rename at least reduces that
> clutter to manageable proportions.  If the abbreviations have some dis-
> tinguishing characteristic, such as being all upper case, then your eye
> can skip across them quite easily.  Standard, project-wide, renames are
> helpful too, but that might not be practical in monstrous projects that
> have hundreds of packages.
> 
>      I don't understand the point of the rename in the package specifi-
> cation.
> 
>                                 Charlie
> 
> --
>      To get my correct email address, replace the "claveman" by
> "csampson" in my fake (anti-spam) address.

What we do at our company is make renames for each operator that we
need to import. e.g. (pulled randomly from our code):

  function "*"(L:Measurements.Distance_Type; R:Measurements.Distance_Type)
    return Measurements.Distance_Type renames Measurements."*";

That way we can use the "*" inline without the messy syntax.  For
instance, we can write:

  A := B * C;

instead of:

  A := Measurements."*"(A, B);

For complex statements, the renames really help.  As far as the TLAs
(three letter acronyms), we used to do that all over our code.  Things
got so bad though that we had to use acronyms that didn't even match
what we were trying to rename because it was already taken by another
renamed package.  What would be nifty would be to allow a package spec
define its own "approved" renames of the package that other packages
would be allowed to use.  I'm sure I'll hear immediately why it's not
a good idea though ;-)

-- Wayne.

Re: Bad coding standards

[Ken Garlington]

"Wayne Lydecker" <wayne@mtws.visicom.com> wrote in message
news:3A3A8272.30052FAD@mtws.visicom.com...
: "Charles H. Sampson" wrote:
: >
: > David Emery <emery@mitre.org> wrote:
: >
: >      Actually, I find this an acceptable compromise between my preferred
: > style of using the use clause and the usual style of requiring fully
: > qualified names.  For me, qualifying everything with package names in-
: > troduces a tremendous amount of clutter, particularly if the package
: > names are long, for the occasional payoff when looking up the name is
: > necessary.  Using the two- or three-letter rename at least reduces that
: > clutter to manageable proportions.  If the abbreviations have some dis-
: > tinguishing characteristic, such as being all upper case, then your eye
: > can skip across them quite easily.  Standard, project-wide, renames are
: > helpful too, but that might not be practical in monstrous projects that
: > have hundreds of packages.
: >
: >      I don't understand the point of the rename in the package specifi-
: > cation.
: >
: >                                 Charlie
: >
: > --
: >      To get my correct email address, replace the "claveman" by
: > "csampson" in my fake (anti-spam) address.
:
: What we do at our company is make renames for each operator that we
: need to import. e.g. (pulled randomly from our code):
:
:   function "*"(L:Measurements.Distance_Type; R:Measurements.Distance_Type)
:     return Measurements.Distance_Type renames Measurements."*";
:
: That way we can use the "*" inline without the messy syntax.  For
: instance, we can write:
:
:   A := B * C;
:
: instead of:
:
:   A := Measurements."*"(A, B);
:
: For complex statements, the renames really help.

If you're using Ada 95, you should definitely consider "use type" as an
alternative. Renaming a set of operators has proven to be so error-prone in
my experience, with the error so unlikely to be detected until run-time,
that I hope no one uses this routinely!

:  As far as the TLAs
: (three letter acronyms), we used to do that all over our code.  Things
: got so bad though that we had to use acronyms that didn't even match
: what we were trying to rename because it was already taken by another
: renamed package.  What would be nifty would be to allow a package spec
: define its own "approved" renames of the package that other packages
: would be allowed to use.  I'm sure I'll hear immediately why it's not
: a good idea though ;-)
:
: -- Wayne.

Re: Bad coding standards

[Robert Dewar]

In article <3A3A8272.30052FAD@mtws.visicom.com>,
  Wayne Lydecker <wayne@mtws.visicom.com> wrote:
> What would be nifty would be to allow a package
> spec define its own "approved" renames of the
> package that other packages would be allowed to
> use.  I'm sure I'll hear immediately why it's not
> a good idea though ;-)


So let me get this right, you are going to create
a long package name and a short package name. The
only purpose of the long package name is so that
people have to include a renames of the short package
name to the long package name in every single client,
and they must do it consistently.

This seems extraordinarily convoluted. Why not call
the package by the short name to start with, and then
include appropriate documentation in the package with
long names and whatever else you want.

The only function of the long name in practice in
your scheme will be to act as incomplete
documentation (incomplete because names alone never
substitute for full documentation) in clients.

But even decrepit environments can easily locate
the file for a package given the name of the package,
so it is trivial for someone to lookup the details on
a package that they don't recognize from the short
name.

One other advantage of using short names for packages
is that in debugging it means that you have to type
less junk.



Sent via Deja.com
http://www.deja.com/

Re: Bad coding standards

[tmoran]

>None of this helps much when porting code.  The browsers I'm familiar
>with don't work until something fully compilable is into the environ-
>ment.   If you have compilation problem during the port, the search for
>identifiers can be painful.
  What happens when a new release of the compiler has a bug that causes
your large system to no longer compile, so you can't use your fancy
browser to go through and change your code.