6 ms·

My team drives me bonkers with this. They hear the general principle "really long lines of code are bad", but extrapolate it to "no characters shall pass the s

My team drives me bonkers with this. They hear the general principle "really long lines of code are bad", but extrapolate it to "no characters shall pass the soft gutter no matter what". Even if you have, say, 5 sequential related structs, that are all virtually identical, all written on one line so that the similarities and differences are obvious at a mere glance... Then someone comes through and touches my file, and while they're at it, "fix" the line that went 2 characters past the 80 mark by reformatting the 4th struct to span several lines. Now when you see that list of structs, you wonder "why is this one different?" and you have to read carefully to determine, nope, it just contained one longer string. Or god forbid the reformat all the structs to match, turning a 1-page file into 3 pages, and making it so you have to read and understand each element of each struct just to see what's going on. If I could have written the rule of thumb, I would have said "No logic or control shall happen after the end of the gutter." But if there's a paragraph-long string on one line- who cares?? We all have a single keystroke that can toggle soft-wrap, and the odds that you're going to need to know anything about that string other than "it's a long string" are virtually nil. Sorry. I got triggered. :-)

yas_hmaheshwari 2y ago
My team also had a similar thing in place. I am saving this article in my pocket saves, so that I can give "proofs" of why this is better From Zen of Python: ``` Special cases aren't special enough to break the rules. Although practicality beats purity. ``` https://peps.python.org/pep-0020/ https://peps.python.org/pep-0020/
BigJono 2y ago
Yep this triggers the fuck out of me too. It drives me absolutely insane when I'm taking the time and effort to write good test cases that use inline per test data that I've taken the time to format so it's nice and readable for the next person, then the next person comes along, spends 30 seconds writing some 2 line rubbish to hit a code coverage metric, then spends another 60 seconds adding a linter rule that blows all the test data out to 400 lines of unreadable dogshit that uses only the left 15% of screen real estate.
- _xiaz 2y ago
  I routinely spot 3-line prints with the string on its own line in our code. Even for cases where the string + print don't even reach the 80 character "limit"
arp242 2y ago
This is why autoformatters that frob with line endings are just terrible and fundamentally broken. I'm fairly firmly in the "wrap at 80" camp by the way; but sometimes a tad longer just makes sense. Or shorter for that matter: forced removal of line breaks is just as bad.
- jimmaswell 2y ago
  80 feels really impractically narrow. A project I work on uses 110 because it's approximately the widest you can comfortably compare two revisions on the same monitor, or was for some person at some time, and I can live with it, but any less would just feel so cramped. A few indentation levels deep and I'd be writing newspaper columns.
  - knodi123 2y ago
    80 lines wide is the width we had back in the late 90s. Displays are nothing like that anymore. I managed to talk my team into setting the linter to something more reasonable, but individuals still feel like they're being virtuous if they stick to 80 and reformat any line they touch that goes over. It's just dogma!
  - kiitos 2y ago
    80 _is_ impractically narrow. Even 120 is overly strict. SLoC line length isn't something that can or should be enforced by linters, or re-formatted by formatters.
  - NotMichaelBay 2y ago
    There is usually a way to restructure the code so that it doesn't have multiple levels of nested indentation, which is a good practice IMO because it makes the code easier to read.
edflsafoiewq 2y ago
This is world autoformatters have wrought. The central dogma of the autoformatter is that "formatting" is based on dumb syntactic rules with no inflow of imprecise human judgements.
- scrollaway 2y ago
  Most autoformatters do not reformat string constants as GP has said, and even if they did, this is something that can be much more accurately and correctly specified with an AF than with a human. Autoformatting collectively saves probably close to millions of work hours per year in our industry, and that’s at the current adoption. Do you think it’s productive to manually space things out, clean up missing trailing commas and what not? Machines do it better.
  - edflsafoiewq 2y ago
    > Even if you have, say, 5 sequential related structs, that are all virtually identical, all written on one line so that the similarities and differences are obvious at a mere glance... Then someone comes through and touches my file, and while they're at it, "fix" the line that went 2 characters past the 80 mark by reformatting the 4th struct to span several lines. Autoformatters absolutely do this. They do not understand considerations like symmetry. I am doubtful as to the costs of "somewhere in the codebase there is a missing trailing comma".
    - JoshTriplett 2y ago
      The wins of autoformatting are 1) never having to have a dispute over formatting or have formatting depend on who last touched code, 2) never manually formatting code or depending on someone's editor configuration, 3) having CI verify formatting, and 4) not having someone (intentionally or unintentionally) make unrelated formatting changes in a commit. Also, autoformatters can be remarkably good. For instance, rustfmt will do things like: x.func(Some(MyStruct { field: big + long + expr, field2, })); rather than mindlessly introducing three levels of indentation.
