Good programming practices

October 8, 2006 at 11:30 pm 2 comments

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{



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{



double X();

double Y();

void setX(double) ;

void setY(double);


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.

Get ready for another dot-com boom An awful gift from Google

2 Comments Add your own

  • 1. Bindu  |  October 9, 2006 at 10:48 am

    Great. These are simple though valuable ideas for the programmers. Most of the programmers don’t follow it because of lack of time and because they wouldn’t stay in the company for more than a year. So the likelyhood of them debugging/managing the software is remote. Someone else bears the brunt.

    I would suggest one more good practice. Always unset/deallocate memory for your variables after using them. Though most of the languages these days use the ‘automatic garbage collection’ method, it is still good to do it ourselves.

  • 2.  |  October 9, 2006 at 2:12 pm

    Good Programming Practices

    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


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


  • RT @beeonaposy: Jumping back into code you wrote ages ago like 10% luck 20% skill 15% concentrated power of will 5% pleasure… 2 weeks ago
  • RT @jimmysong: Stuff CS departments should teach, but don't do very well: * Source control, esp. git * How to do effective code review * H… 1 month ago
  • RT @farbodsaraf: Advice to new managers: 1 earn trust by giving it 2 hire for EQ, train for IQ 3 eat lunch with your team 4 tell people t… 1 month ago


%d bloggers like this: