Coffeehouse Thread

24 posts

The Hungarian Still Lives

Back to Forum: Coffeehouse
  • User profile image
    Minh

    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?


  • User profile image
    Sven Groot

    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#.

  • User profile image
    armbrat

    Same for controls...

  • User profile image
    JPeless

    I also use it for control names but nothing else.

  • User profile image
    W3bbo

    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; }
        }
        
    }
    
    

  • User profile image
    AndyC

    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 Smiley

  • User profile image
    W3bbo

    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 Smiley

  • User profile image
    Roginator

    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

  • User profile image
    AndyC

    W3bbo wrote:


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


    I don't need to - they suck too Smiley

  • User profile image
    W3bbo

    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?

  • User profile image
    Larry​Osterman

    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.

  • User profile image
    AndyC

    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()

  • User profile image
    Rossj

    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.

  • User profile image
    Minh

    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?

  • User profile image
    Sven Groot

    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.

  • User profile image
    TommyCarlier

    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/...).

  • User profile image
    blowdart

    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?

  • User profile image
    AndyC

    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?

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.