Re: How to name instance variables

>> I use this really aggressive Hungarian dialect.
>> We found all kinds of weird shit without even running a debugger.
>
> This says more about your ability to debug than the benefits of that
> naming convention.

Not in this case.
Have you seen the color-coded file tabs used in some physical offices?
They make it simply impossible to misfile things by very much.
The Hungarian I use has similar results.
Many common errors don't happen because the code just looks wrong.
Without structured names, it can be very hard to see these things.

> The problem with HN is that it is a convention and as you have pointed
> out, everyone has their own dialect. In addition to which different
> language families have their own requirements. This means that on
> approaching new (to me) code that uses HN I not only have to determine
> the problem domain but also the dialect of HN in use.

That's a cost I'm willing to bear,
although some dialects are certainly better than others.
I didn't accept the Hungarian idea nicely.
Eventually, its benefits became unavoidably clear in practice.

> Personally I detest HN, it is a case of hiding the wood with the trees.
> If I am dealing with screen co-ordinates for example I would (in C)
> typedef an appropriate integer type to hold those values:
>
> typedef unsigned int CO_ORD;
>
> If I now declare a variable of type CO_ORD using HN in its name (uiX ?)
> renders the typedef useless as I have removed the abstraction that
> creating it provided.

Most of my C has been in embedded systems
where forgetting the implementation invites product failure.
I would write

     typedef unsigned int tiCoordinate;
     tiCoordinate iCoordinateX;

> Variable names should their reflect use not their implementation.

In Smalltalk, you can get away with this most of the time.
Still, you can create some mighty obscure bugs
if you can't easily tell the difference between
globals, classvars, instvars, arguments, and locals.
I count the time spent examining definitions as time lost.

> strcpy(destination, source);
>
> NOT
>
> strcpy(lpzsDest, lpzsSrc);

That's great,
if destination and source are in fact what you think they are.

>> I think she changed all the names back after I left. (sigh)
> Good for her :-)

I'll say it again: she couldn't debug her own code
because she couldn't remember what she was dealing with
to the degree necessary for dealing with that algorithm.
Neither could I, so I changed the names and fixed it.
"Readability" gained her *nothing* of value,
and lost her a great deal.

>> the PPS T&C standard
> Any URL that refers to this?

Don't know.
Maybe Jim Robertson can find it somewhere.

Steve
--
Steven T Abell
Software Designer
http://www.brising.com

In software, nothing is more concrete than a good abstraction.

In message <[hidden email]>, Steven T Abell
<[hidden email]> writes

[big snip]

For myself HN appears simply as noise. My brain seems to work better
with knowing what a variable is for rather than what it is. I do accept
that others see things differently though.

 >> Still, you can create some mighty obscure bugs
 >> if you can't easily tell the difference between
 >> globals, classvars, instvars, arguments, and locals.

I have to agree with this actually, at my previous employment two of us
spent two days tracking down a bug that turned out to be a local
variable called "count" or similar shadowing a global variable of the
same name. There were nearly 2000 global variables in this system!
Shared between 26 process each with 20 or 30 global variables of their
own. :-(

There is the supposed fact that humans can only juggle around 6
independent "things" in memory at once. Perhaps your colleague's code
went beyond this.

Looking at randomly selected methods from a randomly selected file in my
current project (written in an object oriented C) I have the following
numbers of variables

function arguments       local variables       instance variables
2                         3                    3
1                         1                    3
5                         4                    1



However there is a difference between naming variables in the form:

m_varName for class instance variables
g_varName for global variables
etc.

and

puiVarName
ai32VarName
pstVarName

Where the former ally with your example of colour coded filing tags. The
latter are (to me) just noise that tie the code to the implementation
and reduce portability.

This is one of those things that boils down to personal choice,
ultimately there is no right or wrong, just what works for you.

--

Add 'w' after my first name for correct e-mail address.
[hidden email]
web: http://wightman-home.co.uk

Bob Wightman

Bob Wightman wrote:
Agreed entirely, *except* for the last line.  Hungarian is, IMO, Just Plain
Wrong.

I once worked on a project (in C) that used extreme hungarian throughout; it
was a big code base (several million lines IIRC), and I worked on bugfixing and
similar stuff for nearly six months.  At the end of that time I still *could
not* read the code.  I don't mean that I found it "less readable" (whatever
that means); I simly could not read it.  The only way -- in far too many
cases -- that I could keep track of which variable was which was by doing
character-by-character comparisons, or by cut-and-pasting into the editor's
search function.

The fact that it wasn't well-written in the first place, and had been hacked
around by far too many people since, didn't help matters, of course.  But how
in hell can anyone claim to be able to follow thousand-line functions with many
local and (static) globals named scpMLine, and sclMLine, and so on ? (The
examples are made up, but are not exagerated.)

Some people did seem to be able to get by with it, I have to admit, but there's
something about hungarian that throws my ability to read completely off.

I'd like to claim that there were bugs in the system caused by variable-name
confusion.  That's how I remember it, but I'm not really sure at this distance
of time and it may just be wishful thinking.  I'd certainly *expect* that there
were hungarian-induced bugs...

    -- chris

> My brain seems to work better
> with knowing what a variable is for rather than what it is.

In my view, a good name in a typed language will tell you both.

> I do accept that others see things differently though.

Yes, this seems to be kind of like postfix vs. algebraic calculators.
Some people simply can't use one or the other.
When I was at HP, I designed a really excellent algebraic calculator.
One of them is sitting on my desk right now,
right next to the postfix machine that I actually use.

> There is the supposed fact that humans can only juggle around 6
> independent "things" in memory at once. Perhaps your colleague's code
> went beyond this.

It did, involving ints, int*s, int**s, int[]s, etc. for some DSP.
Her code was basically a correct expression of the algorithm's intent,
and the code as I found it even seemed to make sense,
which turned out to be a part of the problem debugging it.
Neither of us could remember specifically
what kinds of things all the variables actually represented,
and our assumption of sensibility continually led us astray.

> Where the former ally with your example of colour coded filing tags. The
> latter are (to me) just noise that tie the code to the implementation
> and reduce portability.

The Hungarian dialect I use results in a sort of algebra
that makes it possible to track through very complex C correctly.
As for portability,
we may be looking at difference in environmental assumptions:
in embedded systems,
portability is not something one talks about very much.
Making the code and data fit in the box and run fast enough matter more.
One always has to think about the specifics of implementation.

> This is one of those things that boils down to personal choice,
> ultimately there is no right or wrong, just what works for you.

Yeah, probably so.
I know that Hungarian rubs a lot of people the wrong way,
and I'll agree that most programmers can write most code without it.
For myself, I found that my productivity in typed languages went up
when I swallowed the evil Hungarian potion. <}:-)
Fortunately, it's much less of an issue in Smalltalk or Lisp.

Steve
--
Steven T Abell
Software Designer
http://www.brising.com

In software, nothing is more concrete than a good abstraction.

Steven T Abell <[hidden email]> might (or might not) have written
this on (or about)  Thu, 01 May 2003 16:56:48 GMT, :

>Still, you can create some mighty obscure bugs
>if you can't easily tell the difference between
>globals, classvars, instvars, arguments, and locals.
>I count the time spent examining definitions as time lost.

The solution to this problem is to keep your methods and classes so
small that the distinction between the variables is obvious.



Robert C. Martin  | "Uncle Bob"                  
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757       | Tel: (800) 338-6716        
565 Lakeview Pkwy | Fax: (847) 573-1658           | www.objectmentor.com
Suite 135         |                               | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring        | www.junit.org
60061             | OO, XP, Java, C++, Python     |