Real World Coding Issues: Part I

I’m writing this article about coding issues at a time when I am winding down a contract I am working on. When I do, I think about the state of the code when I joined the team and the state when I leave. I work very hard to make sure that I leave the code, project, and team in a better state from when I joined. For this contract, I was hired to specifically work on performance and code quality. This project suffers from the same coding issues that I see repeatedly as a contractor. The goal of these articles is to give you some statistics and to highlight just some of the issues that I see in most every project that I work on.

This article is turning out to be full of so much of this information that I want to share, that I’m going to have to break it up into smaller more consumable bites. I hope you read all the articles in this series so you too can improve the performance and memory issues along with the common code issues that I see in the projects where I work. Most of the code samples are from this project along with some from my OOS project Spargine and some from ChatGPT.

The Statistics

I was curious if all the work I’ve done for this project really did help the quality of the code. What I did was to take the comprehensive EditorConfig file that I use for all my projects (link at the end of this article) and apply it to the code the day I started, using Analyze in Visual Studio and compare it to the code the day I left the contract. The code I had in the pull-request process when I left was moving the solution to .NET 7 so that we could take advantage of some of the great performance improvements including code generators.

The statistics I looked at were the number of classes in the solution, members, cyclomatic complexity, maintainability index, depth of inheritance, class coupling, lines of source code, lines of executable code, lines of cloned code, unit tests, code errors, code warnings, and code messages. Most of the statistics are moving in the right direction. Of course, I wished the numbers were better, but am happy with most of them. I do wish the code errors (3,677) and warning numbers (6,426) were better.

This code base has been around since the mid-2000s, so like with most older solutions it suffered from a lot of "dead code". I spent a lot of time cleaning up this dead code and there is more to do, but I was able to remove 883 members, almost 45K lines of source code, and 1,309 lines of cloned code. But there is one statistic that I write and speak about a lot because I see it in every codebase I work on.

Cyclomatic Complexity

I’ve been asking attendees at my coding standard conference session for almost twenty years "What is cyclomatic complexity and what does the number really mean?" Most engineers have a hard time explaining cyclomatic complexity off the top of their heads, but it’s basically the number of paths that a method can take until it is completed. The higher the number, the more paths are taken. You must strive to keep this number low. I try to keep the number under 20. Much of the information online says the maximum number should be 25. Higher numbers make more complex code and makes it less reusable.

But what this number really means to me is that it’s the minimum number of unit tests you need to write just to test the encapsulation of the method! Many methods in this code base had numbers north of 100. So that means over 100 unit tests just to test encapsulation. I’ve never seen that many unit tests for a single method! From my analysis, the code base needs 76,479 more-unit tests at the minimum.

There isn’t a company in the world that will stop development just to add them. So, it’s very important to ensure that unit tests are written at least for every public and protected method in the code base. Since this code base is severely lacking in unit tests, I advised the team to not only make sure they are there for new code, but to add them of the methods that are missing them as they are modified.