EasyMark 2y ago
I have been places where we allow long strings, but other things aren’t allowed and generally 80 to 100 char limits otherwise. I like 100 for c++/java and 80 for C. If it gets much longer than that (not being strings) then it’s time for a rethink in most cases, grouping/scoping symbols are getting too deep. I’m sure other languages may or may not have that as a reasonable argument. It is just a rule of thumb though.
- deleted 2y ago
  [deleted]

yas_hmaheshwari 2y ago

My team also had a similar thing in place. I am saving this article in my pocket saves, so that I can give "proofs" of why this is better From Zen of Python: ``` Special cases aren't special enough to break the rules. Although practicality beats purity. ``` https://peps.python.org/pep-0020/ https://peps.python.org/pep-0020/

BigJono 2y ago

Yep this triggers the fuck out of me too. It drives me absolutely insane when I'm taking the time and effort to write good test cases that use inline per test data that I've taken the time to format so it's nice and readable for the next person, then the next person comes along, spends 30 seconds writing some 2 line rubbish to hit a code coverage metric, then spends another 60 seconds adding a linter rule that blows all the test data out to 400 lines of unreadable dogshit that uses only the left 15% of screen real estate.

_xiaz 2y ago
I routinely spot 3-line prints with the string on its own line in our code. Even for cases where the string + print don't even reach the 80 character "limit"

arp242 2y ago

This is why autoformatters that frob with line endings are just terrible and fundamentally broken. I'm fairly firmly in the "wrap at 80" camp by the way; but sometimes a tad longer just makes sense. Or shorter for that matter: forced removal of line breaks is just as bad.

jimmaswell 2y ago
80 feels really impractically narrow. A project I work on uses 110 because it's approximately the widest you can comfortably compare two revisions on the same monitor, or was for some person at some time, and I can live with it, but any less would just feel so cramped. A few indentation levels deep and I'd be writing newspaper columns.
- knodi123 2y ago
  80 lines wide is the width we had back in the late 90s. Displays are nothing like that anymore. I managed to talk my team into setting the linter to something more reasonable, but individuals still feel like they're being virtuous if they stick to 80 and reformat any line they touch that goes over. It's just dogma!
- kiitos 2y ago
  80 _is_ impractically narrow. Even 120 is overly strict. SLoC line length isn't something that can or should be enforced by linters, or re-formatted by formatters.
- NotMichaelBay 2y ago
  There is usually a way to restructure the code so that it doesn't have multiple levels of nested indentation, which is a good practice IMO because it makes the code easier to read.

edflsafoiewq 2y ago

This is world autoformatters have wrought. The central dogma of the autoformatter is that "formatting" is based on dumb syntactic rules with no inflow of imprecise human judgements.

scrollaway 2y ago
Most autoformatters do not reformat string constants as GP has said, and even if they did, this is something that can be much more accurately and correctly specified with an AF than with a human. Autoformatting collectively saves probably close to millions of work hours per year in our industry, and that’s at the current adoption. Do you think it’s productive to manually space things out, clean up missing trailing commas and what not? Machines do it better.
- edflsafoiewq 2y ago
  > Even if you have, say, 5 sequential related structs, that are all virtually identical, all written on one line so that the similarities and differences are obvious at a mere glance... Then someone comes through and touches my file, and while they're at it, "fix" the line that went 2 characters past the 80 mark by reformatting the 4th struct to span several lines. Autoformatters absolutely do this. They do not understand considerations like symmetry. I am doubtful as to the costs of "somewhere in the codebase there is a missing trailing comma".
  - JoshTriplett 2y ago
    The wins of autoformatting are 1) never having to have a dispute over formatting or have formatting depend on who last touched code, 2) never manually formatting code or depending on someone's editor configuration, 3) having CI verify formatting, and 4) not having someone (intentionally or unintentionally) make unrelated formatting changes in a commit. Also, autoformatters can be remarkably good. For instance, rustfmt will do things like: x.func(Some(MyStruct { field: big + long + expr, field2, })); rather than mindlessly introducing three levels of indentation.

EasyMark 2y ago

I have been places where we allow long strings, but other things aren’t allowed and generally 80 to 100 char limits otherwise. I like 100 for c++/java and 80 for C. If it gets much longer than that (not being strings) then it’s time for a rethink in most cases, grouping/scoping symbols are getting too deep. I’m sure other languages may or may not have that as a reasonable argument. It is just a rule of thumb though.

deleted 2y ago
[deleted]