Standards – Coding in ASP. Net

STANDARDS FOR CODING IN ASP.Net

1.0Objectives

The objective of this document is to define coding standards for programs developed in ‘ASP.Net ’

2.0Scope

This standard applies to programs developed in ‘ASP.Net’.

3.0 References (checklists, guidelines, forms, processes, standards, …..)

None.

4.0 Responsibilities

  • The Project Manager is responsible for ensuring that these coding standards are followed while developing the programs.

5.0 Document structure, Glossary of terms, etc.:

This document is structured in the following manner:

  1. Objectives
  1. Scope
  2. References
  3. Responsibilities
  4. Document Structure, Glossary of terms, etc.

This document is structured in the following manner:

  • .Net Framework Design Standards
  • Naming and Capitalization
  • User Interface Objects and Controls
  • Namespaces
  • Commenting code
  • Functions & Subroutines
  • Generic rules

6.0 Net Framework Design Standards

Follow all .NET Framework Design Guidelines for both internal and external members. Highlights of these include:

  • Do not use Hungarian notation (except for private member variables).

Variables are prefixed with lower-case letters to indicate their data type

For example: intStream

  • Do use the m_ prefix for private Class level member variables.
  • Do use camelCasing for member variables.

Capitalizes the first character of each word except the first word.

For example: fileStream

  • Do use camelCasing for parameters.
  • Do use camelCasing for local variables.
  • Do use PascalCasing for function, property, event, and class names.

Capitalizes the first character of each word.

For example: FileStream

  • Do prefix interfaces names with “I”
  • Do not prefix enums, classes, or delegates with any letter
  • Do not use single-letter naming for variables.
  • Avoid using constants, use Enum instead. However, when you can’t avoid using constants, use PascalCasing.
  • Do uses ex as the local exception variable in a Try…Catch statement.

7.0Naming and Capitalization

Below summarizes the naming recommendations for identifiers in .Net. Pascal casing is used mainly (ie capitalize first letter of each word) with camel casing (capitalize each word except for the first one) being used in certain circumstances.

Identifier / Case / Examples / Additional Notes
Class / Pascal / Person, BankVault, SMSMessage, Dept / Class names should be based on "objects" or "real things" and should generally be nouns.
Method / Pascal / GetDetails, UpdateStore / Methods should use verbs or verb phrases.
Parameter / camel / personName, bankCode
Interface / Pascal with "I" prefix / IDisposable / One of the few times when prefixing is adopted.
Property
Associated private member variable / Pascal
_camelCase / ForeColor, BackColor
_foreColor, _backColor / Use underscore camel casing for the private member variables, but keep the names the same as associated property accessors.
Exception Class / Pascal with "Exception" suffix / WebException, SMSException
Event / Pascal plus optional "EventHandler" suffix where relevant / btnSubmit_Click, Painting, Click, Clicked, MyEventHandler / VS uses underscores to separate an object from its event. Be careful with tense (pre/past), e.g. a Close event that can be canceled should have a Closing event and a Closed event. MS also recommend adding the "EventHandler" suffix where thought needed.

Note that acronym parts of phrases may be all in uppercase (e.g. SMSMessage) where relevant.

User interface objects (text boxes drop down lists etc) are treated as a special case and discussed in the next section.

8.0User Interface Objects and Controls

The Microsoft .Net guidelines do not go into detail on the naming of user interface objects (again probably because they are only objects after all), but one approach that is well adopted is the use of the "control type" prefix convention (similar to Hungarian style often used in VB, C++ etc). Although this should not be used for indicating variable types, it is useful for user interface controls as it makes it explicitly clear where user interface elements are in your code.

Some samples are below for ASP.Net web form controls:

Control / Prefix / Example
Label / lbl / LblSurname
TextBox / txt / TxtSurname
DataGrid / dg / DgResults
Button / btn / BtnSave
ImageButton / ibtn / IbtnSave
Hyperlink / lnk / lnkHomePage
DropDownList / ddl / DdlCompany
ListBox / lst / LstCompany
DataList / dlst / DlstAddress
Repeater / rep / RepSection
Checkbox / chk / ChkMailList
CheckBoxList / chk / ChkAddress
RadioButton / rdo / RdoSex
RadioButtonList / rdo / RdoAgeGroup
Image / img / ImgLogo
Panel / pan / PanSection
PlaceHolder / plh / PlhHeader
Calender / cal / CalMyDate
Adrotator / adr / AdrBanner
Table / tbl / TblResults
[All] Validators / val / valCreditCardNumber
ValidationSummary / vals / ValsErrors

9.0Namespaces

All namespace should use Pascal casing and be prefixed with your company (and department if you wish). See examples below:

Sample "project level" namespaces:

YourCompany.YourDept.YourProject
Visualize.Blog

Generic reusable routines, classes etc which will be used across projects, can sit at the 'company' or 'dept' level, for example:

Visualize.Utils

10.0Commenting code

Code should be commented where necessary and C# XML commenting tags used, to aid VS intellisense, object browsing and on-line documentation generation if needed. Example: some sample C# source is given below for a method in an SMS tool I developed recently:

///<summary>
///SendSMSMessage sends a text message to a valid mobile number
///</summary>
///<param name="mobileNo">Mobile number to send to in format +44 1234 112233</param>
///<param name="message">Message itself, max 160 chars</param>
///<returns>Message result string from gateway</returns>
public string SendSMSMessage(string mobileNo,string message)
{
// rest of code here...

11.0Functions and Subroutines

Any functions used should be prefixed with “fun” and subroutines with “sub”

12.0Generic Rules

  • Before using any declared objects check whether “Is Nothing” is true then initialize object else reuse.
  • After usage of objects is done, destroy it and free the space.
  • Do not keep any unnecessary commented code on the code behind/html page.
  • The code should always be written within a Try…Catch…Finally block and exceptions should be handled in Catch block.
  • Perform activity 4 mostly in finally block of Try…Catch…Finally.

Datamatics Company ConfidentialVersion No.2.0.0Page 1 of 5