Write code which developers can understand

It’s okay to figure out murder mysteries, but you shouldn’t need to figure out code. You should be able to read it.

Steve McConnell

Often we’re faced with a time where a decision needs to be made between what we think is best practice in writing code, and what is best for the project delivery. Is it worth spending more time writing what we think is human understandable code?

Software applications have a lot in common with cars; they both have a purpose and a personality. Cars are expensive to maintain and so is software. A study conducted by Human Factors International found that 80% of software life-cycle costs occur during the maintenance phase. A software meeting requirement is good, but maintenance is even more important. There are real financial consequences when code takes a long time to update. It can even cancel a project.

There is a business law that states the cost of products and services go down over time. It’s called the experience curve. Businesses find cheaper and quicker ways of getting the work done. When a cheaper way to do business is found, a company charges less to increase volume or operates with higher profit margins. Beautiful code can become that competitive advantage to manage the curve.

What I have noticed over the years is regardless of how much you have planned; one always end up having to go back into the code to make edits. As important as this is, there is one more reason why you write understandable code.

The understandable code is likely to be simple and clear. An understandable code should not be cryptic, to the point where it is muddled with a lot of workflows. Developers are generally good at writing code than reading. The developer that comes after you will have to dig through a complicated folder structure to find your files, and when they get there they’ll have to decipher your variable names, dig through your dependencies to find magic values, and try to grok how what you’ve written works for a real business situation. Leave behind the desire to write the code which just meets specs if it means sacrificing clarity. Generally speaking, the money your company will save when the next programmer understands your code immediately will more than make up for the time you think you will save by delivering code quickly

Well, now that I have waxed lyrical why you should write understandable code, the next logical step would be to figure out how to write such code.

Keep it Simple

Do the simplest thing that could possibly work. Always remember the ultimate elegance is simplicity. Controlling and eliminating complexity is the essence of GREAT programming If your style of writing code is such that only you can understand it later, it needs your attention to analyze your style of writing complex code and find out a way to start writing high quality of code in a simple and structured manner. This will help you and your organization in a big way.

Keep it Consistent

The consistent code makes it easy for people to understand how a program works. When reading a consistent code, one subconsciously forms a number of assumptions and expectations about how the code works, so it is easier and safer to make modifications to it. Code that looks the same in two places should work the same, too.

Keep it Clean

Clean code is easy to read with minimum effort. This lets people start to understand it easily. This includes the coding style itself (brace placement, indentation, variable names), and the actual control flow of the code. If you are using any static code analysers, make sure there are no yellow bars on the right-hand side of your code editor.

Keep it to the Point

A programmer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.

Antoine St Exupery

A good code provides a solution to the problem at hand – no more – no less. A sign of good code is when you go through it and feel there is nothing you can remove from it

An ugly code may look like the practical choice. It’s an easy solution when you become defined by deadlines. Some programmers work that way for survival, but surviving isn’t thriving. For businesses to grow and stay competitive they have to have a culture that prizes beautiful code.