NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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
visad archives: