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.
...but they're not. Perhaps one time in 50 you'll find a topic so well worn that you have choices between multiple mature, stable libraries with good APIs that lets you dig into the source code to see how nice it is (by whatever metric) to decide if you want to use it.
Perhaps what, json parsers?
I can barely think of any other examples.
It's a completely pointless metric.
The beauty of the API is far more important than looking into the implementation to see how it was written.
Heck, the library could be one giant regex on one line, but if the api is:
void *libfoo_random_meaningless_name(void *n, ...);
I very much doubt the elegance of the implementation is a metric that should be used to pick a library; there are far more important metrics to look at.
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.
``` (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.