Why has hungarian notation been abandoned?

[Phill]

Does anyone know the reasoning for Microsoft abandoning Hungarina
Notation in C#?

I have found it very usefull in C++. I like this style:

constant: MY_CONSTANT
methos: myMethod()
class: MyClass
variable: iMyInteger

Anyway I'm not crazy about the new style but wonder if there is a good
reason for them capitalizing all functions and classes and not using
hungarian notation?

[David Browne]

"Phill" <wa********@yahoo.com> wrote in message
news:ac**************************@posting.google.c om...

Does anyone know the reasoning for Microsoft abandoning Hungarina
Notation in C#?

IMO Hungarian notaion (or otherwise decorating variable names with
indications of their type and scope) is helpful in procedural languages,
which tend to use a lot of global variables, and in languages which are less
than type-safe. It is necessary to rememeber, when programming in C,
whether a variable is a pointer or an integer, and if a pointer, a pointer
to what.

Consider an array of doubles.

A common C idiom like

*(pDblLocation++)

is very hard to read without hungarian notation. In contrast, in C#

locations[i]

is quite readable as is.

David

[Derek Harmon]

"Phill" <wa********@yahoo.com> wrote in message news:ac**************************@posting.google.c om...

Anyway I'm not crazy about the new style but wonder if there is a good
reason for them capitalizing all functions and classes and not using
hungarian notation?

Developers can now take any identifier into the Immediate Window and
write,

? identifier.GetType()

and voila, you get the type of the variable. Unnatural, unpronounceable
prefixes add no value. I don't know what the Hungarian prefix for an
AutomotivePartSKU-typed object should be (it's probably something
ridiculous like 'obj', which doesn't help me tell it apart from an Aircraft-
PartSKU one bit), and I don't care. All objects in the CLR know what
Type they are, unlike in C.

My advice is not to dogmatically cling to Hungarian notation; recognize
why it was necessary in the past, and why it's no longer necessary in the
present.
Derek Harmon

[Joerg Jooss]

Phill wrote:

Does anyone know the reasoning for Microsoft abandoning Hungarina
Notation in C#?

I have found it very usefull in C++. I like this style:

constant: MY_CONSTANT
methos: myMethod()
class: MyClass
variable: iMyInteger

Anyway I'm not crazy about the new style but wonder if there is a good
reason for them capitalizing all functions and classes and not using
hungarian notation?

Funny -- this was asked in the ASP.NET group just some days ago, so I'll
repost what I've written back then:
Well, HN uses prefixes in an identifier's name depending on the identifier's
type. In a true OO environment featuring polymorphism, the exact type is
quite often unknown (just think of object factories that simply return
interface types). Actually, most of the time you don't even care abut the
real type, as long as the object complies to some sort of interface contract
(by implementing an interface or inheriting from some other class).

Next, there are potentially thousands of types -- which could mean using *a
lot* of prefixes. Oh, and once I need to change a type, I have to rename all
identifiers using that type. Hey, even worse, if it's a "visible" change
like

public int Foo(int someInt)
to
public long Foo(long someLong),

you would want to change your code as well, if you're using my Foo()
method -- any variable in your code holding Foo's return value will use the
wrong prefix otherwise.

Not to mention all those classic HN prefixes that make no sense in .NET at
all -- l, p, sz, ...

Cheers,

--
Joerg Jooss
jo*********@gmx.net

[Bob Grommes]

Hungarian is arguably much less useful in a strongly-typed environment where
the IDE typically tells you instantly what the type of a variable is.

On the other hand, if you have the goal to make code readable and
self-explanatory, I think that even in .NET the judicious use of Hungarian
prefixes is a good thing. If you just want to read code -- particularly
someone else's, or your code months after you wrote it -- a little Hungarian
frees you up to read it quicker and comprehend it better. This is true
whether you are scrolling a display or reading a printout.

I still use prefixes for all the value types and for string and
StringBuilder, which are probably the most commonly used reference types.
Beyond that, the laws of diminishing returns kick in with a vengance; there
is an infinitude of possible reference types. And consider -- if you have,
say, a Hashtable, it might be a mistake to use a reference variable like
htPeople. Suppose that you decide in some later refactoring that you need
to use a SortedList instead? The interface is virtually the same; it seems
that having to change htPeople to slPeople is a lot of work (and chance for
error) for very little benefit.

