GLSEC2008 – Using Metrics to Take a Hard Look at Your Code
From a most-useful-in-my-job perspective, Jake Scruggs’ talk on metrics was it. He is the author of metric_fu which is a gem I keep meaning to incorporate into our code somehow. Here are the notes:
- One of the first slides had a fortune cookie fortune: a can of worms won’t open itself
- Hiring a bunch of smart people does not guarantee beautiful code
- Review old code to see if that hot piece of code holds up 6 months later
- Carlin’s law: everyone slower than me is stupid, and everyone faster is crazy
- Code coverage
- Coverage numbers are relative to the language and/or project for completeness
- A good heuristic for number of tests: # tests = # paths
- complexity measurement
- Another cool tool (with a great url / logo) is Flog
- See Jake’s post on the score values to help you interpret what they tell you. What, you mean 394.7 isn’t good?!?!
- Complexity isn’t (always) bad, you just need to know where the complex parts are
- A ruby cyclomatic complexity tool is Saikuro which I haven’t played with yet. But will.
- Metrics are a guideline, they do not tell you what to do
- Things that score better metrics wise might be worse for your code
- Explain your cool (complex) code
- inject can be evil from a complexity perspective, though I didn’t write down why. This post explains what inject does and it just seems like thinly veiled ruby black magic from here. Of course it could really be quite obvious and I’m just tired and/or suspicious of all things for black magic these days.