What code metric(s) convince you that provided cod

Question

Code lines per file, methods per class, cyclomatic complexity and so on. Developers resist and workaround most if not all of them! There is a good Joel article on it (no time to find it now).

What code metric(s) you recommend for use to automatically identify "crappy code"?

What can convince most (you can't convince all of us to some crappy metric! :O) ) of developers that this code is "crap".

Only metrics that can be automatically measured counts!

Answer 1

Number of commented out lines per line of production code. Generally it indicates a sloppy programmer that doesn't understand version control.

Answer 2

TODO: comments in production code. Simply shows that the developer does not execute tasks to completion.

Answer 3

No metrics regarding coding-style are part of such a warning.

For me it is about static analysis of the code, which can truly be 'on' all the time:

• cyclomatic complexity (detected by checkstyle)
• dependency cycle detection (through findbugs for instance)
• critical errors detected by, for instance findbugs.

I would put coverage test in a second step, as such tests can take time.

---

Do not forget that "crappy" code are not detected by metrics, but by the combination and evolution (as in "trend) of metrics: see the What is the fascination with code metrics? question.

That means you do not have just to recommend code metrics to "automatically identify "crappy code"", but you also have to recommend the right combination and trend analysis to go along those metrics.

---

On a sidenote, I do share your frustration ;), and I do not share the point of view of tloach (in the comments of another answers) "Ask a vague question, get a vague answer" he says... your question deserve a specific answer.

Answer 4

Methods with 30 arguments. On a web service. That is all.

Answer 5

Ratio of comments that include profanity to comments that don't.

Higher = better code.

Answer 6

Metrics alone do not identify crappy code. However they can identify suspicious code.

There are a lot of metrics for OO software. Some of them can be very useful:

• Average method size (both in LOC/Statements or complexity). Large methods can be a sign of bad design.
• Number of methods overridden by a subclass. A large number indicates bad class design.
• Specialization index (number of overridden methods * nesting level / total number of methods). High numbers indicate possible problems in the class diagram.

There are a lot more viable metrics, and they can be calculated using tools. This can be a nice help in identifying crappy code.