14

We are considering writing a static analyzer to collect software metrics for Clojure code. Of course it will handle the obvious stuff like number of files, functions, parameters per function, etc. I wonder if there are any metrics that are specific for Clojure code. Any ideas?

Maurits Rijk
  • 9,789
  • 2
  • 36
  • 53

1 Answers1

13

On average - I think that software metrics are a dubious idea - they usually distract you from the really important question which is "how much value are we delivering to the customer??".

Having said that, I recognise they can be a necessary evil in some contexts and can occasionally give you some useful insights about your code base.

So here's a few that might be Clojure-specific.

  • Number of top-level defines (perhaps expressed as a ratio to total symbol count?)
  • Java coupling: % of symbols related to Java interop (new, ClassName., .someMethod etc.) - ideally keep coupling confined to specific modules responsible for Java interop, i.e. should be verey low % everywhere except libraries that manage the interop.
  • Average maximum nesting level of function defns (I guess 5ish good, 10+ bad??)
  • Macro density: % of forms that require macro expansion
  • % of functions with docstrings
  • % of symbols or function parameters defined with type hints
  • Average size of anonymous functions (these should probably be small!)
  • % of functions in clojure.core used (gives some idea of the "vocabulary range" and sophistication of the code)
  • (Thanks nickik!) number of ref-types created (dynamic vars, atom, ref and agent) - essential if you want to keep careful control of your mutable state!

p.s. if you get this working it would be really interesting to see the variation in results across some of the different open source clojure projects!

mikera
  • 105,238
  • 25
  • 256
  • 415
  • I understand the anti-metrics sentiment. I think metrics are only useful to zoom into problematic areas. Nice answer btw. – Maurits Rijk Apr 13 '11 at 14:12
  • Countig ref-types is really improtend. Counting ref/atom/agent and dynamic vars (in 1.3). – nickik Apr 13 '11 at 14:36
  • @nickik - totally agree ref types are very important. though it's tricky to figure out what metric you'd use though in a static analyser? The problem I foresee is that these often get allocated dynamically so it's not necessarily helpful to just count the ref/atom/agent symbols for example..... anyway have added to the list – mikera Apr 13 '11 at 15:00
  • I think doing it statically is just as good as tracking the number of actual objects. If you only create atoms in one place, the complexity is likely to be equally-constrained: even if that function gets called a thousand times, it's not really more-complex. – amalloy Apr 13 '11 at 15:26