.NET Tutorials, Forums, Interview Questions And Answers
Welcome :Guest
Sign In
Win Surprise Gifts!!!

Top 5 Contributors of the Month
Melody Anderson

Home >> Articles >> .Net Framework >> Post New Resource Bookmark and Share   

 Subscribe to Articles

Coding guidelines

Posted By:Dhiraj Ranka       Posted Date: January 31, 2011    Points: 200    Category: .Net Framework    URL: http://www.dotnetspark.com  

This article explains Microsoft Best practice coding guidelines

Capitalization Rules for Identifiers

Identifier Case Example
Class Pascal AppDomain
Enumeration type Pascal ErrorLevel
Enumeration values Pascal FatalError
Event Pascal ValueChanged
Exception class Pascal WebException
Read-only static field Pascal RedValue
Interface Pascal IDisposable
Method Pascal ToString
Namespace Pascal System.Drawing
Parameter Camel typeName
Property Pascal BackColor

Capitalization Rules for Acronyms

Do capitalize both characters of two-character acronyms, except the first word of a camel-cased identifier.

A property named DBRate is an example of a short acronym (DB) used as the first word of a Pascal-cased identifier. A parameter named ioChannel is an example of a short acronym (IO) used as the first word of a camel-cased identifier.

Do capitalize only the first character of acronyms with three or more characters, except the first word of a camel-cased identifier.

A class named XmlWriter is an example of a long acronym used as the first word of a Pascal-cased identifier. A parameter named htmlReader is an example of a long acronym used as the first word of a camel-cased identifier.

Do not capitalize any of the characters of any acronyms, whatever their length, at the beginning of a camel-cased identifier.

A parameter named xmlStream is an example of a long acronym (xml) used as the first word of a camel-cased identifier. A parameter named dbServerName is an example of a short acronym (db) used as the first word of a camel-cased identifier.

Names of Assemblies and DLLs

Consider naming DLLs according to the following pattern:


Where contains one or more dot-separated clauses.

Word Choice

Do choose easily readable identifier names. For example, a property named HorizontalAlignment is more readable in English than AlignmentHorizontal.

Do favor readability over brevity. The property name CanScrollHorizontally is better than ScrollableX (an obscure reference to the X-axis).

Do not use underscores, hyphens, or any other nonalphanumeric characters.

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.

Avoid using identifiers that conflict with keywords of widely used programming languages.

Abbreviations and Acronyms

In general, you should not use abbreviations or acronyms. These make your names less readable. Similarly, it is difficult to know when it is safe to assume that an acronym is widely recognized.

Do not use abbreviations or contractions as parts of identifier names.

For example, use OnButtonClick rather than OnBtnClick.

Do not use any acronyms that are not widely accepted, and then only when necessary.

Names of Namespaces

The general format for a namespace name is as follows:
For example, Microsoft.WindowsMobile.DirectX.

Do prefix namespace names with a company name to prevent namespaces from different companies from having the same name and prefix.

Do use a stable, version-independent product name at the second level of a namespace name.

Do not use organizational hierarchies as the basis for names in namespace hierarchies, because group names within corporations tend to be short-lived.
The namespace name is a long-lived and unchanging identifier. As organizations evolve, changes should not make the namespace name obsolete.

Do use Pascal casing, and separate namespace components with periods (for example, Microsoft.Office.PowerPoint). If your brand employs nontraditional casing, you should follow the casing defined by your brand, even if it deviates from normal namespace casing.

Consider using plural namespace names where appropriate. For example, use System.Collections instead of System.Collection. Brand names and acronyms are exceptions to this rule, however. For example, use System.IO instead of System.IOs.

Do not use the same name for a namespace and a type in that namespace. For example, do not use Debug for a namespace name and also provide a class named Debug in the same namespace. Several compilers require such types to be fully qualified.

Namespaces and Type Name Conflicts

General Namespace Guidelines

Do not introduce generic type names such as Element, Node, Log, and Message. There is a very high probability it would lead to type name conflicts in common scenarios. You should qualify the generic type names (FormElement, XmlNode EventLog, SoapMessage).

Application Namespace Guidelines

Do not give the same name to types in namespaces within a single application model.
For example, if you were writing a library of special controls to be used by Windows forms application developers, you should not introduce a type named Checkbox because a type with this name already exists for the application model.

Core Namespace Guidelines

Do not give types names that would conflict with any type in the core namespaces.
For example, do not use Directory as a type name because this would conflict with the Directory type.

Technology Namespace Guidelines

Do not assign type names that would conflict with other types within a single technology.
Do not introduce type name conflicts between types in technology namespaces and an application model namespace (unless the technology is not intended to be used with the application model).


 Subscribe to Articles


Further Readings:


No response found. Be the first to respond this post

Post Comment

You must Sign In To post reply
Find More Articles on C#, ASP.Net, Vb.Net, SQL Server and more Here

Hall of Fame    Twitter   Terms of Service    Privacy Policy    Contact Us    Archives   Tell A Friend