I keep missing Hungarian naming; still smart to abandon?

[Ronald S. Cook]

I've been weaning myself off of Hungarian notation because that's what
Microsoft is telling me to do, and I want to be a good little MS developer.
But things keep coming up that make me miss my little 3-character prefixes.

I'm fine with EmployeeFirstNameLabel instead of lblEmployeeFirstName, but at
the table and class level, I get frustrated because terms I want to use
reserved keywords.

I wanted "Event" and "User" as classes and table names. But, because those
are reserved words I have to be creative and come up with a non-ideal
alternative. Also, we have a class "Pen" which is allowed, but then can get
a little confusing (and I did say a little) with the Pen class in the
System.Drawing namespace (i.e. like when viewing Intellisense).

Now, I know I can bracket the table name but... yuk.

The main argument I hear against Hungarian is that a mouseover will tell you
the type so no need to type it in (especially since it could change). But
1) like many, I *read* code and seeing the type helps, and 2) refactoring
will allow me to easily retag my Hungarian tag with another.

Can someone please make me more comfortable leaving my Hungarian friend
behind? I'm not convinced that it's the best decision (from an app dev
standards policy in our shop).

Thanks,
Ron

[=?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=]

Ronald,
Nobody is holding a gun to your head. You can really do whatever you want.
However, when you start getting into wanting to use keywords as class names,
IMHO that's really starting to swim upstream.
Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"Ronald S. Cook" wrote:

I've been weaning myself off of Hungarian notation because that's what
Microsoft is telling me to do, and I want to be a good little MS developer.
But things keep coming up that make me miss my little 3-character prefixes.

I'm fine with EmployeeFirstNameLabel instead of lblEmployeeFirstName, but at
the table and class level, I get frustrated because terms I want to use
reserved keywords.

I wanted "Event" and "User" as classes and table names. But, because those
are reserved words I have to be creative and come up with a non-ideal
alternative. Also, we have a class "Pen" which is allowed, but then can get
a little confusing (and I did say a little) with the Pen class in the
System.Drawing namespace (i.e. like when viewing Intellisense).

Now, I know I can bracket the table name but... yuk.

The main argument I hear against Hungarian is that a mouseover will tell you
the type so no need to type it in (especially since it could change). But
1) like many, I *read* code and seeing the type helps, and 2) refactoring
will allow me to easily retag my Hungarian tag with another.

Can someone please make me more comfortable leaving my Hungarian friend
behind? I'm not convinced that it's the best decision (from an app dev
standards policy in our shop).

Thanks,
Ron

[Stoitcho Goutsev \(100\)]

Ronald,

I don't thing you should leave your Hungarian friend behind if it makes your
code more readable and easy to understand to you and people that use it.
However if this gets in a way, say this is code that you ship to others to
use and they have problems with it you should consider using something that
is confortable for all of you.

I personaly have been using Hungarian notation for a long time and I still
use it for my private fields. At the very end I believe if the name of the
variable is well chosen (descriptive enough) couple of letters in the
begining won't hurt anyone.

At least this is what I think.
--
Stoitcho Goutsev (100)

"Ronald S. Cook" <rc***@westinis.comwrote in message
news:O0**************@TK2MSFTNGP05.phx.gbl...

I've been weaning myself off of Hungarian notation because that's what
Microsoft is telling me to do, and I want to be a good little MS
developer. But things keep coming up that make me miss my little
3-character prefixes.

I'm fine with EmployeeFirstNameLabel instead of lblEmployeeFirstName, but
at the table and class level, I get frustrated because terms I want to use
reserved keywords.

I wanted "Event" and "User" as classes and table names. But, because
those are reserved words I have to be creative and come up with a
non-ideal alternative. Also, we have a class "Pen" which is allowed, but
then can get a little confusing (and I did say a little) with the Pen
class in the System.Drawing namespace (i.e. like when viewing
Intellisense).

Now, I know I can bracket the table name but... yuk.

The main argument I hear against Hungarian is that a mouseover will tell
you the type so no need to type it in (especially since it could change).
But 1) like many, I *read* code and seeing the type helps, and 2)
refactoring will allow me to easily retag my Hungarian tag with another.

Can someone please make me more comfortable leaving my Hungarian friend
behind? I'm not convinced that it's the best decision (from an app dev
standards policy in our shop).

Thanks,
Ron

[Alun Harford]

Ronald S. Cook wrote:

I've been weaning myself off of Hungarian notation because that's what
Microsoft is telling me to do, and I want to be a good little MS developer.

And because you've abandoned BCPL? Excellent. :-)

