none
Hungarian notation RRS feed

  • Question

  • What are the pros/cons of using Hungarian notation with Visual Studio? On one hand I can understand the usefulness of an identifier for variable-type. But since similar controls will all begin with the same letters (as opposed to beginning with unique descriptive names)... that seems to be a hindrance for the Intellisense feature of the IDE.  (Seems to me that a suffix-identifier -- like jobDescriptionCbo -- might be a better approach than cboJobDescription.)  But if Hungarian is the adopted standard, then if I use a different approach, others might struggle with interpreting my code.  So... what to do?  Thanks!
    Wednesday, March 18, 2015 4:23 PM

Answers

  • This is a question likely to generate a lot of personal opinions!

    The wiki page on Hungarian notation (here) contains a set of advantages and disadvantages along with some opinions from notable people.

    For what its worth, I would say that Hungarian notation in Visual Studio is not a very good idea, as C#/Visual Studio is a strongly-typed language and you would only be complicating the readability of the code and not adding any useful information.

    I believe its more worthwhile naming a variable according to what it represents rather than any technical type. For example, if a variable holds an email address then call it emailAddress. This variable might be a string, or it might be an EmailAddress class, but that shouldn't matter and by simply naming the variable according to its meaning you shield yourself from any later design decisions that may actually change the type.
    Wednesday, March 18, 2015 4:51 PM
  • Hungarian notation was invented in a time before good IDEs where everything you might know about a variable was tied to its name.  If you saw, say iValue, then you could assume it was an int without having to go find the definition.  cboType would let you know it was a combo box. 

    With modern IDEs you can generally cursor over an identifier and see its definition so the need for HN has pretty much plummeted.  Additionally in some IDEs, like VS, it can hinder the tools like Intellisense as you might know you have a variable containing payRate but if it is HN'ed then it is harder to find in a sorted list (i.e. was it fPayRate or dPayRate).

    HN is generally frowned upon now in code as adding no value.  There are still cases where it may make sense but as far as style goes it has generally been abandoned.

    Michael Taylor
    http://blogs.msmvps.com/p3net

    Wednesday, March 18, 2015 5:25 PM
    Moderator

All replies

  • This is a question likely to generate a lot of personal opinions!

    The wiki page on Hungarian notation (here) contains a set of advantages and disadvantages along with some opinions from notable people.

    For what its worth, I would say that Hungarian notation in Visual Studio is not a very good idea, as C#/Visual Studio is a strongly-typed language and you would only be complicating the readability of the code and not adding any useful information.

    I believe its more worthwhile naming a variable according to what it represents rather than any technical type. For example, if a variable holds an email address then call it emailAddress. This variable might be a string, or it might be an EmailAddress class, but that shouldn't matter and by simply naming the variable according to its meaning you shield yourself from any later design decisions that may actually change the type.
    Wednesday, March 18, 2015 4:51 PM
  • Hungarian notation was invented in a time before good IDEs where everything you might know about a variable was tied to its name.  If you saw, say iValue, then you could assume it was an int without having to go find the definition.  cboType would let you know it was a combo box. 

    With modern IDEs you can generally cursor over an identifier and see its definition so the need for HN has pretty much plummeted.  Additionally in some IDEs, like VS, it can hinder the tools like Intellisense as you might know you have a variable containing payRate but if it is HN'ed then it is harder to find in a sorted list (i.e. was it fPayRate or dPayRate).

    HN is generally frowned upon now in code as adding no value.  There are still cases where it may make sense but as far as style goes it has generally been abandoned.

    Michael Taylor
    http://blogs.msmvps.com/p3net

    Wednesday, March 18, 2015 5:25 PM
    Moderator