Are variable prefixes (“Hungarian notation”) reall

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 6 years ago.

Since C# is strongly typed, do we really need to prefix variables anymore?

e.g.

iUserAge
iCounter
strUsername

I used to prefix in the past, but going forward I don't see any benefit.

Answer 1

No, we don't need them. I used to follow this when back in the days, we were forced to follow that kind of a coding standard.

Also with Intellisense, Code Definition Window and Refactoring tools built into VS and other third party plugins like CodeRush express and Refactor Pro, it's easier to work with code without it.

Answer 2

I use it all the time but that could because I use VBA with Access and Excel.

For me CountAll is a name intCountAll is a name with this difference that it additionially describes the name (never intended for machines just for humans) like sintCountAll tells me its static pintCountAll private and gintCountAll global so for the purpose I use it; it is very usefull.

• control names is a time safer like instead of ControlName I have lblControlName, txtControlName, cboControlName, lstControlName etc so when I use VBA I just type lst and I have all the names I need so I don't have to remember what is the exact name which saves me a lot of time but again this is mainly VBA in Access and Excel.

Regards Emil

Answer 3

The short answer is NO. But...

I see the point of getting away from Hungarian notation, the standards in our shop forbid it, too, but I still find it useful in my one-off or little utility projects for one reason and one reason only: when I am coding to a large number of controls in a web or win form, using HN makes it easy to use Intellisense make sure I catch every single control while coding.

If I have a five checkboxes and their names all start with chk then typing chk gives me the list of every one of them and I can easily pick which one I'm working on that moment.

Also, sometimes I find myself wondering "what the heck was that checkbox named again?" And I have to break off and look in the .ASPX page again.

One way I have compromised is to begin with HN, and then once I have gotten the main code in a win or web form complete, my last step is to do global renames for the HN-named controls. This has actually worked well for me. YMMV, of course.

Answer 4

I sometimes use a kind of prefix where pName is a parameter passed into my function (notice I don't prefix the type), oName is local to my current method, mName is a member to the class I'm in and cName is a constant or static readonly member.

Personally I find it helps.

Answer 5

Prefixes are a leftover from the VB (and older!) days when Hungarian Notation was king. That is no longer the case, though the C# community does mandate things like using a prefix of Capital I for interfaces (e.g. ILoadable).

The current Microsoft Guidelines are here.

Answer 6

Hungarian notation is no longer needed to identify data types like in your string example, but it still can be useful for identifying characteristics of variables in other ways. Here's a good article that talks about useful ways of using the Hungarian notation: http://www.joelonsoftware.com/articles/Wrong.html

Here's an excerpt

"In Simonyi’s version of Hungarian notation, every variable was prefixed with a lower case tag that indicated the kind of thing that the variable contained.

For example, if the variable name is rwCol, rw is the prefix.

I’m using the word kind on purpose, there, because Simonyi mistakenly used the word type in his paper, and generations of programmers misunderstood what he meant."

He also uses an example of identifying strings prefixed with an 's' or a 'u' to identify if they are secure to print out or not, so that a statement like print(uSomeString); can easily be identified as wrong.