3 ms·

Ask HN: How do you measure your code quality?

11 points by jawns 12y ago

Do you or your team/company have a standard, objective way of measuring the quality of the code that you write, to track personal improvement over time?

bhaisaab 12y ago
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.
loumf 12y ago
I liked the ideas behind CRAP (http://googletesting.blogspot.com/2011/02/this-code-is-crap.html http://googletesting.blogspot.com/2011/02/this-code-is-crap....) -- 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.
jdlshore 12y ago
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.
wikwocket 12y ago
Lines of code. Oh, you said quality, not quantity... Same answer.
oweiler 12y ago
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
S4M 12y ago
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.
tedyoung 12y ago
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,
nkkav 12y ago
In FPMs (or FPHs if the code is in acceptable condition). Other coders user SPM/SPH but it is essentially the same thing.

11 points by jawns 12y ago

Do you or your team/company have a standard, objective way of measuring the quality of the code that you write, to track personal improvement over time?

bhaisaab 12y ago

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.

loumf 12y ago

I liked the ideas behind CRAP (http://googletesting.blogspot.com/2011/02/this-code-is-crap.html http://googletesting.blogspot.com/2011/02/this-code-is-crap....) -- 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.

jdlshore 12y ago

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.

wikwocket 12y ago

Lines of code. Oh, you said quality, not quantity... Same answer.

oweiler 12y ago

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

S4M 12y ago

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.

tedyoung 12y ago

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,

nkkav 12y ago

In FPMs (or FPHs if the code is in acceptable condition). Other coders user SPM/SPH but it is essentially the same thing.