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.