What metrics should we use to judge code quality?

Question

I'm currently working on a large project, where many developers worked over time and the code was terrible. After many refactorings we now arrived a point, where the code is ok. Now I'm thinking what "ok" means - probably for everyone something different.

Do you think it's possible to specify "ok"? What is important? NDepend metrics? Test Coverage? Comments? Coding style? Documentation?

I know there are already many topics about coding style or commenting (for example here). This question is just about what facts are important.

Answer 1

I think for any non-trival project you should have coding guidelines in place (style, comments, etc.) and metrics to know if they are being followed or not. The list you've outlined is a very good start.

Answer 2

There are so many things that can be said to be attributes of ok/good code.

• no errors or warnings when compiled

there are also a few other threads on SO about this topic...

Answer 3

You're mixing up two different things.

You talk about coding style, but then you mention test coverage, metrics, etc.

Coding style can certainly be specified - all the requirements document has to state is that "For purposes of code maintenance and consistency, this project will follow these coding styles and standards."

Generally, however, most projects merely require, "Good industry practices" and "a consistent coding style across the project" and leave the actual definition and implementation of that up the to developers.

However, the other issues you're discussing, bad code which required refactoring, tests, coverage, etc (I'd throw LINT and static analysis as well) these should be explicitly specified and required. There's no reason to leave them out of the specification - they are hard metrics that show what type of coding errors (or, getting on the fuzzy line between style and bad code, what type of coding patterns are likely to produce buggy code) are likely in any given code, how well it performs, and how well the tests show correct operation.

In large projects the customer will sit down with the lead developers and go over the LINT configuration, for instance, to make sure it meets their needs and no frivolous errors are slowing down development.

So, in short, yes, all this can (and should, IMHO) be specified for any project of significance.

Answer 4

You're right that okay is different for everyone. That said, once you've defined the expectations, the best way to maintain it going forward is through frequent code reviews.

People, especially new people on a project, always bring their own style. Code reviews help androgynize the code.

Answer 5

There are a number of things which will improve the quality of a project which have nothing to do with code and tools.

1. Requirements management. Have some process to apply quality control to your requirments. Do they make sense? Who asked for it? Are they the right people to make these requests.

2. Test Design. Build your tests according to the requirments, not the implementation. Do not let your coders do the testing!

3. Test Everything -- Every Time. Go through the complete test cycle for every release, there is no such thing as a minor release.

In my experience things like code metrics and code standards never really work. You will know who the deadbeat coders are; you dont need a formal process to identifiy them.

The one tecnique which really works to improve quality and output are code reviews. You need some disipline and backbone to have three of your resources spend a day reveiwing 5 days work. But nothing uncovers potentail problems so thouroughly, and, damit people just write better code if they know someone is going to critique it next week.

Answer 6

StyleCop ... also, FxCop ...

A team should absolutely standardize their styles. Some room for personal choice, but a team should absolutely standarize their styles. Code is more readable, more maintainable, more easily reviewed, etc. etc. etc.

Answer 7

Some kind of guidelines (style is less important than content IMO), e.g. best patterns / practices, but more importantly CODE REVIEWS.