Quality Assurance in Programming: How to Keep Your Code Clean and Sustainable

Simple Programming Lasts Better and Longer

Of course, anyone who is exceptionally good at their job also wants to show that they are. With developers in particular, vanity can be counterproductive. Solve problems easily in the code instead of building convoluted dependencies and complex constructs. Because the less expertise others need to read the code afterwards, the better. When writing code, think about its upkeep, the customer or your successor and take more time to structure it clearly and to simplify it than to figure out impressive gimmicks.

Here's How to Properly Comment on Your Code

Nobody likes to talk about it, but almost every programmer has experienced it. When you open an older piece of code, you wonder what kind of programme it is, what it's good for, and who wrote it in the first place - only to find out it was you. Bad comments and messy documentation can follow you for years. Something that is especially tough: Even if you put a lot of effort into your comments, your own notes may not mean a thing to you a year later because you took the context - which is lost now - for granted at the time. So put your comments through their paces:

• Write the code in a way that is self-explanatory (for example, name variables according to their content)
• Only comment where the code is not self-evident
• Make dependencies with other programmes clear
• Edit even old comments over and over again. The longer it takes you to wrap your head around old code again, the more urgently it needs new comments
• Describe the solutions to problems you encountered, but also describe the problem itself

In the Beginning Was the Test

How, or rather when, your software is tested can not only improve your own code, but can also be critical for the success of the project. Because for companies that develop with a test-driven approach, the first step is to already assume the ideal result. Then tests are designed that are suitable for checking this success. Only then does coding begin, optimised for the tests created beforehand.

In this way, the developer never works in the dark and can work in a goal-orientated manner. The software is tested again and again so that there are no major deviations from the target and the customer is satisfied as he gets exactly what he ordered. Unit tests can also be used to check partial successes in a straight-forward manner - something that motivates the developers. Test-driven development is therefore worthwhile, because it simplifies the organisation of work and makes it possible to work with several teams at once.

Standardisation Makes Life Easy

While code is designed for computers to maintain it properly, it still requires people. For them to be able to read the code correctly in the first place, however, everyone involved in the project should strictly adhere to the same coding standards. Sounds boring and isn’t difficult in itself, but it does require consistency. Interrupting the workflow to take a look at a manual, just so that a paragraph is correctly formatted which is not visible in the product anyway, can feel like an annoyance. A change of perspective helps at this point, because anyone who works with this code later will thank you.

Quality Assurance While Coding: This Is How exali-IT Does It

We asked our IT department how a consistently high quality of the code is ensured. We have compiled three lessons from the responses:

1. Regular Reviews

Before a new feature is implemented at exali, it goes through three code reviews. First, the developer checks their own code, next, a developer who was not involved in the writing, and finally, the development manager. If an error or inaccuracy is discovered, the process starts all over again. Only when all reviews have been successful is it uploaded into the live system.

2. Enforced Coding Guidelines

At exali, the PSR coding standard is not only recommended for PHP programming, it is mandatory. This means that a violation of the guideline is reported as an error during testing and is treated accordingly and corrected. Inaccuracy and lack of clarity would not be acceptable because of the mass of code that flickers across IT screens every day alone. With PSR, we rely on an established standard so that new colleagues can also be trained quickly or, in the best case, already have some knowledge in this area to begin with.

3. Don't Be Afraid of Change

A website getting old means work. Because, admittedly, there is always some issue and if, in fact, there is nothing to work on, then a new PHP version is released that makes parts of the code unusable. This is what happened to us when the move from PHP version 5 to version 7 was impending. The reason: Features that we used repeatedly were no longer supported. So parts of the base code had to be rewritten and turned inside out. Despite the great code quality, the project turned out to be a major task. Bad code would have made the version upgrade next to impossible.

Bugs in the Code or Other Risks: Professional Indemnity Insurance Offers Protection

You can take out your liability insurance online in just a few minutes. Any questions? Our customer support is happy to provide you with answers. Without a call centre or waiting on hold.

Calculate your premium and get your professional indemnity insurance online in just a few steps here: