The Spoken Word

Good programming practices

October 8, 2006

These practices apply to almost all Object Oriented Languages and should be followed by almost every developer (or programmer or whatever you call). These are simple rules that can save considerable amount of time( and money) but are not followed by most of the developers. Whatever is your background, these rules can help you write better programs in less time and with fewer headaches. So lets begin…

1. Never expose

Do not declare a member data as public. The user of your class should never be able to modify the data directly. For example, let us consider the following class :

class Plot{

public:

….

double x;

double y;

};

In the above class the client code is free to mess with the data anytime anywhere. Also, the object of the plot won’t necessarily know when its values have been changed. Instead the Plot class should have been something like :

class Plot{

public:

…..

double X();

double Y();

void setX(double) ;

void setY(double);

private:

double x;

double y;

};

In the above code, there is only one place where the value of x and y can be modified i.e., setX and setY functions respectively. This can majorly save time in 2 ways:

a. In debugging:

If in some place the value of x is not the expected value, then the only place that you will need to place a break point and check will be the setX function.

b. In Modifying program:

Lets say in future you decide that the plot should not contain any negative values of y, then the only place that you will need to make that change will be setY function. It will be something like :

void Plot::setY(doouble yValue) {

y = yValue;

if(y < 0){

y =0;

}

}

2. Initialize variables during declaration

Initializing variables as they are declared in inexpensive. By this, you will be assured that you’ll never get initialization errors. If you play a lot with pointers then this rule is specially for you. Here are few examples of initializing during declaration :

Employee *employee = 0;

char employeeName[NAME_LENGTH + 1] ={”};

Some languages (like Visual Basic) don’t support initializing variables as they are declared. In such cases it is better to declare and then initialize the variable as close as possible to where they are first use. For example :

Dim accountIndex As Integer
someIndex = 0
‘ code using someIndex
…
Dim total As Double
total = 0.0
‘ code using total

3. Simple routines for simple operations

No one creates a simple routine for a simple purpose. Constructing a simple routine that contains only two or three lines of code might seem too much. But it can be extremely helpful in most of the cases. Small routines improve readability. Consider the following line of code that can appear in lots of places in your program

double twiceSpeed = 2 * (distance / time );

It is probably the most simple line of code that you would have come across. The above code is calculating two times the speed using distance and time. It is highly possible that this code can appear in dozen places and you will just copy and paste the code. You will never write a routine for this, but imagine what if time is equal to zero. You will now have to make changes in all the places. Pain, isn’t it.

Your code should have probably been

double twiceSpeed = 2 * (getSpeed());

and your getSpeed routine would have been

double getSpeed() {

if(time > 0){

return distance/time;

}

return 0;

}

Simple, isn’t it ?

4. One routine one task

One routine should always perform only one task and nothing else. Also, the name of the routine should tell what the routine is suppose to do. For example, the routine calculateSalary(), should only calculate the salary and getSalary() should only return the value of salary. Most of the people tend to combine something like this. They write the calculateSalary part inside getSalary and finally return the value of salary. The best examples of one routine one task are the math functions. sin(), cos(), tan()..etc perform only single task and therefore are very easy to use and also remember.

The above rules will assure you some good code and lesser headaches.

P.S. I am not an expert myself. So, if you think I am wrong somewhere or if you have better ideas, please enlighten me. I will be greatful to you.

Entry Filed under: Geeky stuff. .