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
