Analogize your attitude towards your codebase

I love taking photos. Besides making music, it’s a big hobby of mine. I started about two years ago obsessing it seriously. But instead of buying a new, technically advanced digital SLR, I preferred another way to go. I was lucky, having a father and a grandfather who both used to shoot, too. So fortunately, they handed me some Equipment from their collection. My grandpa gave me some nice old lenes and my father left me his Olympus OM-40 Program. A beautiful 35mm film camera, built in 1985. Nothing fancy for that decade, but very solid for a Camera. You can hammer nails down to a wall with it. I still love it.

But wait. A film camera? I thought we were in the 21st century, you might think. You are right arguing that this is inconvenient, slow and more expensive because of the film development in contrast to the digital photography, where you have almost infinite memory for pictures, immediate picture control via a LCD screen and autofocussing lenses making it easy to point and shoot, getting a technically perfect photo. The great benefit of an analog camera with a fixed focal length lens, which has to be focused manually is very simple: You’re learning the photography much better. Technically and artistically. You have to deal with the theory, the relation of shutterspeed and aperture. In the matter of composition, you are forced to think about taking a photo, before you push the shutter button, because there are only 36 pictures you have. There is a big case of “thinking before acting” in this way of taking photos. It’s hard to resist against the allurement of a digital camera with its possibilities, not to take an endlessly amount of photos of which you throw away the bigger part at the end of the day. The less photos you have in your library, the more of them you will consider as great shots.

So let me tackle the hard transition to the topic here. You probably guessed the point already: The above will serve as an analogy to the attitude of some people towards their codebase. I’ve done a lot of code review recently. On the one hand, it can be a real fun pointing fingers, stating what other people have done wrong. No, of course that is not the main reason why it is fun (but it is a reason damn it!). On the other hand, it can be very frustrating, seeing how much stink somebodys codebase is able to produce. The topic of this article in question, I’ve also seen a lot of this:

header#header {
  width: 1000px;
  height: 40px;
  font-size: 14px;
  font-weight: bold;
  z-index: 9999;
  background-color: #3364a9;
  margin: 0 auto;
  padding-left: 20px;
  padding-right: 20px;
  margin-bottom: 20px;
}

This rule set is way to bloated. Let’s not examine that it’s a qulified selector (which is not good!) and that we have an ID here (even worse!!). Let’s consider what is going on between the curly braces. Alright, it has a fixed width. That’s OK. But why does it get a fixed height? There is no background-image, so no need to assign a fixed height here. As long we have content in #header (which we have in this case), the height produces of the content and its margin and padding. Then we have font assignments in a container(?). This isn’t very future proof. Why not assign these directly to the navigation items (for which they are designed)? The background-color could be extracted to an extra class just like the first margin- and the padding-assignments together with width: 1000px, which make the new wrapper-class. So let’s overwork that rule set:

<div class="header  brand-background  wrapper">
    ...
</div>



.header{
  z-index: 9999;
  margin-bottom: 20px;
}

.brand-background{
  background-color: #3364a9;
}

.wrapper{
  width: 1000px;
  margin-left: auto;
  margin-right: auto;
  padding-left: 20px;
  padding-right: 20px;
}

Now, .brand-background and .wrapper are reusable and we massively cleaned up our codebase.

Why did we had to do this? Look at the original rule set once again. Can you imagine the dev sitting behind his desk, hitting the keys of his keyboard in order to get this header#header done. Without thinking. Without questioning the need of the assignments he makes. Without concerning the poor bastard who has to get in touch with this code a few months later in order to build in some new features on the site. The dev who produced this boisterously beast of code is a point-and-shooter who hits the shutter button permanently.

Those people saying: “I’ll overwork that code later” are the same people taking photos like carpet bombing. Do yourself and possible project-successors a favour and do not point and shoot. Think before you write. Take your time for that and you’ll save that time later, I promise. It will be in favour of code reusability and maintainability and your code will more likely stay clean and clearly arranged. Thus it will treat everybodys nerves with care.