Hungarian can be used not only to show type, but scope. In an environment
like .NET there is really no reason to use prefixes for scoping of
variables; all variables are local to the method they are declared in, there
is no other scope.

Some people use an underscore or "m_" to prefix names of fields; personally
I use the same name for fields and their corresponding properties except
that the first letter is capitalized for the property and lower-case for the
field. Also, I don't prefix for variable type in fields or properties.

Another use of Hungarian can be to show the intended use of a variable.
This is probably the lease useful and most problematic application of
Hungarian in any environment; but in an OOP environment I see no real place
for it at all. OOP inherently associates values with objects, and
well-designed methods are small enough that they don't have that many local
variables. So, the usage of a given variable is always quite self-evident.

All of these are somewhat personal decisions and really it's more important
that you settle on a standard and use it consistently, than exactly what
that standard is.

--Bob

"Phill" <wa********@yahoo.com> wrote in message
news:ac**************************@posting.google.c om...

Does anyone know the reasoning for Microsoft abandoning Hungarina
Notation in C#?

I have found it very usefull in C++. I like this style:

constant: MY_CONSTANT
methos: myMethod()
class: MyClass
variable: iMyInteger

Anyway I'm not crazy about the new style but wonder if there is a good
reason for them capitalizing all functions and classes and not using
hungarian notation?

[clintonG]

You know I just tried using the GetType( ) method in the
Command Window on several different objects and all
that is returned is 'not valid.'

--
<%= Clinton Gallagher, "Twice the Results -- Half the Cost"
Architectural & e-Business Consulting -- Software Development
NET cs*********@REMOVETHISTEXTmetromilwaukee.com
URL http://www.metromilwaukee.com/clintongallagher/

"Derek Harmon" <lo*******@msn.com> wrote in message
news:u9**************@TK2MSFTNGP11.phx.gbl...

"Phill" <wa********@yahoo.com> wrote in message news:ac**************************@posting.google.c om...

Anyway I'm not crazy about the new style but wonder if there is a good
reason for them capitalizing all functions and classes and not using
hungarian notation?

Developers can now take any identifier into the Immediate Window and
write,

? identifier.GetType()

and voila, you get the type of the variable. Unnatural, unpronounceable
prefixes add no value. I don't know what the Hungarian prefix for an
AutomotivePartSKU-typed object should be (it's probably something
ridiculous like 'obj', which doesn't help me tell it apart from an

Aircraft- PartSKU one bit), and I don't care. All objects in the CLR know what
Type they are, unlike in C.

My advice is not to dogmatically cling to Hungarian notation; recognize
why it was necessary in the past, and why it's no longer necessary in the
present.
Derek Harmon

[William Ryan eMVP]

http://neopoleon.com/blog/posts/6630.aspx

--
W.G. Ryan MVP Windows - Embedded

Have an opinion on the effectiveness of Microsoft Embedded newsgroups?
Let Microsoft know!
https://www.windowsembeddedeval.com/...ity/newsgroups
"Phill" <wa********@yahoo.com> wrote in message
news:ac**************************@posting.google.c om...

Does anyone know the reasoning for Microsoft abandoning Hungarina
Notation in C#?

I have found it very usefull in C++. I like this style:

constant: MY_CONSTANT
methos: myMethod()
class: MyClass
variable: iMyInteger

Anyway I'm not crazy about the new style but wonder if there is a good
reason for them capitalizing all functions and classes and not using
hungarian notation?

[Julie]

Phill wrote:

Does anyone know the reasoning for Microsoft abandoning Hungarina
Notation in C#?

I have found it very usefull in C++. I like this style:

constant: MY_CONSTANT
methos: myMethod()
class: MyClass
variable: iMyInteger

Anyway I'm not crazy about the new style but wonder if there is a good
reason for them capitalizing all functions and classes and not using
hungarian notation?

One of the main reasons is due to the capabilities of modern development
environments, and the ability for type information to be instantly available
(in theory for some IDEs!) for any type, definition, function/method, etc.

Hungarian notation is from the early (PC) days where type information wasn't
readily available, and such prepended type 'decorations' assisted the
programmer in 'knowing' type information simply by looking at the name.

Another reason is that w/ each successive language (or library), the number of
types has (probably) exponentially increased. Hungarian notation just couldn't
keep up w/ the massive number of types being introduced.

In short, Hungarian was very useful for its time, but its time has past, and
its utility value has been steadily diminishing for the past few years...

By the way, what you have as an example above is not Hungarian notation, with
the exception of 'variable: iMyInteger'.

[Julie]

William Ryan eMVP wrote:

http://neopoleon.com/blog/posts/6630.aspx

If his book is anything like his blog style, it will be in the $.99 bin in no
time, and probably a rip-off even at that price.

[Jon Skeet [C# MVP]]

Derek Harmon <lo*******@msn.com> wrote:

"Phill" <wa********@yahoo.com> wrote:

Anyway I'm not crazy about the new style but wonder if there is a good
reason for them capitalizing all functions and classes and not using
hungarian notation?
Developers can now take any identifier into the Immediate Window and
write,

? identifier.GetType()

Or, rather more easily, just hover over the identifier.

<snip>
My advice is not to dogmatically cling to Hungarian notation; recognize
why it was necessary in the past, and why it's no longer necessary in the
present.

Agreed.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Mark Rae]

"clintonG" <cs*********@REMOVETHISTEXTmetromilwaukee.com> wrote in message
news:u8**************@tk2msftngp13.phx.gbl...

You know I just tried using the GetType( ) method in the
Command Window on several different objects and all
that is returned is 'not valid.'

Loads of stuff often doesn't work in the command window - ToString(), for
example, only works part of the time...

[Phill]

I'm not familiar w/ the immediate window. Where is it, and how do you use it?

[Phill]

I agree classes instances don't need hungarian notation and its not
practical to keep comming up with them for each class.

But for primitives I think it makes sense.

I think between:

Savings = (OrigPrice * Discount);

And

fSavings = (fOrigPrice * fDiscount);

The 2nd is better because I know fDiscount is a float and its not like
the integer value 25 for 25%. Maybe that's not the greatest example
but I think things are ambiguous otherwise. If you have a decent sized
method that you haven't seen in a while, are you saying you'd rather
determine the variable's type using the debugger than by just looking
at it?

And what about telling the difference between constants classes and
methods. The .Net Naming schema treats them all the same. Each
Beginning word is capitalized. Why not CAPS ALL CONSTANTS, or just
capitalize the 1st word in classes.

Note I'm not really arguing with you guys, I'm kinda hoping someone
can show me this newer scheme is better, because I can't seem to see
it as an improvement myself.

[Jon Skeet [C# MVP]]

Phill <wa********@yahoo.com> wrote:

I agree classes instances don't need hungarian notation and its not
practical to keep comming up with them for each class.

But for primitives I think it makes sense.

I think between:

Savings = (OrigPrice * Discount);

And

fSavings = (fOrigPrice * fDiscount);

The 2nd is better because I know fDiscount is a float and its not like
the integer value 25 for 25%.
I disagree:

1) Just as someone gave an example where the type of a variable which
was a Hashtable could change to SortedList, so the discount might need
to be changed to a double, or a decimal. Are you definitely, definitely
going to change all your code? If you don't, it's worse than not having
the type there at all.

2) It makes it harder to read, IMO. You either have to teach your brain
to skip over the letters, or you have to mentally read them every time,
which breaks up the flow (for me, anyway).
Maybe that's not the greatest example
but I think things are ambiguous otherwise. If you have a decent sized
method that you haven't seen in a while, are you saying you'd rather
determine the variable's type using the debugger than by just looking
at it?
Yes, if that means greater readability when I'm looking at the code
when I *am* familiar with what things are. You don't really need to use
the debugger - just hover over a variable to see its type.
And what about telling the difference between constants classes and
methods. The .Net Naming schema treats them all the same. Each
Beginning word is capitalized. Why not CAPS ALL CONSTANTS, or just
capitalize the 1st word in classes.
Readability. ALL_CAPS is harder to read than CapitalizingWords (it
feels like it's shouting) and ReadingCapitalizedWords is easier than
reading Lotsofwordswithnothingtosaywheretheystart.

It's very easy to tell the difference by context though - unless you're
using a delegate, a method name will always have brackets at the end of
it anyway. When you're using a delegate, it should be obvious that
you're doing so.
Note I'm not really arguing with you guys, I'm kinda hoping someone
can show me this newer scheme is better, because I can't seem to see
it as an improvement myself.

Maybe you will when you've used it for a while and then look back at
some old code. Anything new takes a little while to get used to.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[clintonG]

VS.NET > View > Other Windows > Command Window
-- or --
Debug > Windows > Immediate

Both load the same Command Window but open it in a
different mode and neither function the way it was claimed
in this discussion as two of us have learned and have noted
herein.

Some get lucky. Some do not.

--
<%= Clinton Gallagher, "Twice the Results -- Half the Cost"
Architectural & e-Business Consulting -- Software Development
NET cs*********@REMOVETHISTEXTmetromilwaukee.com
URL http://www.metromilwaukee.com/clintongallagher/

"Phill" <wa********@yahoo.com> wrote in message
news:ac**************************@posting.google.c om...

I'm not familiar w/ the immediate window. Where is it, and how do you use

it?

[Stu Smith]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Phill <wa********@yahoo.com> wrote:

I agree classes instances don't need hungarian notation and its not
practical to keep comming up with them for each class.

But for primitives I think it makes sense.

I think between:

Savings = (OrigPrice * Discount);

And

fSavings = (fOrigPrice * fDiscount);
Well I'm not a fan of Hungarian myself but I have to say that as originally
conceived, it wasn't simply a method of repeating the static type of a
variable. You can see when something is a float or an integer by looking at
the variable declaration.

Rather, it's to make the semantic type of the variable plain. For example, a
float could represent a price (as in your above example), or a ratio.

So these are fine:

amtSavings = amtOriginalPrice - amtDiscount
amtSavings = amtOriginalPrice * ratioDiscount

but these are not fine:

amtSavings = amtOriginalPrice - ratioDiscount
amtSavings = amtOriginalPrice * amtDiscount

The canonical example is indexes and counts:

for( int iWhatever = 0; iWhatever < nWhatevers; iWhatever++ )
{
// This is fine: iXXX = index
arrWhatevers[ iWhatever ] =

// This is bad: nXXX isn't an array index
arrWhatevers[ nWhatevers ] =
}

The compiler does the static type-checking (array indexer must be an
integer). The Hungarian is there to do semantic type-checking (array indexer
should be an index and not a count... or an age... or a character... etc,
all of which are integers).

So people who religiously prefix all integers with 'i' or 'n' or whatever
are really missing the point (and the power) of Hungarian.

Having said all that I still wouldn't advocate it.

Stu

The 2nd is better because I know fDiscount is a float and its not like
the integer value 25 for 25%.

I disagree:

1) Just as someone gave an example where the type of a variable which
was a Hashtable could change to SortedList, so the discount might need
to be changed to a double, or a decimal. Are you definitely, definitely
going to change all your code? If you don't, it's worse than not having
the type there at all.

2) It makes it harder to read, IMO. You either have to teach your brain
to skip over the letters, or you have to mentally read them every time,
which breaks up the flow (for me, anyway).

Maybe that's not the greatest example
but I think things are ambiguous otherwise. If you have a decent sized
method that you haven't seen in a while, are you saying you'd rather
determine the variable's type using the debugger than by just looking
at it?

Yes, if that means greater readability when I'm looking at the code
when I *am* familiar with what things are. You don't really need to use
the debugger - just hover over a variable to see its type.

And what about telling the difference between constants classes and
methods. The .Net Naming schema treats them all the same. Each
Beginning word is capitalized. Why not CAPS ALL CONSTANTS, or just
capitalize the 1st word in classes.

Readability. ALL_CAPS is harder to read than CapitalizingWords (it
feels like it's shouting) and ReadingCapitalizedWords is easier than
reading Lotsofwordswithnothingtosaywheretheystart.

It's very easy to tell the difference by context though - unless you're
using a delegate, a method name will always have brackets at the end of
it anyway. When you're using a delegate, it should be obvious that
you're doing so.

Note I'm not really arguing with you guys, I'm kinda hoping someone
can show me this newer scheme is better, because I can't seem to see
it as an improvement myself.

Maybe you will when you've used it for a while and then look back at
some old code. Anything new takes a little while to get used to.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Stu Smith <st*****@nospam-digita.com> wrote:

Well I'm not a fan of Hungarian myself but I have to say that as originally
conceived, it wasn't simply a method of repeating the static type of a
variable. You can see when something is a float or an integer by looking at
the variable declaration.

<snip>

Agreed, that's the original meaning of Hungarian notation. MS has used
it over the years to pretty much be the declared type, unfortunately,
and that's what a lot of people think of it as. I believe the OP meant
it in this way, so that's what I was addressing :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jim Cooper]

On the other hand, if you have the goal to make code readable

That's one of the main arguments for **not** using Hungarian notation.

It's not called Hungarian notation because it's easier to read! :-)

Users of stringly typed OO languages generally think HN is a big step
backwards.

That said, MS saw fit to keep it for interface declarations... :-)

Cheers,
Jim Cooper

_______________________________________________

Jim Cooper ji*@falafelsoft.com
Falafel Software http://www.falafelsoft.co.uk
_______________________________________________

[Stu Smith]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Stu Smith <st*****@nospam-digita.com> wrote:

Well I'm not a fan of Hungarian myself but I have to say that as originally conceived, it wasn't simply a method of repeating the static type of a
variable. You can see when something is a float or an integer by looking at the variable declaration.
<snip>

Agreed, that's the original meaning of Hungarian notation. MS has used
it over the years to pretty much be the declared type, unfortunately,
and that's what a lot of people think of it as. I believe the OP meant
it in this way, so that's what I was addressing :)

Oh, absolutely.

I can't decide whether to feel sorry for Charles Simonyi for being so
comprehensively misunderstood, or whether to be cross because he tried to
shoe-horn what should have been an automatic system into a language like C,
and spawned what can best be described as a ruddy great mess.

I think what he was trying to say was something like this:

Given:

abstract class Integer;

class Index : Integer { ... }
class Count : Integer { ... }

class Array
{
X operator [] ( Index index ) { ... } // NB not Integer index.
}

Then:

Count nWhatevers = arrWhatevers.Length;

for( Index iWhatever = 0; iWhatever < nWhatevers; iWhatever++ )
{
// Fine
arrWhatevers[ iWhatever ] =

// Compiler error!
arrWhatevers[ nWhatevers ] =
}

....

The one that annoys me the most was the old MFC CWhatever. Surely the point
of C++ is that I shouldn't care if it's a class or a built-in?

Anyway...
Stu


--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Bob Grommes]

Jim,

There is nothing the least bit difficult about Hungarian notation unless
someone has produced a byzantine naming standard that is undocumented, tries
to do too much, or both.

The visual clues from moderate usage of Hungarian makes code more
immediately self-evident and I think helps the developer to keep things
straight in his or her own mind while working on the code. That is the
sense in which it is "easier".

To use a concrete example:

for (i = 0;i < lastName.Length;i++) {
}

for (intCount = 0;intCount < strLastName.Length;intCount++) {
}

for (lCntrIntCount = 0;lCntrIntCount <
lDatStrLastName.Length;lCntrIntCount++) {
}

I would maintain that the first version (no Hungarian) forces you to either
make (potentially dangerous) assumptions about what i and lastName are, or
look it up and remember it as you read it.

The second version makes it clear what the types are.

The third version takes Hungarian over the top, making it harder rather than
easier, by adding scoping and intended usage info that has little or no
value in a managed app.

Of course, everyone has different ways of coping with complexity; your
mileage may vary. It's your prerogative to hate Hungarian and not use it;
but I think that in moderation it's got some real upside and it is perhaps
dismissing entirely it as useless complexity is a little too out-of-hand.

Best,

--Bob

"Jim Cooper" <ji********@virgin.net> wrote in message
news:41***************@virgin.net...

On the other hand, if you have the goal to make code readable

That's one of the main arguments for **not** using Hungarian notation.

It's not called Hungarian notation because it's easier to read! :-)

Users of stringly typed OO languages generally think HN is a big step
backwards.

That said, MS saw fit to keep it for interface declarations... :-)

Cheers,
Jim Cooper

[Bob Grommes]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

1) Just as someone gave an example where the type of a variable which
was a Hashtable could change to SortedList, so the discount might need
to be changed to a double, or a decimal. Are you definitely, definitely
going to change all your code? If you don't, it's worse than not having
the type there at all.
If you have a system, and are committed to it, yes. Generally you are not
talking about a lot of instances of the variable to deal with, and this kind
of refactoring is easily automatable if you are a slow typist or whatever.

That said, I made the original point about Hashtable ==> SortedList and that
in my mind is a somewhat different beast. Both of those classes implement
the same interfaces and are descendants of the same ancestor; making a
distinction between the two is probably less useful than the distinction
between an int and a string or even an int and a float. I mainly advocate
using prefixes on value types.
2) It makes it harder to read, IMO. You either have to teach your brain
to skip over the letters, or you have to mentally read them every time,
which breaks up the flow (for me, anyway).

