Hungarian Notation Vs. Pascal Notation?

[Grey Squirrel]

On wednesday my company will have an open ended discussion whether to
standardize hungarian notation or pascal/cammel case notation. We'd
love to recieve some feedback on what other people are using out there
and why. Thanks!

 

[Aidy]

I'd love to work at your company (not)



Use camel for c# and Pascal for VB cos that's just the standard. There,
I've saved you a meeting.

Just use what you want.

 

[sloan]

a very strict "non hungarian policy" here.

However, hungarian is used and recommended for UI components.

txtFirstName
ddlDepartment

...

string lastName = "Jones";
int deptId = 0;

 

[Nick]

On wednesday my company will have an open ended discussion whether to
standardize hungarian notation or pascal/cammel case notation. We'd
love to recieve some feedback on what other people are using out there
and why. Thanks!

We use pascal and cammel case. Not only because it is the standard
coding convention for .NET as seen in

* http://msdn2.microsoft.com/en-us/library/ms229043.aspx
* http://msdn2.microsoft.com/en-us/library/ms229045.aspx

--- from coding standards on MSDN ---
Do not use abbreviations or contractions as parts of identifier names.
For example, use OnButtonClick rather than OnBtnClick.
------

In addition we stay way from Hungarian notation because I encourage my
developers to take a more object oriented approach to their naming by
naming things by functional group names. Such as

LoginName
LoginPassword
LoginGoToLocationList
LoginSendButton

Instead of the Hungarian way which scatters the names all over the
list like:

txtName
txtPassword
ddlLocation
btnSend

In addition another benefit of not using Hungarian is the ability to
be more flexible and agile when coding.

If you decide all Lists are going to end with the postfix "List" for
drop down, combo boxes, and everything in between. It is a lot easier
to adjust the interface if somebody wants to go from a combo box to a
drop down list.

SomethingList

However if you use Hungarian you have to rename all your variables to
go from a drop down list to a combo box, if you still want to maintain
your naming convention, which is the original reason why you are
having this meeting.

ddlSomething
cmbSomething

Hope this helps.

 

[Steve C. Orr [MCSD, MVP, CSM, ASP Insider]]

Hungarian notation is old fashioned.
It was useful in the pre- .NET days but nowadays there are far too many
object types for Hungarian notation to still be very useful.
If you use it at all it should mostly be limited to prefixing standard
controls only.

 

[Mike Hofer]

On wednesday my company will have an open ended discussion whether to
standardize hungarian notation or pascal/cammel case notation. We'd
love to recieve some feedback on what other people are using out there
and why. Thanks!

VB .NET developer here.

Pre .NET, I used Hungarian. However, I avoid it like the plague now. I
use camel case for variable names; Pascal case for everything else.

As Steve Orr pointed out, the problem is that you have far too many
types out there. You'd end up with potentially hundreds or thousands
of abbreviations. Who could possibly remember them all?

Besides, it's the compiler's job to ensure that your code is type-
safe. VB.NET does this on the fly. If you're using C#, I believe that
VS.NET 2005 does it on the fly as well. (Someone correct me if I'm
wrong.)

The whole point of Hungarian notation was to ensure that the variables
on two sides of an operator were of the same type. .NET languages are
inherently strongly typed. It's required by the CTS. It's one of the
reasons that the use of Hungarian is actively discouraged by
Microsoft.

Don't waste your time adopting Hungarian. It's a relic of the past,
and won't tell you anything that the compiler isn't already telling
you.

Mike

 

[Steve C. Orr [MCSD, MVP, CSM, ASP Insider]]

I've written up a fairly thorough answer to your question here:

http://SteveOrr.net/faq/HungarianNotation.aspx