The Stack Overflow podcast is back! Listen to an interview with our new CEO.
3 Corrected stupid typo.
source | link

At the moment I still use Hungarian for exactly three reasons, judiciously avoiding it for everything else:

  1. To be consistent with an existing code base when doing maintenance.
  2. For controls, eg. "txtFirstName". We often need to distinguish between (say) "firstName" the value and "firstName" the control. Hungarian provides a convenient way to do this. Of course, I could type "firstNameTextBox", but "txtHungarian""txtFirstName" is just as easy to understand and is less characters. Moreover, using Hungarian means that controls of the same type are easy to find, and are often grouped by name in the IDE.
  3. When two variables hold the same value but differ by type. For example, "strValue" for the value actually typed by the user and "intValue" for the same value once it has been parsed as in integer.

I certainly wouldn't want to set up my ideas as best practice, but I follow these rules because experience tells me that it occasional use of Hungarian benefits code maintainability but costs little. That said, I constantly review my own practice, so may well do something different as my ideas develop.


Update:

I've just read an insightful article by Eric Lippert, explaining how Hungarian can help make wrong code look wrong. Well worth reading.

At the moment I still use Hungarian for exactly three reasons, judiciously avoiding it for everything else:

  1. To be consistent with an existing code base when doing maintenance.
  2. For controls, eg. "txtFirstName". We often need to distinguish between (say) "firstName" the value and "firstName" the control. Hungarian provides a convenient way to do this. Of course, I could type "firstNameTextBox", but "txtHungarian" is just as easy to understand and is less characters. Moreover, using Hungarian means that controls of the same type are easy to find, and are often grouped by name in the IDE.
  3. When two variables hold the same value but differ by type. For example, "strValue" for the value actually typed by the user and "intValue" for the same value once it has been parsed as in integer.

I certainly wouldn't want to set up my ideas as best practice, but I follow these rules because experience tells me that it occasional use of Hungarian benefits code maintainability but costs little. That said, I constantly review my own practice, so may well do something different as my ideas develop.


Update:

I've just read an insightful article by Eric Lippert, explaining how Hungarian can help make wrong code look wrong. Well worth reading.

At the moment I still use Hungarian for exactly three reasons, judiciously avoiding it for everything else:

  1. To be consistent with an existing code base when doing maintenance.
  2. For controls, eg. "txtFirstName". We often need to distinguish between (say) "firstName" the value and "firstName" the control. Hungarian provides a convenient way to do this. Of course, I could type "firstNameTextBox", but "txtFirstName" is just as easy to understand and is less characters. Moreover, using Hungarian means that controls of the same type are easy to find, and are often grouped by name in the IDE.
  3. When two variables hold the same value but differ by type. For example, "strValue" for the value actually typed by the user and "intValue" for the same value once it has been parsed as in integer.

I certainly wouldn't want to set up my ideas as best practice, but I follow these rules because experience tells me that it occasional use of Hungarian benefits code maintainability but costs little. That said, I constantly review my own practice, so may well do something different as my ideas develop.


Update:

I've just read an insightful article by Eric Lippert, explaining how Hungarian can help make wrong code look wrong. Well worth reading.

2 Added link to Lippert article.
source | link

At the moment I still use Hungarian for exactly three reasons, judiciously avoiding it for everything else:

  1. To be consistent with an existing code base when doing maintenance.
  2. For controls, eg. "txtFirstName". We often need to distinguish between (say) "firstName" the value and "firstName" the control. Hungarian provides a convenient way to do this. Of course, I could type "firstNameTextBox", but "txtHungarian" is just as easy to understand and is less characters. Moreover, using Hungarian means that controls of the same type are easy to find, and are often grouped by name in the IDE.
  3. When two variables hold the same value but differ by type. For example, "strValue" for the value actually typed by the user and "intValue" for the same value once it has been parsed as in integer.

I certainly wouldn't want to set up my ideas as best practice, but I follow these rules because experience tells me that it occasional use of Hungarian benefits code maintainability but costs little. That said, I constantly review my own practice, so may well do something different as my ideas develop.


Update:

I've just read an insightful article by Eric Lippert, explaining how Hungarian can help make wrong code look wrong. Well worth reading.

At the moment I still use Hungarian for exactly three reasons, judiciously avoiding it for everything else:

  1. To be consistent with an existing code base when doing maintenance.
  2. For controls, eg. "txtFirstName". We often need to distinguish between (say) "firstName" the value and "firstName" the control. Hungarian provides a convenient way to do this. Of course, I could type "firstNameTextBox", but "txtHungarian" is just as easy to understand and is less characters. Moreover, using Hungarian means that controls of the same type are easy to find, and are often grouped by name in the IDE.
  3. When two variables hold the same value but differ by type. For example, "strValue" for the value actually typed by the user and "intValue" for the same value once it has been parsed as in integer.

I certainly wouldn't want to set up my ideas as best practice, but I follow these rules because experience tells me that it occasional use of Hungarian benefits code maintainability but costs little. That said, I constantly review my own practice, so may well do something different as my ideas develop.

At the moment I still use Hungarian for exactly three reasons, judiciously avoiding it for everything else:

  1. To be consistent with an existing code base when doing maintenance.
  2. For controls, eg. "txtFirstName". We often need to distinguish between (say) "firstName" the value and "firstName" the control. Hungarian provides a convenient way to do this. Of course, I could type "firstNameTextBox", but "txtHungarian" is just as easy to understand and is less characters. Moreover, using Hungarian means that controls of the same type are easy to find, and are often grouped by name in the IDE.
  3. When two variables hold the same value but differ by type. For example, "strValue" for the value actually typed by the user and "intValue" for the same value once it has been parsed as in integer.

I certainly wouldn't want to set up my ideas as best practice, but I follow these rules because experience tells me that it occasional use of Hungarian benefits code maintainability but costs little. That said, I constantly review my own practice, so may well do something different as my ideas develop.


Update:

I've just read an insightful article by Eric Lippert, explaining how Hungarian can help make wrong code look wrong. Well worth reading.

1
source | link

At the moment I still use Hungarian for exactly three reasons, judiciously avoiding it for everything else:

  1. To be consistent with an existing code base when doing maintenance.
  2. For controls, eg. "txtFirstName". We often need to distinguish between (say) "firstName" the value and "firstName" the control. Hungarian provides a convenient way to do this. Of course, I could type "firstNameTextBox", but "txtHungarian" is just as easy to understand and is less characters. Moreover, using Hungarian means that controls of the same type are easy to find, and are often grouped by name in the IDE.
  3. When two variables hold the same value but differ by type. For example, "strValue" for the value actually typed by the user and "intValue" for the same value once it has been parsed as in integer.

I certainly wouldn't want to set up my ideas as best practice, but I follow these rules because experience tells me that it occasional use of Hungarian benefits code maintainability but costs little. That said, I constantly review my own practice, so may well do something different as my ideas develop.