4 ms·

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 a

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

entuno 1y ago
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.
- windward 1y ago
  That results in the same AST, it's not really taking anything away
  - einsteinx2 1y ago
    Except for readability
Cthulhu_ 1y ago
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.
- Kinrany 1y ago
  An opinionated formatter plus a smart line counter fix this problem. There's still space for abuse but not enough to overshadow genuine improvements.
  - joseda-hg 1y ago
    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): squared_numbers.append(i \* 2) print(squared_numbers) It's not even a readability thing, assuming list comprehensions don't bother you they're about equally readable
    - Kinrany 1y ago
      You can write more but you can't write less!
sixthDot 1y ago
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 https://en.wikipedia.org/wiki/Halstead_complexity_measures

entuno 1y ago

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.

windward 1y ago
That results in the same AST, it's not really taking anything away
- einsteinx2 1y ago
  Except for readability

Cthulhu_ 1y ago

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.

Kinrany 1y ago
An opinionated formatter plus a smart line counter fix this problem. There's still space for abuse but not enough to overshadow genuine improvements.
- joseda-hg 1y ago
  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): squared_numbers.append(i \* 2) print(squared_numbers) It's not even a readability thing, assuming list comprehensions don't bother you they're about equally readable
  - Kinrany 1y ago
    You can write more but you can't write less!

sixthDot 1y ago

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 https://en.wikipedia.org/wiki/Halstead_complexity_measures