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
back.


-- 
John Brecht
SRI International
Center for Technology in Learning
333 Ravenswood Avenue
Menlo Park, CA  94025
650-859-2325 (voice)
650-859-3673 (fax)
john.brecht@xxxxxxx
begin:vcard 
n:Brecht;John
tel;home:(415)260-7898
tel;work:(650)859-2325
x-mozilla-html:TRUE
url:http://jbrecht.sri.com/john/
org:SRI International;Center for Technology in Learning
version:2.1
email;internet:john.brecht@xxxxxxx
title:Software Engineer
adr;quoted-printable:;;333 Ravenswood=0D=0ABN 261=0D=0A;Menlo Park;CA;94025;USA
fn:John Brecht
end:vcard