Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is the 80 character line limit still relevant? (2008)

richarddingwall.name

Post reply on HN
Print view View original

41–50 of 180 posts

Re: Is the 80 character line limit still relevant? (2008)

#41

Post by driggs »

For Python source code, where indentation is significant, I'm convinced that long lines should never be broken early. It should be the IDE's job to (optionally) fold long lines dynamically to the width of a viewer's editor.

If someone breaks a statement early at 72, or 79, or 99 characters (PEP8 recommendations), indentation no longer represents the structure of the program, it now represents the style of the author. Everyone who uses a wider screen suffers.

But if the IDE knows how to fold long lines dynamically, then any reader can use any width screen for viewing and editing. And users may choose not to enable folding at all, so that indentation exclusively represents program structure.

Re: Is the 80 character line limit still relevant? (2008)

#42

Post by codetrotter »

mattnewton wrote: post #30
PeterWhittaker wrote: post #28

> formatting tennis That's a paddling. Seriously, professionals do this? If someone else wrote it and it does what it is supposed to do, it is not, NOT (no apologies for shouty emphasis), my job to change that. (I hate tabs, but will never :retab someone else's code.) My job is either/both to fix bugs and add new capabilities, not to be precious about, well, anything. I would have serious reservations about any team…

I agree this is terrible primarily because it muddles up any git-blame based workflow for debugging regressions. I think an autoformatter with the config checked into git is a nice way around this.

> an autoformatter with the config checked into git is a nice way around this.

Yes. At my job we mainly use defaults of rustfmt in most repos. Some repos have rustfmt.toml in them. And the neat thing is that cargo picks up this automatically so there’s no per-repo config you have to do after cloning those repos in order to follow repo-specific formatting rules.

In CI we have a step that runs

  cargo fmt --all --check
And that exits with non-zero code if any formatting is different from what rustfmt wants it to be. Which in turn means that that pipeline stage gets marked as failed.

In order then to get your changes merged, you have to follow the same formatting rules that are already in use. Which in turn is as simple as having

  cargo fmt --all
run at some point before you commit. For example invoked by your editor, or from some kind of git hook or alias, or manually.

It’s nice and easy to set up, and it means that every Rust source file within each individual repo follow the same formatting as the other Rust source files in that same repo.

I don’t particularly care about what specific formatting rules each repo owner chose. (And the vast majority of our repos just use the defaults anyway.) All I care about when I’m working on code is that there is some kind of consistent formatting across the files in the project, and that formatting changes between commits from different people are kept to a minimum so that git log and git blame gives the info that you are interested in. So for me I am very happy that they do it this way at my job.

Re: Is the 80 character line limit still relevant? (2008)

#43

Post by bearjaws »

delichon wrote: post #25

I maintain 80 characters in order to edit files side by side on a laptop screen without side scrolling. I seem to grok code better vertically too.

I love how everytime this debate comes up, the 80 character gang keeps adding more stuff to put side by side.

Now we're shrinking the resolution/sizes of the devices we are using to justify it...

Re: Is the 80 character line limit still relevant? (2008)

#44

Post by bitwize »

drivingmenuts wrote: post #10

I use 120 or 132 (no idea why I picked that number), but I tend to break my lines well before that, especially on function signatures. I'm that git that puts each param on a separate line (so I can quickly comment them out when I need to). It annoys other programmers, but once I explain why ... They're still annoyed, but at least they're quiet about it.

If you're that git that makes one param per line a standard that you can flunk code review for not adhering to, I'd seriously consider switching jobs were I under you.

Re: Is the 80 character line limit still relevant? (2008)

#45

Post by nemomarx »

Wowfunhappy wrote: post #37
mattnewton wrote: post #30

Earlier quoted context omitted.

I agree this is terrible primarily because it muddles up any git-blame based workflow for debugging regressions. I think an autoformatter with the config checked into git is a nice way around this.

> I agree this is terrible primarily because it muddles up any git-blame based workflow for debugging regressions. ...it occurs to me, this feels like you're conforming to the tool instead of the other way around. Is there a reason git blame doesn't have an "ignore whitespace" option? Is it harder than it seems?

I would think the issue is that if you format someone else's code, gitblame then sees you editing that code? Unless you can mark that commit as white space changes only somehow

Re: Is the 80 character line limit still relevant? (2008)

#46

Post by SoftTalker »

drivingmenuts wrote: post #10

I use 120 or 132 (no idea why I picked that number), but I tend to break my lines well before that, especially on function signatures. I'm that git that puts each param on a separate line (so I can quickly comment them out when I need to). It annoys other programmers, but once I explain why ... They're still annoyed, but at least they're quiet about it.

Some old "dumb" terminals could be switched into 132-column mode, this corresponded to the 132 columns on the line printers that printed on wide fan-fold green-bar paper.

The 80 column standard for a line of code goes back to the 80 columns on a standard IBM punch card. Why 80 columns on a punch card? I don't know that one.

Re: Is the 80 character line limit still relevant? (2008)

#47

Post by necovek »

type_enthusiast wrote: post #39
necovek wrote: post #34

Earlier quoted context omitted.

I agree with you that writing readable and aesthetically pleasing code is more art than science (that can be expressed with deterministic rules), I still find some of the rules and rule-checkers beneficial (though I dislike strict formatters). As such, 80 is as good a limit as any, and makes you think carefully about avoiding deep nesting of blocks, which is usually a good idea anyway. It also allows putting many win…

I have to push back here a little bit. It really depends. I mainly use Scala, and I think the majority of Scala code would be far less readable if forced to 80 columns, than if it were a larger number (or simply unconstrained). My WFH monitor is an Apple Thunderbolt Display, which is woefully out-of-date now. Even on this display, and even though I use a much larger font than most people (16pt Hasklig), and even with…

With 180 characters on your display and lines of more than 90 characters, you can't put two code windows side-by-side.

But it sure depends on the language too, though I wonder what's so peculiar about Scala to really benefit from long lines?

Re: Is the 80 character line limit still relevant? (2008)

#50

Post by vhcr »

j1elo wrote: post #18
koito17 wrote: post #11

The penultimate paragraph of the article really shows its age. When there are unclear or conflicting rules ... [y]ou can end up with hilarious games like formatting tennis ... Back then, formatters were rarely used, if at all. The major benefit of tools like gofmt, Prettier, etc. is that a major source of vacuous commits and code review has gone away. In the case of Prettier, bikeshedding can still happen over the .p…

In new projects I usually add an empty .prettierrc file with a single comment: // Empty file. Use default Prettier settings. No rules here. To make it clear for other people that it was not just a mistake that the formatter was missing its configuration or that no config file existed at all. Useful to deter from adding new rules because someone is capricious about their own preferences...

Maybe even add a CI step that closes PRs if someone modifies formatter config files.
Post reply on HN