Code Naming Guidelines
I've tried to maintain a consistent set of naming rules for my code. However, sometimes I get into the "zone" of programming and my typing-thread out paces my neat-thread.
Here's a few guidelines that I've collected over the years. Most of guidelines came from Microsoft's Design Guidelines for Class Library Developers.
Feature |
Naming Guidelines |
|---|---|
Namespace |
CompanyName.TechnologyName[.Feature][.Design]
Pascal case for namespaces Example: System.Drawing |
Class |
Use a noun or noun phrase to name a class.
Use Pascal case. Do not use the underscore character. Example: AppDomain |
Enumeration |
Pascal case for Enum types and value names.
Use abbreviations sparingly. Use a singular name for most Enum types, but use a plural name for Enum types that are bit fields. Example: ErrorLevel (type) |
Parameter |
Use camel case.
Use descriptive parameter names. Use names that describe a parameter's meaning rather than names that describe a parameter's type. Do not prefix parameter names with Hungarian type notation. Example: typeName |
Method |
Use verbs or verb phrases to name methods.
Use Pascal case. Example: ToString |
Property |
Use a noun or noun phrase to name properties.
Use Pascal case. Do not use Hungarian notation. Example: BackColor |
Event |
Use Pascal case.
Use an EventHandler suffix on event handler names. Consider naming events with a verb. For example, correctly named event names include Clicked, Painting, and DroppedDown. Use a gerund (the "ing" form of a verb) to create an event name that expresses the concept of pre-event, and a past-tense verb to represent post-event. For example, a Close event that can be canceled should have a Closing event and a Closed event. Do not use the BeforeXxx/AfterXxx naming pattern. Do not use a prefix or suffix on the event declaration on the type. For example, use Close instead of OnClose.Do not use Hungarian notation. Example: ValueChange |
Exception Class |
Use Pascal case.
Always ends with the suffix Exception. Example: WebException |
Interface |
Use Pascal case.
Always begins with the prefix I. Example: IDisposable |
Abbreviations
- Do not use abbreviations or contractions as parts of identifier names. For example, use GetWindow instead of GetWin.
- Do not use acronyms that are not generally accepted in the computing field.
- Where appropriate, use well-known acronyms to replace lengthy phrase names. For example, use UI for User Interface and OLAP for On-line Analytical Processing.
- When using acronyms, use Pascal case or camel case for acronyms more than two characters long. For example, use HtmlButton or htmlButton. However, you should capitalize acronyms that consist of only two characters, such as System.IO instead of System.Io.
- Do not use abbreviations in identifiers or parameter names. If you must use abbreviations, use camel case for abbreviations that consist of more than two characters, even if this contradicts the standard abbreviation of the word.



November 2nd, 2007 - 21:15
Hi,
Can you please explain, why we should not use Hungarion
Notation for variable declaration in .NET
Regards
Saravanan Sundaresan
November 4th, 2007 - 20:19
Saravanan,
There’s a few different articles that describes why. And in the end, it is a personal preference since anyone can name their variables in any manner they see fit.
The usual argument is that you don’t need to use Hungarian notation in strongly typed languages, since you already know what type the object is, so its just redundant information.
I still use Hungarian notation only for WebControls and Form Controls, but nothing else (besides starting all interfaces with “I”). Just so that the object names sort easier in the drop downs, etc.
Here’s a few article links:
http://aspalliance.com/74_Hungarian_in_NET.2
http://msdn2.microsoft.com/en-us/library/ms229045.aspx
http://blogs.techrepublic.com.com/programming-and-development/?p=397