CODING
STANDARD
MANUAL
Change Log:
Date Person Description
Mar 08, 2010 Dipti &Rajesh Created
C#.Net Naming Conventions
Private Variables Naming Guidelines
Use Camel-style notation.
Example:
firstName, employees
Local Variables Naming Guidelines
Use Camel case as a general rule, or uppercase for very small
words.
Example:
Public string AFunction()
{
firstName, employees
. . . .
. . . .
}
Namespace Naming Guidelines
The general rule for naming namespaces is to use the company
name followed by the technology name and optionally the
feature and design as follows:
CompanyName.TechnologyName[.Feature][.Design]
Prefixing namespace names with a company name or other
well-established brand avoids the possibility of two published
namespaces having the same name. Use a stable, recognized
technology name at the second level of a hierarchical name.
Use Pascal case as a general rule, or uppercase for very small
words.
Example:
Akadia.Traffic, System.Web.UI, System.Windows.Forms,
Talibaan.Alkiada
Class Naming Guidelines
Use nouns, noun phrases or occasionally adjective phrases with Pascal case.
Do not give class names a prefix (such as the letter C).
Do not use the underscore character (_).
Example:
FileStream, XMLConverter, Patient, PatientCollection
Interface Naming Guidelines
Use nouns, noun phrases or occasionally adjective phrases with
Pascal case.
Prefix an Interface name with a capital “I”.
Do not use the underscore character (_).
Example:
IServiceProvider, IFormatable
Parameter Naming Guidelines
Use Camel cased 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:
Type GetType(string typeName)
string Format(string format, object[] args)
Method Naming Guidelines
Use verbs or verb phrases in Pascal case to name methods.
Example:
RemoveAll(), GetCharAt()
Property / Enumerations Naming Guidelines
Use a noun or noun phrase in Pascal case to name properties.
Example:
BackColor, NumberOfItems
Event Naming Guidelines
Use Pascal case with an “EventHandler” suffix on event
handler names.
Specify two parameters named sender and e. The sender
parameter represents the object that raised the event. The
sender parameter is always of type object, even if it is possible
to use a more specific type. The state associated with the event
is encapsulated in an instance of an event class named "e".
Use an appropriate and specific event class for the e parameter
type.
Name an event argument class with the EventArgs suffix.
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.
In general, you should provide a protected method called
OnXxx on types with events that can be overridden in a derived
class. This method should only have the event parameter e,
because the sender is always the instance of the type
Example:
public delegate void MouseEventHandler(object sender,
MouseEventArgs e);
public class MouseEventArgs : EventArgs
{
int x;
int y;
public MouseEventArgs(int x, int y)
{ this.x = x; this.y = y; }
public int X { get { return x; } }
public int Y { get { return y; } }
}
Exception Naming Guidelines
Use "ex" as a standard variable name for an Exception object.
Example:
catch (Exception ex)
{
// Handle Exception
}
Constant Naming Guidelines
The names of variables declared class constants should be all
uppercase with words separated by underscores. It is recommended to
use a grouping naming schema.
Example:
AP_WIN_MIN_WIDTH, AP_WIN_MAX_WIDTH,
AP_WIN_MIN_HIGHT, AP_WIN_MAX_HIGHT
Visual Control Type Notation
Prefix the names of controls with the following:
Control Prefix
Assembly asm
Button btn
CheckBox cbx
ComboBox cmb
Container ctr
DataColumn dcol
DataGrid dgrid
DataGridDateTimePickerColumn dgdtpc
DataGridTableStyle dgts
DataGridTextBoxColumn dgtbc
DataReader dreader
DataRow drow
DataSet dset
DataTable dtable
DateTime date
Dialog dialog
DialogResult dr
Exception ex
GroupBox gbx
HashTable htbl
ImageList iml
Label lbl
ListBox lbx
ListView lv
MarshallByRefObject rmt
Mainmenu mm
MenuItem mi
MDI-Frame frame
MDI-Sheet sheet
NumericUpDown nud
Panel pnl
PictureBox pbx
RadioButton rbtn
SDI-Form form
SqlCommand sqlcom
SqlCommandBuilder sqlcomb
SqlConnection sqlcon
SqlDataAdapter sqlda
StatusBar stb
StringBuilder strb
TabControl tabctrl
TabPage tabpage
TextBox tbx
ToolBar tbr
ToolBarButton tbb
Timer tmr
UserControl usr
WindowsPrincipal wpl
1. Coding Guidelines – General
SQL Queries: always write all SQL query strings in UPPER CASE
KISS: Always keep it (code blocks/procedures/classes/projects)
small and simple. Avoid writing very big functions/classes
Write ‘INDEPENDENT’ code: Use KISS method to write
modular code. And, also make sure to avoid logical dependency
between modules.
Remember: modularity or logical in-dependency must be
achieved at higher level (class/class library, etc), also at lowest
level (different blocks in a single function)
Nesting: Avoid deeply nested code
Error handlers: Always use Error handlers.
Debug/error messages: Always include sufficient error/debug
messages in code, so that it would be easier to debug code when
some bug is found.
example: debug logs similar to following should be generated
when refreshing trips -
- Triprefresh() : start
- SQL query - “SELECT TRIPS FROM TRIPS WHERE ……”
- 102 records found in database
- refresh completed successfully
- TripRefresh() : End
Comments:
Rule 1: Your code must become self-explanatory using all above
conventions. So, there should not be any need to write
comments like “Initializing variables, filling object, cleaning up
variables, etc.”
Rule 2: when the code logic in not self-explanatory, or, in case of
any assumptions/considerations/complex algorithm, write
explicit detailed comments
Indentations: Your code MUST be indented properly
Always use TAB key for indentation, NEVER use spaces.
Constants: Never use magic numbers or strings
e.g. if (UserID > 255) then ….
Always declare and use constants.
e.g. if (UserDI > MAX_USER_ID) then …
Abbreviations: Do not use abbreviations or contractions as
parts of identifier names. For example, use GetWindow instead
of GetWin
Technology specific conventions: never use technology
specific conventions, at least for public identifiers.
e.g. Never write -
Sub Write(doubleValue As Double)
Preferred way -
Sub Write(Value As Double);
Remove Temporary Code before check-in
All unnecessary code such as comments, TODOs should be
removed before checkin
2. Code Comment:-
Single line comment in source code format
DOS-Action No/Handler Name
Example:
If(i==1) //DOS-111/Rajesh Gour
Multi line comment in source code format
//>> DOS-Action No/Handler Name
Multiple lines
//<< DOS-Action No/Handler Name
Example:
//>> DOS-111/Rajesh Gour
For(int j=0;j<=10;j++)
If()
}
Else
//<< DOS-111/Rajesh Gour
Final word:
Try to use all above standards, and make sure that one day you will adopt
them up to your DNA level, so that you will never need to refer this
document again.
