You probably hear us mention “quality code” quite a bit, but instead of leaving you to wonder what we mean, we’ve put together an outline to help clarify exactly what we believe makes high “quality code”.
(For a more in-depth look at quality in code, please refer to this blog post on quality in Lean-Agile embedded software development.)
It should work
First and foremost, the software you are writing must work. There is little use in developing something that can’t perform its most basic functions, and for this reason we always make sure the software is fit for purpose.
But how do we know if it works?
Test, test, test
Writing automated tests alongside your code ensures that your software is working at each stage. Without testing, you could come to the end of writing your code only to find that the feature you have just developed isn’t working. You won’t know why it’s not working, and it’s going to take you a long time to find out.
Writing tests at each stage is like creating checkpoints throughout your work. If you find something isn’t functioning as it should, you don’t have to back-track to the beginning. All you need to do is revisit the last point where your tests came back positive, and try to understand what went wrong from there. The main benefit of tests is that they very quickly highlight if something has gone wrong or if you have violated a previous rule of the code base.
A very important element is also understanding whether the tests themselves are working. This is why we practice TDD (Test-Driven Development), where we write a “failing test” first, before writing any line of code. If the test fails before anything is written, then you know for sure that your test works.
Ensuring quality code
Once you know everything is functioning correctly, you can get to work on cleaning up and refining the code. The purpose of making improvements (without changing the functionality of the code) is to ensure it is Readable, Habitable, Maintainable, and Scalable.
If an engineer suddenly leaves or is taken ill, the code they have written needs to be readable so that someone else can come in and understand exactly what each line is being used for. We believe that code shouldn’t contain too many notes or comments, because you shouldn’t need to rely on them to understand what’s going on.
Habitability and Maintainability
Similarly with readability, if someone else is able to read and understand the code, and are able to step in and continue the work, you will have significantly reduced the operational risk to your business.
If the code is clearly laid out, and has plenty of tests, it should be relatively simple to add to it and increase its functionality if need be. Any issues with the new lines of code should be instantly recognised by a failing test.
Software ready for the real world
We hope that helps clarify our understanding of what makes code high quality, but if you have any further questions, please don’t hesitate to email us.
Did you know that we have a monthly newsletter?
If you’d like insights into software development, Lean-Agile practices, advances in technology and more to your inbox once a month—sign up today!Find out more