But things keep coming up that make me miss my little 3-character prefixes.

I'm fine with EmployeeFirstNameLabel instead of lblEmployeeFirstName, but at
the table and class level, I get frustrated because terms I want to use
reserved keywords.

I wanted "Event" and "User" as classes and table names. But, because those
are reserved words I have to be creative and come up with a non-ideal
alternative.

"event" is a keyword (although for classes, you normally start with an
upper case character - Event is not a keyword).
I don't believe "User" (or "user") is reserved in any context.

If you *really* want to use reserved words as names, you can prefix them
with '@' - for example:

string @string = "string";

Also, we have a class "Pen" which is allowed, but then can get
a little confusing (and I did say a little) with the Pen class in the
System.Drawing namespace (i.e. like when viewing Intellisense).

I think it would still be a little confusing if you prefixed it with
'some random characters' :-)
The solution to stop that confusion is to refer to types by their full
names when things could be confusing.

The main argument I hear against Hungarian is that a mouseover will tell you
the type so no need to type it in (especially since it could change). But
1) like many, I *read* code and seeing the type helps, and 2) refactoring
will allow me to easily retag my Hungarian tag with another.

I think the best argument against it is that we have a type system these
days. Also, you only have to hold your mouse over a variable if its type
isn't clear (which 'should' never happen).

Another argument is that plenty of programmers don't use Hungarian
notation (I've never used it - I wasn't programming in the days of BCPL
and it became pointless when C was invented) and it makes reading your
code more difficult for no apparent reason.

Alun Harford

[Peter Duniho]

"Ronald S. Cook" <rc***@westinis.comwrote in message
news:O0**************@TK2MSFTNGP05.phx.gbl...

I've been weaning myself off of Hungarian notation because that's what
Microsoft is telling me to do, and I want to be a good little MS
developer. But things keep coming up that make me miss my little
3-character prefixes.

[...]

Can someone please make me more comfortable leaving my Hungarian friend
behind? I'm not convinced that it's the best decision (from an app dev
standards policy in our shop).

IMHO, the biggest argument for someone who likes Hungarian to switch to the
..NET style is if they are writing code that is published to the general .NET
community. For example, you're writing a library that other people writing
..NET will be using, and so you all of the public API for that library
follows the .NET coding convention.

Even then, there's no need to change the internal parts of the code. Just
keep the public part consistent with the .NET standards so that other .NET
customers can more easily learn your API. (And frankly, if your library is
useful I doubt anyone would have much justification to complain even if you
did follow Hungarian conventions for the public part of the API).

Other than that, seems to me that if Hungarian works for you and you like
it, there's no reason to stop using it internally. I continue to use
Hungarian in my .NET code, and it provides all of the same benefits it
always has.

I certainly don't see the point in switching your coding conventions just
because Microsoft has changed their mind about what the "standard" is. If
you do switch to the .NET conventions internally, you should do so because
there's some real benefit to *your* development team in doing so.

Pete

[Jon Skeet [C# MVP]]

Peter Duniho <Np*********@NnOwSlPiAnMk.comwrote:

<snip>

I certainly don't see the point in switching your coding conventions just
because Microsoft has changed their mind about what the "standard" is. If
you do switch to the .NET conventions internally, you should do so because
there's some real benefit to *your* development team in doing so.

While I take your point, I think that consistency is a benefit in and
of itself. It would look very odd to, say, have all your own method
names in the_c_style_of_naming_with_underscores and still be calling
FrameworkMethodsWithPascalCasing. It just looks uneven and
inconsistent.

As you say though, there's nothing to stop you from naming variables
however you like.

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

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Ronald S. Cook wrote:

I've been weaning myself off of Hungarian notation because that's what
Microsoft is telling me to do, and I want to be a good little MS developer.
But things keep coming up that make me miss my little 3-character prefixes.

I'm fine with EmployeeFirstNameLabel instead of lblEmployeeFirstName, but at
the table and class level, I get frustrated because terms I want to use
reserved keywords.

I wanted "Event" and "User" as classes and table names. But, because those
are reserved words I have to be creative and come up with a non-ideal
alternative. Also, we have a class "Pen" which is allowed, but then can get
a little confusing (and I did say a little) with the Pen class in the
System.Drawing namespace (i.e. like when viewing Intellisense).

Now, I know I can bracket the table name but... yuk.

The main argument I hear against Hungarian is that a mouseover will tell you
the type so no need to type it in (especially since it could change). But
1) like many, I *read* code and seeing the type helps, and 2) refactoring
will allow me to easily retag my Hungarian tag with another.

