C Coding Standards : Part1

//--------------------------------------------------------

// Creation date - 03rd March, 2010

// Last revision - 03rd March, 2010

//--------------------------------------------------------

1. Introduction:
I konw all of you know about C coding and many of you are good in that. So, what the hell is the CODING STANDARD! What shall I get from this black characters written down?
It is quite natural, those above things are giving you a itchy feeling in your brains. Let me explian. When I was merely a student of computer application, writting codes and running that properly and perfectly was enough for me. But after all these years of coding, I understand just working code is not enough. You need to maintain some standards in your coding style.
This makes your codes more orgnaized and readable (edible also), which makes your (and other coders) life easier in future.

2. General Coding Style:

2.1 Tabs:
The editor should be configured to save tabs as four spaces. This ensures that all fixed-character-width (where all the characters have same width) editors view the code in the same way.

2.2 Line Length:
No line should exceed the width of the typical source code editor. This is typically around 80 characters. Lines should not be allowed to "wrap" but rather should have line breaks at the end of each one.

2.3 Statement Indentation:
Each time a new scope is introduced, either through the use of a compound statement or the introduction of braces, the statements contained in the new scope should be indented 4 spaces (1 tab).

2.4 Braces:
2.4.1 Openning Braces
Wars have been fought over whether or not to place the opening brace on the same line as for, if, etc. statements (K&R style) or on the following line (Allman style). Either style is acceptable but it should be used consistently within a code file. The K&R style allows the code to be more compact and thus more eadible, but the opening brace is easily overlooked. The Allman style makes the opening and closing braces clearly visible (what I prefer).

// K&R Style
while (x <= 5) {

printf("Hello");

}

// Allman Style
if (x > 5)
{
printf("Goodbye");
}

2.4.2 CLosing Braces
It is strongly encouraged that closing braces are accompanied by a comment which indicates what the brace is closing. If there is a significant amount of code or multiple levels of braces surrounding the opening and closing braces, this comment is required.

For Example:
for(int i = 0; i <>

{

...

} // for i

2.5 Use of Blank Lines:
It is acceptable to use a single blank line to separate areas of functionality within a method. No more than a single blank line should be used within the body of a method. Two blank lines should be used to separate the end of one method body from the beginning of another.

2.6 Always Check Return Codes:
If the unexpected happens, it can be hard to track down if code isn’t paying attention to return values of the called functions. For this reason, every function or method that has a return code should have its return code checked by the calling function. This could save hours of debugging time if the function does fail. Any function call where the return code is not checked, should include a comment explaining why the return code is being ignored.

3. Naming Conventions:

3.1 Variable Names:
3.1.1 Naming Your Variables
Variables should be descriptively named (should be nouns or compound nouns). Single-character variables should only be used as counters (i, j) or as coordinates (x, y, z). Except for type or scope decorations, each word should be Capitalized. In the case of single-character variables, capitalization is not expected.
The variable names should be prefixed with data-type. I am giving here a list for it (Please knock me, if I miss any data-type).

short - s
int - i
float - f or, flt
double - dbl
char - ch
unsigned - u
pointer - p

// Good Variable Names
int iNumberOfNodes;
char * pchUserName;

// Bad Variable Names
int n; // cannot tell what n is used for
char * Something; // name is not descriptive

3.1.2 Scope Designation
The scope of a variable should be discernable from the name of the variable. The following decorations should be used:
g_ is used for global variables (should be rare).
No decoration indicates a local variable.

3.2 Function and Method Names:
Function and method names should be in the form of a verb or verb-noun structure as in Print() or PrintName(). The first character in each word should be upper case and no underscores should be used.

to be continued...