7 ms·

Come now, I think we all know code is not its line count. 1000 lines of clear code in a mission-critical place is worth far more than a 1-liner which accomplis

Come now, I think we all know code is not its line count. 1000 lines of clear code in a mission-critical place is worth far more than a 1-liner which accomplishes the same task and only one person in the company understands...

deleted 6y ago
[deleted]
lmm 6y ago
Citation needed. This is a popular narrative but I don't believe it; line count is the only thing that has been shown to be consistently correlated with bug count.
- Taek 6y ago
  https://www.nasa.gov/pdf/418878main_FSWC_Final_Report.pdf https://www.nasa.gov/pdf/418878main_FSWC_Final_Report.pdf NASA averages something like 0.1 bugs per 1,000 lines of code, industry average is closer to 15. Surely there are other factors, like testing, linting, and language choice that influence the number of bugs.
- manicdee 6y ago
  Without consulting Stack Overflow, describe the “...” operator in Perl. As for other one-liners, when the one line is actually five instructions squished together inside a ternary operator, you’re probably better off expanding it to an if statement and consuming ten lines of vertical space. Clarity is far better than terse code that suffers from leaning toothpick syndrome.
  - chromatic 6y ago
    Without consulting Stack Overflow, describe the “...” operator in Perl. Does it count as a trick question if I implemented it?
  - lmm 6y ago
    > Without consulting Stack Overflow, describe the “...” operator in Perl. I don't know Perl. But I'm prepared to do that exercise for APL if you want. > As for other one-liners, when the one line is actually five instructions squished together inside a ternary operator, you’re probably better off expanding it to an if statement and consuming ten lines of vertical space. That's exactly what I'm disputing. We know that bug count correlates with line count, and that the chance of bugs increases greatly once a function or class no longer fits on a single screen. So I suspect that squishing five instructions together inside a ternary operator actually makes for fewer bugs.
    - manicdee 6y ago
      Whereas I have seen too-smart people creating bugs by cramming things into one line because the brevity required means you end up with hard-to-visually-parse clusters of brackets, braces, and whatever other punctuation your chosen language allows (is that a minus operator, is it negating a value, or is it a range in a regex?). Bugs are correlated to line count because code complexity drives line count and bug count. It’s not the number of lines of code causing the bugs, it’s the complexity of the problem causing the number of lines and number of bugs to grow independently of each other. Correlation does not imply causation.
    - Cthulhu_ 6y ago
      > We know that bug count correlates with line count Statistically maybe, but when it comes down to it, clear code > compact code hands down. Paraphrasing, but there's basically two ways to write code: either it's so complicated there are no obvious deficiencies, or it's so simple there are obviously no deficiencies. I'm not smart enough to be able to read and understand a nested ternary or other examples of clever / compact code.
      - lmm 6y ago
        > Paraphrasing, but there's basically two ways to write code: either it's so complicated there are no obvious deficiencies, or it's so simple there are obviously no deficiencies. Anyone who's seen an enterprise Java codebase knows there's a third way: so verbose that no-one can tell whether there are any deficiencies, even if each line in isolation is "simple". I think we vastly underestimate the importance of sheer code length. Being able to comprehend the function, class, or program as a whole makes a lot more difference than whether nested ternaries or the like were used, IME.
  - blindluke 6y ago
    > Without consulting Stack Overflow, describe the “...” operator in Perl. Poor example. Any Perl programmer can explain both range ops without breaking a sweat. Smart matching is/was the weird, misbehaving thing.
    - manicdee 6y ago
      And yet most Perl programmers I know do not work in mailing houses so they have never needed to use “...”. I have worked with brilliant people who still have trouble figuring out the ternary operator, and people who should know better who construct ternary operators with five levels of parentheses, causing deciphering of the intent to be impossible. So I choose Alexander the Great’s approach to solving the Gordian Knot: slice it open and remove the complexity to multiple layers that mere mortals can understand. PS: I notice you failed to explain the operator yourself. Minus five points to Slytherin.
    - lizmat 6y ago
      Indeed. That was because smart-matching in Perl was symmetric. The smart-matching in Raku (formerly known as Perl 6) is asymmetric and customizable. If you write: a ~~ b you are effectively executing: b.ACCEPTS(a) In other words, the right hand side of the smart-match is responsible for accepting the left hand side. So as a developer of a class, you can add your own ACCEPTS (multi-)method to govern how your class will handle smart-matching.
deleted 6y ago
[deleted]
dragonwriter 6y ago
I've yet to see 1,000 (or even 100, and rarely 10) lines of code doing what could be done in a 1 liner that is both clear and correct, and generally the more verbose, the less clear and the less correct it is. Moreover, the longer version almost invariably (and more likely the longer it is) either is or contains a DRY violation that was originally copy-and-pasted from elsewhere in the same codebase, often with some intentional changes, which has since diverged (or diverged further than the intended differences) because of inconsistent maintenance.
- TheOtherHobbes 6y ago
  It's not line count, it's the dot product of line count and conceptual clarity. There's a sweet spot where code is as terse as it can be while still being easy to read. The abstractions are clear and fit the domain, they're not decorated with poorly configured edge cases, and they're no more nested than they need to be. It's debatable if this ideal has ever existed, but it's nice to believe it might be possible.
  - dragonwriter 6y ago
    > It's not line count, it's the dot product of line count and conceptual clarity. In my experience, in practice, beyond a very small multiple of the minimum required line count, line count and conceptual clarity for perfoming any given task are inversely related. Also, neither of those are vector quantities, so I'm not sure what you are trying to get at with “dot product”.
