Comments
April 26, 2008 |
Why is it that a programmer never properly documents code? Many programmers are so concentrated on coding and making sure the code runs correctly and efficiently that they don’t consider others or themselves coming back to the code to review (or worse yet, troubleshoot and fix bugs) in the future.
When one thinks about who they are documenting code for, other programmers come to mind. Commenting helps to understand what a block of code does. If it is a function, what data do you pass in, and what does it return. Basically, it’s the answer to ‘What can this do for me?’ A programmer never thinks they document code for themselves (a non-selfish programmer, wow).
There could be a mentality that any good programmer will be able to read the code and understand what it does. If you can’t read someone else’s code (regardless of clarity), how can one expect you to come in and fix code that is buggy and outdated.
If we forgive the less experienced programmers (who can become just as knowledgeable), we could focus on the programmer that writes the code. There’s the programmer that is left to write a block of code and is the only one who comes back to it to maintain and fix it. Do you remember why you wrote something the way you did? All the issues that you anticipated and tried to prevent.
Very well if you do, since you’re probably not working on enough code day after day. If you don’t remember the things mentioned above, do yourself a favor and comment the code you write. It doesn’t take much time, during and after writing small bits at a time. If you wait until you’re done with all the code, you may be intimidated with the amount of documenting you have to do. There’s a high probability that you will be distracted with other tasks that are not related to this code and will never get to document it. You’ll wish you did when you come back to it.