Hungarian Notation

[Ant]

Good or bad? I've always used HG in VB6, but the .NET guidelines say no.
I think it's useful as you can have similar named variables differentiated
only by identifier type, hence more variable options. What's the standard? Is
it still considered choice of team?

Many thanks for your thoughts on this

Ant

[Mattias Sjögren]

Is it still considered choice of team?

For private variables, yes. The .NET naming guidelines only cover
publicly exposed members.
Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Bruce Wood]

Personally, I think that HG is grossly overused. I thought that using
it even in C was a bad idea.

HG was originally created for programming in assembly language, where
it makes tremendous sense: you cannot tell just from a declaration what
type a variable is meant to be; you have to encode it in a name.

In C, HG was problematic: yes, you could tell at a glance what type
your variable was, but then if your variable declaration was so far
away that you couldn't easily find it and with it the type, then there
was something wrong with the way you were coding C, IMHO.

In C#, with Intellisense and the ability to declare variables as you
need them, it makes even less sense, and the arguments against HG
become even stronger. The best anti-HG argument is: what happens when
you change the type of a variable, property, etc? What happens when you
discover that you need that int property to be a decimal property?
Suddenly you have to re-engineer the property name everywhere it's
used, or live with a decimal property named iLinearFeet or something
like that. Yuck.

Intellisense will tell you what type a thing is just by mousing over
it. I see no reason for adding HG to that, especially given the
problems it brings with it.

[Usenet User]

On 27 Aug 2005 12:22:23 -0700, "Bruce Wood" <br*******@canada.com>
wrote:

In C#, with Intellisense and the ability to declare variables as you
need them, it makes even less sense, and the arguments against HG
become even stronger. The best anti-HG argument is: what happens when
you change the type of a variable, property, etc? What happens when you
discover that you need that int property to be a decimal property?
Suddenly you have to re-engineer the property name everywhere it's
used, or live with a decimal property named iLinearFeet or something
like that. Yuck.

Well, it's maybe not so bad, because in VS.NET 2005 there is the
Refactor feature that allows you to change a field/property/method
name very easily.

Yet I agree with you - IntelliSense eliminates HG need.

Another point against HG not mentioned here: HG is useles because one
cannot make it useful. While adding "str" or "int" to variable names
might seem appropriate for string and int types, then what would you
do for objects like DataListItemEventHandler or TransformChain? I've
seen people blindly following their HG habit just to flood their .NET
code with idiotic prefixes like cnsc_ or dgcer_ which make no sense
to anyone, including themselves.

[tal_mcmahon]

or taken to its limit everything is an object so put o_ in front of it
all

[Jon Skeet [C# MVP]]

tal_mcmahon <ta*********@hotmail.com> wrote:

or taken to its limit everything is an object so put o_ in front of it
all

Unfortunately, I've seen that in plenty of code samples...

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

[Bruce Wood]

That's frightening.

[Joerg Jooss]

Mattias Sjögren wrote:

Is it still considered choice of team?

For private variables, yes. The .NET naming guidelines only cover
publicly exposed members.

Which doesn't mean using HN for private members is recommended. It just
means that there's no recommendation for private members.

Cheers,
--
http://www.joergjooss.de
mailto:ne********@joergjooss.de

[Joerg Jooss]

Mattias Sjögren wrote:

Is it still considered choice of team?

For private variables, yes. The .NET naming guidelines only cover
publicly exposed members.

Which doesn't mean using HN for private members is recommended. It just
means that there's no recommendation for private members.

Cheers,
--
http://www.joergjooss.de
mailto:ne********@joergjooss.de

[Usenet User]

On Wed, 31 Aug 2005 00:47:31 -0700, "Joerg Jooss"
<ne********@joergjooss.de> wrote:

Mattias Sjögren wrote:

> Is it still considered choice of team?

For private variables, yes. The .NET naming guidelines only cover
publicly exposed members.

Which doesn't mean using HN for private members is recommended. It just
means that there's no recommendation for private members.

Cheers,

Actually, there is one naming convention for private fields: use camel
notation and prefix with underscore. This way they are conveniently
grouped together at the top of IntelliSense list (in C#) or in the
bottom (VB.NET)

[Usenet User]

On Wed, 31 Aug 2005 00:47:31 -0700, "Joerg Jooss"
<ne********@joergjooss.de> wrote:

Mattias Sjögren wrote:

> Is it still considered choice of team?

For private variables, yes. The .NET naming guidelines only cover
publicly exposed members.

Which doesn't mean using HN for private members is recommended. It just
means that there's no recommendation for private members.

Cheers,

Actually, there is one naming convention for private fields: use camel
notation and prefix with underscore. This way they are conveniently
grouped together at the top of IntelliSense list (in C#) or in the
bottom (VB.NET)

[Joerg Jooss]

Usenet*User wrote:

Actually, there is one naming convention for private fields: use camel
notation and prefix with underscore. This way they are conveniently
grouped together at the top of IntelliSense list (in C#) or in the
bottom (VB.NET)

This is one naming convention many developers seem to use, but it is
not an official recommendation.

Cheers,
--
http://www.joergjooss.de
mailto:ne********@joergjooss.de

[Joerg Jooss]

Usenet*User wrote:

Actually, there is one naming convention for private fields: use camel
notation and prefix with underscore. This way they are conveniently
grouped together at the top of IntelliSense list (in C#) or in the
bottom (VB.NET)

This is one naming convention many developers seem to use, but it is
not an official recommendation.

Cheers,
--
http://www.joergjooss.de
mailto:ne********@joergjooss.de

[Jon Skeet [C# MVP]]

Usenet*User <**@*.**> wrote:

Actually, there is one naming convention for private fields: use camel
notation and prefix with underscore. This way they are conveniently
grouped together at the top of IntelliSense list (in C#) or in the
bottom (VB.NET)

There are lots of conventions - naming them with no prefix, naming them
with m_ (and g_ for statics) etc. None of these are specified in the MS
conventions, however.

--
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]]

Usenet*User <**@*.**> wrote:

Actually, there is one naming convention for private fields: use camel
notation and prefix with underscore. This way they are conveniently
grouped together at the top of IntelliSense list (in C#) or in the
bottom (VB.NET)

There are lots of conventions - naming them with no prefix, naming them
with m_ (and g_ for statics) etc. None of these are specified in the MS
conventions, however.

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