The Hungarian Still Lives

I've found myself abandoning hunGarian notation in .net for everything except control names. I can't seem to let go.

What are your moral, ethical, or legal issues for naming DescriptionTextBox instead of txtDescription?

Same here, I use it only for control names.

I've also given up using it in C++. Nowadays, the style I use in C++ is mostly the same as what I use in C#.

Same for controls...

I also use it for control names but nothing else.

Minh wrote:

I've found myself abandoning hunGarian notation in .net for everything except control names. I can't seem to let go.

What are your moral, ethical, or legal issues for naming DescriptionTextBox instead of txtDescription?

when using VB and using simple properties that map to private variables I use hunGarian for the private variables rather than the typical underscore prefix (which doesn't show up in the VB IDE thanks to the horizontal lines)

So something like this:

public class Foo {
    
    private string strBar = string.Empty;
    
    public string Bar {
        get {
            return strBar; }
        set {
            strBar = value; }
    }
    
}

Reasons Hungarian notation is a pile of old (expletive deleted) :

1) You end up with so many prefixes you need a lookup table to figure out what they mean.

2) It breaks IntelliSense - autocomplete works so much better when you don't have 400 variables all starting szyppq...

3) The IDE tells me what type something is and does it much better them some arcane codes

4) It discourages encapsulation - I should be able to change the internal representation of something without changing the name

5) It looks ugly

AndyC wrote:

2) It breaks IntelliSense - autocomplete works so much better when you don't have 400 variables all starting szyppq...

So justify the use of "To", "Get", and "Set" method prefixes

AndyC wrote:

Reasons Hungarian notation is a pile of old (expletive deleted) :

1) You end up with so many prefixes you need a lookup table to figure out what they mean.

2) It breaks IntelliSense - autocomplete works so much better when you don't have 400 variables all starting szyppq...

3) The IDE tells me what type something is and does it much better them some arcane codes

4) It discourages encapsulation - I should be able to change the internal representation of something without changing the name

5) It looks ugly

Andy is right on all counts, although I suppose #5 is subjective.

The bottom line is, hungarian breaks when you have more than 3-4 data types, and yes this counts with controls too. What do you prefix a calendar? A free text box control? A grid view?

These questions also demonstrate another flaw of hungarian: what if you had a grid-type control in 1.1 such as a DataGrid, but your data type changed in 2.0 to grid view?

You should be able to change data types such as this easily without re-writing code. You shouldn't have dgUsers and then change it to gvUsers. It should have been named UsersGrid all along.

The same applys with the text box example: you should be able to change your text control into a 3rd party "rich" text control without re-naming anything.

Here's my last example: I name all generic listing controls [something]List. The minute you try to call it a "drop-down" list, or *shudder* "ddl", you may need to change it into a multiple select list. Or even a checkbox list.

And, as Andy already mentioned, there's no point in grouping things in intellisence by raw data type. If you want something related to users, you probably want UserName to appear near UserList or UserGrid. It's a rare case that you would care if something is an int32 or an int16 or a string, etc.

This is just my view on the matter, but I know very well that this is a matter of religion for most folks, so take it with a grain of salt.

Roger

W3bbo wrote:

So justify the use of "To", "Get", and "Set" method prefixes

I don't need to - they suck too

AndyC wrote:

W3bbo wrote: So justify the use of "To", "Get", and "Set" method prefixes

I don't need to - they suck too

Well, I use the "Vulcan" approach:

For example:

Foo FooGet(string Name);
void FooAdd(Foo NewFoo);
List<Foo> FooList();

What system do you use?

W3bbo wrote:

Well, I use the "Vulcan" approach:

For example:

Foo FooGet(string Name);
void FooAdd(Foo NewFoo);
List<Foo> FooList();

What system do you use?

For get/set - C# properties with names that identify what it is I want to get/set. Where you have FooAdd , I'd have a method called Add, overloaded as necessary.

But yes, I'd tend to use suffixes in the case of things like FooList()

Unfortunately recent exposure to Objective-C has caused me to start writing long method names like
  [mainForm SetDisplayOptionsOnDisplay: d WithPresets: p] and
  [bloomFilter LoadItemsFromFile: s WithDelimiter:'@']. 

To me that's fine, it is what I prefer, but sometimes it is a real effort to switch to my customer's preferred style during the day - currently terse C like method names.

I guess my point is make sure you differentiate between your style and your employers style,  your team lead will not thank you when all of your code is in a different style to everyone else's.

LarryOsterman wrote:

Minh wrote:I've found myself abandoning hunGarian notation in .net for everything except control names. I can't seem to let go. What are your moral, ethical, or legal issues for naming DescriptionTextBox instead of txtDescription?

You have a class named "TXT"?  What does the TXT class do?

If you don't, then it's not hungarian, but camelCase.

I meant the habbit of the Hungarian notation from the C++ days, which was carried over to the VB6 days, then partially to .Net. I'm only doing that for control names these days.

Another topic is the "m_" prefix for C++ member variables. It's really nice to differentiate member variables from local-function variables, and I'm using "_" instead of "m_" in .Net. Can't say I'm totally happy with it 'cuz sometimes you have to do this._myVar ... but it's better than nothing, I guess.

What are you guys doing for member variables?

Minh wrote:

LarryOsterman wrote: Minh wrote: I've found myself abandoning hunGarian notation in .net for everything except control names. I can't seem to let go. What are your moral, ethical, or legal issues for naming DescriptionTextBox instead of txtDescription? You have a class named "TXT"?  What does the TXT class do? If you don't, then it's not hungarian, but camelCase.

I meant the habbit of the Hungarian notation from the C++ days, which was carried over to the VB6 days, then partially to .Net. I'm only doing that for control names these days.

Another topic is the "m_" prefix for C++ member variables. It's really nice to differentiate member variables from local-function variables, and I'm using "_" instead of "m_" in .Net. Can't say I'm totally happy with it 'cuz sometimes you have to do this._myVar ... but it's better than nothing, I guess.

What are you guys doing for member variables?

_pascalCase in C# and C++, and mCamelCase in VB.

I follow the naming guidelines, except for private class fields and local variables inside a method. For those I use fName and lName. That way, I can always look at a variable, and see whether it's an argument (name), a field (fName), a local variable (lName) or anything else (Name: property/constant/...).

blowdart wrote:

I love how intellisense seems to be a common arguement for dropping Hungarian.

So no-one else has ever tried to fix something on a remote server in notepad?

I'll bite. Do you think the loss in productivity in the >99% scenario (devs working on code in VS) is justified by the negligable benefits in the <1% case?