We all have our own style of coding, a style that suits us and makes the code easier to refer to at a later time. However, considering the situation that someone else might need to understand it, and to ease the process of maintenance, say a year from now, its often a good practice to follow certain norms while coding.
Proper variable names
Say you are using a variable to hold the average marks of students. Now a variable named 'a' will do fine. But the problem is over the entire span of program, it might not make any sense at all. Instead it could be named as 'average', which would give some idea about the data contained in it, or you might as well name it as 'averageMarks'.
Proper indentation
Indentation has a lot to do with how easil;y one can grasp the code you have written. A poorly indented code is hard to maintain. Just have a look and tell which one is easier to comprehend?
if(n==0){
printf("Hello");
}else{
printf("Bye");
}
if(n==0){
printf("Hello");
}
else{
printf("Bye");
}
Initialising variables, arrays, etcSome languages force all variables to be initialised before their first use and some languages don't force. However, it is generally a good idea to initialise the variables, arrays, lists and such, before using them in the program. Unless the developer wants to work with garbage values !
Commenting where necessaryComments are usefull in understanding the logic of the code and the flow of the program in general. With balanced use of comments in the code, the author makes his program easier to understand and maintain. Obscure use of logical operators and pointers are a few examples where comments are really helpful.
Debugging routinesDebugging routines must be embedded in the code itself so that during testing or later in the maintenance phase work can continue smoothly. Although developers can argue that its the work of the debugger but some lines displaying intermidiate values of variables can save hours of work.
Checking array boundsMost of us have heard of vulnerabilities in software applications and in many of those cases the culprit is some buffer overflow problem. So as a rule of thumb, its a good practice to check the bounds of arrays, lists and such data structures where there may be a chance of an overflow or an underflow occuring in the code.
Garbage collectionYes, main memory might be getting cheaper by the day, but gives no excuse for hijacking precious system resources. Garbage collection routines must be coded properly and ensured that all dereferenced objects and out-of-scope dynamic variables and freed. No one wants a simple piece of software to hang on to their memory foot prints forever, isn't it?
Following coding standardsThe general coding standards of the programming language being used must be stricly adhered to. That includes defining prototypes of functions in languages that recommends it, and providing explicit return types and proper type casting. Non standard codes are the last thing any developer would like to work on.
Keeping lines under 80 charactersRemember that a single line of code is easier to see, understand and debug. Since almost all of the monitors nowadays are 80 columns wide, its better if your statements are bounded within it.
Explicit casting of variablesLastly, and most importantly, never rely on implicit type casts. You might get away with some but not all. Specially, where acuracy is of prime importance. Floating numbers are hard to comprehend in general as their arithmetic is mostly machine dependent, so its better to use explicit type casts at all times
Posts
