HAVE YOU EVER revisited code you wrote months or years later and wondered “What the heck was I thinking when I wrote this?”. Most developers I have talked to have done so at least once, and that was because they did not comment their code properly. Emory Brown outlines a logical, clear method used at DBServices to keep this from happening to them. And in an environment with multiple developers working on a project, it’s necessary to leave a good trail:
When writing code, you can only choose two of the following:
- Code that is quick to write
- Easy to read
- Works well
At DB Services, we think it is more valuable to place a higher focus on readability of code that works well than quickness of writing. Since developers spend more time reading and debugging code than actually writing it, any efficiency we can gain through maximizing readability will add up quickly. This ultimately benefits the client because optimizing the readability of code gives the biggest bang for your buck…
Commenting well is possibly the biggest part of writing scripts that are easy to scan and read by developers. To comment well, it’s important to create a high readability factor. High readability can be achieved by spacing out different parts of the code into blocks, preferably by thought process behind each block. Basically, try to keep everything related within a block and allow proper spacing between each block so there is a visual cue where each block begins and ends.
Give it read and put it to use. And save yourself some time and grief.