Computers were designed to make our lives faster.  Modern day computers have so many facilities that many of us would not have been dreamt of fifteen to twenty years back. Modern day software packages give us the liberty of downloading data  into any formats of our choice thereby giving the option of sending huge files through email in a few seconds which years back had to be printed packed and couriered which was a colossal waste of time and energy because we never had a choice at that point of time in our lives.

There is always a flip side in every aspect of our lives and computers and in this regard computers are no exception. The flip side to computers comes in the form of its own advantages often misused by people especially in applications like winword and in emails.  Some flip sides are:-

Editing Facility:- Prior to advent of applications like Microsoft word letters used to be hand written by us or typed on a typewriter.  We were accustomed to finish letters handwritten or typed within fifteen minutes or a maximum of half an hour.  The handwritten letters had a draw back in the sense there were too many scratches and over writing.  Software applications in computers give us the facility to edit and therefore we have become greedy and tend to use this facility much more than what we need.  Any number of editions to the data we are not satisfied.  We not only waste our time in repeatedly editing the data, but also waste others time in getting the edited versions verified time and again.

Spell Check and Grammar:- Users are more concerned than ever before on getting the spellings right which was never a priority earlier.  Also the focus is too much on grammar than on completion of data or sending it before the stipulated time frame.

Beautification of Data:- Many people are more concerned with beautification of data as they waste lot of time in changing fonts.  the choice of fonts offered by most software makes users greedy craving for more thereby resulting in deviation of primary motive of typing out data to beautification of data.

Saving Facility:- One of the best facilities offered by software's is saving for we have the option to save what is already typed so that we can type the balance at a time convenient to us.  Because of this facility to do things in convenience in installments we never try to finish of typing out the entire data at one go.  The facility to save makes us lazy and this is one of the reasons why work gets pending in most organizations as clerks tend to take too many breaks in the midst of typing data like chatting over phone, taking lunch before completion of data and so on.

This article is not to blame facilities offered by computers but to point out how excessive choice corrupts us  and generates a desire in us to crave for more leading to lack of satisfaction.  When we have too many choices we get spoilt for options and  in the end we end up doing nothing.

I have already published an article named "Coding standards in C language".  Some concpets in C++ are same in C. So i have not repeated those here.

In this article  i have explained some guidelines especially for C++ .

1. File Structure

 

Rule 1 (Required)

Implementation files in C++ always have the file name extension ".cpp".

Rule 2 ( Required )

An include file should not contain more than one class definition.

 

2. Naming convention

 

Rule 3 ( Advisory )

Variables representing GUI components should be suffixed by the component type name. Eg. submitButton,  mainWindow etc.

Rule 4( Required )

All private member variables names should be preceded by an underscore

All MFC Class Wizard member variables names should be preceded by ”m_”

Local Variable ->    variableName

Private Variable ->    _variableName

MFC Class Wizard Variable ->    m_variableName

 

3. Control flow

 

Rule 5 ( Required )

Follow each non-empty case statement block in a switch statement with a break statement.

Rule 6 ( Required )

Do not alter a control variable in the body of a for ,do or while statement.

Rule 7 ( Required )

Do not use 'goto'.

Rule 8 ( Advisory )

For functions with non-void return type, ensure all paths have a return statement that contains an expression of the return type.

Rule 9( Required )

Avoid the use of continue.

Rule 10 ( Required )

The break statement shall not be used (except to terminate the cases of a switch statement).

Rule 11 ( Required )

A switch statement must always contain a default branch which handles unexpected cases.

Rule 12 ( Advisory  )

A switch expression should not represent a Boolean value.

Rule 13( Advisory  )

Only expressions concerned with loop control should appear within a for statement.

 

4.Classes

 

Rule 14 ( Required )

The public, protected, and private sections of a class are to be declared in that order

Rule  15 ( Required )

No member functions are to be defined within the class definition.

Rule  16 ( Required )

Class data members should be explicitly declared to be private by using the private keyword

Rule  17 ( Advisory )

Every class should have a constructor, a destructor and a copy constructor defined

Rule  18 ( Required )

Organize class member functions in the source code in the same order they are declared in the class interface

 

5.Functions

 

Rule 19 ( Required )

Always provide the return type of a function explicitly

Rule 20 ( Required )

Pass arguments of class types by reference or pointer.

Rule 21 ( Required )

Specify the name of each function parameter in both the function declaration and the function definition. Use the same names in the function declaration

and definition.

Rule 22 ( Advisory )

Use pass-by-reference in preference to pass by value or pass by pointer.

