
Counting Clojure Code - aaroniba
http://aaroniba.net/counting-clojure-code
======
hacker_9
When I first started learning Clojure I was surprised at how concise it
actually is. I was so used to scanning imperative code in huge jumps, that the
conciseness caught me completely off guard and I would scan functions without
even taking it in. Every.Single.Word matters in Clojure, there is literally
zero boilerplate. So I agree that counting nodes is actually not a bad way to
measure how much the code base grows over time.

------
wellpast
> I also count lines when choosing libraries. When you depend on a library,
> the library code becomes your code in a way. [...] If two libraries do
> roughly the same thing, but one has far fewer lines, I will usually prefer
> the smaller library.

This is a little odd imo. Far more important when choosing a library are other
aspects like its maturity, activity, interface width...

In fact, the goal in choosing a library should be to _minimize_ the
probability that the "code becomes yours." You should be looking for a strong
and _stable_ abstraction, first and foremost.

~~~
adambard
I think this heuristic is using lines-of-code as a proxy for simplicity, in
the simple-vs-easy sense. All other things being equal, and presuming the
difference is architectural rather than an artifact of a too-clever coding
style, I would tend towards the shorter library too.

~~~
wellpast
Fair enough. In my experience it is rare to need library X and to have such an
array of choices that LOC suddenly becomes the differentiator.

~~~
adambard
I've never turned to LOC directly myself, but I have occasionally had to
choose between 2 or 3 lone-wolf Clojure libraries to do a thing, and picked
the one that seemed to have the sharpest focus or the most coherent
implementation, which is usually the shorter one.

------
christophilus
TL;DR; He wrote a tool that accurately counts the number of lines in a Clojure
project (e.g. ignores comments, etc) and _also_ counts the number of nodes in
said project's AST.

I think an interesting metric would be number of AST nodes per line, maybe
even providing the top N most complex lines, where complexity is number of
nodes per line.

I find that some languages (Scala and Perl come to mind) tend to encourage
extremely dense one-liners that have _way_ too much going on with many tiny
little temporary variables and symbols all crammed into a short amount of
space.

A tool like this, if added to a linter could help discourage that sort of
programming.

~~~
Roboprog
It would be humorous, but instructive, to have something like this for Java
that parses it and dumps out metrics about the tree size for a project - AST
node count and static depth, where possible to tell.

------
draw_down
>Obviously

``` (f a b c) ```

> is the same "amount" of code as

> `(f a b c)`

Yes, obviously! But they do not take the same number of lines - one is three
lines and the other is one line.

It's sort of funny to me- number of lines doesn't paint the picture we want it
to... so let's change the metric! Our code is special, anyway.

