RANT: Stop Indicating Type in Variable Name Please

146 views
Skip to first unread message

Michael Covington

unread,
Aug 5, 1997, 3:00:00 AM8/5/97
to

I hear you. I think the best variable names are those that actually
tell you what the variable does. If the data structures are well
designed, the type of the variable should be fairly obvious from its
function. I use "Hungarian-style" names only for minor variables that
are used briefly or would otherwise conflict, e.g.,
LocalDocumentationStrings and then pLocalDocumentationStrings if
for some reason I also have to have a pointer to it.

I do use rather *long* variable names. For those who hate to type,
these can be typed short, then lengthened by a global change in
the editor.

--
Michael A. Covington, Ph.D. http://www.ai.uga.edu/~mcovingt
Associate Director, Artificial Intelligence Center and
Chairman, Computer Security Incident Handling Team
The University of Georgia, Athens, GA 30602-7415 U.S.A. <><

John Burton

unread,
Aug 6, 1997, 3:00:00 AM8/6/97
to

Do you really have so many variable that you can't remember
what they do? I'd suggest doing a bit more design on your
code.

Ell <e...@access2.digex.net> wrote in article
<5saacd$o80$2...@news2.digex.net>...
>
> Here's one vote *for* Hungarian. I can know what a variable is without
> hunting. From context it's often difficult to know, for instance, if a
> number variable is an integer or a float.
>
> I also like the PB convention where even the scope of a variable is
> signified. gVar - global; mVar - member; Var - local function.
>
> Elliott
> --
> "The domain object model is the foundation of OOD."
> "We should seek out proven optimal practices and use them."
> See SW Modeller vs SW Pragmatist Central:
http://www.access.digex.net/~ell
>
>
>

Adrian Milliner

unread,
Aug 7, 1997, 3:00:00 AM8/7/97
to

On Wed, 06 Aug 1997 19:58:24 GMT, "John Burton" <j...@mail.com> wrote:

>Do you really have so many variable that you can't remember
>what they do? I'd suggest doing a bit more design on your
>code.
>

It does happen, ever so often, that a large number of variables are
required. Many classes with many member variables. C code with struct
members. Even plain old globals.

In fact, just about every project I've ever worked on had many
hundreds, if not many thousands of variables (member or otherwise).

Occasionally, in really bizarre cases, more than one person works on a
project, so there could be variables that you would have no knowlege
of.

From the comment you made, it sounds like you've never actually worked
on a project bigger than "hello, world".

Of course if you were refering to local(auto) variables, then your
point is well made and I apologise for my sarcasm. But I doubt it,
somehow.
--
Adrian Milliner
adr...@NOSPAMrefine.co.uk
http://www.ftech.net/~refine/

When replying to messages, remove the NOSPAM from the address.

Ell

unread,
Aug 7, 1997, 3:00:00 AM8/7/97
to

Ma...@mWilden.com wrote:
:
: I have no problem using nChickens to designate the number of chickens in
: a program, because I usually don't care what its internal representation
: is. At some point, I did, so I made it an unsigned char, unsigned int,
: unsigned short, unsigned long or whatever. But having made that choice,
: the rest of the application doesn't have to cart around this baggage
: every time I use the variable--it just needs to know that nChickens
: counts chickens.

But how about the possibility that you will corrupt the integrity of the
meaning of the data in the variable if you assign for example an
unsigned value to a signed variable?

: And if it turns out that I was wrong about the number of chickens I
: needed to count, I simply change one word in one definition and one
: declaration, instead of having to change uccChickens to ulcChickens
: throughout the entire program. Isn't this the opposite of abstraction?
:
: (But the main reason I don't miss Hungarian is that it makes the code
: ugly. :)

Funny, I find it nice looking, and "reassuring". I've been doing MS
Windows programming since the late '80's, so I'm very used to it.

David Brownell

unread,
Aug 7, 1997, 3:00:00 AM8/7/97
to

Ell wrote:
>
> Here's one vote *for* Hungarian.

Bletch ... when I need to change the type of a variable, I need to
change
its name and everywhere I use it? I can't just rely on overloading to
keep
everything straight? I can't just name variables exclusively by
purpose?
I have to capture every bit of potentially relevant data in the name?

.... I need to use a naming convention invented for use in assemblers
with
eight character symbol names, now that languages have full length
symbols?

Where DID that smelly mess come from?

- Dave

Mark Boon

unread,
Aug 8, 1997, 3:00:00 AM8/8/97
to

On Wed, 06 Aug 1997 19:58:24 GMT, "John Burton" <j...@mail.com> wrote:

>Do you really have so many variable that you can't remember
>what they do? I'd suggest doing a bit more design on your
>code.
>

Never had to look at someone elses code and wondered "what the #$@% is
going on here"?

And sometimes code I made myself a long time ago looks like it was
made by someone completely different :-)

I usually indicate both type and scope, although not as much in Java
as in C. Java is more strongly typed, and usually everything is an
object of some sort anyway.

D'Arcy Smith

unread,
Aug 8, 1997, 3:00:00 AM8/8/97
to Ell

Ell wrote:
>
> Here's one vote *for* Hungarian. I can know what a variable is without
> hunting. From context it's often difficult to know, for instance, if a
> number variable is an integer or a float.
>
> I also like the PB convention where even the scope of a variable is
> signified. gVar - global; mVar - member; Var - local function.

So use a convention (naming / placing) :

I use:

- constants - public, protected, package, private
- variables - public, protected, package, private
- methods - public, protected, package, private

- public members have no prefix
- non-public memeber start with an "_"

- all variables are declared at the start of the block that
they are used in

eg:

public class X
{
public static int CONST = 1;

public int pub;

protected int _pro;


public void f()
{
int j;

pub = 1;
_pro = 2;
j = 3;

{
int k;
}
}

private void _g()
{
}
}


This way you can easily find where everything is so in the cases
where there is an ambiguity (like is this protected or private?)
you can easliy figure out where to look.

Also, this follows the more "usual" OO notations of "aVarName"
rather than "mAVarName"...

Its all religious.

..darcy

--
D'Arcy Smith
Symantec, Internet Tools

Check out http://cafe.symantec.com for JDK 1.1.2 for:
- Cafe 1.8

Check out http://cafe.symantec.com for JDK 1.1 for:
- Visual Cafe 1.1 Prerelease 2
- Visual Cafe Pro 1.1 Prerelease 1

Patrick Doyle

unread,
Aug 8, 1997, 3:00:00 AM8/8/97
to

In article <33eab251...@news.xs4all.nl>,

Mark Boon <tes...@xs4all.nl> wrote:
>On Wed, 06 Aug 1997 19:58:24 GMT, "John Burton" <j...@mail.com> wrote:
>
>>Do you really have so many variable that you can't remember
>>what they do? I'd suggest doing a bit more design on your
>>code.
>>
>Never had to look at someone elses code and wondered "what the #$@% is
>going on here"?

And hungarian notation really helps in these situations? I doubt
it. I think code readability would go a lot further towards making
the purpose of a piece of code clear.

-PD
--
--
Patrick Doyle
doy...@ecf.utoronto.ca

Patrick Doyle

unread,
Aug 8, 1997, 3:00:00 AM8/8/97
to

In article <5sch5e$ekv$3...@news2.digex.net>, Ell <e...@access5.digex.net> wrote:
>Ma...@mWilden.com wrote:
>:
>: I have no problem using nChickens to designate the number of chickens in
>: a program, because I usually don't care what its internal representation
>: is. At some point, I did, so I made it an unsigned char, unsigned int,
>: unsigned short, unsigned long or whatever. But having made that choice,
>: the rest of the application doesn't have to cart around this baggage
>: every time I use the variable--it just needs to know that nChickens
>: counts chickens.
>
>But how about the possibility that you will corrupt the integrity of the
>meaning of the data in the variable if you assign for example an
>unsigned value to a signed variable?

*Even C* should warn you about that one. And for types that are truly
incompatible, it won't work anyway.

>Funny, I find it nice looking, and "reassuring". I've been doing MS
>Windows programming since the late '80's, so I'm very used to it.

Yes, the aesthetics are subjective. But I think there's little
question that plain english words are easier to read than random
letters.

However, I suppose the human mind has the capability to get used
to just about anything given long enough.

Patrick Doyle

unread,
Aug 8, 1997, 3:00:00 AM8/8/97
to

In article <5saacd$o80$2...@news2.digex.net>, Ell <e...@access2.digex.net> wrote:
>
>Here's one vote *for* Hungarian. I can know what a variable is without
>hunting. From context it's often difficult to know, for instance, if a
>number variable is an integer or a float.