Rule 23 ( Required )

Functions shall always be declared at file scope.

Rule 24 ( Required )

Functions shall always have prototype declarations and the prototype shall be visible at both the function definition and call.

Rule 25 ( Required )

Identifiers shall either be given for all the parameters in a function prototype declaration,or for none.

Rule 26 ( Required )

Functions with no parameters shall be declared with parameter type void.

Rule 27( Advisory )

A function should have a single point of exit.

Rule 28( Advisory )

If a function returns error information, then that error information should be tested.

 

6.Variables and Constants

 

Rule 29( Required )

Initialize all objects at definition. Never use an object before it has been given a value.

Rule 30 ( Advisory )

If possible, always use initialization instead of assignment.

Rule 31 ( Required )

Constants are to be defined using const or enum; never using #define.

Rule 32 ( Advisory )

Use suffixes L, U, F,and UL for all constants of type 'long', 'unsigned int' ,’Float’and 'unsigned long'.

Rule 33 ( Required )

There shall be no unreachable code. Examples of unreachable code are given below:

• Code after a goto or return.
• Code in a switch body, before the first label.
• Code after an infinite loop (a loop with a constant controlling expression that  evaluates to true).
• Code after a function call of a function that is known not to return.
• Code after break in a switch clause.
• Code after an if statement that is always taken where the end of the dependent statement is unreachable.
• Code after an if statement where the ends of both dependent statements are unreachable.
• Code after a switch statement where the ends of all clauses are unreachable.

 

7. Memory Allocation

 

Rule 34 ( Required )

Do not use malloc, realloc or free.

Rule 35 ( Required )

If memory allocation is done for an Array using new operator. Be careful that you delete the whole array .

 

8. Thread Handling

 

Rule 36 ( Required )

If global variables can be accessed by more than one thread, code altering the global variable should be enclosed  using a synchronization mechanism

such as a mutex. Code accessing the variable should be enclosed with the same mechanism.

Rule 37 ( Required )

Always design a Thread Safe Class

Whenever threads are used proper synchronization should be done.Since one thread could be updating the contents of a structure while another thread is reading the contents of

the same structure. It is unknown what data the reading thread will receive: the old data, the newly written data, or possibly a mixture of both. To avoid accessing incorrect data

always use Critical Section (Lock and Unlock functions)

 

9. Synchronization

 

Rule 38 (Required)

It is important to release the locks in the same order they were acquired to avoid deadlock situations.

 

10. Optimization Techniques

 

Pass Class Parameters by Reference

Passing an object by value requires that the entire object be copied (copy ctor), whereas passing by reference does not invoke a copy constructor, For strings, passing

by reference is almost 30 times faster! For the bitmap class, it's thousands of times faster. Passing a complex object by reference is almost 40% faster than passing by

value. Only ints and smaller objects should be passed by value, because it's cheaper to copy them than to take the dereferencing hit within the function.

 

Postpone Variable Declaration as Long as Possible

 

For maximum efficiency, declare variables in the minimum scope necessary, and then only immediately before they're used.The only time where it may make sense to declare an

object outside of the scope where it's used is in the case of loops. An object declared at the top of a loop is constructed each time through the loop.If the object naturally changes

every time through the loop, declare it within the loop. If the object is constant throughout the loop, declare it outside the loop.

 

// Declare Outside (b is true half the time)

T x;

if (b)

x = t;

 

// Declare Inside (b is true half the time)

if (b)

T x = t;

 

Prefer Initialization over Assignment

 

Initializing an object invokes the object's copy constructor. Defining and then assigning an object invokes both the default constructor and then the assignment operator.

 

Reduce the number of parameters

 

Function calls with large number of parameters may be expensive due to large number of parameter pushes on stack on each call. For the same reason, avoid passing

complete structures as parameters.

 

Don't define a return value if not used

 

The called function does not "know" if the return value is being used. So, it will always pass the return value. This return value passing may be avoided by not defining

a return value which is not being used.

C language is widely used in embedded programming and many programmers write programs in their own style. Sometimes it is very diffcult for programmers to understand

and maintain code written by other programmers. So it is better to have some set of rules and adhere to that while writing programs.

The rules and recommendations presented here are not the only set of rules to be followed, but it can be used as a basis for writing C programs.

I have explained the rules in different categories of C language. The rules are classified under two categories : Required and Advisory.

Required means that rule has to be strictly followed and advisory means it can be followed but not mandatory.

 

1. File Structure

Rule 1 ( Required )

Include files in C always have the file name extension ".h"