balladeer 6y ago
Shorter code block doesn't mean unclear code. Besides, in your very implausible example (unless there's some underlying library - or an esoteric language maybe?) 1 line of that code (apparently) replacing 1000 line of clear code can have a comment to explain itself.

deleted 6y ago

[deleted]

lmm 6y ago

Citation needed. This is a popular narrative but I don't believe it; line count is the only thing that has been shown to be consistently correlated with bug count.

Taek 6y ago
https://www.nasa.gov/pdf/418878main_FSWC_Final_Report.pdf https://www.nasa.gov/pdf/418878main_FSWC_Final_Report.pdf NASA averages something like 0.1 bugs per 1,000 lines of code, industry average is closer to 15. Surely there are other factors, like testing, linting, and language choice that influence the number of bugs.
manicdee 6y ago
Without consulting Stack Overflow, describe the “...” operator in Perl. As for other one-liners, when the one line is actually five instructions squished together inside a ternary operator, you’re probably better off expanding it to an if statement and consuming ten lines of vertical space. Clarity is far better than terse code that suffers from leaning toothpick syndrome.
- chromatic 6y ago
  Without consulting Stack Overflow, describe the “...” operator in Perl. Does it count as a trick question if I implemented it?
- lmm 6y ago
  > Without consulting Stack Overflow, describe the “...” operator in Perl. I don't know Perl. But I'm prepared to do that exercise for APL if you want. > As for other one-liners, when the one line is actually five instructions squished together inside a ternary operator, you’re probably better off expanding it to an if statement and consuming ten lines of vertical space. That's exactly what I'm disputing. We know that bug count correlates with line count, and that the chance of bugs increases greatly once a function or class no longer fits on a single screen. So I suspect that squishing five instructions together inside a ternary operator actually makes for fewer bugs.
  - manicdee 6y ago
    Whereas I have seen too-smart people creating bugs by cramming things into one line because the brevity required means you end up with hard-to-visually-parse clusters of brackets, braces, and whatever other punctuation your chosen language allows (is that a minus operator, is it negating a value, or is it a range in a regex?). Bugs are correlated to line count because code complexity drives line count and bug count. It’s not the number of lines of code causing the bugs, it’s the complexity of the problem causing the number of lines and number of bugs to grow independently of each other. Correlation does not imply causation.
  - Cthulhu_ 6y ago
    > We know that bug count correlates with line count Statistically maybe, but when it comes down to it, clear code > compact code hands down. Paraphrasing, but there's basically two ways to write code: either it's so complicated there are no obvious deficiencies, or it's so simple there are obviously no deficiencies. I'm not smart enough to be able to read and understand a nested ternary or other examples of clever / compact code.
    - lmm 6y ago
      > Paraphrasing, but there's basically two ways to write code: either it's so complicated there are no obvious deficiencies, or it's so simple there are obviously no deficiencies. Anyone who's seen an enterprise Java codebase knows there's a third way: so verbose that no-one can tell whether there are any deficiencies, even if each line in isolation is "simple". I think we vastly underestimate the importance of sheer code length. Being able to comprehend the function, class, or program as a whole makes a lot more difference than whether nested ternaries or the like were used, IME.
- blindluke 6y ago
  > Without consulting Stack Overflow, describe the “...” operator in Perl. Poor example. Any Perl programmer can explain both range ops without breaking a sweat. Smart matching is/was the weird, misbehaving thing.
  - manicdee 6y ago
    And yet most Perl programmers I know do not work in mailing houses so they have never needed to use “...”. I have worked with brilliant people who still have trouble figuring out the ternary operator, and people who should know better who construct ternary operators with five levels of parentheses, causing deciphering of the intent to be impossible. So I choose Alexander the Great’s approach to solving the Gordian Knot: slice it open and remove the complexity to multiple layers that mere mortals can understand. PS: I notice you failed to explain the operator yourself. Minus five points to Slytherin.
  - lizmat 6y ago
    Indeed. That was because smart-matching in Perl was symmetric. The smart-matching in Raku (formerly known as Perl 6) is asymmetric and customizable. If you write: a ~~ b you are effectively executing: b.ACCEPTS(a) In other words, the right hand side of the smart-match is responsible for accepting the left hand side. So as a developer of a class, you can add your own ACCEPTS (multi-)method to govern how your class will handle smart-matching.

deleted 6y ago

[deleted]

dragonwriter 6y ago

I've yet to see 1,000 (or even 100, and rarely 10) lines of code doing what could be done in a 1 liner that is both clear and correct, and generally the more verbose, the less clear and the less correct it is. Moreover, the longer version almost invariably (and more likely the longer it is) either is or contains a DRY violation that was originally copy-and-pasted from elsewhere in the same codebase, often with some intentional changes, which has since diverged (or diverged further than the intended differences) because of inconsistent maintenance.

TheOtherHobbes 6y ago
It's not line count, it's the dot product of line count and conceptual clarity. There's a sweet spot where code is as terse as it can be while still being easy to read. The abstractions are clear and fit the domain, they're not decorated with poorly configured edge cases, and they're no more nested than they need to be. It's debatable if this ideal has ever existed, but it's nice to believe it might be possible.
- dragonwriter 6y ago
  > It's not line count, it's the dot product of line count and conceptual clarity. In my experience, in practice, beyond a very small multiple of the minimum required line count, line count and conceptual clarity for perfoming any given task are inversely related. Also, neither of those are vector quantities, so I'm not sure what you are trying to get at with “dot product”.

balladeer 6y ago

Shorter code block doesn't mean unclear code. Besides, in your very implausible example (unless there's some underlying library - or an esoteric language maybe?) 1 line of that code (apparently) replacing 1000 line of clear code can have a comment to explain itself.