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