Readable Code

I've been working as a developer a good number of years. During those years, I have seen my share of good code and bad code. Some of it written by myself (good and bad I might add...). But we learn from our mistakes, and eventually principles, dos and don'ts gets integrated into the way we code, hopefully into something great.

I still struggle somewhat with analysis paralysis, but my best remedy for that is to go back to the core of agile and focus on what is needed right now. TDD helps a lot as well. Agile practices are great for keeping the code slim and to the point, but that alone is not enough for producing good code. So I'd like to spend some time writing a bit about what I think good and bad code looks like.

First, I believe code should be written as prose, with the primary intent that other humans should be able to easily read and understand it. The reasoning is that code is read a lot more often than it is written. This simple sentiment makes it obvious that code must be easy to digest, so it is worth spending some time now making your code readable, to save lots of frustration later. I loathe having to read and re-read the same code chunks again and again until I understand what it does, only to realize I was looking in the wrong place and have to go search somewhere else to fix it.

Clean, readable code is a joy to read and it serves as good examples for others as well. Programmers, especially juniors, learn a lot from reading code and it is natural to mimic existing code. This means that good code breeds good code and, unfortunately, the same is true about bad code.

These are my priorities when writing code:

1. It should work correctly.
2. It should be clean and readable.
3. ...
4. If needed, optimize for performance.

Lets start this with my favorite coding guideline: Write readable code instead of comments.