The Importances of Standards:
Coding is easy but writing an effecient code is hard. It is common practice that developer ignore the importance of the coding standards and guidelines due to project pressure and hectic deadlines. But they pay penalty for not using the coding standards in form of lot of rework when their program become ready for QA testing.
We can avoid a lot of hassle and hardship by following coding standards and guideline. For example, suppose you write a program without giving a variable a meaningful name and your program consists of many routines which are too big to understand. Your logic is very messy. Can you believe it how long will it take to debug the code. You maytake a lot of time even for fixing simple error.
The standards are importants because they allow group of people to commmunicate for the same perspective.
When it comes to any Software language coding standards, we can save a lot of time and rework by following coding standard for that particular language.
Code Documentation
Even with naming convention is in place, coding standard is very important. Depending on the objects being documented, it can tells us when it was created, and by whom.
Commenting Code
Comments are the most obvious form of code documentation. Use the appropriate comment style to comment your code. Comment headers provide an overview of various
sections of your code.
Writing Clean Code
Clean code means that the code that can easily be read by other programmers. The logic flow will be easy to follow, the object names will be self-descriptive and comments will be liberally sprinkled throughout.
The Sixty-Second Rule
A routine should be understandable within 60 seconds by a skilled developer. If it cannot, this is usually indicative of a problem with the routine (too long, not commented, convoluted). Be sure that your routines provide clarity in objective and operation by keeping them small, focused and well documented.
Single-Entry, Single-Exit
There is only one way to enter a method, and there should be only one way to exit a method. Instead of having several return statements in a routine, save results in a single variable, scoped at the method level, and use a single return when processing is complete
Correct Way
public string OverUnder (int a_iNumber)
{
// Code commenting template would go here…
string sReturnValue = “”;
if (a_iNumber < 5)
sReturnValue = “Under”;
else
sReturnValue = “Over”;
return sReturnValue;
}
Incorrect Way
public string OverUnder (int a_iNumber)
{
if (a_iNumber < 5)
return “Under”;
else
return “Over”;
}
Naming Convention
Name of the Variables and objects should be self descriptiive. It should help reader to understand the purpose of the objects or variable quickly and properly.
Notation Styles
Use the following three conventions for notating identifiers.
Pascal case
The first letter in the identifier and the first letter of each subsequent concatenated word are capitalized. You can use Pascal case for identifiers of three or more characters. For example:
Color BackColor;
Uppercase
All letters in the identifier are capitalized. Use this convention only for identifiers that consist of two or fewer letters. For example:
System.IO
System.Web.UI
Hungarian
Hungarian notation is a set of conventions for naming variables in which a programmer adds a meaningful prefix of one or several characters to the object’s name to identify what type of object it is. For example:
String sUserName;
Naming Variables Guidelines:
Hungarian notation is a set of conventions for naming variables in which a programmer adds a meaningful prefix of one or several characters to the object’s name to identify what type of object it is.
Consistancy in naming convention is very important.
Example:
DataType Name
Bool bIsValid
Integer iCounter
Char cStatus
.Net Controls
Button BtnAdd
ComboBox cboStates
Database Objects
Connection connMaster
Dataset dsEmp
Scope Modifiers
The following table depicts the various scope modifier prefixes to that will be used for all variables, parameters, and member functions contained within a class.
Examples:
Private:/Protected
Variable : _ : _UserName
Methods/Function: _GetUserName()
Property : _MyProperty
Public:
Variable : _ : UserName
Methods/Function: GetUserName()
Property : MyProperty
General:
|
General |
||
| Parameters | a_ | a_bCalcInProgress |
| Local variables | {none} | iCounter |
Namespace Naming Guidelines:All namespaces are to be determined in an orderly fashion. A new namespace selection must be ran by the Program Management group first for approval.
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]
For example:
XXX.Media
XXX.Media.Design
Prefixing namespace names with a company name or other well-established brand avoids the possibility of two published namespaces having the same name. For example, XXX.EMS is an appropriate prefix for the Email Management System.
Use a stable, recognized technology name at the second level of a hierarchical name. Use organizational hierarchies as the basis for namespace hierarchies. Name a namespace that contains types that provide design-time functionality for a base namespace with the .Design suffix. For example, the System.Windows.Forms.Design Namespace contains designers and related classes used to design System.Windows.Forms based applications.
A nested namespace should have a dependency on types in the containing namespace. For example, the classes in the System.Web.UI.Design depend on the classes in System.Web.UI. However, the classes in System.Web.UI do not depend on the classes in System.Web.UI.Design.
You should use Pascal case for namespaces, and separate logical components with periods, as in XXX.EMS.Exceptions. In the case where branding employs nontraditional casing, follow the casing defined by your brand, even if it deviates from the prescribed Pascal case. For example, the namespace XXX.eDelivery illustrate appropriate deviations from the Pascal case rule.
Use plural namespace names if it is semantically appropriate. For example, use System.Collections rather than System.Collection. Exceptions to this rule are brand names and abbreviations. For example, use System.IO rather than System.IOs.
Do not use the same name for a namespace and a class. For example, do not provide both a Debug namespace and a Debug class.
Finally, note that a namespace should parallel an assembly name. For example, if you name an assembly XXX.EMS.dll, it should to contain a XXX.EMS namespace.
Class Naming Guidelines
The following rules outline the guidelines for naming classes:
· 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. For example, the class name IdentityStore is appropriate.
· 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. For example, ApplicationException is an appropriate name for a class derived from a class named Exception, because ApplicationException is a kind of Exception. Use reasonable judgment in applying this rule. For example, Button is an appropriate name for a class derived from Control. Although a button is a kind of control, making Control a part of the class name would lengthen the name unnecessarily.
The following are examples of correctly named classes.
public class FileStream
public class Button
public class String
