Hungarian Notation in C#

Azurewrath

Hi all,

In the first book I read, it was prefixing all variable names with 3 letter-data types, like strName, btnQuit, etc. Is it still popular or used with C#, because I saw some websites that tells not to use it

Do most people use it

Thanks,

aw

nobugz

It's had its hey-days many years ago. I don't see a lot of people using it anymore. It was useful back in the days of the 'C' compiler being sloppy about accepting frivolous type conversions. No more, C++ and all popular .NET languages scream at you when you try. My personal exception: Windows Forms controls. They all derive from the Control class and share a lot of properties. So I write "lblCost" and "txtCost".

Other than that, it's a religion.

Azurewrath

Thanks alot for replying.

So you mean you use it for windows controls But not for variables Also I realized what I meant wasn't hungarian notation. (checked on wikipedia)

I was basically talking about adding 3-letter prefix in front of variables, controls, etc like your examples and stuff like: intCount, strUserName, etc.

So is this kind of stuff popular in C#

Thanks again,

aw

Peter Ritchie

In addition to Hans' comments; early high-level languages had sever limitations on variable name lengths (I believe C originally had a 31 character limit) which severely limited what you could name your variables. With a lack of GUI-based IDEs with abilities like Intellisense, programmers really needed a way to tell more information about their identifiers by their name--hence Hungarian notation.

As high-level language languages increased their identifier naming limits (essentially unlimited), depending on language, eliminating the need for Hungarian notation. In fact, it has fallen out of favour because it is very subjective and reduces readability as a result (i.e. 'n' is a common prefix for integer in some languages but some people use 'i'

With essentially unlimited naming I prefer to spell things out: costButton, or costLabel. That cascades down into your event handlers and makes for a much more readable source code.

Matthew Watson

I agree with the previous two posts.

Also consider this: In a language that allows you to define new types, what prefixes would you use for all these new types It just doesn't scale.

nobugz

I found this KB article on Hungarian notation conventions. It gets pretty bizarre towards the bottom.

Azurewrath

Thanks alot people. But I was only using 3 letter prefix for controls representing control type, and for variables representing the data type. No other stuff like locals, globals, etc.

Is this still a disadvantage I saw this on alot of code, and thought using btn for Button is pretty useful.

What do you think

Thanks again,

aw

Peter Ritchie

Using prefixes like "btn" is typical for VB code, not for C# code. Plus, if you use something like FxCop or Code Analysis it will just spit out warnings that "btn" isn't an English word...

Myself, I prefer suffixes: okButton.

Azurewrath

Thanks man.

aw

James Curran

(I believe C originally had a 31 character limit)

Actually, for public symbols (functions mostly, but also extern varaibles), the limit was EIGHT characters! (limit of the linker actually). Hence such tongue-twisters as "printf", "scanf", "strcpy", "memcmp" instead of "printformatted" "scanformatted" "stringcopy" and "memorycompare"

Peter Ritchie

James Curran wrote:

(I believe C originally had a 31 character limit) Actually, for public symbols (functions mostly, but also extern varaibles), the limit was EIGHT characters! (limit of the linker actually). Hence such tongue-twisters as "printf", "scanf", "strcpy", "memcmp" instead of "printformatted" "scanformatted" "stringcopy" and "memorycompare"

That must have been before my time. The first C compiler I used had the 31 character limit...

Matthew Watson

Personally, I prefer prefixing rather than suffixing (if I do it at all).

The reason Simple! If you view a class in the class diagram tool, or the "members" list, it sorts things in alphabetical order.

If you start all the buttons with "button", then they'll all be together in the list.

Peter Ritchie

Matthew Watson wrote:

Personally, I prefer prefixing rather than suffixing (if I do it at all). The reason Simple! If you view a class in the class diagram tool, or the "members" list, it sorts things in alphabetical order. If you start all the buttons with "button", then they'll all be together in the list.

That's not alphabetical order, that's grouping. Handy, yes, if you want to group all your buttons together. But, if you want to deal with all the variables relating to a TextBox (like the label, event handlers, the control, etc.) then they'd be all over the place. Suffixing puts all the related variables together, like totalTextBox, totalLabel, totalLabel_Click, totalTextBox_TextChanged, etc.

I never need to see all the textboxes grouped together...

Matthew Watson

That's very true - when I use prefixing, it isn't normally for controls.

I would use prefixing for Form-derived classes, so all my forms appear together in lists of classes.
So instead of PatientDetailsForm and ExportDetailsForm, I'd use FormPatientDetails and FormExportDetails. Then all my forms are together in the solution explorer (which is a lot more useful than grouping all the buttons together...)

Having said that, I tend to create subfolders in which to put related classes like that, so it's probably not even necessary for me to prefix form classes either!

pawel.krakowiak

There is an article on MSDN entitled Guidelines for Names. It's also in the local MSDN help. I've seen a suggestion not to use prefixes in C#. I also used prefixes before, when I coded in Delphi, the company I worked at had a "standard" to prefix form controls, such as buttons (btnOK in Delphi, instead of okButton in C#). When I read those guideline articles I started refactoring my C# code.