Re: [J.Kelly@xxxxxxxxxx: Understanding VisAD]

Steve Bellenot wrote:
> ----- 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
> From:    *** Ottinger's Rules for Variable and Class Naming ***
>    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.

The "rule" you present here applies to creating and maintaining REAL
code.  What James suggests is a potentially useful crutch for LEARNING
how to write VisAD code.  If the relatively trivial learning curve
associated with James' convention signifigantly lessens the learning
curve associated with VisAD, then that's a signifigant gain. 
Certainly "your mileage may vary," but at least it's worth a case
study.  I notice that there are a lot of new users on the list.  They
could try this out, see if it accelerates their progress, and report

John Brecht
SRI International
Center for Technology in Learning
333 Ravenswood Avenue
Menlo Park, CA  94025
650-859-2325 (voice)
650-859-3673 (fax)
org:SRI International;Center for Technology in Learning
title:Software Engineer
adr;quoted-printable:;;333 Ravenswood=0D=0ABN 261=0D=0A;Menlo Park;CA;94025;USA
fn:John Brecht