Clean Code Matters

Why am I obsessed about code quality? Do you know that abandoned house in your neighbourhood? The one that has windows all broken, and has probably stood there for a long time already. It all started when someone threw a rock in one of the windows. Nobody cared to fix it. People began thinking that breaking the windows of the house was ok, and soon all the windows were broken. Then it started to rain, and the house was ruined beyond repair.

I have lived in that house, except that the house was the software that I was building and maintaining. Flashy features were added on top of each other, but the code base started to break apart here and there. Nobody spent time on maintaining the existing code, so gradually the whole thing just became a big mess and most working days were spent on putting out emerging fires. The people who originally built the software got frustrated and started leaving, and the newcomers were even less aware of the monsters lurking in the depths of the code base. That’s when I decided that I will only live in a house that is properly built and where windows get fixed when they break.

Building robust things

I spend eight hours a day building software. I see myself as craftsman, a professional who crafts code. And if the work results in crappy code, it makes me feel like I’m not living up to my profession. I want to be able to take pride in what I do, and that means creating quality software.

To me, doing things right means taking responsibility for what I do. I strive to build things that others can rely on, and can easily understand and change. When people make changes to my code, their heart should not be pounding out of fear that something will break down.

Doing things right also means that when a problem is found in the existing code, you take the time and fix it instead of just ignoring it and moving on. I want to live by the motto “Leave the code cleaner than you found it”.

And what’s most important, I’m very specific about living in a house where people share the same attitude: It is ok to take the time to focus on quality and to fix the existing structures. I want to be able to trust the people around me and know that they, too, care. That’s why I also focus on code quality when recruiting new people. It’s dangerous to leave indifference in, because indifference is highly contagious, and leads to windows breaking in no time.

So, how to avoid crappy code? First of all, you need people who care and a culture that allows quality.  There are a few things that we do at Sievo to ensure quality:

• We hire people who care, and whose code shows that they care.
• Code reviews are embedded in our software development process.
• Most of our code is covered by automatic tests.
• We reserve time for improving our existing code base.
• In addition to end users, we consider our fellow developers our customers as well.

What does clean code look like?

People often ask me what quality code looks like. But describing good code is rather tricky. Sometimes it feels easier to list the things that should not be done. And sometimes, you can just see from a piece of code that it should have been done in a different way. But here are some dos and don’ts that I hold dear:

Do

• Make it as simple and clean as possible.
• Write code that speaks for itself, so that minimal commenting is required.
• Use existing libraries.
• Strive for making work of other people, who will have to maintain your code, as easy as possible.
• Pay attention to coding conventions.
• Optimize maintainability, even at the cost of efficiency.
• Use LINQ (Select, Where, Take, Skip etc.).

Don’t

• Try to impress with all the available bells and whistles.
• Try to reinvent the wheel.
• Over engineer.
• Focus on pretty output only without paying attention to the code itself.
• “Kill a fly with a cannon” – use the most powerful tool for a small task.
• Use for and while loops - they are the most common reasons for spaghetti code.