Recently, after doing the keynote session on code quality at a conference in Denver, I received a comment from one of the attendees. He said my session was “too much angry coder”. After receiving many great comments about the session, this one took me by surprise. I thought about it and commented back, via Twitter…
My comment is so true, most of the in-production code that I see is severely lacking in code quality, even the basics. Many of the apps I use are also lacking when it comes to code quality. Since I feel so passionately about this, the theme for all my code conference sessions is and will be for the foreseeable future…
Improving Code Quality… One Developer At A Time™
Several years ago, I decide to just focus on the developer, to try to improve code quality. My goal every time I do a conference session is to motivate just one of the attendees to go back to their team and make quality an important feature of their software projects.
In a few of my conference sessions, I show the following numbers from a in-production application, they are pretty shocking.
- Critical Error Violations = 4
- Error Violations = 741
- Critical Warning Violations = 41
- Warning Violations = 22,316
- Information Violations = 1,100
The solution has 333,606 lines of code… that is a violation every 13.78 lines of code!
Here is the breakdown by violation type:
- NET = 28
- NET Security = 46
- Code Style = 1,100
- Code Design = 1,254
- Exception Handling Design = 458
- Exception Handing Usage = 221
- General = 391
- Globalization = 5,378
- Interoperability = 2
- Maintainable = 73
- Naming = 8,074
- Performance = 1,180
- Security = 49
- Spelling = 5,759
- Usage = 189
On top of that, the solution has:
- Over 65K possible cloned lines of code.
- Average maintainability index of 77. The goal is to have an index of 100.
- Total cyclomatic complexity of 95K.
- Average inheritance depth of 1.7.
- Average class coupling of 5.76.
I would like to talk about the cyclomatic complexity number. In the end, that number is the minimum number of unit tests that need to be written just to test encapsulation (the first pillar of Object Oriented Programming)! This project has only 1,800 unit tests (that takes over an hour to run) with none of them testing encapsulation! This is a recipe for disaster or what I like to say, it is a house of cards. All house of cards will eventually fall down.
Unfortunately, these numbers and worse are what I see in most code that I analyze. The trick to not getting numbers like this is to either not do them in the first place or fix them while you are coding. I doubt that if you went to your manager and said that the app has over 24K violations, he or she would give you the time to go and fix them. The numbers above are down from when I first got a hold of the code since I spent over a year fixing the most important ones!
How to Learn Good Code Quality Practices
Unfortunately, most training sites like Pluralsight, and conferences like VSLive, do not focus on code quality at all. I wrote an article on this subject titled “Quality Of Software Is Getting Worse, Not Better, In 2017” and about conferences titled “Soft Skills – As Important If Not More Important Than Technical Skills At Conferences”. If you are lucky, they might teach this at a local school. You should check out your local user group or local community conference like Code Camp since real world developers teach them, just like you.
Another good way to learn is to find a team that already practices good code quality practices. I was lucky in my beginner days to be part of a few of these great teams. My code quality also naturally got better since I did not enjoy getting bugs from quality assurance. Fixing bugs are never fun and take away from implementing new features. Customers pay for features, not bugs.
Let Tools Help You
These are the tools that I swear by to help me find quality issues and fix them. The good thing about these tools that I do not think most companies realize is that they are a teaching tool too! Once these tools finds issues in your code over and over, you will eventually learn. You will start avoiding these issues without even thinking! Below are the tools I always install before I can code.
StyleCop (free from Microsoft) makes sure standards are adhered to, makes sure you document your code and more. Before I run StyleCop, I run GhostDoc (free & paid versions from Submain) since it makes it easy to add proper xml comments to my code and proper headers to each file.
CodeIt.Right from Submain is a static code analysis add-in to Visual Studio. It follows the same rules as FxCop/ Analyze. The best part of CodeIt.Right is that it not only finds violations but 90% or more of them it will fix for you, properly, using good coding standards and patterns. It can save your company tens of thousands of dollars per year and more. At one company I worked at I estimated it could save them over three million dollars per year.
Analyze in Visual Studio
To make sure CodeIt.Right found all the violations, I run Analyze in Visual Studio. If it finds anything then I fix them before checking into source control. If you do not have Analyze in your version of Visual Studio, you can run FxCop on the compiled assemblies.
I also use CodeRush from DevExpress. It is a refactoring tool that also makes it easy to find defects and runs unit tests in half the time and lots more.
There are many other tools out there, but these are my top four.
Code Quality Experience Comes with Time
If you use the tools above, go to user group meetings or community conference, you will get better and better over time. The same person that called me an angry coder, also called me old! This is how I replied…
Check out another one of my articles titled “Politicians… Welcome to the Real World of Software Engineering”. I also talk about this in more detail in my book “David McCarter’s .NET Coding Standards”.
In the end I think this attendee mistook my passion as anger. Then I will freely admit that I am an old, angry coder! How do you learn or implement code quality? Please make a comment below.