These tools could be used to turn code smells, duplication, and poorly written tests into a total "score" for well-written code. Although this should hardly be the way code is evaluated.
Also, complex code that isn't written "the best way" isn't so bad. It incurs technical debts. Like financial debt, technical debt can be very good if used properly--or end with disastrous results if used irresponsibly. So let some component of a code base bloat if you need to hit a deadline so long as you're going to refactor later.
Nice link. There are lots of metrics, but in this case, I'm talking about multi-language, large projects where considering tons of code and not enough engineers, there's no bandwidth to even compute this stuff. Thus I'm sticking with the easiest metric there is: lines of code. It's not perfect, but it's still valuable.
Comments
I would think that the number could greatly fluctuate. Perhaps there are better ways to measure complexity of code such as http://thinksimple.pl/entries/88-Ruby-static-code-analysis.
These tools could be used to turn code smells, duplication, and poorly written tests into a total "score" for well-written code. Although this should hardly be the way code is evaluated.
Also, complex code that isn't written "the best way" isn't so bad. It incurs technical debts. Like financial debt, technical debt can be very good if used properly--or end with disastrous results if used irresponsibly. So let some component of a code base bloat if you need to hit a deadline so long as you're going to refactor later.
Nice link. There are lots of metrics, but in this case, I'm talking about multi-language, large projects where considering tons of code and not enough engineers, there's no bandwidth to even compute this stuff. Thus I'm sticking with the easiest metric there is: lines of code. It's not perfect, but it's still valuable.