First of all, this is not a mandatory topic. You can name your variables whatever you like. However, you will soon come to understand that choosing significant variable names is a very good programming practice.
If you ask me, the term “generally accepted programming naming convention” is practically a joke. Even with long established naming conventions, there is always some smart guy or company out there that thinks they can re-invent the Universe, by modifying/creating new naming conventions. There is a general war out there among the programmers regarding which naming conventions are “good” and which are “evil”, so it is quite difficult to establish a standard.
In my opinion, it is best to stick to the practices that appeared a long time ago (possibly, the first practices that ever appeared) and that proved their efficiency by passing the test of time.
Hence, there are a few “rules” that you may want to adopt:
DO
Use PascalCasing for class names and method names:
Reason: keeping consistency with the Microsoft’s .NET Framework and easiness to read.
Use camelCasing for method arguments and local variables.
Reason: keeping consistency with the Microsoft’s .NET Framework and easiness to read.
Use PascalCasing for abbreviations 3 characters or more (2 chars are both uppercase):
Reason: consistent with the Microsoft’s .NET Framework. Two successive capital letters would visually steal too much attention.
Use predefined type names instead of system type names like Int16, Single, UInt64, etc:
Reason: Consistent with the Microsoft’s .NET Framework, makes code more natural to read, shortens typing.
Use noun or noun phrases to name a class:
Reason: Consistent with the Microsoft’s .NET Framework, easy to remember, casing differentiates classes by variables
Use letter I as prefix for interfaces. Interface names are noun (phrases) or adjectives:
Reason: Consistent with the Microsoft’s .NET Framework.
Use organized namespaces with a clearly defined structure
Reason: Consistent with the Microsoft’s .NET Framework. Maintains good organization of your code base.
Use capital letters for constants or readonly variables:
Reason: consistent with the Microsoft’s .NET Framework. Quickly identifies a read-only value.
DO NOT
Use Hungarian notation or any other type identification in identifiers:
Reason: consistent with the Microsoft’s .NET Framework and Visual Studio IDE makes determining types very easy (via tooltips). In general you want to avoid type indicators in any identifier.
Use abbreviations. Exceptions: abbreviations commonly used as names, such as Id, Xml, Ftp, Uri:
Reason: Consistent with the Microsoft’s .NET Framework and prevents inconsistent abbreviations.
Use underscores in identifiers. Exception: you can prefix private static variables and constants:
Reason: Consistent with the Microsoft’s .NET Framework. Makes code more natural to read (without ‘slur’). Also avoids underline stress (inability to see underline).
Many of the concepts presented in these examples are still unfamiliar to you. Do not concern yourself with that, for now. However, once in a while, when you will become more advanced and you will develop the usual and inevitable programming “habits”, do come back and refer to this article again, before “the evil takes roots too deep” and you find yourself stuck with a poor choice in choosing significant variable names that will be much harder to correct.
The concepts explained in this lesson are also shown visually as part of the following video:
Tags: best programming practices, variable names, variable naming conventions, variables
