what is the accepted naming convention for int, string, array, list, object, etc...

Question

The company I work for now uses a set naming convention for their C# variables such as iSomeName for int, sSomeName for string, aSomeName for arrays, bSomeName for boolean, dSomeName for datetime and so on. My previous employer did not use the i, s, a, b and d prefixes and just named the variables a good understandable name. My impression is that these prefixes lost favor a while ago and from what I read it is not the current trend. It seems fine to me either way as long as the variable is descriptive enough to understand what it is doing but I was wondering what the now-a-day accepted practice is for naming variables?

Answer 1

Your previous employer was more in line with current practices. Prefixing variables with codes is not currently considered best practice. You should only do it now and then if it clarifies code, and it usually doesn't. The apparent need for any type of prefixing should be considered a minor bad small, indicating that the current routine is probably too complex. Time is better spent improving the code rather than putting in prefixes.

See Hungarian Notation for a history of this practice. The version called Apps Hungarian notation means the prefix helps indicate the variable's purpose, rather than its type. This is legitimate every once in a while, but should seldom be necessary. The more common practice is called Systems Hungarian notation, where the prefix indicates the type. This is (thankfully) becoming less common.

Don't be too depressed to have to do this. There are many worse practices that we are compelled to implement. If this is as bad as it gets, you're lucky. And having some standards (as long as they're not crazy) is better than no standards.

Answer 2

The "modern" and "popular" way to do it is without the Hungarian Notation (the i, s, etc.). The reason for this is that refactoring is more of an issue anymore. What this means is essentially changing code in bulk rather than specifically over time. When you refactor things, Hungarian Notation makes it hard to do properly as it tends to be done with the help of various tools and these tools don't know everybody's custom Hungarian Notation standards.

Imagine if you had an iAge member variable on an object that was an integer. Well, what if you wanted to change this this from an int to a long because this age was in milliseconds? Well, then you'd also have to rename it to lAge now. Changing types is easy and something that can be automated, but "creative standard naming" is much more difficult to do. And really, having an i or an l before this Age variable - does it REALLY tell you anything more about what the code is doing? Sure, it tells you the data type, but hover over it in any modern IDE and that will tell you the data type as well.

In short, the "modern preference" is making sure the intention of your code is easy to ready. The trivial stuff like data types in Hungarian Notation only confuses that. Code is hard enough to read as it is - don't make it worse!

Answer 3

Well, a lot of naming depends on the language you are using.. camelCase or PascalCase or underscore_variables. Naming them correctly/readable/understandable is the most important thing.

Relating this prefixing (or Hungarian Notation): It is adressed specifically in the MSDN: General Naming Conventions in C# article:

[...]

Do not use Hungarian notation.

Hungarian notation is the practice of including a prefix in identifiers to encode some metadata about the parameter, such as the data type of the identifier.

[...]

Answer 4

The usual advice to these questions though is to be consistent within your own code and within your employers'; if your employer uses Hungarian notation, you should use it too regardless of accepted practices.

Answer 5

Modern accepted practice for C# is to not use Hungarian notation. Instead, best practice is to use an understandable and descriptive variable name.

StyleCop is often used to enforce code formatting standards in C# and by default is does not allow Hungarian notation although it does allow exceptions through configuration.

Answer 6

Your current employer is using Systems Hungarian Notation

I personally don't see the value in this naming convention, as most development environments will provide colored syntax highlighting and variable inspection so you can easily determine the type. In the worst case it is confusing, as you may alter the type of a variable but not alter the variable "prefix":

double iCount = 0.0;

Answer 7

You need to refer to the Framework Design Guidelines, specifically Chapter 3. The same information (without the annotations for the "back story") is available online.

The naming system your current employer is using is called Hungarian notation and is no longer recommended by Microsoft. (In fact, the majority of places don't use it anymore.)

Answer 8

Yeah, Hungarian is not too used anymore, and I think its preferable to use meaningful names that are self-explanatory.

If you want to read a nice article (maybe forward it to the big wigs :P) about it, check out Joel's take on Making Code Ugly and the Hungarian Notation, it is a nice explanation of why the Hungarian notation was made, and how it has been misused for generations.