I am looking for statistics (or estimations) that backup the claim that coding standards help reduce bugs. Hard-numbers would be nice, although I haven't had much look finding any. I've even looked at bug tracking for various open-source projects, but have not been very successful finding what I need. Does anyone out there know of any place I might be able to find this? Or do any of you contribute to any open-source projects that have had bugs that may have been avoided with better coding standards?

  • 5
    good luck! finding stats on just about anything programming related is really hard. – Winston Ewert Mar 8 '12 at 22:57
  • I read the coding standards once ... and that is the end of that story. StyleCop, on the other hand - I run it every day. – Job Mar 9 '12 at 3:59
  • IMO most of the time to fix bugs is spent fixing bugs that arise out of complexity. Therefore, your job as a developer is to continue to battle against all the legion and various Forces of Complication. starting with business requirements themselves, and going through to coupling, dependencies, and architecture, as well as consistency and readability. Poor coding standards represent only a small battalion in the Forces of Complication lined up against you. – Brad Thomas Jun 17 '16 at 20:36

Coding standards on their own don't reduce bugs. Coding standards as part of a sound software development process reduce bugs.

Here are two papers that study the statistical impact of sound software engineering process on defect reduction that you can use as a starting point:


Coding "standards"... There are a lot of areas of development that can be standardized. Are we talking about coding conventions, like naming standards etc? Or are we talking about something deeper, like TDD/BDD, CI, etc?

I can tell you that adherence to a "test-first" methodology, with CI enforcing passing tests and good code coverage, does reduce the number of bugs found by the client. Automated testing, both by the developer and QA, is also a relatively "cheap" way to find bugs because they generally have very short feedback times. You can know that you didn't write what you thought you wrote by running about 45 seconds' worth of unit tests. A couple hours of integration tests will find places where plugging things together didn't go as planned, and end-to-end and automated UI testing can quickly spot functional faults in the software at very high levels.

They also prevent regression. You found a bug. You write a test that will prove that behavior no longer occurs, you code until the test passes, and now you have a test that from this point forward will ensure that bug is never a problem again. This is, in my experience, a major source of new bugs; fixing one thing breaks something else, and your developer testing of the fix may not cover that other situation that's now broken. Breaking stuff that used to work is a HUGE red flag to your clients.

Lastly, this automated testing structure you build as part of this methodology will very easily give you an environment where you can release a new build of the software at literally a moment's notice. "Hey, that bug you just fixed has been causing some real headaches; when will you have that ready in a new version?" click "Oh, in about 5 minutes when the build server finishes publishing it to the download page".

As far as basic coding conventions, like standardizing variable names etc, I have found most of that to be less useful and more irritating. Those are the kinds of standards that are "wonderful, because there are so many to choose from". What you perceive as the difference between a PascalCased and camelCased identifier may not be what someone else thinks. Leading underscores, name length limits (or requirements that method/field names tell a story); other than conventions enforced by the compiler or that are commonly seen in language-specific library code, the modern IDE can tell you everything you need to know about a variable or function including whether you should or shouldn't try to use it in a particular circumstance. In addition, running a code convention check will often return problems with code you can't or don't want to change, like a third-party library that used a different set of standards, or interop code which may conform to Win API naming standards instead of your native language's standards. You end up adding cruft to your code to tell your tool to ignore the cruft in your code.


Every SQL injection vulnerability is a defect that could have been prevented with a coding standard. Statistics on SQL injection vulnerabilities are, AFAIK, available.

Every buffer overflow vulnerability could have been prevented with a coding standard. Statistics on those are probably available too.

Not the answer you're looking for? Browse other questions tagged or ask your own question.