Hungarian notation in .NET

I'm curious...

I've been wondering why I haven't seen any Hungarian notation used in
variable/object names when looking at programming examples in any .NET
training literature.

I've always had hammered in my head to use two or three letter
prefixes such as txtFirstName, intCounter, cnEmployees, for a text
box, integer data type, and connection object, etc... for VB coding.
I think there are "standards" for different programming
languages/environments, and I've tended to follow them, especially
since other coders may have to maintain your code, and it's a lot
easier to identify what variables/objects actually are if you prefix
them IMHO.

Also, my MCT for VB 6 went to a .NET MOC training course, and he said
the MOC didn't have any prefixes/mnemonics in any of the coding
examples. Is this something that .NET is getting away from???

Kael

Kael V. Dowdy

You are free to define any coding standards and practices you wish,
the importance points to keep in mind are consistency and relevance.

My on view is that Hungarian notation is rather pointless within
modern object oriented practices given that a 'name' should be self
describing and relate back to the actual type. Even in procedural C, I
found some really funny examples of Hungarian notation usage,e.g. how
would you represent an array of functions pointer (which accept an
array of longs) which return and array of functions pointers which
return an array of vectors?

>I'm curious...
>
>I've been wondering why I haven't seen any Hungarian notation used in
>variable/object names when looking at programming examples in any .NET
>training literature.
>
>I've always had hammered in my head to use two or three letter
>prefixes such as txtFirstName, intCounter, cnEmployees, for a text
>box, integer data type, and connection object, etc... for VB coding.
>I think there are "standards" for different programming
>languages/environments, and I've tended to follow them, especially
>since other coders may have to maintain your code, and it's a lot
>easier to identify what variables/objects actually are if you prefix
>them IMHO.
>
>Also, my MCT for VB 6 went to a .NET MOC training course, and he said
>the MOC didn't have any prefixes/mnemonics in any of the coding
>examples. Is this something that .NET is getting away from???

Kline Sphere

>I haven't seen any Hungarian notation
....
>Is this something that .NET is getting away from???

Yes, with .Net they have dropped the hungarian notation.

http://msdn.microsoft.com/library/default.asp?
url=/library/en-
us/cpgenref/html/cpconparameternamingguidelines.asp

Naming conventions are a pain to enforce but a real time
saver for the people who need to maintain the code later
on. There is a nice customisable utility called FxCop that
inspects your .net assemblies for for conformance to the
Microsoft .NET Framework Design Guidelines:
http://www.gotdotnet.com/team/fxcop/


>-----Original Message-----
>You are free to define any coding standards and practices
you wish,
>the importance points to keep in mind are consistency and
relevance.
>
>My on view is that Hungarian notation is rather pointless
within
>modern object oriented practices given that a 'name'
should be self
>describing and relate back to the actual type. Even in
procedural C, I
>found some really funny examples of Hungarian notation
usage,e.g. how
>would you represent an array of functions pointer (which
accept an
>array of longs) which return and array of functions
pointers which
>return an array of vectors?
>
>>I'm curious...
>>
>>I've been wondering why I haven't seen any Hungarian
notation used in
>>variable/object names when looking at programming
examples in any .NET
>>training literature.
>>
>>I've always had hammered in my head to use two or three
letter
>>prefixes such as txtFirstName, intCounter, cnEmployees,
for a text
>>box, integer data type, and connection object, etc...
for VB coding.
>>I think there are "standards" for different programming
>>languages/environments, and I've tended to follow them,
especially
>>since other coders may have to maintain your code, and
it's a lot
>>easier to identify what variables/objects actually are
if you prefix
>>them IMHO.
>>
>>Also, my MCT for VB 6 went to a .NET MOC training
course, and he said
>>the MOC didn't have any prefixes/mnemonics in any of the
coding
>>examples. Is this something that .NET is getting away
from???
>
>.
>

Maria

> >-----Original Message-----
> >You are free to define any coding standards and practices
> you wish,
> >the importance points to keep in mind are consistency and
> relevance.

Very true...

> >
> >My on view is that Hungarian notation is rather pointless
> within
> >modern object oriented practices given that a 'name'
> should be self
> >describing and relate back to the actual type. Even in

Yes, you are right...I feel too that names should be self subscribing
(something that the .NET base class library namespaces did pretty
well, WTG MS!)

> procedural C, I
> >found some really funny examples of Hungarian notation
> usage,e.g. how
> >would you represent an array of functions pointer (which
> accept an
> >array of longs) which return and array of functions
> pointers which
> >return an array of vectors?
> >

That'd be a really funny and long name, huh?

"Maria" <> wrote in message news:<07de01c3915f$083d94c0$>...
> >I haven't seen any Hungarian notation
> ...
> >Is this something that .NET is getting away from???
>
> Yes, with .Net they have dropped the hungarian notation.
>
> http://msdn.microsoft.com/library/default.asp?
> url=/library/en-
> us/cpgenref/html/cpconparameternamingguidelines.asp

I checked this out, gotta spend some more time perusing through this
section of MSDN.

>
> Naming conventions are a pain to enforce but a real time
> saver for the people who need to maintain the code later
> on. There is a nice customisable utility called FxCop that
> inspects your .net assemblies for for conformance to the
> Microsoft .NET Framework Design Guidelines:
> http://www.gotdotnet.com/team/fxcop/

