+972 52-548-6969
Meaningless code quality, part 2
time to read 1 min | 86 words
Here is the next slide in my presentation.
Code quality is a hard metric, it can be backed up by numbers, if you need to. Fairly often, it is measured by gut feeling and "this is a mess".
One interesting problem with code quality is that you generally don't have a good way to measure the maintainability of a particular solution, regardless of its current code quality.
Comments
A good code quality metric exists - it's WTFs/minute.
Easily googlable.
For example,
http://imod.co.za/2008/02/07/wtf-measure-of-good-quality-code/
Metrics about coupling and dependencies are a good indication of maintainability. But, they're not foolproof.
One thing I've learned over the years is to never underestimate people's ability to write lousy code to make metrics look good.
Metrics should not be known by developers, if you do not known the metric you cannot write code only for the sake of having good metrics. But in the end metrics themselves are not so useful.
Code quality can means different things, I think that we should speak of Code quality in a team, meaning that the code have good quality if everyone in the team can look at it, and understand how it works and most important, he can modify it with good confidence.
Clearly that are some factor like number of bug found that can be also a good starting point to measure quality of a particular piece of code.
alk.
Comment preview