Coding Standards & Guidelines

You can download the word document from here

 

Naming Guidelines

Capitalisation Styles

Pascal Case:

The first letter in the identifier and the first letter of each subsequent concatenated word are capitalized. E.g. TaskName.

Camel Case:

The first letter of an identifier is lowercase and the first letter of each subsequent concatenated word is capitalized. E.g. taskName

Upper Case:

All letters in the identifier are capitalized. Use this convention only for identifiers that consist of two or fewer letters. E.g. System.Web.UI

Hungarian notation:

Hungarian notation is a naming convention in programming where the naming of a variable indicates its usage. Hungarian notation was designed to be language-independent eg. lSerialNumber — indicates that the variable is of type long 

The following table summarizes the capitalization rules and provides examples for the different types of identifiers.

Identifier

Case

Example

Class

Pascal

ScheduleOff

Enum type

Pascal

ErrorLevel

Enum values

Pascal

FatalError

Event

Pascal

ValueChange

Exception class

Pascal

WebException

Read-only Static field

Pascal

RedValue

Interface

Pascal

IDisposable

Method

Pascal

ToString

Namespace

Pascal

FedEx.COMPASS

Parameter

Camel

typeName

Property

Pascal

AssignScheduleOffDate

Case Sensitivity

  •          Do not use names that require case sensitivity.
  •          Do not create namespaces with names that differ only by case.
  •          Do not create a function with parameter names that differ only by case.
  •          Do not create a namespace with type names that differ only by case.
  •          Do not create a type with property names that differ only by case.
  •          Do not create a type with method names that differ only by case.

Abbreviations

  •          Do not use abbreviations or contractions as parts of identifier names. For e.g.: use GetManagers and not GetMngrs.
  •          Do not use acronyms that are not generally used in the computer field.
  •          Where appropriate, use well-known acronyms to replace lengthy phrase names. For example, use UI for User Interface.
  •          When using acronyms use the Pascal case or camel case for acronyms more than two characters long. For e.g.: use HTMLControl or HtmlControl
  •          Avoid using class names that duplicate commonly used .NET Framework namespaces. For example, do not use any of the following names as a class name: System, Collections, Forms, or UI. 

Class Name Guidelines

  •          Use a noun or noun phrase to name a class.
  •          Use Pascal case.
  •          Use abbreviations sparingly.
  •          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.
  •          Do not use the underscore character (_).
  •          Occasionally, it is necessary to provide a class name that begins with the letter ‘I’, even though the class is not an interface. This is appropriate as long as ‘I’ is the first letter of an entire word that is a part of the class name.
  • Where appropriate, use a compound word to name a derived class. The second part of the derived class's name should be the name of the base class.

Namespace Naming Guidelines

  •  The general rule is to use the company name followed by the project name and optionally the feature and design – Wipro.HRWEB.[Module].[Screen]
  • A nested namespace should have dependency on the types in the containing namespace. For e.g. – System.Web.UI and System.Web.UI.Design
  • Use plural namespace name appropriate. For e.g. – System.Collections
  • Do not use the same name for namespace and a class.

Interface Naming Guidelines

  •          Name interfaces with nouns or noun phrases, or adjectives that describe behavior.
  •          Use Pascal case.
  •          Use abbreviations sparingly.
  •          Prefix interface names with the letter I, to indicate that the type is an interface.
  •          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 (_).

Attribute and Enumeration type Naming Guidelines

  •          Add the suffix Attribute to custom attribute classes.
  •          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.
  •      Always add the FlagsAttribute to a bit field Enum type.

Static Field Naming Guidelines

  •          Use nouns, noun phrases, or abbreviations of nouns to name static fields.
  •          Use Pascal case.
  •          Use a Hungarian notation prefix on static field names.
  •          It is recommended to use static properties instead of public static fields whenever possible. 

Parameter Naming Guidelines

  •          Use descriptive parameter names with camel casing.
  •          Use names that describe a parameter's meaning rather than names that describe a parameter's type. Use type-based parameter names sparingly and only where it is appropriate.
  •          Do not prefix parameter names with Hungarian type notation.

Method and Property Naming Guidelines

  •          Use verbs or verb phrases to name methods.
  •          Use a noun or noun phrase to name properties.
  •          Use Pascal case.
  •          Do not use Hungarian notation.
  •          Consider creating a property with the same name as its underlying type.

Constant Naming Conventions

  •          Use a mixed-case format in which constant names have a "const" prefix.
  •          E.g.: constYourOwnConstant

Variable Naming Conventions

To enhance readability and consistency, use the following prefixes with descriptive names for variables

Data Type

Prefix

Example

Boolean

bln

blnFound

Byte

byt

bytRasterData

Date (Time)

dtm

dtmStart

Double

dbl

dblTolerance

Error

err

errOrderNum

Integer

int

intQuantity

Long

lng

lngDistance

Object

obj

objCurrent

Single

sng

sngAverage

String

str

strFirstName

 

 

 

Variable Declaration

  •          <Data Type> <Space> <var1>;
  •          E.g: String strMonth;

Comments

Comments are necessary at the start of each section, logical block of program code and critical statements. Comments should briefly expalin the purpose of the statements that follow.

E.g: ‘This is a comment line

Object Naming Convention

The following table lists recommended conventions for objects

Web Form Controls

 

Object Type

Prefix

Example

Button

btn

btnSubmit

Checkbox

chk

chkMon

CheckedListBox

clb

clbTemplates

Combobox

cbo

cboLocation

RadioButton

rad

radGender

CrystalReportViewer

crv

crvMaxSettings

MonthCalendar

cal

calEmpScheduleOff

Panel

pnl

pnlDailyMaxSettings

GridView

gdv

gdvEmployees

Label

lbl

lblState

LinkLabel

lnk

lnkEmpSchDetails

ListView (3.5)

lvw

lvwData

LinqDataSourceControl (3.5)

ldsc

ldscTestdatabase

ListBox

lsb

lsbBPCategories

MainMenu and MenuItem

mnu

mnuTasks

TabControl

tab

tabRoute

TextBox

txt

txtEmpName

ToolTip

tip

tipContinue

Tree Node

tvn

tvnLocations

TreeView

tvw

tvwCountries

Image

img

imgLogo

MultiView

mvw

mvwTasks

Update Panel

upl

uplTasks

Calendar

cal

calShiftPlanner

UserControl

ucl

uclCalendar

Table

tbl

tblEmpDetails

Data List

dls

dlsTasks

Repeater

rpt

rptCertification

PlaceHolder

phd

phdTask

RadioButtonList

rbl

rblTemplates

RangeValidator, RegularExpressionValidator, RequiredValidator, ValidationSummary ,etc

val

valMonthDays

Table

tbl

tblTasks

TableCell

tcl

tclWk

TableRow

trw

trwFirstRow

 

 

 

 Note: Form objects follow class naming conventions.

  •          Server controls that support server-based AJAX development. This includes the ScriptManager, UpdatePanel, UpdateProgress, and Timer controls. These controls enable you to create rich client behavior with little or no client script, such as partial-page rendering and displaying update progress during asynchronous postbacks.

ADO.NET

           

Object Type

Prefix

Example

Connection

con

conCompass

Command

cmd

cmdManagers

DataAdapter

da

daEmployees

DataColumn

dc

dcEmail

DataReader

dr

drTasks

DataRow

drw

drwDeletedShift

Dataset

ds

dsTasks

DataTable

dt

dtRoutes

DataView

dv

dvLineHauls

Parameter

prm

prmEmpId

Transaction

trn

trnUpdateShifts

 

 

 

Class Member Usage Guidelines

Property Usage Guidelines

  •          Decide whether the requirement is for a property or a method.
  •          Avoid creating a property with the same as an existing type.
  •          Use a property when the member is a logical data member.
  •          Use a read-only property when the user cannot change the property's logical data member. Do not use write-only properties.
  •          Use only one indexed property per class, and make it the default-indexed property for that class.
  •          Do not use non default-indexed properties.
  •          Use an indexed property when the property's logical data member is an array.

Method Usage Guidelines

  •          Do not use Hungarian notation.
  •          By default, methods are not overridable. Maintain this default in situations where it is not necessary to provide overridable methods.
  •          Use method overloading to provide different methods that do semantically the same thing.
  •          Use method overloading instead of allowing default arguments. Default arguments do not version well.
  •          Use default values correctly. In a family of overloaded methods, the complex method should use parameter names that indicate a change from the default state assumed in the simple method.
  •          Use a consistent ordering and naming pattern for method parameters. It is common to provide a set of overloaded methods with an increasing number of parameters to allow the developer to specify a desired level of information.
  •          Use method overloading for variable numbers of parameters. Where it is appropriate to specify a variable number of parameters to a method, use the convention of declaring n methods with increasing numbers of parameters.