One gets used to it -- but you're right, we're all wired differently and
this may be a perpetual distraction for some.

If you have a decent sized
method that you haven't seen in a while, are you saying you'd rather
determine the variable's type using the debugger than by just looking
at it?

Yes, if that means greater readability when I'm looking at the code
when I *am* familiar with what things are. You don't really need to use
the debugger - just hover over a variable to see its type.

Ah, but to me, this is where the evaluation of the usefulness of prefixing
variable names usually runs afoul. It is much less useful when you are
writing the code, or have familiarity with it. But where it really shines
is months or years later when you're no longer familiar with it, or tomorrow
when you hire someone new to work on it. That is where the value is -- in
making code you're either unfamiliar or rusty with, more self-evident and
therefore, easier to read accurately in the long run.

--Bob

[Jim Cooper]

There is nothing the least bit difficult about Hungarian notation
I strongly disagree. It rapidly descends into nonsense.
The second version makes it clear what the types are.
I don't agree with that statement at all. It makes the hidden assumption
that you know what "int" and "str" mean. In all but the most trivial
type systems that gets completely out of hand. Only using it for
primitive types, as someone suggested earlier, seems completely silly.
What's the point of only using it sometimes? That suggests to me that
there is no point using it at all, since you can get by without it most
of the time.

Also, if you know so little about a variable that you don't even know
its type, I think you have no business using it, frankly (anyway, all
modern IDEs will tell you the type by hanging the mouse pointer over the
symbol).
perhaps dismissing entirely it as useless complexity is a little too out-of-hand.

Having worked extensively both with and without it, my experience is
that it is completely worthless. It adds nothing to the readability of
the code, it justs adds another maintenance headache.

Cheers,
Jim Cooper

_______________________________________________

Jim Cooper ji*@falafelsoft.com
Falafel Software http://www.falafelsoft.co.uk
_______________________________________________

[Jon Skeet [C# MVP]]

Bob Grommes <bo*@bobgrommes.com> wrote:

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

1) Just as someone gave an example where the type of a variable which
was a Hashtable could change to SortedList, so the discount might need
to be changed to a double, or a decimal. Are you definitely, definitely
going to change all your code? If you don't, it's worse than not having
the type there at all.
If you have a system, and are committed to it, yes. Generally you are not
talking about a lot of instances of the variable to deal with, and this kind
of refactoring is easily automatable if you are a slow typist or whatever.

I thought it was a lot of work, and error-prone? That's what you
claimed before.
That said, I made the original point about Hashtable ==> SortedList and that
in my mind is a somewhat different beast. Both of those classes implement
the same interfaces and are descendants of the same ancestor; making a
distinction between the two is probably less useful than the distinction
between an int and a string or even an int and a float.
What about between a float and a double, or an int and a long though?
I mainly advocate using prefixes on value types.

Either it's a pain to change the names of variables or it's not,
frankly. I don't think your point can stand up for reference types but
not for value types.

2) It makes it harder to read, IMO. You either have to teach your brain
to skip over the letters, or you have to mentally read them every time,
which breaks up the flow (for me, anyway).

One gets used to it -- but you're right, we're all wired differently and
this may be a perpetual distraction for some.

And why should you have to get used to something in the first place? I
dare say I could get used to K&R bracing if I absolutely had to, but
I'd rather use something which was natural to start with...

If you have a decent sized
method that you haven't seen in a while, are you saying you'd rather
determine the variable's type using the debugger than by just looking
at it?

Yes, if that means greater readability when I'm looking at the code
when I *am* familiar with what things are. You don't really need to use
the debugger - just hover over a variable to see its type.

Ah, but to me, this is where the evaluation of the usefulness of prefixing
variable names usually runs afoul. It is much less useful when you are
writing the code, or have familiarity with it. But where it really shines
is months or years later when you're no longer familiar with it, or tomorrow
when you hire someone new to work on it. That is where the value is -- in
making code you're either unfamiliar or rusty with, more self-evident and
therefore, easier to read accurately in the long run.

If they're sufficiently unfamiliar with the code that they don't even
know the type of it, how are they meant to know its meaning? The two go
together - and a well chosen name can imply both with no prefixing, in
my experience.

That's also where hovering over a variable name can help - if it
displays the XML documentation (which I can't remember off-hand whether
or not VS.NET does, but I would hope it does) then you get more
information than just the type anyway.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Bob Grommes <bo*@bobgrommes.com> wrote:

There is nothing the least bit difficult about Hungarian notation unless
someone has produced a byzantine naming standard that is undocumented, tries
to do too much, or both.

The visual clues from moderate usage of Hungarian makes code more
immediately self-evident and I think helps the developer to keep things
straight in his or her own mind while working on the code. That is the
sense in which it is "easier".

To use a concrete example:

for (i = 0;i < lastName.Length;i++) {
}

for (intCount = 0;intCount < strLastName.Length;intCount++) {
}

for (lCntrIntCount = 0;lCntrIntCount <
lDatStrLastName.Length;lCntrIntCount++) {
}

Here's a version which makes it even clearer though:

for (int i=0; i < lastName.Length; i++)
{
....
}

Look ma, the type is visible in the code itself!

Keep declaration as close to first use as possible and there's usually
no problem in the first place for local variables - and if you've got a
non-local variable called either "intCount" or "i" you've got more to
worry about than just whether or not to use Hungarian.

Rather than deal with the complexity, avoid it cropping up in the first
place: keep methods short, keep declaration close to first use, and
keep names meaningful. The more semantic meaning is in the name, the
more obvious the type becomes anyway.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Bob Grommes]

Jon,

I almost always do declare a counter in a for loop. It was a contrived
example.

Perhaps at the end of the day my choice has to do with who has to work
harder, the writer of the code or the one who reads it at some later time.
Personally I find code easier to read with prefixes (up to a point of
diminishing returns that varies according to the language; I certainly use
prefixing much less in C# than in any language I've used to date). And
since I end up maintaining (or supervising the maintenance) of hundreds of
thousands of lines of code I've written or become responsible for over the
years, I prefer to put in a little more effort up front to make my life
easier later. I recognize and respect that some would see this as making
both the writing *and* the reading of code harder.

Actually your point about keeping declarations close to first use addresses
the same issue -- can I read one or two lines of code, or at most a single
code block, and not have to hunt around in a half-dozen different places for
missing bits of info that will make that code self-evident? I find
declaring variables close to their use, good naming conventions, consistent
formatting choices, a reasonable amount of commenting, and avoiding the
temptation to say too much in one line without some overriding good reason,
all contribute to this end.

Different people have different perceptions and sensibilities about what's
smooth or jarring, helpful or annoying, elegant or kludgy. I also know that
most of the people I've worked with are fairly comfortable with prefixing
and don't see it as an evil to be stamped out. These are intelligent people
of good conscience, just as you are.

Ultimately what it boils down to is, settle on a naming convention; then
document and use it consistently. What has made my professional life more
unpleasantly interesting than the exact variable naming convention used
(with or without prefixes), has been the lack of a convention, or a mixture
of several.

--Bob

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Here's a version which makes it even clearer though:

for (int i=0; i < lastName.Length; i++)
{
...
}

Look ma, the type is visible in the code itself!

Keep declaration as close to first use as possible and there's usually
no problem in the first place for local variables - and if you've got a
non-local variable called either "intCount" or "i" you've got more to
worry about than just whether or not to use Hungarian.

Rather than deal with the complexity, avoid it cropping up in the first
place: keep methods short, keep declaration close to first use, and
keep names meaningful. The more semantic meaning is in the name, the
more obvious the type becomes anyway.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Bob Grommes]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Bob Grommes <bo*@bobgrommes.com> wrote:

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Either it's a pain to change the names of variables or it's not,
frankly. I don't think your point can stand up for reference types but
not for value types.
It's a question of cost vs benefits. There are too many reference types to
come up with memorable prefixes for. But there are a very finite number of
value types, and the list is not likely to grow much, if at all. One can
find prefixing useful, even if it is not practical for 100% of the places it
could be used.
And why should you have to get used to something in the first place? I
dare say I could get used to K&R bracing if I absolutely had to, but
I'd rather use something which was natural to start with...

Well, perhaps I should not admit this -- but I happen to find K&R bracing
more natural, as well as more compact and readable overall. I find opening
braces on their own line considerably harder to follow. It probably has to
do with how my brain has wired itself to follow the text.

There is no right or wrong about it. It's an individual matter.

