Smelly code

In computer programming, how do you know when a program is going bad? First, it begins to smell.

The term “code smell” describes code that isn’t great. But not only is it not great, it’s probably an indicator of some deeper and larger problems in the program. The analogy, I suppose, is to a dead body in an attic. It smells bad, and you can hide the smell with air freshener… but you should really be doing something about that body in the attic instead.

Here’s an example. I’ll try not to use too much jargon, so forgive me computer science people if it seems like a gross oversimplification. A particular style of programming language is “object-oriented.” Computer programs in object-oriented languages use a lot of little objects, which can be defined as “bits of data and code to manipulate it.” Essentially, objects are little mini-programs that do just one part of the overall task, all fitting together in a modular fashion like Lego.

This is good for many reasons: you can have different programmers working on different objects at the same time; the program itself can reuse objects, making it smaller and more efficient; if something goes wrong inside an object it’s less likely to spread to other parts of the program.

But! Sometimes you find a program in which one object seems to do everything. Instead of being one cog in the larger machine, the programmers have pretty much thrown a lot of stuff into that one object. It’s a “god object,” and it smells real bad. If a program has an object that does too much, it loses many of the advantages of object-oriented programming, so it’s symptomatic of a larger problem.

Now, this is just one example of a code smell – the Wikipedia article below lists a bunch more, many of which relate to classes (which I am not going to go into, but are basically code that creates objects). I’m just really a fan of this metaphor.

• Code smell
• Object-oriented programming
• God object