I think having to look up a variable's declaration is a small price to
pay for code readability.

Code readability is highly underrated, in my opinion.

Uwe Grensing

unread,
Aug 8, 1997, 3:00:00 AM8/8/97
to


Scott Robert Ladd <srl...@frontier.net> schrieb im Beitrag
<01bca287$80231a00$69c9...@animas.frontier.net>...
> Richard J Kucera <kuc...@hhmi.org> wrote in article
> <33E73FDE...@hhmi.org>...
>
> Not only is such notation ugly -- it also makes Java code look like
> Microsoft-style Windows code! Ugh... <grin>
>
Best thing:

Even Microsoft uses (or used) at least 2 different types of Hungarian
Notation:

Sometimes int's are iFoo, sometimes they say, it's an index to something,
then it's nFoo.
Also, in 32-bit, pointers are still long-pointers. Really useless.

But: I think, normally you can quite live without hungarian notation. The
only thing I always do is p for Pointer and h for Handle. This helps a lot
in C++, at least for me.

Yours

Uwe

Dean Roddey

unread,
Aug 8, 1997, 3:00:00 AM8/8/97
to

But you are kind of missing the point that people who use HN, do it
because they think it improves readability :-)

--------------------------
Dean Roddey
The CIDLib Class Libraries
'CIDCorp
dro...@netgate.net
http://ng.netgate.net/~droddey/

"Software engineers are, in many ways, similar to normal people"

Robert C. Martin

unread,
Aug 8, 1997, 3:00:00 AM8/8/97
to

Patrick Doyle wrote:
>
> Yes, the aesthetics are subjective. But I think there's little
> question that plain english words are easier to read than random
> letters.
>

Granted. But the real problem with variable names that contain
their types is that the type information is redundant. The
compiler knows the type of a variable and will warn, or out and out
prevent misuse of the type. Therefore the type info in the name is
redundant and supplies little benefit. On the other hand, that
info is a rather large liability since if must be changed if the
variable type ever gets changed. The impact of such a change is
so high that often the variable name *will not* be changed even though
the type is.

Thus, the type info becomes a lie. Programmers who have found a few
such lies (and everyone will) will soon realize that they cannot trust
the type info, and will therefore ignore it.

The end result is that the convention will slowly defeat itself. The
project will contains many different varieties of variable names. Some
that don't contain type info; some that do, but lie; and some that do
and tell the truth. In other words, a mess.
--
Robert C. Martin | Design Consulting | Training courses offered:
Object Mentor | rma...@oma.com | Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 | C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com

"One of the great commandments of science is:
'Mistrust arguments from authority.'" -- Carl Sagan

Ell

unread,
Aug 9, 1997, 3:00:00 AM8/9/97
to

Robert C. Martin (rma...@oma.com) wrote:
:
: ... But the real problem with variable names that contain

: their types is that the type information is redundant. The
: compiler knows the type of a variable and will warn, or out and out
: prevent misuse of the type. Therefore the type info in the name is
: redundant and supplies little benefit.

Hugarian sure helps me as the programmer writing the code which is sent to
the compiler. You being one who is often railing against having to
re-compile, should see that one shouldn't wait for a compile or link to
find an error.

On the other hand, that
: info is a rather large liability since if must be changed if the
: variable type ever gets changed. The impact of such a change is
: so high that often the variable name *will not* be changed even though
: the type is.

What's so hard about using a global search and replace?

Scott Stanchfield

unread,
Aug 9, 1997, 3:00:00 AM8/9/97
to

Code should just plain be readable -- if someone uses a name like
numberOfWoozles rather than iNum I'm very happy. I get the idea.

I worked at a place that insisted on their own version of Hungarian.
THAT sentence should say it all -- _their_own_version.

Everyone who worked there knew a different variation on Hungarian.
Sure, several common traits like "p" and "i" existed, but there were all
sorts of variations on more complex data.

One of the biggest points of OO programming is encapsulation -- you
shouldn't _care_ about the details, only the interface, if things are
designed well.

Also, in Java you never have this issue of "if this an object, a
reference or pointer?" Everything is either a reference or a primitive
variable. Besides, haven't tools progressed to the point that if you
want to find out what something is, you just look at a class browser?
IMHO, most of the code I've worked with isn't that hard to figure out
what the variables are, just from previous context.

-- Scott

Doug Frietchen

unread,
Aug 9, 1997, 3:00:00 AM8/9/97
to

Jo Grant wrote:
>
> I abhor Hungarian notation. However my preferred technique is unlikely to
> please anyone. Back in good, old Fortran (the only language where a
> Complex Number is one of the basic types) they had this feature where if
> you didn't declare the type for a variable it could be deduced from the
> first character of its name. For example, i and j were always integers.
> When I tend to write my code I use a similar thing where I always use the
> same names for variables of similar functions. Obviously this only works
> for utility variables...
> Jo

IMHO, deducing the type from first char was more dangerous than
useful. If you made a typo, rather than give you an error message,
suddenly you had a new variable set to 0 ! This leads to many hard to
find errors that C,C++, Java, et al... compilers would catch.

I still don't understand why C, C++ and Java don't add Complex numbers
as a basic type?

-----
Doug Frietchen
fri...@erols.com
dbfri...@tasc.com

The views expressed do not necessarily represent
those of TASC, nor the left side of Doug's brain.

If you need instructions on how to reply to me, browse to:
www.clueless.websurfers.com
/************************************************/

David Harmon

unread,
Aug 9, 1997, 3:00:00 AM8/9/97
to

On Fri, 08 Aug 1997 23:53:38 -0500, "Robert C. Martin"
<rma...@oma.com> wrote:
>redundant and supplies little benefit. On the other hand, that

>info is a rather large liability since if must be changed if the
>variable type ever gets changed. The impact of such a change is
>so high that often the variable name *will not* be changed even though
>the type is.

The cannonical example being wParam and lParam in MS Windows programs.
In the 16-bit API, wParam was a "word" (16-bit int) and lParam was a
"long" (32-bit int). In the new 32-bit API, they are both 32 bits,
but for some unknown reason, Microsoft overlooked changing the name of
wParam in all their SDKs and documentation. For maximum accuracy and
clarity, they should obviously both be named lParam.

Patrick Doyle

unread,
Aug 9, 1997, 3:00:00 AM8/9/97
to

In article <01bca435$4f6b1110$0132a8c0@golliwog>,

Uwe Grensing <gren...@stud-mailer.uni-marburg.de> wrote:
>
>But: I think, normally you can quite live without hungarian notation. The
>only thing I always do is p for Pointer and h for Handle. This helps a lot
>in C++, at least for me.

Yes, mark variables according to usage, not type. That makes sense
to me.

kdlitwak

unread,
Aug 9, 1997, 3:00:00 AM8/9/97
to

I first tried using Hyngarian notatin but then abandoned it in favor
of a system that will probably be liked less by others but works for
me. I now apend the type of object to the end of the name. So, for
purposes of unqiue names in my whole file, with no overlap between
classes, I might have
addParmDlgOkButton
It makes for long names but it's very clear to me exactly what the
object belongs to (the AddparmDialog class) and wht object it is within
that. I ned those names because I can't always depend upon a "label"
for getting an action or something like that. I need the name and it
helps me avoid confusion when my file contains a big Frame class and
seveal dialogs. A name like okay or picture1 (the sorts of names that
Cafe creates) isn't going to work when I have an application with thirty
dialogs. Hey, I was a COBOL programmer for five years. I'mused to long
variable names!

Ken Litwak


Daniel F. Savarese

unread,
Aug 9, 1997, 3:00:00 AM8/9/97
to

In article <33EAAC1C...@itools.symantec.com>,

D'Arcy Smith <d...@itools.symantec.com> wrote:
> - constants - public, protected, package, private
> - variables - public, protected, package, private
> - methods - public, protected, package, private
>
> - public members have no prefix
> - non-public memeber start with an "_"
>
> - all variables are declared at the start of the block that
> they are used in

At ORO, we think scoping in Java is much more important than typing issues
that lead people to use things like Hungarian notation. We use a convention
similar to the one you mention, but we take it to an extreme:
o public members and local variables have no prefix
o default scope members start with a "_"
o protected members start with a "_" and end with a "_"
(e.g, protected int _foo_;)
o private members start with a "__"
This makes it immediately obvious to a programmer what the scope of a variable
is. We do this only because our own experience is that when creating Java
packages and trying to properly control the level of data encapsulation,
that being aware of variable scope is vastly more important than variable
type.

>Its all religious.

I agree that it definitely comes down to a matter a preference. But I think
the kind of issues people had in C programming that led them to things
like Hungarian notation do not apply so much in Java. Although, I don't
see anything wrong with hand generated GUI code having variable names like
fooPanel or barCanvas which indicate what type of AWT component a variable
is. To each his own. As long as the system you choose is productive for your
organization (i.e., minimizes bugs and code maintenance, etc.), then it
can't be faulted if applied consistently.

daniel

orororororororororororororororororororororororororororororororororororororororo
Daniel F. Savarese email: d...@oroinc.com
ORO, Inc. "Component software for the Internet."tm http://www.oroinc.com/
orororororororororororororororororororororororororororororororororororororororo

Ralph Richard Cook

unread,
Aug 9, 1997, 3:00:00 AM8/9/97
to

mcov...@aisun1.ai.uga.edu (Michael Covington) wrote:

>I hear you. I think the best variable names are those that actually
>tell you what the variable does. If the data structures are well
>designed, the type of the variable should be fairly obvious from its
>function. I use "Hungarian-style" names only for minor variables that
>are used briefly or would otherwise conflict, e.g.,
>LocalDocumentationStrings and then pLocalDocumentationStrings if
>for some reason I also have to have a pointer to it.
>
>I do use rather *long* variable names. For those who hate to type,
>these can be typed short, then lengthened by a global change in
>the editor.

In your Java code how are people (or are they) distinguishing object
member variables from local variables, and both from function
parameters. In my own code so far I'm borrowing the "m_" notation from
MFC, but I'd like to use the Java standard, even if it's de facto.
----------------------------------------------
Ralph Richard Cook's Java Opinions and Applets
http://personal.atl.bellsouth.net/atl/r/a/ralphc/java/

Leo Bellew

unread,
Aug 9, 1997, 3:00:00 AM8/9/97
to

In math and science, the formal manipulation of a formula is
important, and the rules for finding a solution by manipulating the
formula are independent of the meaning of the variables, except
perhaps for their numerical type. It makes sense that the formula use
short, abstract names to illuminate the formula's essence.

In business programming, the meaning of the variables is more at issue
than the abstract algorithmic manipulations. In this case, the "type"
tends to be the noun: date, amount, quota, ratio, percent, ... These
go at the end of the phrase in English:

SalesDate ExpenseDate
SalesAmount ExpenseAmount
SalesQuota ExpenseRatio

It is always possible to objectify these:

Sales.Date Expense.Date
Sales.Amount.Dollars Expense.Amount.Dollars
Sales.Amount.Marks Expense.Amount.Marks
Sales.Quota Expense.Ratio

In systems programming, the machine properties of the variable are
more important than in either math/science or business. Here it makes
sense to talk about long pointers and abbreviate that as "lp" and put
it at the front of the variable. Here Hungarian seems really helpful.

Leo


On 07 Aug 1997 11:43:22 -0400, Chris Paris <c...@cmu.edu> wrote:

>mcov...@aisun1.ai.uga.edu (Michael Covington) writes:
>
>> I do something similar:
>>
>> i, j, k, m, n are temporary integers or loop counters (note: not l)
>>
>> c, d are temporary chars
>>
>> s, w are temporary strings (how I arrived at w I'm not sure)
>>
>> x, y, z, t, t1, t2... are temporary floats or doubles
>
>Note that such conventions are pervasive in mathematics and physical
>sciences. I'm not sure what to deduce from that, but at least these
>conventions have been around for a long time. Perhaps our problem is
>that every programmer has her own personal conventions for these
>"local" variable names, whereas in other disciplines the short
>symbolic names tend to have a standard meaning.
>
>Chris


Tom Valesky

unread,
Aug 10, 1997, 3:00:00 AM8/10/97
to

Patrick Doyle (doy...@ecf.toronto.edu) wrote:

: I think having to look up a variable's declaration is a small price to
: pay for code readability.

: Code readability is highly underrated, in my opinion.

I agree, strongly. Of course, it's possible to write unreadable code even
without Hungarian notation, but variables named, say, glpszName are
guaranteed to be unreadable. It gets really interesting when
organizations start tacking on extra "helpful" information. It gets even
more interesting when combined with an environment like MS Windows, where
the number of types available seems to grow without bound.

I once worked at a shop that was so bitten by the Hungarian bug that the
following code
for (i = 0; i < 10; i++)
wasn't allowed past a walkthrough until it was changed to
for (ii = 0; ii < 10; ii++)


--
===========================================================================
Tom Valesky -- tval...@patriot.net
http://www.patriot.net/users/tvalesky

Patrick Doyle

unread,
Aug 10, 1997, 3:00:00 AM8/10/97
to

In article <33EC1699...@scruz.net>,

Scott Stanchfield <the...@scruz.net> wrote:
>
>One of the biggest points of OO programming is encapsulation -- you
>shouldn't _care_ about the details, only the interface, if things are
>designed well.

I agree with what you said, and I don't like Hungarian notation.
But the fact is that types are all about interfaces, so putting
type information in a variable could arguably still be important
in OOP, if it's done properly.

But I don't want to develop this idea any further because I might
just have to start using HN. :-)

Gerry Quinn

unread,
Aug 10, 1997, 3:00:00 AM8/10/97
to

I like to use m_Blah for most member variables, but for certain common things
like controls, images or sounds I use but_Blah, gif_Blah, or au_Blah.

Local variables are lowerUpper, and classes are UpperUpper in C++. Java
annoys me a bit when it uses my local variable convention for methods - I
still haven't settled on what I want to do here.

- Gerry

==================================================================
Mailto: ger...@indigo.ie (Gerry Quinn)
Original puzzlers (Windows or Amiga)-> http://indigo.ie/~gerryq
==================================================================

Jeffrey C. Dege

unread,
Aug 10, 1997, 3:00:00 AM8/10/97
to

On Sun, 10 Aug 1997 15:13:47 GMT, Patrick Doyle <doy...@ecf.toronto.edu> wrote:
>In article <33EC1699...@scruz.net>,

>But the fact is that types are all about interfaces, so putting
>type information in a variable could arguably still be important
>in OOP, if it's done properly.

Except, of course, that if you are doing OOD correctly, you end up
with a very rich type system. The problem with HN, as implemented
by Microsoft, isn't that they embed type information in their
variables, but that all of their variables are low-level machine
types. They could define a window handle as an instance of
a window handle type, and define wh as a window handle HN prefix.
Seeing whXxxx might then tell me something useful. Instead, of course,
Microsoft defines a window handle as an instance of a long int, and
names window handles as lXxxx, which tells me absolutely nothing.
Can I use an lXxxx anywhere I can use a long? To what purpose?
Can I use any long as a window handle? What will happen if I try?

--
"[I]n fact, I didn't know that cats _could_ grin."
"They all can," said the Duchess; "and most of 'em do."
"I don't know of any that do," Alice said very politely, feeling quite
pleased to have gotten into a conversation.
"You don't know much," said the Duchess; "and that's a fact."


Ell

unread,
Aug 10, 1997, 3:00:00 AM8/10/97
to

Doug Frietchen (fri...@erols.com.NOSPAM) wrote:
:
: IMHO, deducing the type from first char was more dangerous than

: useful. If you made a typo, rather than give you an error message,
: suddenly you had a new variable set to 0 !

If I mistype a variable's name in my C++ definition code, I get compile,
or link error.

Dean Roddey

unread,
Aug 10, 1997, 3:00:00 AM8/10/97
to

Patrick Doyle wrote:
>
> In article <33EC1699...@scruz.net>,
> Scott Stanchfield <the...@scruz.net> wrote:
> >
> >One of the biggest points of OO programming is encapsulation -- you
> >shouldn't _care_ about the details, only the interface, if things are
> >designed well.
>
> I agree with what you said, and I don't like Hungarian notation.
> But the fact is that types are all about interfaces, so putting
> type information in a variable could arguably still be important
> in OOP, if it's done properly.
>

As I pointed out in a previous post on this thread, a 'family prefix' is
exactly what you are talking about and what I use. Every class derived
from the base window class uses 'wnd', every class derived from the base
string class uses 'str'. This provides a lot of self documenting code,
without losing any encapsulation because the prefix represents the same
level of abstraction as is being modelled.

Only if a very few places, where a derived class becomes VERY
specialized and potentially spawns its own family of derivatives will I
give it a new prefix. I've only done that a couple times in my whole
system.

This scheme keeps prefixes down to a quite manageable number, but it
makes it obvious what family of classes an object belongs to (and
therefore what its basic interface and capabilities are.)

Those folks who say "Just use the browser" must not be working on large
scale systems. That browser information generation can add significantly
to the build time of every rebuild if the system is large. Its just not
worth it for me. And, it kind of ignores the fact that often times code
is read outside of any built system, such as code review meetings or on
an airplane to a customer site or whatever.

In general, a lot of the anti HN arguments tend to be reactions to bad
use of it by someone else, which is also a lot of the arguments for why
Java can't do something (because someone misused in C++.) I never find
these arguments very compelling personally. Some people put their own
eyes out with kitchen utensils, but I prefer to use them because they
make it a lot easier for me to eat when used correctly.

John A. Grant

unread,
Aug 10, 1997, 3:00:00 AM8/10/97
to

Adrian Milliner <adr...@NOSPAMrefine.co.uk> wrote in article
<33e98a49....@news.ftech.net>...

> On Wed, 06 Aug 1997 19:58:24 GMT, "John Burton" <j...@mail.com> wrote:
>
> >Do you really have so many variable that you can't remember
> >what they do? I'd suggest doing a bit more design on your
> >code.
>
> It does happen, ever so often, that a large number of variables are
> required. Many classes with many member variables. C code with struct
> members. Even plain old globals.
>
> In fact, just about every project I've ever worked on had many
> hundreds, if not many thousands of variables (member or otherwise).
>
> Occasionally, in really bizarre cases, more than one person works on a
> project, so there could be variables that you would have no knowlege
> of.
>
> From the comment you made, it sounds like you've never actually worked
> on a project bigger than "hello, world".
>
> Of course if you were refering to local(auto) variables, then your
> point is well made and I apologise for my sarcasm. But I doubt it,
> somehow.
I wouldn't say a code redesign is necessary if there is confusion
with the variable names. Usually, all that is required is a little more
common sense in choosing variable names.

Personally, I think Hungarian notation sucks and I work on 100k+ loc
projects, not 'hello world'. Admittedly, I'm the only one writing the code,
so I can get away with it. I'm in the fortunate position of not having
these silly things imposed upon me by 'project standards'. And I don't
think anyone would have any difficulties in understanding my code
because of variable names.

I find it very difficult to believe that people need to use things like
'lpszfilename' (i.e. as in Windows) to indicate that it is a 'long pointer
to a zero-terminated string'. I mean really, could 'filename' be anything
but a 'char pointer' or 'char array'? Nobody in their right mind would
mistake 'filename' for any kind of integer or float or object.

The concept of using an 'n' prefix to indicate an integer:
for(int ncount=0;ncount<...

is absolutely ludicrous. Almost everyone is familiar with math terminology
that routinely uses i,j,k for subscripts of arrays:
n m
---- ----
\ \ X
/ / i j
---- ----
i=0 j=0

and so the direct anology is to use the following
for(i=0;i<n;i++){
for(j=0;j<m;j++)
}
}

