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 EmployeeFirstNa meLabel instead of lblEmployeeFirs tName, 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" <r...@westinis. comwrote:

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 EmployeeFirstNa meLabel instead of lblEmployeeFirs tName, 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 programmaticall y 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 TableLayoutPane l, 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.Writi ng.Instruments. Pen, then you could do
something as simple as:
using Contoso = Contoso.Windows .Controls.Writi ng.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" <r...@westinis. comwrote:

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 EmployeeFirstNa meLabel instead of lblEmployeeFirs tName, 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" <r...@westinis. comwrote:

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 EmployeeFirstNa meLabel instead of lblEmployeeFirs tName, 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" <r...@westinis. comwrote:

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 EmployeeFirstNa meLabel instead of lblEmployeeFirs tName, 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] wrote:

Peter Duniho <NpOeStPe...@Nn OwSlPiAnMk.comw rote:

<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_und erscores and still be calling
FrameworkMethod sWithPascalCasi ng. 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