6 tips for writing more maintainable code
Unless a developer is self-employed, the code he or she writes will likely be touched by somebody else in the (distant or near) future. Not making code easily understandable for other developers will inevitably increase the cost down the line, especially if the person working on the code you wrote has no other choice but to start over from scratch.
It is common knowledge that software maintenance eats up anywhere between 50 percent to 80 percent of total software development costs. However, not many developers appear to understand the importance of writing maintainable code, which is why applications with large amounts of code can quickly turn into unmanageable messes that nobody wants to touch.
For those who haven’t read Steve McConnell’s book titled Code Complete, which teachers developers how to build quality into the beginning, middle, and end of their projects, exploit opportunities to refactor code, and do it safely, to name a few tricks, here are some tips for writing more maintainable code.
Comment your code
Jeff Vogel, the founder of indie video game developer Spiderweb Software, wrote in a post that commenting your code is of utmost importance because if you write a procedure and fail to comment it, the lack of comments will cost you time when you decide to rework it. However, commenting is a skill, which means that practice makes perfect; writing too much and using a bombastic language will not help you because understanding what you actually meant will not be an easy job a few months later.
Writing too little is also a solution you should avoid and commenting in ways that no one can understand (not even you) will eventually turn against you.
Don’t forget about error checking
Every middle-sized program has a lot of functions and procedures, which means that each one should have error checking. Good error checking keeps your program from exploding and makes it faster to debug. When you take a look at a procedure where all the error checking is in order, you don’t have to spend time seeking the mistake.
SEE ALSO: You are what you eat (and code)
Use less code
It makes sense to remember that the less code you have, the less there is to maintain. The oh-so-famous quote “Less is more” works wonders in this case because getting rid of untouched functions and diagnostic statements will make your code look cleaner. If you have the chance to use existent libraries, even better! Although it’s better to rewrite some libraries due to their low quality, some are actually helpful.
Write code that can be easily modified
You can make your code easier to change at one point or another if you avoid certain pitfalls. One of them is some developers’ obsession for writing code for a certain purpose only to copy and paste it elsewhere to do something else. If there is something wrong with it and you have used it in multiple places, you have officially multiplied your problem.
One other common problem is that developers fail to split the code in five modules that each do only one thing if it needs to do five things. Doing all things in one module will make it tougher (even impossible) to make changes without breaking the rest.
SEE ALSO: NASA’s ten coding commandments
Write code that can be easily tested
The sooner an error is found, the cheaper it is to fix it. Although testing every possible scenario can be time-consuming, you should definitely implement automated unit testing because it allows you to see what needs to be fixed when you make changes.
Fix the problem, not the symptoms
The difference between quick fixes and real fixes is that the first scenario occurs when a developer decides to solve the symptoms and not the problem. Real fixes occur when the developer understands the cause of a bug and manages to pinpoint it; everything done hastily will only create confusing code for the next person to clean up.
The secret to saving time and money is to keep it simple and clear. If the person who works on code you’ve written feels the need to start over from scratch, you are not doing them any favors. Before you ask what’s in it for you, the answer is this: the beauty of code is in the eye of the beholder.