I have a few quick rules of thumb which I follow when writing code. Nothing earth-shaking or non-obvious; just simple ways that I avoid making the worst and most obvious mistakes.
- If you use a number or a string more than once, make it a constant. Maybe even if you only use it once.
- Do not check in commented out code. You’ve got version control to show you what your code used to look like.
- Double check your code before checking it in to insure that you’re only checking in the change you intended–not code experiments you were playing with to try to figure out a bug.
- If you find something in the code or application behavior which is not a bug but which seems like a bug, document it when you figure it out. The developer time you save later may be your own. (Corollary:If there’s not already a knowledge base of some sort in existence at your work place, create one. A wiki usually works best but even a text file is better than nothing. Make it easy for everyone to get to and make it easy for anyone to update or add to.)
- If a routine gets longer than one screen, look at what you’re doing in the routine very closely.
- If you can identify a potential point of failure chances are very good that it’s not an exception.
- Almost always, explicit is better than implicit. If you can spell things out explicitly, it’s almost always better to do so.
I have been guilty of number 2, mainly as a memory aid or multiple version of the same routine which in turn violate number 3!
Number 7 kind of goes against type generalisation, I’m not sure I quite agree, although I think we are thinking in different contexts 🙂