Blame it on the Weatherman

Friday, January 10th, 2014
By Daniel Cooper

For a few months now we’ve been using code climate on our main projects and, in the spirit of new year evaluation, I thought I’d share our experience.

Early and often

I should probably make it clear that code climate doesn’t, and shouldn’t, substitute for regular code reviews.

Having said that, I would suspect it’s the case in most programming teams that it’s super easy to get super busy and this means, despite our best intentions, too much time can pass between in depth code reviews. For any reasonably sized project there will be a bit of a scrum where we talk about high level design but it usually doesn’t get into too much detail. This leaves a lot of space for the developer(s) working on the project to build as they see fit.

Nothing is worse than developing for a week, stepping back to look at the project, and seeing the new addition you have made increasing the technical debt of the system. We usually address these at code review meetings but, as I’ve said, they’re not as frequent as we’d like. This is where code climate really shines.

We like to develop “test first” with lots of small pushes hitting the feature branch as the working day progresses. When we do push, code climate will take a look at it for us and perform some static analysis – looking at the following things (taken from the code climate website)

 1. Duplication — Repeated syntax structures in your project. We’ll detect both identical and similar code blocks.

2. Complex method — High complexity for a method definition.

3. Complex class/module definition — This smell occurs when the class has a lot of DSL-style code in its class definition outside of methods. An example would be a User class with dozens of lines of association and validation definitions. On its own, this may not be a problem, but in the presence of other smells it indicates the class may be doing too much.

4. High total complexity of a class/module — Even if a class is made up of simple methods, it will be detected by this smell if it gets too large. This is a sign it might have too many responsibilities.

An extra, slightly rude, developer

After code climate has done its evaluation, and if we’ve been naughty developers, we might get an email looking something like this (names removed to protect the innocent).

Untitled

Now, the static analysis code climate uses is not perfect. It’s possible to write great code with a F score and terrible code with an A. The usefulness of code climate is that the email you get as soon as you check something in forces you to re-evaluate what you’ve just done, and that re-evaluation step is essentially a micro code review. That micro code review should lead to a micro refactor (and because we’ve been testing thoroughly that shouldn’t be too much of an issue). And hey presto, we’ve paid down that £50 technical debt credit card purchase before it balloons to be £300 by the week’s end.

At $100 a month code climate isn’t cheap on paper. However, the first time it nudges you to do a micro review and refactor we think you’ve already broken even on the price.