For Code Monkeys

1.       No you don’t have to design before implementation in all cases. You may have read it in some standard software book, or you may have learnt it in your first company, but it is wrong. You should design only if you need to. So when do you need to design? Glad you asked. Here is when you should design. When you think that spending time on design is going to benefit the implementation, this is only when what you are implementing is non-trivial, i.e. some sort of system or framework for system, it also implies that you are familiar with the underlying infrastructure. However if what you are doing in effect is tweaking parameters of some function, and you are not familiar with the underlying implementation, there is no point in having a design.

 

2.       Guess what is not in the ten commandments Moses brought with him from the mountain. If you guessed thou shall comment every line of code, Congratulations. See, comments are for a purpose, specifically to convey information for maintenance of the code. And believe it or not, there is something like too much information. Which is why, comment no more than what is necessary for the intended purpose. This is why comment should not be trivial. Here is what you can comment.

 

a.       A brief comment at the beginning of the function stating the purpose of function and some other critical information. This is useful for automatic documentation.

b.       Inside the function, comment only to provide overview of the algorithm and that too only when the implementation of algorithm is non intuitive.

c.       Similarly comment there is some particular piece of code which is not very intuitive to understand, this may happen when you are fixing some bug.

 

Fortunately rule for what not to comment is simple. Never comment on any thing which is trivial. This means, you need not comment for every damned variable declaration /definition, loop, or control.

 

3.       I forgot, there is one more rule about what not to comment. It is the FREAKING OBSOLETE CODE. Yes, I know some of you are under impression that it is a very good practice. Here is my request, die, preferably painfully. Obsolete code is not documentation and doesn’t provide information in concise form for maintenance. Instead the commented code keeps piling on cycle after cycle and the rotting stench of thousands of lines of obsolete code just repels anyone from actually reading the code. If you are commenting obsolete code for reversion, then either you are too stupid, or you work in a really pathetic company which can not afford any tool for version control.

 

4.       Objected oriented programming is a paradigm which means approaching the problem from a specific direction. Specifically the problem must be understood in terms of objects which are implements as classes and their behaviors which is implemented as functions. This means that if you have flag to track some property of the object it is not required to return the flag in the “Get” function. Instead the proper behavior of the function is to return the property of the Object as accurately as possible.