On Writing Quality Code.
I’ll fix it later…
We’ve all done it, and its bad enough when you’re maintaining your own code… but if you are working with other developers (or if someone may one day be working with your code), the ‘dirty hack now, fix it later’ way of coding is simply not acceptable.
Source is meant to be read by human beings. Disregarding this truth is the first step on a dark path. Taking the time to do it right the first time pays off fast.
A lot of it isn’t even hard to do. Naming your variables clearly consumes mere seconds, and pays off immediately by reducing the amount of documentation you need to write. For example, naming an object scd1 rather than OverviewMenu creates the need for documentation that could have been avoided. If you append an item to scd1, someone looking at your code may need to figure out what scd1 actually does to understand that, while appending an item to OverviewMenu probably means you’re adding an item to the menu. The code documents itself.
Indenting your code properly is trivial to accomplish (and all but the most primitive editors make it very easy to do without thinking about it), and it simplifies understanding program flow.
Doing it the ‘easy’ way now, with the intent of fixing it later is almost always a recipe for trouble, and more often than not it creates more work for you very quickly. Now you have ugly code that needs to be fixed, and replacing it can take longer than it would have to write it well in the first place. Besides, why write something just to throw it out? Your time should be worth more than that.
If you happen to be writing web code, don’t create JavaScript functions or complex code inside event handlers, or apply inline styles your HTML. JavaScript has functions, and the style tag exists to be used. There are reasons for these things, part of which is making it easy to manage your code.
If it’s worth doing at all, it should be worth doing right. Please, don’t create more work than you need to for yourself, and other developers.
