Hungarion Notation is out but..

[Jeff Jarrell]

Hungarion Notation is out but..

I am trying to keep the notion of naming things "it is what it is, name it
that"

Class Names are an interesting side. If we name them in a meaningful way and
then we name an instance of in a meaningful way there will ultimately be a
semantic collision.

For example,

In a VB6 way
dim oUser as new clsUser

In a .Net way
dim User as new User

When I read vb6 example, it jumps out at me whether I am refering to the
type or the instance. In the .Net way I am not sure from just reading it.
(am I using a static function in a type or a function that uses an
instances).

I am tempted to either suffix the type or prefix the instance. But thats
not in the spirit of .net now. Should I just get used to not immediately
recognizing the difference between an instance and a type?

thanks,
jeff

 

[Brian Henry]

since when is hungarian notation out? We use it all the time in code, and
every major dev we've worked with uses it.

 

[Jeff Jarrell]

This isn't a thought of my own invention. I have read it (.net\hungarion
not) in a number of books and my eyes popped out the first time I read it,
but in practice I found that with a few exceptions I am ok with this style.
I wouldn't convert an existing codebase or change coding conventions on a
continuing codebase.

But I am starting a new codebase at work that has nothing to do with the
past. So I am trying to stay in the spirit of the .net conventions. You
might want to look at FXCop. I find it way too rigid for my taste, though.

Here is a good discussion of hungarion\not by Richard Hale Shaw.
http://www.richardhaleshawgroup.com...ramming_in_general/archive/2005/03/03/20.aspx

jeff

 

[Herfried K. Wagner [MVP]]

This isn't a thought of my own invention. I have read it (.net\hungarion
not) in a number of books and my eyes popped out the first time I read it,
but in practice I found that with a few exceptions I am ok with this
style. I wouldn't convert an existing codebase or change coding
conventions on a continuing codebase.

But I am starting a new codebase at work that has nothing to do with the
past. So I am trying to stay in the spirit of the .net conventions. You
might want to look at FXCop. I find it way too rigid for my taste,
though.

Here is a good discussion of hungarion\not by Richard Hale Shaw.
http://www.richardhaleshawgroup.com...ramming_in_general/archive/2005/03/03/20.aspx

Before discussing whether or not using the Hungarian Notation makes sense
it's important we make sure that we are all referring to the same thing:

Making Wrong Code Look Wrong
<URL:http://www.joelonsoftware.com/articles/Wrong.html>

I don't think that the Hungarian Notation as introduced by Charles Simonyi
is completely obsolete, not even strict typing and OO make it obsolete.

 

[ML]

Any naming convention is used properly and consistently is good. To say HN
is obsolete is foolishness IMHO. Naming conventions are there to make the
code easier to follow and read, how can using HN with .NET be bad? It may
be redundant but certainly not bad/wrong.

 

[Jeff Jarrell]

nice point. it is an important distinction between apps hungarion and
system hungarion. I have to admit though, this is the first time I have
read or considered the distinction. I'd like to say I was simply thinking
of system hungarion but that wouldn't be the case for my example.

I am just trying to grow into the spirit of .net. I wasn't trying to
project a point of view with how the community at large should think of
hungarion notation. Fact is that as a old timer, I have had to open my mind
to reconsider the issue.

Now lets take it from a different point of view.

I have an domain object type that describes a user. What would you name it?

I have an instance of the above user domain object type. What would you
name it?

 

[Alejandro Lapeyre]

Here is where Microsoft recommends not to use Hungarian notation:

Standard ECMA-335
Common Language Infrastructure (CLI)

2nd edition (December 2002)
http://www.ecma-international.org/publications/standards/Ecma-335.htm

Annex D Class Library Design Guidelines
This is a nice chapter I specialy recommend to read.

"Do not use Hungarian notation. Good names describe semantics, not type."

This is the index:

D.1. Naming Guidelines
D.1.1. Capitalization Styles
D.1.1.1. Pascal Casing
D.1.1.2. Camel Casing
D.1.1.3. Upper Case
D.1.1.4. Capitalization summary
D.1.2. Word Choice
D.1.3. Case Sensitivity
D.1.4. Avoiding Type Name Confusion
D.1.5. Namespaces
D.1.6. Classes
D.1.7. Interfaces
D.1.8. Attributes
D.1.9. Enums
D.1.10. Fields
D.1.10.1. Static Fields
D.1.11. Parameter Names
D.1.12. Method Names
D.1.13. Property Names
D.1.14. Event Names

Best Regards,
Alejandro Lapeyre

 

[Herfried K. Wagner [MVP]]

Here is where Microsoft recommends not to use Hungarian notation:

Standard ECMA-335
Common Language Infrastructure (CLI)

2nd edition (December 2002)
http://www.ecma-international.org/publications/standards/Ecma-335.htm

Annex D Class Library Design Guidelines
This is a nice chapter I specialy recommend to read.

"Do not use Hungarian notation. Good names describe semantics, not type."

CLI <> All .NET programming languages!

I don't think that a general statement or recommendation would make much
sense at all. First, as I already mentioned in another post, "Apps
Hungarian" as described in
<URL:http://www.joelonsoftware.com/articles/Wrong.html> doesn't describe
types, it describes semantics of variables in a handy abbreviated form.

This is especially important when dealing with programming languages'
intrinsic types which often cannot and should not be extended by renaming,
aliasing or subtyping. For example, when dealing with angles given in
degrees and radians, a distinction is important to prevent mixing both
units, however, all of these values are stored in 'Double' format. There
are much more examples when introducing prefixes like 'deg', 'rad', etc.
would make sense. One could argue that a well-built project doesn't mix
units, but as practice shows, this is not always the case. 3rd-party
libraries sometimes use different units, data stored in legacy-databases and
file formats can suffer from the same problem.

Additionally not all .NET programming languages support strict typing and/or
provide a way to turn strict typing off to make dealing with COM etc.
objects easier. In this case, /type/ prefixes can help to write better code
by preventing the developer from mixing types without using appropriate
conversion methods or assigning variables of incompatible types to each
other.

To make a conclusion: I don't think that Hungarian Notation (both, Apps and
System) are bad per-se and should be avoided under all circumstances.
Shifting to programming languages which support strict typing will reduce
the need for using these notations, but they won't become completely
obsolete.

I am curios about other people's thoughts on this topic.

 

[Cor Ligthert]

Herfried,

I am curios about other people's thoughts on this topic.

ACK,

As addition, the size of a project (in size or time of live, workers) makes
in my opinion how much agreements there are needed. In which this is one of
those.

Cor

 

[Carlos J. Quintero [.NET MVP]]

I agree with you, I don´t think that Hungarian notation is bad per-se. On
the one hand, it should be avoided in the public classes, methods,
parameters, etc. of a class library, because people should not be forced to
use your naming conventions. For that purpose MS has some class library
naming guidelines. But on the other hand, for internal code not exposed
outside the assembly, I find it very useful (and productive for
intellisense) to use "i" for Integers and so on, or say, to use "m_" to
denote class variables as opposed to procedure variables or parameters. In
fact, it can help to reduce programming errors.

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio .NET, VB6, VB5 and VBA
You can code, design and document much faster.
Free resources for add-in developers:
http://www.mztools.com

 

[Jay B. Harlow [MVP - Outlook]]

Jeff,
| Class Names are an interesting side. If we name them in a meaningful way
and
| then we name an instance of in a meaningful way there will ultimately be a
| semantic collision.
I normally use camelCasing for variables & ProperCasing for types, so I
don't have as big a problem with the perceived semantic collision.

Dim user As New User



I find using "a", "an", "the" as a prefix helps make the code more human
readable and helps avoid the perceived semantic collision. I understand its
used by some Java programmers.

Dim aUser As New User ' a user of a set/collection of users

Dim anOperator as New Operator ' an operator from a collection

Dim theUser As New User ' the only user

Unfortunately I don't use "a", "an", & "the" as often as I probably should
or could. They & Hungarian notation don't adhere to the .NET Design
Guidelines for Class Libraries for fields, properties & parameters..

http://msdn.microsoft.com/library/d...en-us/cpgenref/html/cpconNamingGuidelines.asp

http://msdn.microsoft.com/library/d...ry/en-us/cpgenref/html/cpconAbbreviations.asp

http://msdn.microsoft.com/library/d...ref/html/cpconStaticFieldNamingGuidelines.asp

http://msdn.microsoft.com/library/d...enref/html/cpconParameterNamingGuidelines.asp

http://msdn.microsoft.com/library/d...genref/html/cpconPropertyNamingGuidelines.asp

Which does not say you cannot use them on private instance fields or local
variables...

For control names I normally spell out (normally one or two words) the
control type rather then attempt to abbreviate it. In other words I use
textFirstName & buttonCancel instead of txtFirstName, btnCancel, or
cmdCancel.

Hope this helps
Jay

