//  The Importance of Clean Code



tl;dr “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” ~John Woods

I’m a stickler for clean code. So much so, I’ve read books about the importance of it. Books like “Clean Code” talk about the importance of consistency and clarity. I eat all of that up. I thrive on it. I love having high standards. Our code is our art – we should work hard to make it as impressive as possible.

I don’t mean “impressive” like having algorithms that make CS degrees drool. Impressive code, to me, is code that is readable by all levels of developer, regardless of whether or not they were there for its composition. Impressive code is well organized, seems like it was written by the same mind (in one sitting), and reads consistently. To me, this is important for all projects.


Team Cleanliness

While it’s important for all, it’s easiest with team projects. You may be thinking, “how can you achieve code made of ‘one mind’ in a team?” It’s actually pretty simple. The first step is to setup tools like Swift Lint, if you’re using Swift, or Objective-Clean, if you’re using Objective-C. There are some massive wins to be had by just setting up some rules with your team and linting the code based on those rules. Linters help enforce rules by running regexes over your code and making sure it adheres to rules like curly brace placement, white space, or even variable naming. Basically, if you can write a regex for it, you can have the linter check for it.

func myFunc()
{
  if true {	// linter calls this brace an error on my team
    print("all is well")
  }
  else
  {
    print("the world is on fire")
  }
}

It also important for teams to sit down and make a code standards document. This document details how the team wants to format common code elements. This is especially important if your language lacks idiomatic guidelines. Swift, for instance, is a new enough language that we, the community, don’t quite have a defined style of coding yet. Therefore, to keep your project clean, it’s important to always (within reason) consistently do things the same way. Until developers get used to these standards, pair programming can really help keep developers consistent.

The following code is from Natasha The Robot
let myFunClass = MyFunClass()

myFunClass.doSomething("fun", handler: { (funString) -> Void in
    // do something
})

myFunClass.doSomething("fun") { (funString) -> Void in
    // do something
}

/* which is the right syntax for you and your team? */


“It’s dangerous to [code] alone.”

If you’ve read this far you might be wondering, “But is this important for my own projects?” My answer is “yes!” But it’s definitely harder to achieve code cleanliness alone. I often hear developers say “I wrote it, so I’ll remember it in a year.” However, I have yet to see that be the case. I like to regularly review my old code – it’s a good way to see how I’ve grown as a developer (and sometimes I like to reuse old code). The way I wrote code a year ago is vastly different than the way I do now. Some of that old code is pretty hard to read too.

I’m currently working on a personal project for my friends. It started architected using MVC. I then decided to switch to MVP, but switched back to MVC when I needed to get something done quick. I switched JSON parsing countless times and have at least two or three different ways I do the networking. I’m ashamed to say, I have a messy codebase and it confused me when I went to edit it earlier today. This is code I largely wrote only a month ago. Sure, I don’t always have the best memory – But a month is a lot shorter than a year.

So what should I do?


Conclusion

It’s important for individuals to keep up their standards as if they were working on a team. If your language doesn’t have idioms, set up your own. Regularly audit your code to check for consistency in style and formatting. Make systemic changes when a new architecture or pattern is chosen for the codebase. Refactoring everything might be a bit of a pain. But you’ll thank yourself later (and your psychopathic teammates won’t hunt you down).