

Ask HN: How do you measure your code quality? - jawns

Do you or your team&#x2F;company have a standard, objective way of measuring the quality of the code that you write, to track personal improvement over time?
======
jdlshore
I haven't seen any code quality metrics that were worth anything. The most
popular is cyclomatic complexity. You can also simply count lines of code and
get a similar result for most real-world code.

The problem with these metrics is that they only detect bad code, and they're
not very sensitive. In other words, a good score doesn't mean your code is
good; it just means it's not hideous. They don't tell you anything that isn't
obvious just by looking.

You're better off using collective ownership and pair programming or code
reviews if you're interested in improving your skills.

 _Edit_ The issue is that "code quality," once you're past the novice level,
is really about _design_. It's about how maintainable and understandable your
entire system is to humans. It's very subjective and context-sensitive, and
it's the kind of judgment question computers are bad at.

------
loumf
I liked the ideas behind CRAP
([http://googletesting.blogspot.com/2011/02/this-code-is-
crap....](http://googletesting.blogspot.com/2011/02/this-code-is-crap.html))
-- basically it combines Coverage with Complexity and highlights code that is
both complex and has low test coverage.

It's kind of hard to game -- reducing CRAP is easiest with a test or
refactoring.

On the last team I was on, we kept an eye on it, but didn't do anything
systematic.

------
tedyoung
I like to look not just at the code itself (simple measures such as nesting
level and lemgth of method/function), but also at the frequency and
correlation of file changes. Noticing that you often change the same files
together is an indication of coupling that might be bad. You can also weight
the code metric higher for files that change frequently and recently, because
if it's an old file, or one that doesnt change much, the quality is probably
good enough,

------
S4M
It's not exactly a measure, but I recall Ken Thompson saying that good code
makes it easy to change or extend a functionality. (I think it was in _Coders
at work_ from Peter Seibel).

If you want to derive a quantitative metric from that, I guess you could take
the average number of lines/time required to change or extend something.

------
bhaisaab
It is subjective, we've papers on this area but the industry is yet to find
something concrete. Most of us measure code quality by different apparatus,
such as: \- code coverage \- average number of bugs per kloc \- no. of
bugs/faults reports per day/hour/per kloc etc.

------
oweiler
I measure the number of WTFs when the code is being reviewed

[http://www.osnews.com/images/comics/wtfm.jpg](http://www.osnews.com/images/comics/wtfm.jpg)

------
nkkav
In FPMs (or FPHs if the code is in acceptable condition).

Other coders user SPM/SPH but it is essentially the same thing.

------
wikwocket
Lines of code.

Oh, you said _quality_ , not _quantity_...

Same answer.

