Why is bug reports (unit testing, QA testing, etc.) not a good measure of code quality? And what is the best way to measure code quality?
I believe code quality can be measured more during peer reviews rather than the number of bug reports during testing. Is this reasonable?
UPDATE: Which quality metric should number of bug reports be attributed to then?
Code can be of utmost quality and still do the wrong thing, so bugs and code quality sometimes don't correlate. Also, I've seen plenty of bad code that did what it was supposed to do just fine.
"Quality" is about code doing the correct thing the appropriate way, not just moving the instruction pointer from one statement to the next. There are a vast number of bug-free ways to do the wrong thing, e.g. implementing a O(n**3) algorithm when a O(n log n) algorithm that has the same results exists.
Because bug count is a measure of the status of your code, while code quality is a measure of the ease of performing understanding/modifications to it. These two measures are, of course, related in some way, but they represent two completely different facts.
I'd say bug count is a measure of good quality code, but it's more of a reflection of bad code than the definition of bad code itself. Keeping the cyclomatic complexity low, and the organization of your code high, you can reduce the number of bugs in your application. I've seen some code that's ridiculous spaghetti code, but somehow has no apparent bugs. That's great and all, but it's a nightmare to maintain.
It's sort of the difference between using good writing style, and having a good plot that has no holes. You can have an excellent, enthralling writing style, but if your plot is full of holes, your book sucks. On the other hand, you could have the best plot on the face of the planet, but if your wording is too difficult to understand and your writing style is boring, you've not written a good book.
They tend to be correlated, but one is more causally correlated. Bad code often leads to bugs, not the other way around.
Another issue not mentioned so far is that bug count only serves as a comparative measure between the same project being worked on the same people and being used by roughly the same amount of people.
For example, you've always had a program written by your team used by 20 people in total. By some unexpected event, your program becomes suddenly famous and 4000 people start using it. You'll very probably see a surge in the amount of outstanding bugs with the exact same code (and thus the exact same quality.)
Bug count is more a measure of testing quality than of code quality. Awful code will have lots of bugs, but great code can too, the measures are not directly correlated.
Now, to close the loop, if your code is developed by the same team and used by the same people, an amount in the bug count probably will point to some problem in the process.
Bug counts (e.g. P1/P2 bugs per iteration) is a decent indicator of perceived quality1, if you did the appropriate testing of course (if nobody tests or uses your software, bug count doesn't mean anything).
And if you have high P1/P2 bug counts, you can't consider a software product as being high quality, regardless of the maintainability of its code (because it follows standards, because it is frequently inspected by static analysis tools, because it doesn't use copy paste, because it has a high test coverage rate - sigh - etc).
1 The customer's perception of the overall quality or superiority of a product or service with respect to its intended purpose, relative to alternatives. Perceived quality is a perception by customers.
Bug count is usually a result of the code quality, but the variations are so large that you can't use it to measure the code quality directly.
Horrible code can still be rather bug free, expecially if it has been around for a while and has been thoroughly tested. Really neat code is still no guarantee that it is bug free, doing the wrong thing the right way still isn't right.
Code quality is usually measured in such terms as readability, managability, stability and testability. It's not that easy to measure, and it's hard to motivate a lot of resources going into measuring it. The customer usually isn't interrested in code quality at all, only in a product that works.
Three reasons, because everything good comes in threes:
Bug count only refers to the bugs you know about. There may be many, many bugs that you don't know about yet, especially if you don't have proper QA. The bug count may drastically understate the real quality problems.
Individual bugs vary dramatically in severity and impact, and even when tagged with these attributes, they are subjective and there's no simple formula for aggregating them. One show-stopper bug (50% of users cannot start the program) is infinitely worse than several dozen cosmetic bugs (this text isn't localized properly in Estonian).
Even if you could somehow prove that your product has zero bugs, it might still suck. I can write a 5000 line program to print "Hello World" to the console using a combination of Reflection, XML, SQL, and Web Services, or I could do the same thing in 5 lines of code. Both have no bugs; one is not very good. I'll let you guess which one.