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

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 2

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 3

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 Code smell, 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 4

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!