Re: How to name variables in a program?



websnarf@xxxxxxxxx wrote:
> Arafangion wrote:
> > I came across a rumour (I _think_ I got it from www.joelonsoftware.com),
> > but the rumour suggests that Hungarian notation originated from a
> > missunderstanding of Apps hungarian, particularly on the word 'type'.
> > For instance, Apps Hungarian would never simply say iWidth, but would
> > use something more like scrWidth, and scrHeight, with a convention that
> > scr means "the screen", which helps you not mix it with, say, panelWidth
> > and panelHeight.
> >
> > I'm going out on a limb here, could someone confirm or deny this?
>
> I thought "hungarian" was just a reference to its inventor Charles
> Simonyi (worked on Excel, and other high level projects at MS) who is a
> hungarian.

That is correct.

However, other programmers independently discovered variants of the
technique and naming variables according to their type is mentioned in
a very early (1962) book by John Diebold. It was enforced within
certain programming groups at IBM. Since Szymonyi worked in mainframe
programming before coming to Microsoft he may have allowed the practice
to be more or less named after him with proper attribution.

Here's my own VB.Net standard as used consistently for the Visual Basic
..Net code in <shamelessPlug>Build Your Own .Net Language and Compiler
(Apress 2004): this book contains a 26000 line compiler/interpreter for
a significant subset of Quick Basic)</shamelessPlug>.

(1) The following lower case type prefixes are used for LOCAL variables

boo - Boolean as in booOption
byt - Byte as in bytKeyValue
shr - 16 bit Short integer as in shrIndex1: the obvious choice sht is
not on for obvious reasons
int - 32 bit Integer as in intIndex1
lng - 64 bit Long integer as in lngIndex1
sgl - Single precision real number as in sglTemperature
dbl - Double precision real number as in dblParsecs
str - String as in strName
col - Ordinary .Net Collection as in COLvariables
frm - Windows form as in frmCustomer
ctl - Abstract Windows control as in ctlControl
cmd - Windows command button: other Windows controls have the types
hsc, vsc, lbl, txt etcetera in line with common praxis
obj - Any other type of reference object

Since the above prefixes are lower case the resulting name is camelCase

(2) For class state variables at the class level as well as for global
variables (almost never used in good practice) the above prefixes are
used but in upper case, with the first character of the rest of the
name in lower case as in INTindex.

(3) For Shared variables (variables accessible to multiple class
instances) the above standard (2) applies but the Shared variable is
prefixed with an underscore. This causes no problems in Visual Basic
..Net because its variable syntax now allows underscores as well as
letters to start identifiers.

(4) Structures are prefixed with TYP: because they are necessarily at
the class (and sometimes, in bad praxis at the module or global level)
TYP is always upper cased in the standard. However, this is somewhat
legacy because in fact and in .Net today, a Structure is a lightweight
class which can have, for example, a paramareterized constructor and in
development structures may easily become classes and vice versa.
Therefore while Build Your Own uses TYP my praxis is moving away from
this standard which is a reminder of the bad old days of VB COM, when a
Structure was a Type, men were men, and the women were glad of it, and
the sheep were nervous.

(5) Structure instances in the book have the prefix USR or usr
depending on whether they are global or local. But as I discover the
increasing convergence between the Structure and the Class the praxis
on my part changes to OBJ OR obj.

Basically, a structure is a legacy creature of the C era in which
records and structures dreamed of being objects, with the ability to
self-create and self-serialize.

(5) Classes have NO Hungarian prefix because it is incoherent to tie a
class to a type. A class doesn't have a type. A class is a type. But I
consider it overkill to go to the next step, and devise, for each new
class, a Hungarian prefix for instances of that class. There almost
aren't enough three character combinations and the multiplicity of
prefixes would only cloud the mind.

To have a multiplicity of Hungarian prefixes is I agree the Mountains
of Madness.

(6) Parameters of procedures are considered to be and are treated as
local variables from the standpoint of this standard. Note that this
does NOT force the caller to use your standard except in one case. When
you have, using a feature unique to VB.Net, declared an optional
variable, the user has to grit her teeth (if she hates Hungarian) and
type the name you have chosen!

However, you should try NOT to use optional VB.Net parameters because
interoperability is damaged. Programs in C++ and C# can't use the
optional parms, and they can usually be replaced by overloading.

The above standard ports to other OO languages easily. It creates a
little extra work in Visual Studio when you use Intellisense to find a
variable, in that to get to intIndex1 you have to type inti (you don't
have to shift the final i).

But this is more than made up for by thinking time.

If you don't use Hungarian, then you have to THINK, what did I call
that stinky variable? If you do use the notation of the Magyars, then
you can think faster: "oh, I need that integer, what was it, tippy
typee i-n-t, oh yeah, there it is".

And your result is FAR more readable. See my book for examples of the
code.

As to being able to pronounce the name, the Hungarian prefix creates
only a modicum of clumsiness as in obj-uh-Fanorkle. OK, if you spend a
lot of time reading your code to fussy babies to put them to sleep,
then this is a consideration.

It is always dangerous to draw an ideogram as shown by the "drift" of
Chinese ideograms away from their original referents. But if you
combine a sense of personal responsibility with a modern editor it is
in my experience a snap to keep variables in line with their prefixes.
And you can use anything from a VS add-in to awk to develop a checker
upper onner.

I conclude that resistance to Hungarian notation is just laziness, and
I think that full support for Hungarian should be in Visual Studio:
when I type intIndex before declaring it, Visual Studio should insert
Dim intIndex As Integer in the closest enclosing block that is not a do
or for loop. Of course, this means that I am in the sense of mere tippy
typee lazy too, but my real motivation is to PRODUCE READABLE CODE
which can be in a coffee table book in the finest homes.

Code with thousands of variables with unstructured names like customer,
snawk and voidola is an obscenity.

>
> --
> Paul Hsieh
> http://www.pobox.com/~qed/
> http://bstring.sf.net/

.