To be fair, bugs are highly correlated with line count, and all code is inscrutable in the absence of knowledge. I do like vocabulary-based metrics for legibil

To be fair, bugs are highly correlated with line count, and all code is inscrutable in the absence of knowledge. I do like vocabulary-based metrics for legibility/difficulty; Halstead metrics can't tell you how good a piece of code is, but they can tell you how difficult it is for others to read, empirically. The old 7 +- 2 rule applies, if you are using more than 9 functions/methods and arguments, the vocabulary of a function is difficult. f compose g is 0.5. It has 3 elements. It's not hard to understand. def compose (f: B=> C, g: A => B): A => C = x => f(g(x)) Is 2.5, counting all the definition parts and type level stuff. It has 14 distinct elements. If you don't know the pieces, it's really difficult to read if you don't know any of the parts. If your language doesn't care about types, def compose(f, g) = (x) => f(g(x)) Comes to 2.1 by my count, but you have to look up fewer things at 7, so it's easy to read for new people. Now, the types make it easier once you advance beyond a pure beginner- the constrain the function to only one possible implementation. But if you're totally unfamiliar with things, they make stuff unreadable. Even in tiny functions.