Re: Sucking (was Re: How can I avoid Using a Semaphore? (long))

["Mark Lundquist" <mark@rational.com>]

DuckE <nospam_steved94@home.com> wrote in message
news:0PKe6.366080$U46.10801728@news1.sttls1.wa.home.com...
>
> Our code started in a different language (EPascal) where external
functions,
> procedures and type definitions were not easily discernable from local
> definitions.  Knowing the origin of these definition "at a glance" without
> having to look it up has its advantages.
>
> In Ada, I could certainly see eliminating these acronyms in favor of
> qualifying these external definitions with their origins (ie:
> Ada.Text_Io.Put_Line ).

There's an Ada style out there that you might find gives you the best of
both...  To use your code as an example, you would name your package
Network_Packet_Utilities (since I'm writing it this time I get to insist on
the underscores :-).  Then in other units that with your package, you say

    package NPU renames Network_Packet_Utilites;

Now you can use qualified names to explicate the name space relationships in
the formal way rather than the ad hoc way of using format conventions, but
it allows for a less prolix style :-).  I haven't looked at a whole lot of
the Ada code in the GNAT distribution, but I think I've seen that style used
there, and I know it's used internally at Rational in places too.

>
> > The style of "aFoobar" and "anApteryx" for type names seems like a
> different
> > form of the "The_Foobar" cop-out for parameter names -- both meant to
> spare
> > us the trouble of thinking up a parameter name that would be more
> meaningful
> > than just repeating the name of the type, am I right?
>
> Our use of "a" or "an" to start a type definition simply adds instant
> recognition of an identifier as a data type without regard to context.

Well, I have to wonder of what use is that information ("this identifier
names a type") apart from the context.  If there is none, then *to*me* the
"instant" recognition doesn't add value since I have to move immediately to
making some use of that information, and that depends on the context anyway.

(Your reply got me to thinking if there are any places in Ada where the fact
that an identifier names a type is not manifest from the syntax.  The only
case I could think of was that of conversions.  That's not saying you
_shouldn't_ want "instant recognition", only that I can't relate to the
reason why :-)).

It can be fun and instructive to postulate variants of a language, just for
the sake of argument :-).  So I wonder if people who like instant
recognition of types would be happier with an Ada in which occurences of a
type names were all accompanied by the word "type", e.g.

    Foo : constant type Wumpus;
    type Wumpi is array (Blah range <>) of type Wumpus;
    Z := type Wumpus'(X + Y);

(N.B. I am *not* advocating this... :-) :-)  But anyway, would this provide
the same level of satisfaction as building "this is a type" hints into
identifiers?

Some people (not I :-)) like to append "_Generic" or "_G" to generic unit
declarations.  In context of usage, "this is a generic" is even more
apparent than "this is a type", since you can't do squat with a generic
except instantiate it (or name it as a generic formal package, which looks
just like an instantiation), where it's always preceded by "is new" (and
"package", "procedure", or "function").  But one place that can get a little
confusing is in the generic body itself.  I've always sort of wished that
generic bodies weren't identical to nongeneric bodies -- e.g. that you had
to recapitulate the "generic" and the formal part in the body syntax.  I
usually do that in a comment (and then I have to accept the problem of
keeping the body comment in sync with the spec).

> IMHO
> this is not much different than quickly identifying the start of a
sentence
> with a capital letter.

More like the capitalization of nouns in German, I'd say :-)

--mark

P.S. One reason I find Ada style is so interesting is that it's the idea
with Ada that the style of writing should be optimized in favor of readers
rather than the writer (and "reader" of course includes the person of the
"writer" in her role as a reader of her own code).  So the question that
immediately follows is "which reader", because you potentially have a
diverse population of readers who differ in knowledge of Ada, knowledge of
the problem domain, knowledge of the present source text itself (in regard
to which each reader changes as their understanding increases), learning
style, etc., and you're shooting for a "best fit" across all these.  This
relates to commenting style as well as "coding" style.  Certainly it applies
not only to Ada, but to programming in any language where you are attempting
to be reader-friendly...