TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Matthew Heaney <[log in to unmask]>
Tue, 20 Apr 1999 07:36:19 -0500
"David C. Hoos, Sr." <[log in to unmask]>
"David C. Hoos, Sr." <[log in to unmask]>
Steffen Bretz <[log in to unmask]>, Matthew Heaney <[log in to unmask]>
text/plain; charset="iso-8859-1"
text/plain (55 lines)
----- Original Message -----
From: Matthew Heaney <[log in to unmask]>
To: David C. Hoos, Sr. <[log in to unmask]>
Cc: Steffen Bretz <[log in to unmask]>; <[log in to unmask]>; Matthew
Heaney <[log in to unmask]>
Sent: Tuesday, April 20, 1999 6:34 AM
Subject: Re: Environment Variables

> "David C. Hoos, Sr." <[log in to unmask]> writes:
> > The use of verbs as the names of functions is not considered
> > good style by many authorities.
> Well, I'm considered an authority by some, and I say verbs are AOK for
> functions.  I routinely use Get_<noun> as the names of functions (as you
> may have noticed if you've been following my patterns articles).
> I call arguments like this the "argument by appeal to higher authority."

Well, I certainly don't want to get into a contest over who or what is the
"higher authority," but I think the "Ada 95 Quality and Style Guide" is
a pretty good one, from which I include a small excerpt:

Chapter 3: Readability - TOC - 3.2 NAMING CONVENTIONS
3.2.5 Program Unit Names

Use action verbs for procedures and entries.
Use predicate clauses for Boolean functions.
Use nouns for non-Boolean functions.
Give packages names that imply a higher level of organization than
subprograms. Generally, these are noun phrases that describe the
abstraction provided.
Give tasks names that imply an active entity.
Use nouns descriptive of the data being protected for protected units.
Consider naming generic subprograms as if they were nongeneric subprograms.
Consider naming generic packages as if they were nongeneric packages.
Make the generic names more general than the instantiated names.

To me, the explicit statement of the guideline is far more instructive
than examples which often do not follow a particular pattern, whether
for historical reasons, or whatever.

I have followed the patterns -- as you may remember I recently questioned
a statement in one of them -- but no number of counter examples will
convince me that there is not value in following the aforementioned

I also want to make it clear that my comments are not intended to
deprecate anyone's work, but are offered in the realization that
"iron sharpens iron," and that the exposition of various points of
view can be beneficial to all -- if done without rancor.