[J.Kelly@xxxxxxxxxx: Understanding VisAD]

• To: visad-list@xxxxxxxxxxxxx
• Subject: [J.Kelly@xxxxxxxxxx: Understanding VisAD]
• From: *** Ottinger's Rules for Variable and Class Naming ***
• Date: Thu, 2 Dec 1999 08:24:31 -0500

----- Forwarded message from James Kelly <J.Kelly@xxxxxxxxxx> -----

Hello VisADevelopers,

I have some thoughts on how to better understand VisAD, and was interested
to hear other opinions.

Looking through the VisAD examples I find the examples easier to understand 
if I adopt a consistent convention for the variable names.

The aim here is to have variable names which suggest what the
underlying structure is, and which I can understand just
by looking at them. This relieves me of the burden of looking
back through the code continuously to see what a given variable
represents.

Combined with using Hungarian notatation (eg preceeding FunctionType 
variable names with ft), and listing all the variables in say 30 lines or so,
I can understand the flow of the program (after some study
and cross reference to the program of course).

--- clip ---

Hungarian notation is very undesirable

   2. Don't use Encodings:

     Encoded names require decyphering. This is true for hungarian
     and other 'type-encoded' or otherwise encoded variable names.
     Besides, encoded names are seldom pronouncable (#1).

     When you worked in name-length-challenged programs, you
     probably violated this rule with impunity and regret. Fortran
     forced it by basing type on the first letter, making the
     first letter a 'code' for the type. Hungarian has taken this
     to a whole new level.

     Of course, you can get used to anything, but why create an
     artificial learning curve for new hires? Avoid this if you
     can avoid it.

• Follow-Ups:
  • Re: [J.Kelly@xxxxxxxxxx: Understanding VisAD]
    • From: John Brecht