Dev’s Corner: Clean Coding (Part One)

Contributed by Jack Scuncio

I am a software developer, but do not let the title mislead you. I rarely develop software, it happens, but for the most part, (and the most part of every software developer’s day to day), I am a software mechanic.

When I first started working in the industry, I thought I would be a developer. It was the title of the job, the reality however is that you work on an existing product. You maintain it. You try to keep that product running as long as you can and occasionally, with great difficulty you actually do develop a new feature then spend time working the kinks out. Over time, as more things are fixed, more features integrated, the code becomes dirty, harder to maintain. The code itself begins to lose meaning, becoming riddled with commented out code, dead methods, and obscure, undocumented fixes. The list of woes can go on.

You should be doing this every time you touch your code.
You should be doing this every time you touch your code.

Sound familiar?

A few years ago I came across a book, Clean Code: A Handbook of Agile Software Craftsmanship, by Robert C. Martin. It changed everything. If you are going to be a software developer, this is the book to read. If you develop software and have not read this book, do so. You will thank me and the future code mechanics keeping your code running. They will thank you too.

The author takes an approach to coding that is fully aware of the refactoring power of IDE’s, at how effective version control is, and a deep understanding of the development process over time. This book is an eye opener, it is the thing that will let you spend less time being a mechanic and more time being an actual developer.

Actually, with good clean code practices, you can even become a code doctor. Not the kind of doctor that just peddles pills and quick fixes, but instead a doctor that practices true preventative medicine. Before that happens however you must become a software janitor.

The basic idea is to be a code boy scout not a bear. This means when you enter a camp site you are the boy scout who leaves it nicer than when you found it. Do not be the bear who eats all the food, rips down the tent, and terrorizes the camp site.

When making a change, always ask yourself, “Is it more readable?”, “Is it less complex?”, “Is the code cleaner?”. Be strict with yourself, consider anything less a failure.

While in legacy code, If you cannot follow a function because it is too long or does too many things, then the code is broken. If a variable name does one thing but is named another, then the code is broken. If you find yourself making excuses like “If it ain’t broke, don’t fix it.”, then the code is most certainly broken. Clean it up. You will get better with practice and the next time you are in that section of code, you will spend less time fixing the problem.

Get into a habit of being a software janitor. If you are good at it, eventually you can spend much more time being a software developer.

Stay tuned for the second part of my clean coding post where I will talk about some clean code techniques.