Hacker News Reader

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.

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"

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/

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.

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.

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!

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.

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.

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.

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.

> 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".

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.

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.