Coding Practice

July 1, 2008

I had just one look at the code and anyone could have said that I have seen a ghost by looking at my face. Few minutes back I had agreed to help a colleague to resolve the issue by modifying the code. But I had no idea that the code would look like this.

The code was supposed to be ready for testing by customers & had just a small change to be done to fix the small bug. Unfortunately the associate who had written this code was on leave.

I had to go through the whole program to understand where the change needs to be done. The code was correct. However the code was not good. The code was very hard to follow as there were no comments anywhere. Maintenance of code was very difficult as the code was of 500 lines.

Just writing a code which gives correct output should not be your aim.

Few tips to write good code:

a) Always put comments.

b) Always try to break a code into sub functions.

c) Don’t assume anything while writing a code. Any wrong assumption will make your whole effort toss out of window for e.g. never assume that the user will not enter wrong data.

d) Don’t test if your code is working fine by testing it but you need to be sure that the logic applied is correct beforehand as not all real life data can be tested.

e) Don’t code in haste.

f) Capture the garbage inputs very well.

I hear this reason many a times that the issue is with existing application and hence the newly function that we added is crashing. My answer to this would be

What happens when Microsoft Windows hangs while I am working on my MS Word which I have not saved explicitly?

Had the team who had coded MS Word assumed that Windows would not hang then my effort would have wasted. Thanks to the team Word is coded in such a way that it saves automatically in few minutes on its own. There always is a way around.

At the end of day style does matter.

0 comments: