Programming Rule #3

“Thou shalt always leave the code cleaner than when you found it.”

If you’ve ever had to work on a medium to large size code base you very quickly learn that the level of effort to maintain such a beast is indirectly proportional to the level of quality and cleanliness of the source code.

Every dirty hack, every one-off, every “chunk of ‘this-is-just-temporary’ code”, every badly named variable/method, every bit of sloppily formatted code makes maintaining it that much harder.

As a result you get into a mindset that you are dammed & determined that you will not let code rot on your watch and you start to do everything you reasonably can to prevent it.

If you’ve never worked in a wide-sweeping role that brings to light how the little issues become big problems… trust me they do. One badly named method becomes several hundred badly named methods in no time flat, and suddenly you now have a confusing and complicated API due to the lack of foresight.

The end result of learning about the “Broken Windows Theory” (the problem this rule is solving) is that you very quickly adjust your approach and work extra hard to ensure that you do your 110% to ensure it not only doesn’t get worse – but it has to get better… even if only just a little.

When you come across a file, no matter how you got there… if you see a problem you do something about it.

  • Bad spacing or indentation?…  you FIX it!
  • Inconsistent attribute quoting?… you FIX it!
  • Funky statement formatting?… you FIX it!
  • Risky error prone code?… you FIX it!
  • Dead, empty or commented out code blocks?… you DELETE them!
  • Useless comments?… you DELETE them!
  • Redundant line breaks?… you DELETE them!
  • Trailing whitespace?… you DELETE it!
  • Badly named local variables?… you RENAME them!
  • Unused variables?… you DELETE them!
  • Typos or grammatical errors?… you FIX them!

The 30-60 seconds of your time to attack these problems will save many minutes for every future developer that looks at this code and in time save aggregated hours or even days of time and frustration for future developers attempting to debug when something goes wrong.

You’ll notice that many of the above issues are resolved by deleting code.  This is a good thing! In fact you’ll find that there is very little in programming that is more satisfying than deleting code! Just ask Jeff Atwood (aka @CodingHorror)!

Related: Programming Rule #1, Programming Rule #7


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 )

Google photo

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

Twitter picture

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

Facebook photo

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

Connecting to %s