| Hungarion Notation is out but..
|
| I am trying to keep the notion of naming things "it is what it is, name it
| that"
|
| Class Names are an interesting side. If we name them in a meaningful way
and
| then we name an instance of in a meaningful way there will ultimately be a
| semantic collision.
|
| For example,
|
| In a VB6 way
| dim oUser as new clsUser
|
| In a .Net way
| dim User as new User
|
| When I read vb6 example, it jumps out at me whether I am refering to the
| type or the instance. In the .Net way I am not sure from just reading it.
| (am I using a static function in a type or a function that uses an
| instances).
|
| I am tempted to either suffix the type or prefix the instance. But thats
| not in the spirit of .net now. Should I just get used to not immediately
| recognizing the difference between an instance and a type?
|
| thanks,
| jeff
|
|

 

[Jay B. Harlow [MVP - Outlook]]

Herfried,
Although I agree with the intent of Making Wrong Code Look Wrong, I would
avoid the use of abbreviations for example instead of s & us, I would
probably use safe & unsafe as prefixes or better still encoded & unencoded
prefixes as IMHO encoded & unencoded gives "better" semantics on what the
variables contain.

I would consider refactoring the unencoded prefix to something "better"
later as encoded & unencoded tend to "blur" together... Based really on how
the unencoded variables were being used.

Remember the .NET Design Guidelines for Class Libraries suggests to avoid
abbreviations.

http://msdn.microsoft.com/library/d...ry/en-us/cpgenref/html/cpconAbbreviations.asp

Just a thought
Jay


| > This isn't a thought of my own invention. I have read it
(.net\hungarion
| > not) in a number of books and my eyes popped out the first time I read
it,
| > but in practice I found that with a few exceptions I am ok with this
| > style. I wouldn't convert an existing codebase or change coding
| > conventions on a continuing codebase.
| >
| > But I am starting a new codebase at work that has nothing to do with the
| > past. So I am trying to stay in the spirit of the .net conventions.
You
| > might want to look at FXCop. I find it way too rigid for my taste,
| > though.
| >
| > Here is a good discussion of hungarion\not by Richard Hale Shaw.
| >
http://www.richardhaleshawgroup.com...ramming_in_general/archive/2005/03/03/20.aspx
|
| Before discussing whether or not using the Hungarian Notation makes sense
| it's important we make sure that we are all referring to the same thing:
|
| Making Wrong Code Look Wrong
| <URL:http://www.joelonsoftware.com/articles/Wrong.html>
|
| I don't think that the Hungarian Notation as introduced by Charles Simonyi
| is completely obsolete, not even strict typing and OO make it obsolete.
|
| --
| M S Herfried K. Wagner
| M V P <URL:http://dotnet.mvps.org/>
| V B <URL:http://classicvb.org/petition/>
|

 

[Mitchell S. Honnert]

Hello Jeff. It seems like most of the other posts have been focused on the
merits
of Hungarian Notation, but because I've found myself in the same dilemma as
you, I'd like to give some input on the original question.

So, if you accept Microsoft's recommendation to avoid HN, how to handle the
following code?

dim User as new User

I've found that in most cases, the code I am writing to access an instance
of a particular class is in some kind of special context that can be used in
the variable name. In other words, I use the type of operation being
performed on the class to differentiate the class name from the instance
name. For example, if the person is selecting a User from a ListBox, my
variable name would be SelectedUser. If I'm getting ready to insert a new
User into a collection, I would name the variable InsertUser.

Now, admittedly, there isn't always an obvious choice for a "context prefix"
(perhaps because you are writing code that intentionally handles the class
in any context). Personally, I handle this in one of two ways. The first
is just to use the My prefix, as in MyUser. Using "My" has always seemed a
bit amateurish to me, but my aversion to HN is strong enough that it always
wins out over any fear that my fellow programmers would make fun of my use
of "My". The other way (which happens more as a result of my design rather
than another way to avoid this naming conflict) is to imbed the logic
which uses the instance in a method. For example, my code often contains
functions in this format...

Public Sub InsertUser(user as User)

I personally am not a fan of C#'s case sensitivity, but VB.NET's case
"awareness" can come in very handy in this situation. The Microsoft naming
standard specify that parameter names be in camelCase (and "user" is in
camelCase). So by following this naming standard you can differentiate
the class name (User) from the instance (user).

HTH.

- Mitchell S. Honnert

 

[Jeff Jarrell]

thanks for the coming back to the original question. i share a similar
feeling with respect to HN and at this point feel its ok to prefix the
instance. I am not sure I can keep my team consistent that with naming that
only differentiates in terms of case usage (c# a different story). I think
i am going to go with "aUser".

 

[Guest]

You should check out my new book about this and a lot more .NET coding
standards. You can pick up a copy @
http://www.cafepress.com/vsdntips.20412485.

=====================
David McCarter
www.vsdntips.com