Identifier significance CHALLENGE

[ldl at genix.UUCP]

I realize that this is a bit late, and that this discussion has died down
to some extent, but out news source was in the process of upgrading to 4.2
and we were out of contact for a while.  Please forgive this late of a 
response.  This will clarify how it can be done without too much hassle.

First of all, the names (short ones) MUST be chosen with care.  If you 
divide the routines up into libraries, then all short names should indicate
where the name originates.  For example, I have a library named 'runtime'.
In this library, there are both user calls, and support routines.  The names
of all 'user calls' are tagged 'rtgnn' and 'supports' are tagged 'rtlnn', for
'RunTime Global' and 'RunTime Local', respectively. Similarly, any variables
used (common) by these routines are named 'rtgxnn' and 'rtlxnn' for 
'RunTime Global eXternal' and 'RunTime Local eXternal'. (The 'nn' is a number
sequence like '01', '02', etc).  In general, there are less than 20 user calls
and 30 supports, and no more than 10 variables (of each, global and local).

Secondly, I have rarely had to resort to going to adb.  I guess that it comes
from having worked on systems that did not allow highly interactive debugging
(i.e. communications front-ends, etc), but a long session of desk checking
is worth 10 times that amount of time in debugging.  (Typically, the 'debug'
time, running the new code, is less than 10% of the total coding time, for me).
Those few times that I have resorted to using adb, I was able to quickly track
down what was happening and correct the fault.

I guess that I should mention that I have put a preprocessor in front of the
actual 'cc' that does the real remapping, thus the mapped names are easily
accessible mechanically (have not interfaced to adb, thus the objections are
valid from the standpoint of adb or even sdb).  Considering the advantages
of name conflicts between library support routine names (i.e. routines that
are never accessed, nor accessible, outside of the library proper), the funky
names have aided rather than hindered the conflicts that could otherwise
result (like if the wrong routine was linked to the right spot because the
name was the same).  There have been many good suggestions, but apart from
the language being changed (universally, on all Unix environments), there
are disadvantages to all shortening approaches.  The solution (apart from
changing the definition of the language) appears to be deciding which poison
tastes least bad.  :-)

-- 
Spoken: Larry Landis
USnail: 5201 Sooner Trail  NW
        Albuquerque, NM 87120
MaBell: (505)-898-9666
  UUCP: {ucbvax,gatech,parsec}!unmvax!genix!ldl