Can someone please make me more comfortable leaving my Hungarian friend
behind? I'm not convinced that it's the best decision (from an app dev
standards policy in our shop).

Thanks,
Ron

In my opinion, there is no good reason to use hungarian notation for
data types in a type safe language.

The original intention of the hungarian notation was to convey crucial
information about the data that could not be done in any other way. In
the beginning this was used in BPCL, that only has one data type, to
specify the intended data type of a variable. For some reason this
spread to other languages, and is today widely regarded as the proper
use of the hungarian notation, and is used even in type safe languages,
eventhough it is not at all in line with the original intention.

There are other uses for hungarian notation that might be useful, like
specifying that a variable contains unverified user input, or
differentiating between horisontal and vertial coordinates.

If you personally feel that you need to use hungarian notation to
specify the data type in order to write good code, feel free to do so.
Then at least you are doing it by choise, and not just beacause everyone
else is doing it. :)

--
Göran Andersson
_____
http://www.guffa.com

[Peter Duniho]

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

Peter Duniho <Np*********@NnOwSlPiAnMk.comwrote:

<snip>

>I certainly don't see the point in switching your coding conventions just
because Microsoft has changed their mind about what the "standard" is.
If
you do switch to the .NET conventions internally, you should do so
because
there's some real benefit to *your* development team in doing so.

While I take your point, I think that consistency is a benefit in and
of itself. It would look very odd to, say, have all your own method
names in the_c_style_of_naming_with_underscores and still be calling
FrameworkMethodsWithPascalCasing. It just looks uneven and
inconsistent.

I have always had that issue, whether I used Hungarian or not. Even in the
olden days, the early Mac *and* Windows API did not have a 100% consistent
naming convention, making it very hard to match my code to theirs (and while
you could come close in the earliest versions of their APIs, every time some
new technology came along, it diluted whatever API-wide convention
existed...see DirectX and Quickdraw 3D for examples). Throw third-party
libraries into the mix, and all bets were off.

Personally, I just don't sweat it. I can easily deal with having my code
all follow one convention, while using an API that uses a different
convention. Consistency does have value, but IMHO internal consistency is
much more important than external consistency (that is, where two
independently developed modules meet, it is acceptable to have some naming
inconsistencies somewhere, and in fact is nearly unavoidable even in today's
development community). And there are other issues that rank much higher in
priority.

If you don't agree, then by all means spend your time making your code look
just like everyone else's. But for those of us who find real added value in
Hungarian (or any coding convention different from the .NET convention, for
that matter), making one's own code look just like someone else's code is
pretty low on the priority list. I don't disagree that doing so has value,
I just don't think it deserves much weight when other factors are also to be
considered.

Pete

[Peter Duniho]

"Göran Andersson" <gu***@guffa.comwrote in message
news:uM**************@TK2MSFTNGP04.phx.gbl...

In my opinion, there is no good reason to use hungarian notation for data
types in a type safe language.

It seems obvious to me that the question of whether there's a good reason
*to* use Hungarian isn't relevant here. Obviously the OP prefers it, and
has his own opinions supporting that preference.

The original intention of the hungarian notation was to convey crucial
information about the data that could not be done in any other way. In the
beginning this was used in BPCL, that only has one data type, to specify
the intended data type of a variable. For some reason this spread to other
languages, and is today widely regarded as the proper use of the hungarian
notation, and is used even in type safe languages, eventhough it is not at
all in line with the original intention.

As anyone who has read these threads here in the past probably knows, I
disagree. If and when a language provides a way for me to *easily* and
*conveniently* typedef (for example) an "int" to be my own typesafe data
type that the compiler will prevent me from using in any other context, then
perhaps we can talk about whether Hungarian is no longer useful.

But until then, there are still examples too numerous to count of places
where a compiler will happily accept code that is semantically incorrect.
Hungarian guards against this (and provides other benefits as well, as you
mention...it's a mistake to think that type-checking is the only benefit of
Hungarian).

There are other uses for hungarian notation that might be useful, like
specifying that a variable contains unverified user input, or
differentiating between horisontal and vertial coordinates.

If you personally feel that you need to use hungarian notation to specify
the data type in order to write good code, feel free to do so. Then at
least you are doing it by choise, and not just beacause everyone else is
doing it. :)

I can certainly agree with that. :)

Pete

[Susie DBA [MSFT]]

if you miss it.. then use hungarian

On Apr 24, 6:15 am, "Ronald S. Cook" <[e-mail]:

I've been weaning myself off of Hungarian notation because that's what
Microsoft is telling me to do, and I want to be a good little MS developer.
But things keep coming up that make me miss my little 3-character prefixes.

I'm fine with EmployeeFirstNameLabel instead of lblEmployeeFirstName, but at
the table and class level, I get frustrated because terms I want to use
reserved keywords.

I wanted "Event" and "User" as classes and table names. But, because those
are reserved words I have to be creative and come up with a non-ideal
alternative. Also, we have a class "Pen" which is allowed, but then can get
a little confusing (and I did say a little) with the Pen class in the
System.Drawing namespace (i.e. like when viewing Intellisense).

Now, I know I can bracket the table name but... yuk.

The main argument I hear against Hungarian is that a mouseover will tell you
the type so no need to type it in (especially since it could change). But
1) like many, I *read* code and seeing the type helps, and 2) refactoring
will allow me to easily retag my Hungarian tag with another.

Can someone please make me more comfortable leaving my Hungarian friend
behind? I'm not convinced that it's the best decision (from an app dev
standards policy in our shop).

Thanks,
Ron

[Susie DBA [MSFT]]

I think that it's goddamn ridiculous to NOT use hungarian

at Microsoft; we all use hungarian STILL

On Apr 24, 6:15 am, "Ronald S. Cook" <[e-mail]:

I've been weaning myself off of Hungarian notation because that's what
Microsoft is telling me to do, and I want to be a good little MS developer.
But things keep coming up that make me miss my little 3-character prefixes.

I'm fine with EmployeeFirstNameLabel instead of lblEmployeeFirstName, but at
the table and class level, I get frustrated because terms I want to use
reserved keywords.

I wanted "Event" and "User" as classes and table names. But, because those
are reserved words I have to be creative and come up with a non-ideal
alternative. Also, we have a class "Pen" which is allowed, but then can get
a little confusing (and I did say a little) with the Pen class in the
System.Drawing namespace (i.e. like when viewing Intellisense).

Now, I know I can bracket the table name but... yuk.

The main argument I hear against Hungarian is that a mouseover will tell you
the type so no need to type it in (especially since it could change). But
1) like many, I *read* code and seeing the type helps, and 2) refactoring
will allow me to easily retag my Hungarian tag with another.

Can someone please make me more comfortable leaving my Hungarian friend
behind? I'm not convinced that it's the best decision (from an app dev
standards policy in our shop).

Thanks,
Ron

[Chris Benard]

I'm not convinced either. At my work, we've standardized on naming
all elements with which we will programmatically interact
uxControlName, no matter their type. This groups them together in
intellisense. For labels, since you frequently have something like
lblFirstName and txtFirstName, we call those lblFirstName and
uxFirstName. For containers, such as a TableLayoutPanel, we use the
cnt prefix.

With that said, I'm not convinced that's the best way to go, either.
I think it's vastly more informative to see txtFirstName in your
code. It instantaneously tells you what the control does and what
type it is. In my personal projects, I'm not ready to let go of
hungarian at this time.

However, in SQL Server, I think it's improper form to use Hungarian
notation. tblCustomers looks bad, and you know it's a table. If
you're getting confused between views, tables, or even table valued
functions, then perhaps you need to do the suffix like Microsoft
suggests.

For your conflicting class names, such as Pen, I suggest you make a
short abbreviation alias in your using statements. For instance, if
your company name was Contoso and the full path to your Pen class was
Contoso.Windows.Controls.Writing.Instruments.Pen, then you could do
something as simple as:
using Contoso = Contoso.Windows.Controls.Writing.Instruments;

Then in your code, you can address it as:
private Contoso.Pen myPen = new Contoso.Pen();

I hope that helps you in your resolve to keep using Hungarian. Fight
the system! :)

Chris Benard
MCTS Windows, Web, SQL Server 2005

On Apr 24, 8:15 am, "Ronald S. Cook" <[e-mail]:

I've been weaning myself off of Hungarian notation because that's what
Microsoft is telling me to do, and I want to be a good little MS developer.
But things keep coming up that make me miss my little 3-character prefixes.

I'm fine with EmployeeFirstNameLabel instead of lblEmployeeFirstName, but at
the table and class level, I get frustrated because terms I want to use
reserved keywords.

I wanted "Event" and "User" as classes and table names. But, because those
are reserved words I have to be creative and come up with a non-ideal
alternative. Also, we have a class "Pen" which is allowed, but then can get
a little confusing (and I did say a little) with the Pen class in the
System.Drawing namespace (i.e. like when viewing Intellisense).

