Programming Rules Of Thumb

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.

  1. If you use a number or a string more than once, make it a constant.  Maybe even if you only use it once.
  2. Do not check in commented out code.  You’ve got version control to show you what your code used to look like.
  3. 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.
  4. 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.)
  5. If a routine gets longer than one screen, look at what you’re doing in the routine very closely.
  6. If you can identify a potential point of failure chances are very good that it’s not an exception.
  7. Almost always, explicit is better than implicit.  If you can spell things out explicitly, it’s almost always better to do so.

One response

  1. 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 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: