If there's one thing I want you to take away from this post, it's that you should read Clean Code by Robert Martin. Eventually we'll summarize his work into a digestible video course, but in the meantime please read that book.

But why does writing clean code matter?

Here are several good reasons:

  • It's faster and easier for everyone involved to maintain.
  • The odds of misunderstanding what something does decreases.
  • Improved readability, means improved team moral.

Bad Code by example.

A Poker Calculator

The first piece of commercial software I ever wrote was a poker odds calculator (please excuse the horrific default WPF style).

At the time I thought it was great... and in fairness it gave perfect results. But as soon as I wanted to extend it to do more than simple 5 Card Draw, I was stuck. For a single example of how bad the code was, look at this method, and try to tell me what it does:

Some of the problems include:

  • A 4-value tuple return type (rather than a named class).
  • A triple-nested loop.
  • A 5-line return statement.
  • Meaningless variable names, like i1 and i2.

The one good feature of that code-block is that it has a mostly meaningful method name (in context). Other blocks of code were even worse...

A Sudoku Puzzle generator

The first large, non-academic, project I made was a Sudoku puzzle generator. I thought it would be a good way to automatically create hundreds of eBooks. If I ever find the code I'll include some snippets (amateur-me didn't know about source control). But in the meantime, it's enough for you to know that I had:

  • Many methods with 200+ lines each.
  • If()s that had 10+ nested conditions.
  • Almost all variables were 1 or two letters


Don't do this to yourself, or your fellow devs. Adhere to a formal style, implement automated linting, and follow all the other rules we set out in our (upcoming) Clean Code Summarized course.