How many bugs per lines of code?

How many bugs per lines of code?

On average, a developer creates 70 bugs per 1000 lines of code (!) 15 bugs per 1,000 lines of code find their way to the customers. Fixing a bug takes 30 times longer than writing a line of code.

How many bugs per 1000 lines of code?

Commercial software typically has 20 to 30 bugs for every 1,000 lines of code, according to Carnegie Mellon University’s CyLab Sustainable Computing Consortium.

What is defect removal efficiency?

Defect Removal Efficiency (DRE) allows the development team to eliminate bugs before release. DRE is calculated as the correlation of bugs detected internally (by testers and software testing) with the amount of bugs that were detected externally (by users).

What’s the average number of bugs per line of code?

The idea of bugs per lines of code isn’t really a new idea. Steve McConnell, the primary source for the previously mentioned post, has written extensively on defects per lines of code. Covering average bugs per LOC stats in his great book Code Complete (a) Industry Average: “about 15 – 50 errors per 1000 lines of delivered code.”

How does refactoring reduce number of bugs per line of code?

A refactoring that doesn’t make the code easier to read (and likely not any more difficult) but delivers the same functionality while reducing the total LOC is a big win. A win in terms of maintainability, it reduces the far too frequent bugs where multiple files/functions need to be ‘kept in sync’ to ensure correct functionality.

How does a compiler affect the number of bugs?

Compilers make no difference on the nature or number of bugs. Bugs are purely relative to the person who wrote the source code, and bugs themselves can be very subjective in nature.

Is the average number of bugs the same for different languages?

Although the resulting metric might be a bit useful when comparing projects written in the same language, it would be fairly useless for projects written in different languages. One possible source for the claim is Les Hatton’s Software failures-follies and fallacies: