Code health metrics

[Chris Ford]

Hi all,

Are there any good tools for measuring the health of a Clojure codebase? What is even useful to measure for Clojure? Afferent/efferent coupling, cyclomatic complexity and unit test coverage are metrics I would use for Java, but do they apply equally to Clojure?

I'm aware of Clique and Vanity, which look nice, but they don't seem to perform any analysis.

Cheers,

Chris

[Atamert Ölçgen]

My toolbox is: lein-cloverage (mostly vanity), Midje (TDD), Eastwood (to decrease wtf/minute) + lein check (once in a while).

No fancy cyclomatic coupling hyperdrives. Metrics become more important in larger teams, say 3+ people. They don't add much value for small teams as everyone can follow up with everybody else and provide direct feedback. What's the size of your team?

It's harder to (programmatically and statically) analyze dynamic languages.

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Kind Regards,
Atamert Ölçgen

-+-
--+
+++

www.muhuk.com

[Ambrose Bonnaire-Sergeant]

Hi Chris,

Dynalint can help identify undefined behaviour.

Thanks,

Ambrose

On Wed, Jul 2, 2014 at 4:53 AM, Chris Ford <christop...@gmail.com> wrote:

--

[Paul deGrandis]

Hi Chris,

I have long collected metrics on various Clojure code bases, and have had grand plans for automating the process with an open source tool.

The metrics you look at depend heavily on what you care about - the most telling metrics I've used recently are Assertion Density [1], an adaption of LSCC [2], and an attempt at cognitive load [3].  Typical things I look at are namespace manipulation/jumps per file, docstring-on-function-percentage, distribution of defn size, distribution of anonymous function size, number of functions per namespace, number of symbols per namespace.  In the past I've looked at an adaptation of cyclomatic complexity, distribution of all functions used, and namespace fan-in/fan-out.

I'll echo what others have said above: eastwood, dynalint, and basic `lein check` are good approaches for general lint activities.

Cheers,
Paul

[1] http://cacm.acm.org/magazines/2014/2/171689-mars-code/fulltext
[2] http://139.141.170.133/drjehad/A%20precise%20method-method%20interaction%20based%20cohesion.pdf
[3] http://www.ucalgary.ca/icic/files/icic/59-JECE-IEEE919.pdf

[Chris Ford]

A little more context on what I'm considering.

I work in a team of about 10 developers on a Clojure project. In the larger enterprise there are mainly Java applications.

I'm interested in a way to visualise which parts of the codebase are getting sticky and might require intervention. As well as being a non-subjective measure of relative tech debt for our internal purposes, this is also about communicating with the rest of the enterprise in terms similar to ones they already understand.

Linting tools are very useful, and of course the subjective impressions of those who work with the codebase are very important too.

Cheers,

Chris

[ian.tegebo]

How large is your Clojure codebase?