Rule 2 ( Required )

Implementation files in C always have the file name extension ".c".

Rule 3 ( Required )

Divide up the definitions of  functions into as many files as possible.

Rule 4 ( Advisory )

Place machine-dependent code in a special file so that it may be easily located when porting code from one machine to another.

Rule 5 ( Required )

Always give a file a name that is unique in as large a context as possible.

Rule 6 ( Required )

File names must be in mixed case starting with lower case

Rule 7 ( Required )

Every include file must contain a mechanism that prevents multiple inclusions of the file.

Rule 8 ( Required )

Use the directive #include "filename.h" for user-prepared include files.

Rule 9 ( Required )

Use the directive #include for include files from libraries.

Rule 10 ( Advisory )

If a file only contains information that is only needed in an implementation file, that file should not be included in another include file.

Rule 11 ( Required )

All function definitions should reside in implementation files

Rule 12 ( Advisory )

Include statements should be sorted and grouped. Sorted by their hierarchical position in the system with low level files included first. Leave an empty line

between groups of include statements.

Rule 13 ( Required )

Always give the project workspace file a name that is unique in as large a context as possible.

Rule 14 ( Required )

Don’t use absolute pathnames for header files. Use the construction for getting them from a standard place, or define them relative to the current directory.

Rule 15 ( Required )

Global ( Extern ) variables and structures are declared ( .h ) and defined ( .c ) in separate files

2. Naming Conventions

Rule 16 ( Required )

The names of variables, constants, and functions are to begin with a lowercase letter.

Rule 17 ( Required )

The declarations for Structures should be in the format given below

Rule 18 ( Required )

The declarations for Enumerations should be in the format given below

Rule 19 ( Required )

In names which consist of more than one word, the words are written together and each word that follows the first is begun with an uppercase letter.

Rule 20 ( Advisory )

Do not use typenames that differ only by the use of uppercase and lowercase letters.

Rule 21 ( Advisory )

Names should not include abbreviations that are not generally accepted.

Rule 22 ( Required )

Choose variable names that suggest the usage.

Rule 23 ( Required )

Named constants (including enumeration values) must be all uppercase using underscore to separate words.

Rule 24 ( Required )

Iterator variables should be called index1, index2, index3 etc..

Rule 25 ( Advisory )

The prefix is should be used for boolean variables and methods.

Rule 26 ( Advisory )

Enumeration constants can be prefixed by a common type name.


3. Control Flow

Rule 27 ( Advisory )

If a conditional expression always has the same result, there is no need for the condition.

Rule 28 ( Advisory )

The control variable in a for loop should be tested against a constant value, not a function or expression.

Rule 29 ( Advisory  )

When testing incrementing or decrementing counters try to use the >= or <= instead of == in if-statements. If for some reason the value of the counter gets

higher or lower than expected in the test for equal you would run into problems.

4. Functions

Rule 30 ( Required )

Always write the left parenthesis directly after a function name

Rule 31 ( Required )

Function names must identify the action performed or the information provided by the function.

Rule 32 ( Required )

Do not have overly complex functions.

The number of control flow primitives( if, else, for etc  ) in a function should be minimal

Rule 33 ( Advisory )

Do not use ellipsis '...' in function parameters.

Use of the ellipsis notation (...) to indicate an unspecified number of arguments should be avoided. It is better to develop specific methods for all

situations. Use of ellipsis defeats the type checking capability of C++

5.  Variables and Constants

Rule 34 ( Required )

The use of magic numbers in the code should be avoided. Numbers other than 0 and 1 should be considered declared as named constants instead

Rule 35 ( Required )

Use of global and static variables should be avoided

Rule 36 ( Required )

Pointers and references should have their reference symbol next to the type rather than to the name.

Rule 37 ( Required )

Declare each variable on a separate line in a separate declaration statement. If the declaration is not self-explanatory, append a comment describing the variable.

Rule 38 ( Required )

Variables should be initialized in separate statements

Rule 39 ( Required )

Static variables should be explicitly initialized to 0

6.  Pointers

Rule 40 ( Required )

Do not compare a pointer to NULL or assign NULL to a pointer; use 0 instead.

Rule 41 ( Required )

Pointers to pointers should whenever possible be avoided.

7.  Comments

Rule 42 ( Required )

All files must include copyright information.

Rule 43 ( Required )

Every file that contains source code must be documented with an introductory comment that provides information on the file name and its contents.

Rule 44 ( Required )

All comments are to be written in English.

Rule 45 ( Required )

Write some descriptive comments before every function.