If you want to add in a bit of context, you will probably use variables
that are more specific to the application:
for(ifile=0;i<nfile;i++)... //iterating through a table of files
or
for(irow=0;irow<nrow;irow++){
for(jcol=0;jcol<ncol;jcol++){

My point is that i,j,k are traditionally used as subscripts and 'n' is
traditionally used for 'the NUMBER of things'. It makes a lot of sense:
'Nfile' is the 'Number of files', 'Nitem' is the Number of items'. It is
absurd
to use 'n' just to indicate an integer, when it can have a far more useful
role as an indicator of the 'Number' of things.Once you have painted
yourself in a corner because all variables that begin with 'n' are integers,
then you are forced to use absurd names like:
for(nfile=0;nfile<nnfile;nfile++)
or
for(n_file=0;n_file<n_nfile;n_file++)

both of which are just plain silly. Couple that with the 'm_' and 'g_'
prefixes
to indicate their scope and you have unreadable code.

And what about this mixed case variable name nonsense? To me,
constants are UPPERCASE, functions are MixedCase() & variables
are *ALWAYS* lowercase. In my mind, there is a hierarchy of
'importance' and 'volatility'. Variables are the most volatile and the
least important (to the 'flow' of the code) and usually have the
smallest scope, so they are always lowercase. At the other end
are constants, with more global scope and certainly permanency,
so they are always uppercase. Using mixed case variable names
makes it very difficult to scan code and pick out the function
calls because function calls are also MixedCase(), or in the case
of Java, mixedCase(). If you want to be able to see the 'flow' of
your code (i.e. 'active' things like function calls), then use lowercase
for variable names (so they fade into the background) and MixedCase
for function names.

And what about 'the', as in:
PICTURE thePicture=new PICTURE;
TABLE theTable= new TABLE;
URL theUrl= new URL;
DIALOG theDialog= new DIALOG;

Who started this silly practice? It reeks. Are people so lacking in
creativity and imagination that they can't choose a better variable
name? I can think of much more meaningful names:
PICTURE backgroundpic=new PICTURE;
TABLE customers= new TABLE;
URL homepage= new URL;
DIALOG about= new DIALOG;

Well, enough already. The same could be said about many of the other
absurdities I see in Hungarian notation. The unfortunate thing is that
this nonsense has run rampant in the C++ (Windows) world and is
now finding its way into Java code, making it just as unreadable as
Windows code. A common sense choice of variable names will go
a lot farther in making your code readable and understandable than
a lot of extra prefixes. If you think that this:
for(nCount=0;nCount<m_gnFile;nCount++)
TABLE g_theTable=new TABLE;
g_theTable.Add("John Doe");

is more readable or easier to type than:
for(i=0;i<nfile;i++)
TABLE customers=new TABLE;
customers.Add("John Doe");

then you have indeed gone over to the Dark Side and you are lost.

Patrick Doyle

unread,
Aug 10, 1997, 3:00:00 AM8/10/97
to

In article <5sk74p$78g$1...@news.indigo.ie>, Gerry Quinn <ger...@indigo.ie> wrote:
>I like to use m_Blah for most member variables, but for certain common things
>like controls, images or sounds I use but_Blah, gif_Blah, or au_Blah.
>
>Local variables are lowerUpper, and classes are UpperUpper in C++. Java
>annoys me a bit when it uses my local variable convention for methods - I
>still haven't settled on what I want to do here.

You can tell methods without a convention. They're the ones with
the parentheses. :-)

Incidentally...
I always thought this was a bit backwards. For example, if I get a
dog and call him Dog, then "dog" is the class and "Dog" is the instance.
The convention you refer to seems to be at odds with regular english
usage.

Matt Kennel (Remove 'NOSPAM' to reply)

unread,
Aug 10, 1997, 3:00:00 AM8/10/97
to

On Tue, 05 Aug 1997 10:59:42 -0400, Richard J Kucera <kuc...@hhmi.org> wrote:
:As someone who's actually had to maintain
:and re-use someone else's code fragments, I have to say
:that naming standards practices of indicating type in variable
:name is wasteful and unnecessary.

It *really* sucks when somebody changes the type, which is rather
frequent in a statically typed language, and doesn't bother to change the
variable name since it would be too much of a pain in all the various
pieces of code and documentation.

One of these screwups negates 100 small microwins from the type encoding.

Del Archer

unread,
Aug 10, 1997, 3:00:00 AM8/10/97
to

David Harmon wrote:
> ...

> The cannonical example being wParam and lParam in MS Windows programs.
> In the 16-bit API, wParam was a "word" (16-bit int) and lParam was a
> "long" (32-bit int). In the new 32-bit API, they are both 32 bits,
> but for some unknown reason, Microsoft overlooked changing the name of
> wParam in all their SDKs and documentation. For maximum accuracy and
> clarity, they should obviously both be named lParam.

Actually, wParam is declared as type WPARAM, not WORD. WPARAM is defined as
16-bits for Windows 3.x and 32-bits for Win32.


Del.

Chris Quartetti

unread,
Aug 11, 1997, 3:00:00 AM8/11/97
to

> What's so hard about using a global search and replace?

Nothing, but you touch more code. If somebody comes along after you and
looks at your changes by diffing the file against the previous version,
s/he'll get a much larger diff for a very small change.

-Chris

Dave Harris

unread,
Aug 11, 1997, 3:00:00 AM8/11/97
to

jag...@nrcan.gc.ca (John A. Grant) wrote:
> And what about this mixed case variable name nonsense? To me,
> constants are UPPERCASE, functions are MixedCase() & variables
> are *ALWAYS* lowercase. In my mind, there is a hierarchy of
> 'importance' and 'volatility'. Variables are the most volatile and the
> least important (to the 'flow' of the code) and usually have the
> smallest scope, so they are always lowercase. At the other end
> are constants, with more global scope and certainly permanency,
> so they are always uppercase. Using mixed case variable names
> makes it very difficult to scan code and pick out the function
> calls because function calls are also MixedCase(), or in the case
> of Java, mixedCase(). If you want to be able to see the 'flow' of
> your code (i.e. 'active' things like function calls), then use
> lowercase for variable names (so they fade into the background)
> and MixedCase for function names.

For me the difference between constant and variable is a matter of time
scale, not an absolute. Sometimes I write code using a constant and then a
later change makes it a variable. Or it's a constant that gets fixed at
runtime rather than compile time. Further, I dislike using reassignment:
I'd rather introduce a new variable than change the value of an old one,
if I can. So, once defined, my variables don't vary. The upshot is that I
don't like encoding constantness into the variable name.

My main languages are C++ and Java, and both of them require brackets
after function names so nothing further is needed to distinguish them. I
like Eiffel's convention of putting classname into upper case, though.
Class names carry a lot of information so it's good to make them stand
out. This is especially true for readers who don't know the language very
well (eg when posting code on Usenet). Also, in languages that allow
variables to be declared at the point of first use, the declarations can
get lost in the midst of other code.

I don't really agree about the relationship between global scope and
permanency. I do think that scope is worth distinguishing in names.

Dave Harris, Swansea, UK | "Weave a circle round him thrice,
bran...@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."

Alf P. Steinbach

unread,
Aug 11, 1997, 3:00:00 AM8/11/97
to

Dave Harris wrote:
>
> jag...@nrcan.gc.ca (John A. Grant) wrote:
> > And what about this mixed case variable name nonsense? To me,
> > constants are UPPERCASE, functions are MixedCase() & variables
> > are *ALWAYS* lowercase. In my mind, there is a hierarchy of
> > 'importance' and 'volatility'. Variables are the most volatile and the
> > least important (to the 'flow' of the code) and usually have the
> > smallest scope, so they are always lowercase. At the other end
> > are constants, with more global scope and certainly permanency,
> > so they are always uppercase. Using mixed case variable names
> > makes it very difficult to scan code and pick out the function
> > calls because function calls are also MixedCase(), or in the case
> > of Java, mixedCase(). If you want to be able to see the 'flow' of
> > your code (i.e. 'active' things like function calls), then use
> > lowercase for variable names (so they fade into the background)
> > and MixedCase for function names.
>
> For me the difference between constant and variable is a matter of time
> scale, not an absolute. Sometimes I write code using a constant and then a
> later change makes it a variable. Or it's a constant that gets fixed at
> runtime rather than compile time. Further, I dislike using reassignment:
> I'd rather introduce a new variable than change the value of an old one,
> if I can. So, once defined, my variables don't vary. The upshot is that I
> don't like encoding constantness into the variable name.

I think John was talking about #define constants, e.g. in C. There's a
good reason to always use uppercase for macro names, and only for them:
it partitions the name space so you cannot accidentally write some
non-macro code which a macro (you don't know about) will change. But
the best thing is, of course, to avoid macros where C++ has syntactic
support, e.g. constants. Unfortunately, C'isms won't disappear...

My personal style is like this:


Macro: ALL_UPPERCASE_SO_TO_BETTER_AVOID_USING_THEM
Function: MixedCase,
because functions can and *do* appear
with no argument list, and want to know when.
var, type, const: this_style_is_simply_best
some pointers: p_whatever, pp_whatever
the p_ prefix is sometimes useful, but most often redundant!
loop indices: i, j


The main rationale for this style is that things that can (easily)
change should not be hard-coded in name styles. So no hardcoding of
types etc.

- Alf

Nathan Fiedler

unread,
Aug 11, 1997, 3:00:00 AM8/11/97
to

Patrick Doyle wrote:
> Scott Stanchfield <the...@scruz.net> wrote:
> > One of the biggest points of OO programming is encapsulation -- you
> > shouldn't _care_ about the details, only the interface, if things are
> > designed well.
>
> I agree with what you said, and I don't like Hungarian notation.
> But the fact is that types are all about interfaces, so putting
> type information in a variable could arguably still be important
> in OOP, if it's done properly.
>
> But I don't want to develop this idea any further because I might
> just have to start using HN. :-)

I have a question for everyone: Are you basing your choice of naming
convention purely on opinion or have you read a book about this kind of
thing? I agree with Steve McConnell's argument for Hungarian Notation in
"Code Complete" and I've used it myself when writing in C. Now that I'm
writing in Java I've just been naming variables in whatever way makes
sense at the time.

I have yet to be confused about which variables are local, member
variables, methods, or parameters. I suppose it's because, as one
gentleman said, there are so few variables within the scope of any given
method that it would be difficult to lose track of their meaning. At the
same time I agree that Java could use a simple convention for
distinquishing methods from member variables. Currently they are named
using the same lowerUpper convention with no other distinction. In
contrast, GEOS uses a very strict convention for naming instance fields
and message names, making it impossible to mistake what a variable or
message is for.

Nathan Fiedler

Patrick Doyle

unread,
Aug 11, 1997, 3:00:00 AM8/11/97
to

In article <5sl66p$dlb$3...@news2.digex.net>, Ell <e...@access2.digex.net> wrote:
>Doug Frietchen (fri...@erols.com.NOSPAM) wrote:
>:
>: IMHO, deducing the type from first char was more dangerous than
>: useful. If you made a typo, rather than give you an error message,
>: suddenly you had a new variable set to 0 !
>
>If I mistype a variable's name in my C++ definition code, I get compile,
>or link error.

Hey, um, do you think that's because C++ doesn't deduce the type
from the first character?

Just a thought.

Jonas Andersson

unread,
Aug 12, 1997, 3:00:00 AM8/12/97
to

On Sat, 09 Aug 1997 12:52:44 -0700, kdlitwak <kdli...@concentric.net>
wrote:

I used to append the tyoe of the variable to the name but nowadays I
don't. Instead, I write short methods 20 lines max avg 5 lines(fast
check up is possible with this visibility). I also use 2 prefixes one
for attributes, m, and one for associations, a.
I notice that in 95% of the cases there is never any confusion/need to
know about the type of the object and if it is a need to know then the
object is so important that you should take a look at the object
diagram.

Jonas

---------------------------
Jonas Andersson
E-mail: jonas.a...@adiuvabo.se

Patrick Doyle

unread,
Aug 12, 1997, 3:00:00 AM8/12/97
to

In article <memo.19970811...@btinternet.com>,

Dave Harris <bran...@cix.co.uk> wrote:
>
>My main languages are C++ and Java, and both of them require brackets
>after function names so nothing further is needed to distinguish them. I
>like Eiffel's convention of putting classname into upper case, though.
>Class names carry a lot of information so it's good to make them stand
>out. This is especially true for readers who don't know the language very
>well (eg when posting code on Usenet).

I agree with your comments about Eiffel. I didn't like the convention
at first, because there's the problem of finding variable names which
should be the same as the class name. That is, if your CAR class contains
an instance of a STEERING_WHEEL class, why call it anything other
than steering_wheel? It makes no sense to come up with a contrived
name like direction_changer. It's the car's steering wheel, so call
it that.

In C++, typically the class would be CSteeringWheel and the
variable could be SteeringWheel or steeringWheel. In fact, being
case-sensitive, the class could be steeringWheel and the variable
could be SteeringWheel. No problem.

Then I discovered that Eiffel lets you have a variable with the
same name as a class, which I think is fantastic.
Languages that disallow this are IMHO solving a problem
that doesn't exist.

(It seems that every time I learn more about Eiffel, I think to
myself "if I were designing the language, that's how I would
have done it!" Except of course for the total lack of superclass
encapsulation. :-)

Jonas Andersson

unread,
Aug 12, 1997, 3:00:00 AM8/12/97
to

On 07 Aug 1997 11:43:22 -0400, Chris Paris <c...@cmu.edu> wrote:

>mcov...@aisun1.ai.uga.edu (Michael Covington) writes:
>
>> I do something similar:
>>
>> i, j, k, m, n are temporary integers or loop counters (note: not l)
>>
>> c, d are temporary chars
>>
>> s, w are temporary strings (how I arrived at w I'm not sure)
>>
>> x, y, z, t, t1, t2... are temporary floats or doubles
>
>Note that such conventions are pervasive in mathematics and physical
>sciences. I'm not sure what to deduce from that, but at least these
>conventions have been around for a long time. Perhaps our problem is
>that every programmer has her own personal conventions for these
>"local" variable names, whereas in other disciplines the short
>symbolic names tend to have a standard meaning.
>
>Chris

Having studied the physics and mathematics, I think that this is a
major problem of respective fields.
You cannot understand a formula without:

1. Prior knowledge about the problem. Familiarity with the common
domain names.

2. Explanatory text.

I think that the main reason for this is historical i,e that
mathematicians used hanwriting and simplifyind formulas. IMHO it
doesn't justify the unclearity of formulas presented in textbooks now.
A simp,le search replace operation in a textbook would add a lot of
clarity.

Jonas Andersson

unread,
Aug 12, 1997, 3:00:00 AM8/12/97
to

On 9 Aug 1997 05:35:41 GMT, e...@access1.digex.net (Ell) wrote:


>
>What's so hard about using a global search and replace?

I can by accident have used the same variable name in several places,
local variables, and only changed the type of one.

William Harris

unread,
Aug 12, 1997, 3:00:00 AM8/12/97
to

In article <33EF3788...@earthlink.net.remove>,
nfie...@earthlink.net.remove says...

>thing? I agree with Steve McConnell's argument for Hungarian Notation in
>"Code Complete" and I've used it myself when writing in C. Now that I'm
>writing in Java I've just been naming variables in whatever way makes
>sense at the time.

"One benefit to using Hungarian names is that it makes it easier to decipher
pointer expressions." (from Maguire's Writing Solid Code, a book that scares
me as much as it encourages me about Microsoft programming practices. :-)

I tend to agree that in a Windows environment, it can become a lot more
important to tell at a glance whether something is an lpsz, or whether a
particular variable is a hwnd. That, I think, may be the single biggest
reason why so many people adopted it.

But I find it harder to argue for it in a Java environment, for many of the
same reasons others have given.
--
William Harris wil...@carsinfo.com
Check out the NAGS spam filter. http://www.cs.hmc.edu/~ivl/nags/index.html


Michael Davis

unread,
Aug 12, 1997, 3:00:00 AM8/12/97
to

In article <5sq7ci$d7h$1...@malgudi.oar.net>,

William Harris <wil...@carsinfo.com> wrote:
>In article <33EF3788...@earthlink.net.remove>,
>nfie...@earthlink.net.remove says...

>>thing? I agree with Steve McConnell's argument for Hungarian Notation in
>>"Code Complete" and I've used it myself when writing in C. Now that I'm
>>writing in Java I've just been naming variables in whatever way makes
>>sense at the time.
>
>"One benefit to using Hungarian names is that it makes it easier to decipher
>pointer expressions." (from Maguire's Writing Solid Code, a book that scares
>me as much as it encourages me about Microsoft programming practices. :-)
>
>I tend to agree that in a Windows environment, it can become a lot more
>important to tell at a glance whether something is an lpsz, or whether a
>particular variable is a hwnd. That, I think, may be the single biggest
>reason why so many people adopted it.
>
>But I find it harder to argue for it in a Java environment, for many of the
>same reasons others have given.

I agree. Hungarian notation was introduced by a Microsoft employee.
If you've ever done Windows programming, and looked at the windows.h file,
you'll see that there are dozens of types defined that mostly all reduce
down to an unsigned integer ( e.g. HWND ), or a pointer to void.

That makes it easy to make mistakes like passing a handle to a palette
to a function that expects a handle to a window, or whatever. The compiler
can't catch such mistakes when everything is typedef'd to an
unsigned int or a void pointer.

In that kind of environment, Hungarian names help prevent some mistakes.
In Java, and in other C++ GUI environments which have truly different
types instead of different names for the same type, Hungarian names
are less useful because the compiler will catch many more type-related
problems.

Regards,

--
// Michael Davis, Programmer/Analyst I don't speak for Multipath. //
// mda...@DELmultipath.com Nor do I speak against them. //
// Toronto The 'DEL' in my address is an anti-spam device. //

Warren Young

unread,
Aug 12, 1997, 3:00:00 AM8/12/97
to

sou...@netcom.com (David Harmon) wrote:

>On Fri, 08 Aug 1997 23:53:38 -0500, "Robert C. Martin"
><rma...@oma.com> wrote:
>>redundant and supplies little benefit. On the other hand, that
>>info is a rather large liability since if must be changed if the
>>variable type ever gets changed. The impact of such a change is
>>so high that often the variable name *will not* be changed even though
>>the type is.

>
>The cannonical example being wParam and lParam in MS Windows programs.
>In the 16-bit API, wParam was a "word" (16-bit int) and lParam was a
>"long" (32-bit int). In the new 32-bit API, they are both 32 bits,
>but for some unknown reason, Microsoft overlooked changing the name of
>wParam in all their SDKs and documentation. For maximum accuracy and
>clarity, they should obviously both be named lParam.

This sort of issue is responsible for the latest evolution in my
naming style. Way back when, I started with a milder form of
Hungarian. As time went on, I found what a pain it was to keep
inventing new, nonconflicting, short type abbreviations. I also found
that it didn't help all that much, and that it tended to lower the
level of abstraction in the code.

Recently, I've adopted this form:

p = pointer
a = array
2, 3, etc. = array dimension
c = character
s = string (C++ string type, not char*, which is "pc")
n = numeric type
e = enumerated type
k = constant, usually integral, although kpc is also used.
g = global

and that's it [1]. Notice that the notation avoids primitive types.
Except for "pc" versus "s" (discussed below), this notation is largely
language and platform independent. These prefixes are mostly
modifiers and general classifiers, rather than actual type
information.

As for type information, I find that if you need that at all, you just
need an "abstract" type in the variable name proper. So instead of
pbmpFoo (pointer to bitmap foo), you get pFooBitmap. I make sure to
keep the abstract nature of this form in mind. For example, I never
say FooVector, preferring FooList, because it lets me change the type
(within reason) and not have to rename all of the variables.

The limited "Hungarian" form (I guess I should call it
"Hungarian-American", since it's been so diluted <grin>) I use has
these advantages:

1. It makes it easy to tell what general class of operations are valid
for a particular variable. The "p" and "a" prefixes are especially
useful, because they help keep the dereferences straight -- this is
critical in C++, where a language like Java doesn't have this need.
As an example, consider a 2-D array of pointers to bitmaps. (Yes,
I've used constructs like this!) The variable is a2pFooBitmap.
Without this minimal amount of type encoding, you have to constantly
keep looking up the declaration to make sure everything is consistent.
The notation really proves its value when you begin mixing levels of
indirection.

2. The "n" prefix lets me know that a variable can be manipulated with
arithmetic.

3. The "k" type lets me know that an entity is constant. In a way,
it's my C++ way of saying what I would have said with an ALL-CAPS
#define in C. Also, "k" alone implies "kn", because other types of
constants use modifiers. Also, I only use "k" for global constants,
rather than for constant parameters. I may evolve this quirk out
soon, however.

4. The "e" prefix is similar to "n", but it lets me know that while a
value is basically numeric, it has a strict range of named values that
are legal for it, so it throws red flags when I say something like
"eFoo = nBar;". Also note that the _members_ of the enumerated type
are prefixed with "k", because they are. B-) So, we have "enum Foo {
kBar, kBaz } eQux = kBar;"

5. The "pc" and "s" types let me know what kind of string I'm dealing
with. This is simply a "transitional" C/C++ thing that probably has
no use in other languages. Maybe "pc" will die some day. (No, that's
not a triple entendre. I promise. B->)

6. The "g" type lets me know where a given variable is. If you also
use m_ or a trailing _ for member variables, hunting is largely
eliminated, and this can only be a good thing.

In sum, this to me is just one of those good disciplines that keeps
your mind nicely focused on the task at hand, rather than on the
niggling details of the mechanisms. Once you use this form for a
while, the prefixes become second-nature and comforting. It off-loads
a lot of type mixing anxiety, because it's easy to verify that the
types are interacting properly. "Classic Hungarian", on the other
hand, seems almost exactly opposite to this: you spend all your time
appeasing the notation, rather than thinking about the problem.

[1] I've also been experimenting with a trailing _ for member
variables (m_ looks horrid to me).

= Warren -- http://www.cyberport.com/~tangent/
=
= Remove the SPAMCATCHER to email. -- Finger me!

Jeff Miller

unread,
Aug 12, 1997, 3:00:00 AM8/12/97
to

e...@access1.digex.net (Ell) writes:

>Robert C. Martin (rma...@oma.com) wrote:

> On the other hand, that
>: info is a rather large liability since if must be changed if the
>: variable type ever gets changed. The impact of such a change is
>: so high that often the variable name *will not* be changed even though
>: the type is.

>What's so hard about using a global search and replace?

But what if your Hungarian notation is used in the naming of
an element of a structure that is defined in a header file?
You have absolutely no way of knowing who is using that file
in their code. Accordingly, you have no way of knowing what
code to examine with your global search and replace.

Jeff Miller
Terrapin Technologies, Inc.
jmi...@cycletime.com
http://www.cycletime.com


Peter Eddy

unread,
Aug 13, 1997, 3:00:00 AM8/13/97
to Ralph Richard Cook

This is a multi-part message in MIME format.
--------------3B55D15B811ADC275139E27B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'm really fond of the m_ notation for member variables myself. I
particularly like how the following code reads:

public void setColor( Color color ) { m_color = color; }

That is to say, you don't have to invent a name for the parameter that
is less descriptive than the member variable name and you don't have to
resort to the clumsy and probably error prone "this.color = color".

My only reserveration is that the '_' is hard to type.

Peter

Ralph Richard Cook wrote:
>
> In your Java code how are people (or are they) distinguishing object
> member variables from local variables, and both from function
> parameters. In my own code so far I'm borrowing the "m_" notation from
> MFC, but I'd like to use the Java standard, even if it's de facto.

--
Peter Eddy
Folding Chair Software
Columbus Ave.
Boston, MA
http://www.ziplink.net/~petere/fcs.html
pet...@bigfoot.com
--------------3B55D15B811ADC275139E27B
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Peter Eddy
Content-Disposition: attachment; filename="vcard.vcf"

begin: vcard
fn: Peter Eddy
n: Eddy;Peter
org: Folding Chair Software
email;internet: pet...@bigfoot.com
title: Contractor
x-mozilla-cpt: ;0
x-mozilla-html: TRUE
end: vcard


--------------3B55D15B811ADC275139E27B--


Ma...@mwilden.com

unread,
Aug 13, 1997, 3:00:00 AM8/13/97
to

Aaron D. Wieland wrote:

>
> On Wed, 13 Aug 1997 09:44:03 -0400, Peter Eddy <pet...@bigfoot.com>
> wrote:
> >I'm really fond of the m_ notation for member variables myself. I
> >particularly like how the following code reads:
> >
> >public void setColor( Color color ) { m_color = color; }
> >
> >That is to say, you don't have to invent a name for the parameter that
> >is less descriptive than the member variable name and you don't have to
> >resort to the clumsy and probably error prone "this.color = color".

It does indeed appear to be error prone. :) I gave the m_ notation a try
for a while (together with the rest of Microsoft's pseudo-Hungarian),
but reverted back to natural variable names on my current project, and I
haven't missed it.

> >
> >My only reserveration is that the '_' is hard to type.
>

> Alternately, if you don't use the m_ notation, you can write the code
> as:
>
> public void setColor( Color aColor ) { color = aColor; }

I use

public void setColor(Color color) { this->color = color; }

Yes, it's more typing, but I don't have to think of an artificial
variable name.

In a constructor's base/member init-list, this isn't even necessary,
since you can do

Class::Class(Color color) : color(color) {}

Aaron D. Wieland

unread,
Aug 13, 1997, 3:00:00 AM8/13/97
to

On Wed, 13 Aug 1997 09:44:03 -0400, Peter Eddy <pet...@bigfoot.com>
wrote:
>I'm really fond of the m_ notation for member variables myself. I
>particularly like how the following code reads:
>
>public void setColor( Color color ) { m_color = color; }
>
>That is to say, you don't have to invent a name for the parameter that
>is less descriptive than the member variable name and you don't have to
>resort to the clumsy and probably error prone "this.color = color".
>
>My only reserveration is that the '_' is hard to type.

Alternately, if you don't use the m_ notation, you can write the code
as:

public void setColor( Color aColor ) { color = aColor; }

I.e., you avoid using a less descriptive name by prepending an article
to the parameter. This convention is particularly common among
Smalltalk programmers.

-- Aaron Wieland


Tran Phan Anh

unread,
Aug 14, 1997, 3:00:00 AM8/14/97
to

Aaron D. Wieland wrote:
>
> On Wed, 13 Aug 1997 09:44:03 -0400, Peter Eddy <pet...@bigfoot.com>
> wrote:
> >I'm really fond of the m_ notation for member variables myself. I
> >particularly like how the following code reads:
> >
> >public void setColor( Color color ) { m_color = color; }
> >
> >That is to say, you don't have to invent a name for the parameter that
> >is less descriptive than the member variable name and you don't have to
> >resort to the clumsy and probably error prone "this.color = color".
> >
> >My only reserveration is that the '_' is hard to type.
>
> Alternately, if you don't use the m_ notation, you can write the code
> as:
>
> public void setColor( Color aColor ) { color = aColor; }

I use this convention, and I find it to be a very convenient
convention. A quick look, and one knows where the variable came from
right away. That's the only variable name decoration I use. Otherwise,
I find 'type decorations' on variables name to be a really disgusting
practice.

Anh

Jonas Andersson

unread,
Aug 14, 1997, 3:00:00 AM8/14/97
to

On Wed, 13 Aug 1997 19:43:05 GMT, awie...@turing.scs.carleton.ca
(Aaron D. Wieland) wrote:

>On Wed, 13 Aug 1997 09:44:03 -0400, Peter Eddy <pet...@bigfoot.com>
>wrote:
>>I'm really fond of the m_ notation for member variables myself. I
>>particularly like how the following code reads:
>>
>>public void setColor( Color color ) { m_color = color; }
>>
>>That is to say, you don't have to invent a name for the parameter that
>>is less descriptive than the member variable name and you don't have to
>>resort to the clumsy and probably error prone "this.color = color".
>>
>>My only reserveration is that the '_' is hard to type.
>
>Alternately, if you don't use the m_ notation, you can write the code
>as:
>
>public void setColor( Color aColor ) { color = aColor; }
>

>I.e., you avoid using a less descriptive name by prepending an article
>to the parameter. This convention is particularly common among
>Smalltalk programmers.
>
>-- Aaron Wieland
>

I personally think that the aColor, or anObject, convention is a bad
idea. The name as used in Smalltalk usually is a poor substitue for
lack of tye definition. I prefer the use of a meaningful name and the
m prefix as in:

public void setColor(Color newColor) {mColor=newColor;}

Just my point of view.

Ma...@mwilden.com

unread,
Aug 14, 1997, 3:00:00 AM8/14/97
to

Patrick Doyle wrote:
>
> In article <5sch5e$ekv$3...@news2.digex.net>, Ell <e...@access5.digex.net> wrote:
> >Ma...@mWilden.com wrote:
> >:
> >: I have no problem using nChickens to designate the number of chickens in
> >: a program, because I usually don't care what its internal representation
> >: is. At some point, I did, so I made it an unsigned char, unsigned int,
> >: unsigned short, unsigned long or whatever. But having made that choice,
> >: the rest of the application doesn't have to cart around this baggage
> >: every time I use the variable--it just needs to know that nChickens
> >: counts chickens.
> >
> >But how about the possibility that you will corrupt the integrity of the
> >meaning of the data in the variable if you assign for example an
> >unsigned value to a signed variable?
>
> *Even C* should warn you about that one. And for types that are truly
> incompatible, it won't work anyway.

Dang. Lately it seems that my newserver has been missing more messages
than it's getting! Anyway, thanks Patrick, for giving the answer I'd
have given.

Also, WRT signed/unsigned, a count (of chickens, e.g.) is by its nature
unsigned. I don't need to specify this in the variable name. I just need
to indicate that the variable holds the number of chickens.

Ma...@mwilden.com

unread,
Aug 14, 1997, 3:00:00 AM8/14/97
to

Ell wrote:
>
> Hugarian sure helps me as the programmer writing the code which is sent to
> the compiler. You being one who is often railing against having to
> re-compile, should see that one shouldn't wait for a compile or link to
> find an error.

Frankly, this kind of error doesn't happen that much in my experience.
Certainly not as often as leaving out a paren. :) Maybe it's because
most variables are either data members, whose type and purpose is part
of the design, and hence well understood, or locals/parameters, whose
type I can determine (if it's not obvious, which it usually is) just by
looking a few lines back in the source.

I've given Hungarian a shot, but it didn't catch many errors compared to
the amount of time it takes to implement it for every single variable
name use.

> What's so hard about using a global search and replace?

It's not hard, but it does have drawbacks. For example, let's say I
decide that my unsigned char isn't large enough any more to count the
number of chickens on my farm and I change it to an unsigned int. I
globally search and replace to change the variable name. Now, I'd have
to recompile everything anyway, so that's not the issue. But now every
file in my project appears changed and I can no longer use a directory
listing to see what files I should update my colleagues with. I have to
zip up the whole damn thing.

It gets even worse if I'm using version control on a multiprogrammer
project. I've got to get everyone to check everything in (which means
they have to give me compilable code), then check everything out, do the
s&r, then check everything in. The automatic merging features I've seen
on PC platforms, at least, aren't very good at identifying changed
lines.

