In the more than a decade that I’ve been programming, I’ve found that there are three programming principles that I really wish were included in the computer science program that I enrolled in during the late 1990s:

• Code reuse (the DRY principle)
• Implementing version control
• Unit testing your code

There’s really no excuse for these topics not being covered, but it perhaps reflects upon how the academic world differs from the professional business world.  Academia considers you successful if you’ve studied all sorts of general aspects of computer science, while success in the business world requires following general coding principles, and not necessarily a grasping a thorough understanding of say, machine code or Artificial Intelligence (of course, my argument falls apart if you are designing computer processors, robotics, or video games!).

Covering all three topics in one article would be a bit much, so I’m going to split this up over the course of a few days.

Code reuse

My biggest programming pet peeve is when my fellow programmers don’t write code that is reusable, or worse yet, “reuse” their code by copying and pasting it into a multitude of different program files.  As a developer, you ideally shouldn’t write the same bit of code twice, which is known as the DRY principle (or Don’t Repeat Yourself).  As soon as you find yourself writing one or more lines of code that resemble something you already wrote, you should evaluate it for use in a function or utility class.  That way, if you need to make a change to your repeated logic, you only have to do it in one place, and the various places in your code where you reference it should all automatically work the same way.

One of my fellow programmers is absolutely notorious for copying and pasting code.  I’ve had to drastically refactor a few of his web applications, because he had copied and pasted the same script and HTML outline into numerous files.  His worst offending application had 30 files containing much of the same code in each!  It took me several weeks of cleaning it up just to get it into an easily maintainable shape – and I hadn’t even gotten to adding any of the new requested functionality that I was supposed to be working on by that point!

I probably don’t need to mention that I had thoughts of poking him with sharp pointy objects if I ever ran into him again.  After refactoring his code, it felt good looking at the result and knowing that I now only needed to make a change in one place to affect all the files at the same time, but to the end user, there was no difference in the application and I wasn’t helping to make it do “cool” new stuff.  If you develop your code the right from from the beginning, you can get at that “cool stuff” that much sooner.

Later in the week: we discuss version control and then unit testing!  Stay tuned!