I should probably apologise for the somewhat presumptuous title of this blog. After all, Robert C. Martin’s masterpiece “Clean Code” was released in 2009, and he penned multiple equally worthwhile sequels afterwards. However, time doesn’t stand still. Programming languages change, new paradigms enter the industry, and sometimes, this pressure to innovate and adapt distracts us from the core tenet of software engineering. We don’t write software for computers. We write it for other developers. Code is an explanation to other humans of how a problem is solved. The fact that it can be run on a machine is a happy by-product.

There are hundreds of definitions of clean code, and the book helpfully includes many of them in its introduction. Grady Booch offers my favourite one:

Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control.

I particularly enjoy the choice of the word “simple” here. Clean code is simple, yet it is not easy. A lot of care needs to be taken to make code clean, and yet when you read it, you should be astonished by just how obvious every single line is. The abstractions are crisp because they do not include anything extra and directly correspond to your program's subject. You can immediately deduce the program flow at any branching point because it is clear what the decision is based on. To quote a different definition by Ward Cunningham:

You know you are working on clean code when each routine you read turns out to be pretty much what you expected.

My name is Paulina Jonušaitė, and I have been a software developer using Java and Kotlin for the last 15 years. Throughout the years, I have seen (and written!) a lot of awful code. Hopefully, I can transfer my experience to this blog and make it a helpful guide for other software developers to write the best code they can.