mgroves

If you are a programmer, then Coding Horror should be in your RSS reader / regular site reading list. Even if you don’t agree with him, he has some of the most incredible insight and opinion into the world of programming: coding and beyond.

The latest blog there is about OOP for the sake of OOP. In case you aren’t familiar, OOP is Object Oriented Programming that involves inheritance, modularity, polymorphism, and encapsulation. If you’re not a programmer, you can quit reading now. I’ll sign your hall-pass.

Anyway. Inheritance, modularity, polymorphism, and encapsulation. These are all good things, but they are not always necessary things. Inheritance is only useful if you plan on having a complex hierarchy of classes and “child” classes. Modularity is only good if you are going to use more than one instance of an class. Encapsulation is nice for hiding the messy details, but sometimes it makes doing what you want harder than it needs to be. Polymorphism is cool, but it is often a hindrance or unnecessary.

And don’t forget: the customer doesn’t give a damn if you are using OOP, Pascal, assembler, or an abacus and a pocket calculator. All they want it to do is work according to their requirements, and keep on doing so tomorrow.

Now before you go thinking I’m all anti-OOP, hold on a minute, jack! OOP is a really great design technique, but it shouldn’t be considered “the” design technique or the “best” design technique. Far from it! If your app is conducive to using one or more of the tools that I described above, OOP is the way to go. But object oriented programming can be like building a car from scratch to drive a block when you could’ve just walked.

I very much agree with Jeff Atwood when he says “a little OOP goes a very long way”. No matter what technique you use, Object Oriented, functional, whatever–the most important thing (besides that it works in the first place) is to code for the poor sap who has to read your code later.

This is ultimately the same reason why “hacks” are bad. Not because they work–because they do–but because the next guy may not have a clue why it works, what you are trying to do, or how to fix the app that suddenly broke out of nowhere.

I’ll admit right now: I’m far from achieving the goal of churning out “empathetic” code. And I don’t just mean lots of comments. My guess is that the vast majority of code in production right now (my own code included) is far from empathetic, and I’d bet a large portion of that is downright unreadable by the ‘next guy’ right now and by myself a year from now. Think about the last time you looked at source code that was 2+ years old. The phrase “good Lord, what a mess” usually comes to mind for me.

So, what are some things that we can do right now to make source code an easier place to hang out? I’d like to have a list of specific things (at both a high or low level design perspective) that I can start doing today. I think the first thing we should do is stop assuming that “Object Oriented” is a synonym of “good”.