Rule 46 ( Required )

Use /* */ for all comments, including multi-line comments.

Rule 47 ( Required )

Tricky code should not be commented but rewritten

Clear code is preferable to well-commented messy code. Every effort should be made to make code clear through good design, simplicity, good naming and layout.

Comments are definitely required where code is not clear.

Rule 48 ( Advisory )

All comments in source code files must be up-to-date at all times during that code's lifetime.

8.  Spacing , Indentation , Code Style

Rule 49 ( Required )

There should be only one operation per line.

Rule 50 ( Required )

Use spaces instead of tabs in a source file.The tab size for source files should be set to every three spaces.

Rule 51 ( Required )

Conventional operators should be surrounded by a space character.

Rule 52 ( Required )

Matching braces (‘{‘ ’}’) should line up vertically inline with the parent statement

Rule 53 ( Required )

Place single spaces immediately after commas, round brace in routine parameter lists, Control Flow Structures ( if,while,for ,switch etc )

Rule 54 ( Advisory )

Place single line space between blocks of code for better readability

Rule 55 ( Required )

Place single line space between variable declaration and statements inside the function

Rule 56 (Required)

Write only one function parameter per line in function declaration, definition

Rule 57 (Required)

Parenthesis should be used for return value

Rule 58 ( Required )

Do not use spaces around `.' or `->', nor between unary operators and operands.

Rule 59 ( Required )

Write switch and case keywords on the same level

Rule 60 ( Required )

One line spacing between if and else is not needed.

Rule 61 ( Required )

While using if-else if -else ,Else should be separated from if

9. Compiler Settings

Rule 62 ( Required )

While building the final exe file the mode of the compiler should be in ‘ Release ‘ and  not ‘ Debug ‘

Rule 63 ( Required )

If the compiler supports any code checking standards like MISRA C enable that option

Rule 64 ( Advisory )

While compiling it is a good practice to set  compiler warning levels to the maximum level. Eliminate warnings by changing your code, not by reducing the

warning level.

10.  Portable code

Rule 65 ( Advisory )

Use explicit type conversions for arithmetic using signed and unsigned values.

Rule 66 ( Advisory )

Do not use compiler specific language or pre-processor extensions.

Rule 67 ( Advisory )

Organize source files so that the machine-independent code and the machine-dependent code are inseparate files. Then if the program is to be moved to a new machine,

it is a much easier task to determinewhat needs to be changed.

Rule 68 ( Required )

Always treat include file names as case-sensitive.

Rule 69 ( Advisory )

Do not depend on the order of evaluation of arguments to a function.The order of evaluation of function arguments is strongly compiler dependent.

Never use ++, -- operators on method arguments in function calls.

 

11.  Optimization Techniques

Usage of For Loop

Try using decrementing for loop instead of incrementing for loop.

Passing Parameters to a function

It is better to have structure/ union pointers passed as function parameters instead of structure/ union instances. This is because if a structure/ union as a whole is passed

all the members will be passed as parameters which will increase the code memory. Instead pointers can be passed as parameters.

12. General Recommendations

 

• File content must be kept within 80 columns.

Naming Conventions

• The terms get/set must be used where an attribute is accessed directly.Eg. employee.getId();  employee.setId(id);

• The term compute can be used in methods where something is computed.Eg. valueSet->computeSum();

• The term find can be used in methods where something is looked up.Eg: vertex.findNearestVertex();

• Complement names must be used for complement operations

Eg : get/set, add/remove, create/destroy, start/stop, insert/delete, increment/decrement, old/new, begin/end, first/last, up/down, min/max, next/previous, old/new,

open/close, show/hide, suspend/resume, etc.

• It is also a good practice to keep track of the software versions and the Bugs found.

• It is always a good practice to have keep regular backups of the software.

 

Now a days cell phone has become a most important subject in our life, it is very essential in our daily life because its plays each and every role of our needs you can talk through a person one country to  another with the help of cell phone you can send messages through cell phone you can access Internet through cell phone and for poor peoples it is very hard to buy a television or a music system it's cost a lot but now they can fulfill there dreams by the help of cell phone, yes now you can watch movies, TV serials and music too. And now this is time to change every body needs a portable thing which they can carry with, for example a worker is working in some company he needs a office stuff and laptop but laptop is not portable it is like a baby with schoolbag and now you can replace it, I mean keep laptop in your home and bring a cell phone because cell phone also have a featured of laptop you can make presentation, worksheet, PDF file, Ms Office and many more through the help of cell phone so my friends I told previously that cell phone is very essential in our daily life.