Constructor Usage Guidelines

  •          Provide a default private constructor if there are only static methods and properties on a class.
  •          Minimize the amount of work done in the constructor. Constructors should not do more than capture the constructor parameter or parameters.
  •          Provide a Protected constructor that can be used by types in a derived class.
  •          Don’t provide an empty constructor for a value type structure.
  •          Use parameters in constructors as shortcuts for setting properties. There should be no difference in semantics between using an empty constructor followed by property set accessor, and using a constructor with multiple arguments.
  •          Use a consistent ordering and naming pattern for constructor parameters.

Field Usage Guidelines

  •          Do not use instance fields that are Public or Protected. If you avoid exposing fields directly to the developer, classes can be versioned more easily because a field cannot be changed to a property while maintaining binary compatibility. Consider providing get and set property accessors for fields instead of making them public.
  •          Expose a field to a derived class by using a protected property that returns the value of the field.
  •          It is recommended that you use read-only static fields instead of properties where the value is a global constant.
  •          Spell out all words used in a field name. Use abbreviations only if developers generally understand them. Do not use uppercase letters for field names.
  •          Do not use Hungarian notation for field names. Good names describe semantics, not type.
  •          Do not apply a prefix to field names or static field names. Specifically, do not apply a prefix to a field name to distinguish between static and non static fields. For example, applying a g_ or s_ prefix is incorrect.
  •          Use public static read-only fields for predefined object instances. If there are predefined instances of an object, declare them as public static read-only fields of the object itself. Use Pascal case because the fields are public.

Parameter Usage Guidelines

  •          Check for valid parameter arguments. Perform argument validation for every public or protected method and property set accessor. Throw meaningful exceptions for invalid parameter arguments.
  •          The actual checking does not necessarily have to happen in the public or protected method itself. It could happen at a lower level in private routines.

Type Usage Guidelines

Base Class Usage Guidelines

  •          Use base classes instead of interfaces whenever possible.
  •          From a versioning perspective, classes are more flexible than interfaces.
  •          Provide class customization through protected methods.
  •          The public interface of a base class should provide a rich set of functionality for the consumer of the class. However, users of the class often want to implement the fewest number of methods possible to provide that rich set of functionality to the consumer.
  •          Provide a set of non virtual or final public methods that call through to a single protected method that provides implementations for the methods. This method should be marked with the Impl suffix. Using this pattern is also referred to as providing a Template method.
  •          Many compilers will insert a public or protected constructor if you do not. Therefore, for better documentation and readability of your source code, you should explicitly define a protected constructor on all abstract classes.
  •          Use sealed classes if it will not be necessary to create derived classes. A class cannot be derived from a sealed class.

Inheritance Usage Guidelines

  •          Examine your objects for parent-child relationships to identify possible super classes from which to derive your subclasses.
  •          Look for multiple levels of parent-child relationships to build and Inheritance Tree.
  •          Override attributes in the derived class when the inherited functionality does not fit your needs. (If you are overriding most of the inherited functions, then this probably is not a good candidate for inheritance.)
  •          When modeling, decide which super class functions can be overridden and which must be overridden, and declare these as Overridable or Must Override

Usage Guidelines

  • Use structure for types that meet the following criteria:Act like primitive types.
    •  Have an instance size fewer than 16 bytes. 
    • Are immutable.
    • Value semantics are desirable.
  • When using a structure, do not provide a default constructor. The runtime will insert a constructor that initializes all the values to a zero state.
  • Use an enum to strongly type parameters, properties, and return types. Always define enumerated values using an enum if they are used in a parameter or property.
  • Do not assume that enum arguments will be in the defined range. Perform argument validation
    Use an enum instead of static final constants.
  • Use type Int32 as the underlying type of an enum unless either of the following is true:
  • The enum represents flags and there are currently more than 32 flags, or the enum might grow to many flags in the future.
  • The type needs to be different from int for backward compatibility.
  • Do not use a non integral enum type. Use only Byte, Int16, Int32, or Int64.
  • Do not define methods, properties, or events on an enum.
  • Do not use an Enum suffix on enum types.

Nested Type Usage Guidelines

  • Use Nested types when –
    • The nested type logically belongs to the containing type.
    •  The nested type is not used often, or at least not directly.
    •  Do not use Nested types when –
      •   The type is used in many different methods in different classes.
      •   The type is commonly used in different APIs.

Last edited Jun 28, 2014 at 8:39 PM by mrinmoyd, version 5