Jake Scruggs

I just released version 0.7.6 of metric_fu and there's all sorts of new stuff: First, MetricFu is now a Ruby gem on GitHub at: http://github.com/jscruggs/metric_fu Also, the Flog task can now flog any set of directories you like. Just put this into your Rakefile: MetricFu::DIRECTORIES_TO_FLOG = ['cms/app', 'cms/lib'] And, the Flog reports are much nicer: The Flog report generator now looks at a MD5 hash of the files its examining to determine if they files need to be re-Flogged -- which saves time. The Saikuro report generator can also look at custom directories like so: MetricFu::SAIKURO_OPTIONS = {"--input_directory" => '"cms/app | cms/lib"'} MetricFu started its life as a Rails Plugin, but I'm trying to turn it into a flexible gem that can be used in any Ruby application (but still have defaults that enable easy use in a Rails project). Eventually I'd like to create something that could tell you about methods that have hig...

If you're going to be in the Chicago area on or about Saturday, September 20th, you can see me give my "Using Metrics to take a Hard Look at Your Code" talk at the Windy City Rails Conference . David Heinemeier Hansson, David Chelimsky, and Noel Rappin have been announced as speakers and I'll be joining them for a interesting day of Rails related goodness. Here's the abstract: It's an interesting fact of human nature that you can't do something every day and not secretly suspect that you're good at it. Which goes a long way toward explaining why everyone thinks they write fine code. To combat this self-delusion you can use metrics to take a hard look at your application. This talk will discuss the ways in which you can measure how good your Rails project really is. And how to fix the bad parts. Using a daily metrics build (run every day by CruiseControl.rb) you can compile a 'hit-list' of the worst methods in your application. Then your team ...

Every time I create a new rails project I usually put off writing tasks to analyze the code's quality 'cause it takes time and time is, you know, finite. So I've decided to extract some code into a rails plugin which I call metric_fu. It's a bunch of rake tasks that produce reports on code coverage (using Rcov ), cyclomatic complexity (using Saikuro ), flog scores (using Flog ), and rails stats (using 'rake stats'). It knows if it's being run inside a CruiseControl.rb build and puts the output in the Custom Build Artifacts folder so when you view a build you see this: The coverage report is your standard rcov report: Flog output is thrown into an html file: At the end metric_fu calculates the average flog score per method: You might want to check out my previous posts on what to do with a Flog report: The Method Hit List and When You Should Ignore Metrics Saikuro's output is the same as always: (I changed the warning and error levels for this pic -...

Everyone thinks they write good code -- it's just part of human nature. You can't do something every day and not secretly suspect that you're good at it. Self-delusion is a powerful thing so you need to use metrics to take a hard look at your code. On my current project, we've just added a daily metrics build (run every day at midnight by CruiseControl.rb ) that takes a look at our code in three ways: Code coverage with Rcov Cyclomatic complexity with Saikuro And um..., Flogging with Flog Rcov is a code coverage tool that can be used with Rails Rcov to add a bunch of rake tasks to your build so you can figure out which lines of code are run by your tests... and which are not. Saikuro computes cyclomatic complexity which "measures the number of linearly independent paths through a program's source code." Methods with more paths are harder to understand/debug/modify. And Flog is cyclomatic complexity with an attitude. It scores ruby methods with an ...