Now, I know I can bracket the table name but... yuk.

The main argument I hear against Hungarian is that a mouseover will tell you
the type so no need to type it in (especially since it could change). But
1) like many, I *read* code and seeing the type helps, and 2) refactoring
will allow me to easily retag my Hungarian tag with another.

Can someone please make me more comfortable leaving my Hungarian friend
behind? I'm not convinced that it's the best decision (from an app dev
standards policy in our shop).

Thanks,
Ron

[Sir Psycho]

Hey Ronald,

>From my experience, Its best not to worry about these sorts of things

and just get on with coding. If your contracting like myself, you'll
find different coding standards depending on where you work so really,
how you write your code shouldent be that important. A good coder will
stick to the standards currently used in the work place to make it
easy on future developments.

And really, if your coding at home for fun or something more serious,
your the only one looking at your code so whatever makes you happy
really.

And if your involved in a group project with people on the net, just
negotiate something and plug away at the real problem at hand.

Don't get caught up in little things like standards. Took me 10 years
to figure that out :)

Bye

On Apr 24, 11:15 pm, "Ronald S. Cook" <[e-mail]:

I've been weaning myself off of Hungarian notation because that's what
Microsoft is telling me to do, and I want to be a good little MS developer.
But things keep coming up that make me miss my little 3-character prefixes.

I'm fine with EmployeeFirstNameLabel instead of lblEmployeeFirstName, but at
the table and class level, I get frustrated because terms I want to use
reserved keywords.

I wanted "Event" and "User" as classes and table names. But, because those
are reserved words I have to be creative and come up with a non-ideal
alternative. Also, we have a class "Pen" which is allowed, but then can get
a little confusing (and I did say a little) with the Pen class in the
System.Drawing namespace (i.e. like when viewing Intellisense).

Now, I know I can bracket the table name but... yuk.

The main argument I hear against Hungarian is that a mouseover will tell you
the type so no need to type it in (especially since it could change). But
1) like many, I *read* code and seeing the type helps, and 2) refactoring
will allow me to easily retag my Hungarian tag with another.

Can someone please make me more comfortable leaving my Hungarian friend
behind? I'm not convinced that it's the best decision (from an app dev
standards policy in our shop).

Thanks,
Ron

[Dom]

I use Hungarian when I name controls, eg, btnNext, txtFilename, etc.
This sorts everything together in the intellisense window. But I
don't use it for variables. I think the argument there is that often
the type of the variable will change. Are you old enough to remember
wParam from the bad old days?

Dom
On Apr 24, 9:15 am, "Ronald S. Cook" <[e-mail]:

I've been weaning myself off of Hungarian notation because that's what
Microsoft is telling me to do, and I want to be a good little MS developer.
But things keep coming up that make me miss my little 3-character prefixes.

I'm fine with EmployeeFirstNameLabel instead of lblEmployeeFirstName, but at
the table and class level, I get frustrated because terms I want to use
reserved keywords.

I wanted "Event" and "User" as classes and table names. But, because those
are reserved words I have to be creative and come up with a non-ideal
alternative. Also, we have a class "Pen" which is allowed, but then can get
a little confusing (and I did say a little) with the Pen class in the
System.Drawing namespace (i.e. like when viewing Intellisense).

Now, I know I can bracket the table name but... yuk.

The main argument I hear against Hungarian is that a mouseover will tell you
the type so no need to type it in (especially since it could change). But
1) like many, I *read* code and seeing the type helps, and 2) refactoring
will allow me to easily retag my Hungarian tag with another.

Can someone please make me more comfortable leaving my Hungarian friend
behind? I'm not convinced that it's the best decision (from an app dev
standards policy in our shop).

Thanks,
Ron

[Susie DBA [MSFT]]

underscore naming convention sucks

an underscore is a wildcard character; stfu kid


On Apr 24, 10:47 am, Jon Skeet [C# MVP] <[e-mail]:

Peter Duniho <[e-mail]:

<snip>

I certainly don't see the point in switching your coding conventions just
because Microsoft has changed their mind about what the "standard" is. If
you do switch to the .NET conventions internally, you should do so because
there's some real benefit to *your* development team in doing so.

While I take your point, I think that consistency is a benefit in and
of itself. It would look very odd to, say, have all your own method
names in the_c_style_of_naming_with_underscores and still be calling
FrameworkMethodsWithPascalCasing. It just looks uneven and
inconsistent.

As you say though, there's nothing to stop you from naming variables
however you like.

--
Jon Skeet - <[e-mail]>http://www.pobox.com/~skeet Blog:http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too