Writing code isn't easy. Writing good quality code is difficult. Testing code quality is even more difficult. So what makes for good quality code and how do we test for it? The short answer is: it really depends.
As a developer, I often discuss what constitutes well-written code with other developers. Sometimes we end up agreeing, but usually it turns into a very lengthy discussion. Aspects which are thought to determine code quality include:
All of the above aspects have merit, but they could just as easily be wrong given that quality is subjective. Consider the following I have recently been working on:
There are advantages and disadvantages of each application’s quality aspects.
Application A has fewer bugs, but more work needs to go into rearranging code in order to allow for new features. Application B, on the other hand, has a higher bug rate, but can quickly accommodate new features and fixes for the bugs that do occur.
Code quality continuum
These application examples are at opposite ends of the ‘code quality continuum’, as I call it.
This continuum defines the quality aspects that constitute good quality code for each application and provides a measurable scale that allows for an objective view of each individual aspect. Besides acting as a scale, the continuum also provides the following: the rationale for each aspect, the advantages and disadvantages of being at either end of the scale and guidance on how to objectively verify the position on the scale. An example is given below.
|Rationale||The reasoning behind how this aspect applies to code quality|
|High advantage||The advantages of being at a high position on this scale|
|High disadvantage||The disadvantages of being at a high position on this scale|
|Scale (1 to 5)||Each scale position should define what it means to be at that position|
|Low advantage||The advantages of being at a low position on this scale|
|Low disadvantage||The disadvantages of being at a low position on this scale|
|Verification||How to verify an application’s position on the scale|
The aspects I am most interested in are: separation of concerns, unit test count, code coverage percentage, code coverage exclusion percentage, release frequency and bug regression. Other concerns might be expressiveness of code, comment use, etc. For now, though, I will settle for the aspects I mentioned first.
Some of the aspects I mentioned above have no direct link to the actual code. However, in my experience, they are indicators of a software product’s general quality. These aspects are also often thought to constitute good code quality.
The table below provides possible definitions for several aspects.
If we take this table of code quality aspects and apply it to the applications mentioned above, we could come up with the following table.
|Application vs. code quality aspect scale||Separation of concerns||Unit test count||Release frequency||Bug regression||Avg. score|
From the table above, we can conclude the following:
Which application has the higher quality? Given the amount of data, it is still not possible to determine which application has the higher quality. The table only indicates how each application can improve on each scale aspect. To benchmark applications against each other, we would have to broaden the number of aspects on which to test each application, so as to increase the data set.
However, it is probably safe to say that an application scoring high on all aspects is of better quality than an application that scores lower.
In a real-world situation, these numbers might be used as quality gates to promote an application to production.
Code quality is subjective and can only be made objective if it is broken down into individual aspects. Each aspect needs to be assessed independently. In the future, I may look into tooling that facilitates the assertion of these quality aspects.
27 oktober 2020 (online seminar op 1 ochtend) Iedere organisatie heeft te maken met het integreren van systemen en applicaties. Maar hoe worden integratieprocessen en informatiestromen nu werkelijk geautomatiseerd? En hoe pakt u dit op een efficiën...
24 november 2020 Praktisch seminar waarin Sander Hoogendoorn u laat zien hoe u microservices kunt inzetten in uw softwarearchitectuur.Het nieuwste architectuurprincipe microservices lijkt veelbelovend: verkorte time-to-market, schaalbaarheid, autonom...
25 en 26 november 2020 Praktische tweedaagse workshop met internationaal gerenommeerde spreker Alec Sharp over herkennen, beschrijven en ontwerpen van business processen. De workshop wordt ondersteund met praktijkvoorbeelden en duidelijke, herbr...
8 december 2020Workshop met BPM-specialist Christian Gijsels over business analyse, modelleren en simuleren met de nieuwste release van Sparx Systems' Enterprise Architect, versie 15.Intensieve cursus waarin alle basisfunctionaliteiten van Enterprise...