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

141–150 of 180 posts

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

#141

Post by o11c »

ycombobreaker wrote: post #124
o11c wrote: post #15

Earlier quoted context omitted.

It's worth noting that most of those studies are for body text. To make that more directly applicable we should exclude indentation, but the additional punctuation (especially commas, but unfortunately no parentheses) also affects it. Shading lines can also improve readability (this is known; the rest of this comment is speculation). It's probably not enough to simply alternating between e.g. white and off-white back…

Why exclude indentation? A block of code that is indented say... 5 levels deep at 4 spaces is missing 20 columns. If that loss of space gives the developer discomfort, it sounds like a healthy reminder about complexity. Every level of nested scope is additional mental context of "global" state for a maintainer. There should be (reasonable) pressure on the author to refactor towards less indentation/nested scope.

Sure, excessive indentation is a code smell. But that doesn't impede the ability to read and track lines within a highly-indented block, which roughly follows the readability of prose and thus can use its numbers for comparison.

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

#142

Post by binary132 »

duxup wrote: post #129
binary132 wrote: post #126

Just because some people like to have a single pane of text cover their entire 16:9 display doesn’t mean I should have to. I find very vertical text much easier to follow. Wide lines are usually wide due to nesting and chaining, either of blocks or of inline expressions. Both are a thing which should not be. Concisely and clearly define one concept or abstraction. Then, use it in the next definition. This isn’t hard!…

> doesn’t mean I should have to. I don’t believe the article says you should have to.

What I mean is that if I’m working on a file with some other people, and I write some 80-column code, they can easily view it in their nice wide panes, but I can’t easily view their wide code in my nice tiled square or vertical panes. I often have as many as 8 (or more!) tiles in a single fullscreen window.

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

#143

Post by sfpotter »

binary132 wrote: post #126

Just because some people like to have a single pane of text cover their entire 16:9 display doesn’t mean I should have to. I find very vertical text much easier to follow. Wide lines are usually wide due to nesting and chaining, either of blocks or of inline expressions. Both are a thing which should not be. Concisely and clearly define one concept or abstraction. Then, use it in the next definition. This isn’t hard!…

It's hard if you don't know how to do it... and lots of people don't know how to do it.

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

#144

Post by fsckboy »

koolba wrote: post #133
j1elo wrote: post #18

Earlier quoted context omitted.

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

I like to put a haikus in spots like this: // Empty by choice // Use the Prettier defaults // No customized rules Taking the time to write a specific one gives added weight to the decision to use the defaults as anyone adding a rule has to remove the haiku.

haiku: "empty by choice" is only 4 syllables

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

#145

Post by lanstin »

benced wrote: post #40
taeric wrote: post #9

Earlier quoted context omitted.

Took me a second to realize ETA was "edited to add." I was very confused on what an estimated time of arrival meant, here. :) I'm surprised reading on a phone is common. Not at all something I would want to do. I'm assuming largely read only there? Makes me curious if the CWEB idea of styling specifically for reading has extra merit in that flow?

I've made edits to config files on the GitHub mobile app while on-call. Not something I like doing but I like having the option.

I have also done this on VTA (local train). It's very thrilling but not very high-bandwidth sort of thing. I haven't done it a lot. But I do read a fair amount of code on my phone, in blogs or whatever.

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

#146

Post by fsckboy »

eviks wrote: post #136

And not a single mention of soft wrapping > Long lines that span too far across the monitor are hard to read. This is typography 101. The shorter your line lengths, the less your eye has to travel to see it. But the longer your eyes have to travel vertically, so 101 doesn't justify a specific number 80, thus doesn't help much in resolving the trade-off

i don't think that guideline is correct, it's

"the shorter your line lengths, the less your eye has to travel to get back to the left margin, the quicker and more error free you'll find the next line"

and no similar idea occurs vertically, save that it is already mediated by vertical section markers. (I very frequently wish that hitting page down would show me a distict mark where the previous bottom of screen is now)

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

#147

Post by flakes »

bcrl wrote: post #78
dqh wrote: post #57

An 80 character limit is difficult to stay within when using highly descriptive variable names, and I think the benefits of highly descriptive variable names outweigh other considerations.

In my experience, if your variable names are long enough to overflow an 80 column limit, you've probably already got a problem. Longer variable names have a cognitive load in and of themselves, which, to me, usually means someone didn't think about naming enough or is subject to too many levels of pointless indirection. To me it is important to try to keep code concise so that it is easier to read. This applies to va…

I care less about the length of the code, and more-so about the cognitive load. As the business logic grows, and the lines of code increases, the assignment of variables tend to get further and further away from their usage. What was once simple to read, now requires back-tracking as you read to double check exactly what they are.

Consider this contrived example:

    margin = (price - cost) / price
You can be reasonably sure what is being calculated, but it's hard to be exactly sure unless the surrounding context is very small. Having longer names allows you to keep more context for a line in isolation, meaning (personally) I require less backtracking while reading.

e.g. the above could be rewritten as the following, removing a lot of ambiguity:

    retail_margin = (retail_price - wholesale_cost) / retail_price
I find 80 character limits much too small in these cases. 100-120 characters is the sweet spot for me. I can still have 2 split panes of code on a single screen at once, and write more expressively without excessive linebreaks per statement.

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

#148

Post by tommiegannert »

steve_taylor wrote: post #118
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…

Prettier docs recommend a line length of 80 characters because of a fundamental design flaw: Lines are greedy and cramming as much as possible into each line decreases readability as lines increase in size.

Yesterday I was running Prettier on an existing code base, and decided to go with 100. Even at 2-space indentation, 80 caused too many if-expressions to be split up. Google's JS styleguide also says 80. (I also have 450 character lines there, in a table of CSS classes for dark/light/selected/hover/disabled/focused modes. Leaving it long makes it much easier to confirm all modes set the right class.)

However, the benefit of automatic formatters is that if you really like 80 better, you can reformat before editing, and undo that before sharing your results.

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

#149

Post by eviks »

fsckboy wrote: post #146
eviks wrote: post #136

And not a single mention of soft wrapping > Long lines that span too far across the monitor are hard to read. This is typography 101. The shorter your line lengths, the less your eye has to travel to see it. But the longer your eyes have to travel vertically, so 101 doesn't justify a specific number 80, thus doesn't help much in resolving the trade-off

i don't think that guideline is correct, it's "the shorter your line lengths, the less your eye has to travel to get back to the left margin , the quicker and more error free you'll find the next line" and no similar idea occurs vertically, save that it is already mediated by vertical section markers. (I very frequently wish that hitting page down would show me a distict mark where the previous bottom of screen is no…

Maybe, though I've also read fundmentals care about eye strain, where distance could matter?

> hitting page down would show me a distict mark where the previous bottom of screen is now)

For a literal page down the last line would literally become the first line, but yeah, that's the mark/animation that could be useful for when it's not a page

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

#150

Post by Minor49er »

shiroiushi wrote: post #108
Minor49er wrote: post #19

Sticking with 80 characters has been great for my team. Not only does it encourage shorter lines, but comparing diffs on GitHub ensures that both old and new comparisons fit evenly on the page without any cutoffs or wrapping

What kind of monitors does your team use? I view diffs side-by-side all the time with much wider lines than 80 chars, but I have 27" monitors, which are not unusual these days.

All of my main external displays are 27". The diffs fit perfectly on them with the 80 character limit
Post reply on HN