FxCop looks like a really cool too...gotta check it out!

> >
> >>I'm curious...
> >>
> >>I've been wondering why I haven't seen any Hungarian
> notation used in
> >>variable/object names when looking at programming
> examples in any .NET
> >>training literature.
> >>
> >>I've always had hammered in my head to use two or three
> letter
> >>prefixes such as txtFirstName, intCounter, cnEmployees,
> for a text
> >>box, integer data type, and connection object, etc...
> for VB coding.
> >>I think there are "standards" for different programming
> >>languages/environments, and I've tended to follow them,
> especially
> >>since other coders may have to maintain your code, and
> it's a lot
> >>easier to identify what variables/objects actually are
> if you prefix
> >>them IMHO.
> >>
> >>Also, my MCT for VB 6 went to a .NET MOC training
> course, and he said
> >>the MOC didn't have any prefixes/mnemonics in any of the
> coding
> >>examples. Is this something that .NET is getting away
> from???
> >
> >.
> >

Kael V. Dowdy

It's used for the (name) property.
>-----Original Message-----
>I'm curious...
>
>I've been wondering why I haven't seen any Hungarian
notation used in
>variable/object names when looking at programming
examples in any .NET
>training literature.
>
>I've always had hammered in my head to use two or three
letter
>prefixes such as txtFirstName, intCounter, cnEmployees,
for a text
>box, integer data type, and connection object, etc... for
VB coding.
>I think there are "standards" for different programming
>languages/environments, and I've tended to follow them,
especially
>since other coders may have to maintain your code, and
it's a lot
>easier to identify what variables/objects actually are if
you prefix
>them IMHO.
>
>Also, my MCT for VB 6 went to a .NET MOC training course,
and he said
>the MOC didn't have any prefixes/mnemonics in any of the
coding
>examples. Is this something that .NET is getting away
from???
>
>Kael
>.
>

Jaime

Another reason why - is because everything is strongly
typed.. generic objects and type-casting are less
frequent.

Most people will use mObjectName and cObjectName to
represent class level objects, functions and property
instances just represent what you're doing.

dim consultRows as DataRow()




>-----Original Message-----
>I'm curious...
>
>I've been wondering why I haven't seen any Hungarian
notation used in
>variable/object names when looking at programming
examples in any .NET
>training literature.
>
>I've always had hammered in my head to use two or three
letter
>prefixes such as txtFirstName, intCounter, cnEmployees,
for a text
>box, integer data type, and connection object, etc...
for VB coding.
>I think there are "standards" for different programming
>languages/environments, and I've tended to follow them,
especially
>since other coders may have to maintain your code, and
it's a lot
>easier to identify what variables/objects actually are
if you prefix
>them IMHO.
>
>Also, my MCT for VB 6 went to a .NET MOC training
course, and he said
>the MOC didn't have any prefixes/mnemonics in any of the
coding
>examples. Is this something that .NET is getting away
from???
>
>Kael
>.
>

Jay Walters

On Tue, 14 Oct 2003 20:16:08 -0700 in article
<2b00f01c392ca$ad3ad930$> in
microsoft.public.cert.exam.mcsd , "Jay Walters"
<> wrote:

>Another reason why - is because everything is strongly
>typed.. generic objects and type-casting are less
>frequent.
>
>Most people will use mObjectName and cObjectName to
>represent class level objects, functions and property
>instances just represent what you're doing.
>
>dim consultRows as DataRow()
>

I'm not sure you're right about mObjectName and cObjectName. Our shop
follows the MS recommendations for .NET and thus we don't use them at
all. (On a side note, I never did myself.)


--
Simon
simon dot smith at snowvalley dot com
"Insomnia is a small price to pay for the stuff you read on UseNet"

Simon Smith

That's the thing, this isn't about right or wrong, it's
all preference.

The Microsoft way seems to be regular Camel Case and no
prefixes, (even though VS control names default to pascal
case).

But many people find it nicer to use a prefix for class
fields. Using 'm' and 'c' for example allows intellisense
to group all of your objects. Most of the MSFT people I
know use just a '_' --> string _connString;

Some people are also fanatical about using Base. and Me.

The most important thing in all of this is to be
consistant within your projects.

For more information about namimg guidelines:

http://msdn.microsoft.com/library/default.asp?
url=/library/en-
us/cpgenref/html/cpconpropertynamingguidelines.asp





>
>I'm not sure you're right about mObjectName and
cObjectName. Our shop
>follows the MS recommendations for .NET and thus we
don't use them at
>all. (On a side note, I never did myself.)
>
>
>--
>Simon
>simon dot smith at snowvalley dot com
>"Insomnia is a small price to pay for the stuff you read
on UseNet"
>.
>

Jay Walters

On Wed, 15 Oct 2003 11:44:56 -0700, "Jay Walters"
<> wrote:

>That's the thing, this isn't about right or wrong, it's
>all preference.

.... And consistence within an organization.

>Most of the MSFT people I
>know use just a '_' --> string _connString;

Been a common approach taken to indicate 'private' members for as long
as I can remember.

Kline Sphere