Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

["John G. Volan" <johnvolan@sprintmail.com>]

Robert Dewar wrote:
> 
> John asks
> 
> <<It's against my religion to give up on the "Thou shalt not abbreviate"
>   commandment so easily.  :-)
> 
> I notice again you using the term religeon. I strongly advise an agnostic
> viewpoint when it comes to programming. Religeously inspired rules and
> views tend to be a menace when it comes to programming style. 

You of course noted my smiley there, right? ... :-)  I knew this
discussion would arouse some strong emotions and challenge some
cherished habits, so I deliberately sought to defuse the situation in
advance with a bit of humor in the subject line...

> I understand
> the comfort of letting rules substitute for judgment, but I think it is a
> bad idea to have any absolute rules (except this self referential one :-)

Every rule has a domain of applicability, beyond which it becomes
oppressive. But within its domain of applicability, I do not see why it
should not be absolute.  Rigor can reap great benefits.  The exercise of
applying a rule rigorously can sometimes, just by itself, crystallize a
person's thinking and reveal flaws in a design.

Where judgment should come into play is knowing where the bounds of a
rule's domain extend. In this discussion, I have been trying to push the
bounds outward a bit, to challenge what I perceive as loose thinking. 
Perhaps in some cases the bounds have been stretched too far and must be
pulled back. If so, it is not going to be satisfying to me if the
rationale for tightening the bounds is simply "we're not used to it" or
"just doesn't _feel_ right."  It is much more satisfying to me if the
rationale is based on some higher order rule freshly discovered, leading
to even greater comprehension.

As for comfort, comfort was not one of my primary goals in devising a
naming convention.  Reducing the mental workload for the author and the
readers was.  Simple rules rigorously applied can eliminate unnecessary
work at a lower level and leave energy available for higher-order
problems.

Also, I believe keeping to Engish reduces work in the long run.  I cling
to English words wherever I can simply because of English's universal
utility: English is the one constant I can guarantee that all readers
will be immediately familiar with, at all times, in all contexts. 
(That's not jingoism, it's just reality: for better or worse, this is an
Engish-speaking world.)

> Well as you know well if you have looked at the GNAT sources, the
> Get_ and Set_ prefixes are extensively used, 

Haven't looked, not recently anyway. But "Get_" and "Set_" have ample
precedent elsewhere.

> but again, I think it
> is a mistake to take a religeously consistent view here. 

Again, it's not religion, but rather a drive for rigor.

> The
> fundamental tree walking functions Next, Prev, and Parent are
> used *so* extensively that choosing any other names for them
> would add unnecessary obfuscatory expansion to the code.

I do not dispute your choice to reserve simple unmarked words for use in
naming these functions, but it does mean that those identifiers become
unavailable for the recipient objects.  The latter must then be marked
in some way.  That's an acceptable trade-off.  I'm just a bit
disappointed that the way you chose to mark them involved devising ad
hoc abbreviations on the spot.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------