Coding standards and Naming conventions

This post will helps you to understand basic coding conventions.

A consistent naming pattern is one of the most important elements of predictability and discover-ability in a managed class library.

Purposes of coding conventions

• They create a consistent look to the code, so that readers can focus on content, not layout.
• They enable readers to understand the code more quickly by making assumptions based on previous experience.
• They facilitate copying, changing, and maintaining the code.

Capitalization Styles

• Pascal Case

The first letter in the identifier and the first letter of each subsequent concatenated word are capitalized. Use Pascal Casing for class names and method names.

public class TestClass
{
public void TestStatus()
{
//...
}
public void GetStatus()
{
//...
}
}

• Camel case

The first letter of an identifier is lowercase and the first letter of each subsequent concatenated word is capitalized. Use camel Casing for method arguments and local variables.

public class UserLog
{
public void Add(LogEvent logEvent)
{
int itemCount = logEvent.Items.Count;
// ...
}
}

General rules for Identifiers

• Do not use Hungarian notation or any other type identification in identifiers.

// Correct
int rollNumber;
string name;

// Wrong
int iRollNumber;
string strName;

• Do not use Screaming Caps for constants or read-only variables.

// Correct
public static const string ShippingType = "DropShip";

// Avoid
public static const string SHIPPINGTYPE = "DropShip";

• Do not use Underscores in identifiers. Exception: you can prefix private static variables with an underscore.

// Correct
public DateTime lastUpdated;
public TimeSpan timeLeft;

// Avoid
public DateTime last_Updated;
public TimeSpan time_Left;

// Exception
private DateTime _registrationDate;

• Use predefined type names instead of system type names like Int16, Single, UInt64, etc

// Correct
string firstName;
int lastIndex;
bool isSuccess;

// Avoid
String firstName;
Int32 lastIndex;
Boolean isSuccess;

• Use implicit type var for local variable declarations. Exception: primitive types (int, string, double, etc) use predefined names.

var stream = File.Create(path);
var customers = new Dictionary();

// Exceptions
int index = 100;
string timeSheet;
bool isCompleted;

Case Sensitivity

To avoid confusion and guarantee cross-language inter-operation, follow these rules regarding the use of case sensitivity. Do not use names that require case sensitivity. Components must be fully usable from both case-sensitive and case-insensitive languages.

• Do not create two namespaces with names that differ only by case.

namespace ee.cummings;
namespace Ee.Cummings;

• Do not create a function with parameter names that differ only by case.

void MyFunction(string a, string A)

• Do not create a type with property names that differ only by case. In the following example, int Color and int COLOR are inappropriate property names because they differ only by case.

int Color {get, set}
int COLOR {get, set}

• Do not create a type with method names that differ only by case. In the following example,calculate and Calculate are inappropriate method names because they differ only by case.

void calculate()
void Calculate()

Abbreviations

• Do not use abbreviations or contractions as parts of identifier names.
• 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.

// Correct
UserGroup userGroup;
Assignment employeeAssignment;

// Avoid
UserGroup usrGrp;
Assignment empAssignment;

// Exceptions
HtmlHelper htmlHelper;
XmlDocument xmlDocument;
FtpHelper ftpHelper;
UriPart uriPart;

Class Naming 

• Use a noun or noun phrase to name a class.
• Use Pascal case.
• Use abbreviations sparingly.
• Do not use the underscore character (_).
• Do not use a type prefix, such as C for class, on a class name. For example, use the class name FileStream rather than CFileStream.

public class Employee
{
}
public class BusinessLocation
{
}

Interface Naming

• Use Pascal case.
• Use abbreviations sparingly.
• Prefix interface names with the letter I, to indicate that the type is an interface.
• Name interfaces with nouns or noun phrases, or adjectives that describe behavior. For example, the interface name IComponent uses a descriptive noun. The interface name ICustomAttributeProvider uses a noun phrase. The name IPersistable uses an adjective.
• Use similar names when you define a class/interface pair where the class is a standard implementation of the interface. The names should differ only by the letter I prefix on the interface name.
• Do not use the underscore character (_).

public interface IShape
{
}
public interface IShapeCollection
{
}

Enumeration Type Naming

The enumeration (Enum) value type inherits from the Enum Class.

• Use Pascal case for Enum types and value names.
• Use abbreviations sparingly.
• Do not use an Enum suffix on Enum type names.
• Use a singular name for most Enum types, but use a plural name for Enum types that are bit fields.
• Do not explicitly specify a type of an enum or values of enums (except bit fields).

// Correct
public enum Color
{
Red,
Green,
Blue,
Yellow,
Magenta,
Cyan
}

[Flags]
public enum Dockings
{
None = 0,
Top = 1,
Right = 2,
Bottom = 4,
Left = 8
}

// Don't
public enum Direction : long
{
North = 1,
East = 2,
South = 3,
West = 4
}
// Don't
public enum CoinEnum
{
Penny,
Nickel,
Dime,
Quarter,
Dollar
}

 

Thanks 🙂