Based on 8,000+ analyzed software projects
Program maintenance is one of the most tedious and unliked jobs in the software industry. If software programs start to become complex, maintenance costs will increase exponentially. Who didn’t experience the “open a source file and quickly close it after being overwhelmed by too much complexity”? An interesting question is whether certain programming languages force engineers to write complex code. Assembly code immediately pops to my mind, but what about the higher-level languages? Are there any differences?
TIOBE measures more than 8,000 commercial software projects each day, which is more than 1.5 billion lines of source code, and we keep track of complexity. Let’s data mine this vast lake of figures a little bit and check what programming languages produce most complex code.
For the sake of simplicity, we focused in this study on the mother of all complexity metrics: cyclomatic complexity. This metric was introduced by McCabe in 1976 and is an approximation of the number of paths through a function. If you have one “if” statement in a function, its cyclomatic complexity is 2 (one for the “if” branch and one for the “else” branch). We could have applied other and maybe better complexity metrics such as cognitive complexity, static N path count, or any other new and shiny kid on the block but cyclomatic complexity is simple to understand and I am pretty sure that results will not differ much.
Let’s have a look at the average number of paths through a function we found per language:
(Based on 1,515,092,113 lines of commercial source code)
Wow. There are quite some differences! Note that we took the 8 most checked languages by us and added the best (Rust) and the worst (MATLAB) language as a reference.
Rust is a clear winner, followed by C# and Java. Since Rust is a young language, there is not much industrial code available yet. Hence, the 1.32 number of paths should be taken with a grain of salt, although it gives good hopes for the future. C# and Java are well established high-level languages with expressive power. The results for C# and Java are affected by the huge number of simple getters and setters (and properties) that are often used and usually are one-liners.
At the other side of the spectrum, we find MATLAB with an average of 6.03 paths through a function. This is not because the language forces programmers to write complex code, but because the majority of MATLAB programmers are domain experts with little experience in software engineering. Interestingly, C is at position 2 in this list. One of the reasons for this is the lack of error handling support in C thus resulting in lots of “if” statements to check for possible error status returns. This is exactly why also Go has a bad score. Error handling in Go is idiomatically done via return statements as well, thus increasing the need for lots of extra “if” statements.
JavaScript is also on the wrong side. There is no clear reason for this, except that we experience that the overall measured quality of JavaScript code is usually pretty bad. Front-end development appears to be more about speed of delivery, ever-changing requirements and tools, and less skilled engineers.