So while making massive s&r's on smaller, one-programmer projects is
viable, it doesn't scale up well.

Ell

unread,
Aug 14, 1997, 3:00:00 AM8/14/97
to

Ma...@mWilden.com wrote:
:

If you wanted to note the count 3 gigs and expected that a variable would
hold such a count, you'd have a problem with a signed int.

Also if you were making a calculation that went negative and assigned it
to an unsigned int, you'd likely have a problem.

Elliott
--
"The domain object model is the foundation of OOD."
"We should seek out proven optimal practices and use them."
See SW Modeller vs SW Pragmatist Central: http://www.access.digex.net/~ell

Ell

unread,
Aug 14, 1997, 3:00:00 AM8/14/97
to

Tom Keane (tke...@cts.com) wrote:
:
: Elliott wrote:
: >

: > Someone wrote:
: > : Also, WRT signed/unsigned, a count (of chickens, e.g.) is by its nature
: > : unsigned. I don't need to specify this in the variable name. I just
: > : need
: > : to indicate that the variable holds the number of chickens.

: > If you wanted to note the count 3 gigs and expected that a variable would
: > hold such a count, you'd have a problem with a signed int.
: >
: > Also if you were making a calculation that went negative and assigned it
: > to an unsigned int, you'd likely have a problem.

: I don't know, Elliott, you're almost starting to sound a bit pragmatic....
: ;-)

I'm really in deep kimshee now aren't I? ;-}

I like dealing with "practical" matters, but:

1) By understanding that there is an objective domain object model (DOM)
for whatever context, or level, is being considered, and

2) By expressing that DOM in OOD (with or without helper classes)

It's fairly easy to avoid being a pragamtist/empiricist.

Cheers,

Tom Keane

unread,
Aug 14, 1997, 3:00:00 AM8/14/97
to

> :
> : Also, WRT signed/unsigned, a count (of chickens, e.g.) is by its nature
> : unsigned. I don't need to specify this in the variable name. I just
need
> : to indicate that the variable holds the number of chickens.
>
> If you wanted to note the count 3 gigs and expected that a variable would
> hold such a count, you'd have a problem with a signed int.
>
> Also if you were making a calculation that went negative and assigned it
> to an unsigned int, you'd likely have a problem.
>

> Elliott
> --
> "The domain object model is the foundation of OOD."
> "We should seek out proven optimal practices and use them."
> See SW Modeller vs SW Pragmatist Central:
http://www.access.digex.net/~ell
>
>

I don't know, Elliott, you're almost starting to sound a bit pragmatic....
;-)

Tom Keane


David Brower

unread,
Aug 14, 1997, 3:00:00 AM8/14/97
to

ct...@probe.net (Jeff Miller) writes:
>e...@access1.digex.net (Ell) writes:
>>Robert C. Martin (rma...@oma.com) wrote:

>> On the other hand, that
>>: info is a rather large liability since if must be changed if the
>>: variable type ever gets changed. The impact of such a change is
>>: so high that often the variable name *will not* be changed even though
>>: the type is.

>>What's so hard about using a global search and replace?

>But what if your Hungarian notation is used in the naming of


>an element of a structure that is defined in a header file?
>You have absolutely no way of knowing who is using that file
>in their code. Accordingly, you have no way of knowing what
>code to examine with your global search and replace.

Which suggests you probably shouldn't be changing the type signature
of this public interface willy nilly, and ought to reconsider why
you were thinking about changing in the first place...

-dB

--
"It's hard to find a black cat in a dark room. | David Brower
Especially if the cat's not there. | dbr...@oracle.com
But we will!" | da...@acm.org

Tran Phan Anh

unread,
Aug 14, 1997, 3:00:00 AM8/14/97
to

Ie. what if you have a newcolor member variable? m_NewColor?
mPreviousColor?

It is a function argument, so let's just append an 'a' as in aColor, and
everyone who is familiar with the convention can immediately recognize a
variable as a pass-in argument. If they are not familiar with the
convention, it will take 2 seconds to introduce them.

Note that 'a' is like 'a' in 'argument' not 'a' like 'a' in the article
'a'.

Another point, member variables and methods are 'intrinsic' to a class,
so why decorate them with fluffs such as 'm' ?

I once ported a 30Kloc C program (small example) from a 32-bit
architecture to a 64-bit power beast, and even though I still mumble
about the use of integer types to store pointer values and the mix of
ints and longs in the code by the original author, I am very glad he did
not use some dumb hungarian notation.

If you design your code properly, use block scoping appropriately, and
comment the code generously, there is never a real need to append
artificial artifacts to variable names. And this is especially true for
C++ and JAVA.

Anh

Ma...@mwilden.com

unread,
Aug 14, 1997, 3:00:00 AM8/14/97
to

> > : Also, WRT signed/unsigned, a count (of chickens, e.g.) is by its nature
> > : unsigned. I don't need to specify this in the variable name. I just
> need
> > : to indicate that the variable holds the number of chickens.
> >
> > If you wanted to note the count 3 gigs and expected that a variable would
> > hold such a count, you'd have a problem with a signed int.

As I mentioned, I wouldn't use a signed int (or a float or a string) to
count chickens.

> > Also if you were making a calculation that went negative and assigned it
> > to an unsigned int, you'd likely have a problem.

If that calculation involved the number of chickens I own (assuming I'm
not worried about chickens that I owe to other people), I'd have more
problems than just the type of my variables! A negative chicken is not a
pretty sight. :)

(Dang, there's _another_ post I missed. Good thing people reply to
Elliott's stuff or I'd never see it. :(

Thaddeus L. Olczyk

unread,
Aug 15, 1997, 3:00:00 AM8/15/97
to


Ell <e...@access1.digex.net> wrote in article
<5sgvjd$oc8$3...@news2.digex.net>...


> Robert C. Martin (rma...@oma.com) wrote:
> On the other hand, that
> : info is a rather large liability since if must be changed if the
> : variable type ever gets changed. The impact of such a change is
> : so high that often the variable name *will not* be changed even though
> : the type is.
>
> What's so hard about using a global search and replace?

1) The process must be monitored. Otherwise you run the risk of
changing SlipDate to SlirDate, when you change pDate to rDate.

2) Most methods for search and replace ( generally combinations of grep awk
and sed ) on multiple files don't give you much of a chance to monitor
the changes. On anything larger then a small program it can be such a
large job, that it is impossible.

3) I've yet to see anything on a windows platform which allows me to do a
global search and replace on many, many files.

It's obvious you haven't spent much time working on large projects.
--------------------------------------------
Thaddeus L. Olczyk

Dave Harris

unread,
Aug 15, 1997, 3:00:00 AM8/15/97
to

a...@gte.net (Tran Phan Anh) wrote:
> Note that 'a' is like 'a' in 'argument' not 'a' like 'a' in the article
> 'a'.
> Another point, member variables and methods are 'intrinsic' to a class,
> so why decorate them with fluffs such as 'm' ?

I have used "myElement" and "anElement" for instance variables and
parameters respectively. This feels nice because I identify with the
object when I'm reading or writing code or comments. So I think of *my*
instance variables, which are mine and belong to me. Where as parameters
could have come from anywhere: an arbitrary element.


> If you design your code properly, use block scoping appropriately, and
> comment the code generously, there is never a real need to append
> artificial artifacts to variable names.

I don't agree about comments. Good variable names should reduce the need
for comments. Very often if you need a comment to explain what a variable
is doing, it's because the name is not vivid enough.

Dave Harris, Swansea, UK | "Weave a circle round him thrice,
bran...@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."

Tran Phan Anh

unread,
Aug 15, 1997, 3:00:00 AM8/15/97