Comment by rossant
1 year ago
I think lines of code could be an interesting and valuable metric.
If the lower (negative) score, the better (given a fixed set of features).
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” ― Antoine de Saint-Exupéry, Airman's Odyssey
That just encourages bad behaviour in the other direction though. A massive multi-level nested ternary on one line is usually going to be worse than a longer but clearer set of conditions. Trying to make code brief can be good, but it can often result in an unmaintainable and hard to read mess.
That results in the same AST, it's not really taking anything away
Except for readability
Halstead complexity ([0]) might interest you. It's a semi-secret sauce based on the count of operators and operands that tells you if your function is "shitty".
[0]: https://en.wikipedia.org/wiki/Halstead_complexity_measures
You'll never get it right though. Focusing on "features per LOC" means people will write shorthand, convoluted code, pick obscure, compact languages, etc. To use an adage, if a metric becomes a target, it stops being a useful metric.
An opinionated formatter plus a smart line counter fix this problem. There's still space for abuse but not enough to overshadow genuine improvements.
How does a formatter affect me intentionally writing more (or less) lines for the sake of reaching a line count?
print([i * 2 for i in range(10)])
vs
squared_numbers = []
for i in range(10):
print(squared_numbers)
It's not even a readability thing, assuming list comprehensions don't bother you they're about equally readable
1 reply →