2.15Local variables

The following rules outline the naming guidelines for local variables:

• Use camel case for parameter names.

• Use descriptive parameter names. However, in for cycle, it is possible to use System.Int32 variable with name i (and j, if necessary).

• Avoid unnecessary abbreviations.

For example,

int accumulator;

String result;

double spin = 0.5;

for (int i = 0; i < size; i++) { … }

2.16Type parameters

The following rules outline the naming guidelines for type parameters:

• Use Pascal case.

• Do name generic type parameters with descriptive names, unless a single letter name is completely self-explanatory and a descriptive name would not add value.

• Consider using T as the type parameter name for types with one single letter type parameter.

• Do prefix descriptive type parameter names with “T”.

• Consider indicating constraints placed on a type parameter in the name of parameter. For example, a parameter constrained to ISession may be called TSession.

For example,

public interface ISessionChannel<TSession> { … }

public delegate TOutput Converter<TInput, TOutput>(TInput from);

public class List<T> { … }

2.17Summary

Identifier	Case	Example
Class	Pascal	Application
Enum	Pascal	ErrorLevel
Enum value	Pascal	FatalError
Event	Pascal	ValueChange
Exception class	Pascal	WebException (always ends with Exception)
Attribute class	Pascal	VersionAttribute (always ends with Attribute)
Interface	Pascal	IDisposable (always starts with I)
Method	Pascal	ToString
Namespace	Pascal	System
Parameter	Camel	typeName
Property	Pascal	BackColor
Private field	Camel	redValue
Non-private field	Pascal	RedValue
Local variable	Camel	accountType
Type parameter	Pascal	TSession

3.Comments

3.1Introduction

All source code documenting inside source files has to follow C# language specification (“Documentation comments” appendix). Specific additions are described in the following sub-sections.

3.2Class comments

Although it’s recommended to provide enough details on each source code part (method, class, etc) in accordance with C# language specification, at least class <summary> section is absolutely mandatory. No file should be delivered without this part of source code documentation.

3.3Method comments

All public and protected methods should have detailed documentation. <summary> section is absolutely mandatory. If method throws non-trivial exceptions they should be documented (for example, NullReferenceException in case of passing null parameter may not be documented). Parameters and return value should be documented if method is complex or its name is not enough understandable.

3.4Inline comments

Non-trivial code should be obligatory documented. It relates to: algorithms (for example, fast Fourier transform), not documented features usage, some non-trivial optimizations, etc.

It may be convenient to place specific comments indicating that some source code is not finalized yet and still require further changes or improvements. In the same time, intermediate source code versions may be released prior to such “finalization”. In that case, the following way should be used to declare intention of applying some modifications to that part of source code in the future:

// TODO: <Details of planned modification/improvement>

This comment should be placed either just before target source code part or at the end of the first line of target source code part.

Example:

// TODO: Use caching mechanism here.

Service service = GetService();