Let me express my appreciation for your points -- yours and everyone else's
here -- against prefixing (and K&R bracing!) If I take nothing else away
from this discussion, it'll be to consider the possibility that I might
inconvenience myself a bit more for the sake of others, if I can be
convinced that more people find my conventions appalling than don't. I have
had the luxury of using only occasional outside help with most of my
projects; as time wears on that is less and less true. It's not like I
would be horribly crippled without prefixing or bracketing as I do. It's
just how my own comfort zone has evolved, and none of the two dozen or so
fine people I've worked with off and on over the years has ever expressed
that it is odd or impeding or complicated.

--Bob

[David]

On 2004-08-16, Bob Grommes <bo*@bobgrommes.com> wrote:

The visual clues from moderate usage of Hungarian makes code more
immediately self-evident and I think helps the developer to keep things
straight in his or her own mind while working on the code. That is the
sense in which it is "easier".

To use a concrete example:

for (i = 0;i < lastName.Length;i++) {
}

for (intCount = 0;intCount < strLastName.Length;intCount++) {
} I would maintain that the first version (no Hungarian) forces you to either
make (potentially dangerous) assumptions about what i and lastName are, or
look it up and remember it as you read it.

How does Hungarian help in this regard? The only likely error here is
that somebody changes lastName to point to something other than a string
(say, to a custom class that maintained multiple last names, where
..Length referred to words). But how does Hungarian help you there? Do
you simply remove the prefix, then assume that the *lack* of a prefix
means that lastName isn't one of the special preferred types. Or do you
come up with some other prefix to refer to your new class? The first
doesn't sound very useful, while the second doesn't sound manageable.

I'm trying to understand your point here, so could you give specifics
about your example? What kind of (dangerous) assumptions could a
programmer make about lastName that would be cured by the presence of an
Hungarian prefix.

The intCount issue isn't a good example probably, since intCount is such
a bad variable name in so many ways (I realize these are just examples
you're tossing out off the top of your head). I do feel that Hungarian
tends to lead to bad variables names, largely because the mixing of
abstraction levels confuses the issue, but it's probably unfair to blame
that on the notation itself.

[Bob Grommes]

"David" <df*****@woofix.local.dom> wrote in message
news:slrnci2hc5.5bv.df*****@woofix.local.dom...

On 2004-08-16, Bob Grommes <bo*@bobgrommes.com> wrote: But how does Hungarian help you there? Do
you simply remove the prefix, then assume that the *lack* of a prefix
means that lastName isn't one of the special preferred types. Or do you
come up with some other prefix to refer to your new class? The first
doesn't sound very useful, while the second doesn't sound manageable.

If I see "strLastName" I instantly know it's a string. I don't have to hunt
for where it was defined or passed in, or trust my memory of having seen it
earlier.

If I see lastName I know it's some other sort of object reference (as
personally I only prefix strings and StringBuilders, all other reference
types are unprefixed). I don't attempt to come up with a prefix for every
reference type because, as you point out, it's not practical.

Basically I'm trying to avoid having to stop and ask myself "what the heck
is that referring to?" even if the answer would come pretty quickly from the
context. I'm trying to get lines of code (even printed lines of code, where
you don't have access to IntelliSense) to read quickly and smoothly, yet
accurately. For me at least, prefixing is helpful in that regard; however,
it has the limitation that you have to work with a finite set of prefixes --
so I've chosen value types and a couple of common reference types and left
it at that. Half a loaf being better than none.

Again though, it's better that one uses prefixes (or not) with conscious
intent and consistency than it is that you agree with my preferences (or
anyone else's). We are really debating fine points here. I wouldn't think
the less of an applicant coming to me with sample code that doesn't use
prefixes; I wouldn't chafe significantly doing work for a customer who wants
me to adhere to a coding standard that prohibits them. What I *would*
disrespect is the randomness I see far too often in code where there seems
to be no plan and no consistency at all. The same remarks apply to
bracketing, indenting, commenting, etc.

--Bob

[Steve Barkto]

On Mon, 16 Aug 2004 10:20:02 -0700, "Bob Grommes" <bo*@bobgrommes.com>
wrote:

for (i = 0;i < lastName.Length;i++) {
}

for (intCount = 0;intCount < strLastName.Length;intCount++) {
} I would maintain that the first version (no Hungarian) forces you to either
make (potentially dangerous) assumptions about what i and lastName are, or
look it up and remember it as you read it.

The second version makes it clear what the types are.

I have seen a _lot_ of code where the prefix is incorrect. If your
variables are named well, there is no need for HN.

--
Steve