6 ms·

I don't doubt that the author's story is correct, but I think that 80 is a perfectly reasonable number to have as a standard. It's very annoying when I read cod

I don't doubt that the author's story is correct, but I think that 80 is a perfectly reasonable number to have as a standard. It's very annoying when I read code that doesn't use the 80-character limit, because my terminal is not guaranteed to be as wide as theirs, and I really don't like resizing my terminal window to fit their line length. For car width, I think that that's also a pretty reasonable width, since it's the perfect width to fit two people side-by-side comfortably, with a bit of room in the middle. Now we only need to think of things that have developed for historical purposes, yet are not reasonable defaults.

DanBC 10y ago
> It's very annoying when I read code that doesn't use the 80-character limit, because my terminal is not guaranteed to be as wide as theirs, and I really don't like resizing my terminal window to fit their line length. Considering the numbers of programmers in the world, and how long they've been working with text, and how much annoyance text breaks / line wrapping / format flowing causes it's kind of surprising that there isn't better ways of wrapping lines without line breaks. What's current best practice? Or is it just down to the project style guide?
- andrey_utkin 10y ago
  I guess these are enough general: put operator sign before line break; don't break inside of the most nested expression; don't break between variable type and name... There are more such rules which differ between standards (like Linux kernel style vs. PHP PSR-2 style), e.g. how to pad trailing lines of function call. Linux style says to align trailing lines at offset next to the opening brace. (This doesn't look good in case of long function name, though, but most of time readability of this way is very good.) K&R is referenced as an original of such style, just as everywhere in Linux coding style. Also Linux coding style is not just what is told in Documentation/CodingStyle - there are some unwritten tools which you'll encounter when you run scripts/checkpatch.pl or get reviews on your patch submission.
- zyxley 10y ago
  gofmt comes to mind here. It renders the particulars of what you do while writing a non-issue by taking any valid Go input and producing a "canonical" final formatted version.
simplicio 10y ago
It used to seem natural to me, but as screens have gotten wider, it now seems like I usually have my terminals set wider when I have two set side-by-side. Even on my relatively small laptop screen. I actually was just contemplating ditching the 80-char limit the other day, at least for personal projects.
strictnein 10y ago
80 characters seems really narrow. IDEs like IntelliJ put a guideline at 120 characters, which basically allows two full width editing windows side by side (depending on your font size) at the pretty standard resolution of 1920x1080. We've all got widescreen monitors now, right? So it makes sense that people are going well past 80 characters.
- s_kilk 10y ago
  > We've all got widescreen monitors now, right? Sure we do, but some/many of those widescreen monitors are only eleven or thirteen inches diagonally, and can't reasonably fit two buffers of text 120-chars wide without shrinking the font to eye-straining sizes (yes, even on retina screens). Plus, this only gets worse as you get older and your eyesight starts to diminish.
  - epalmer 10y ago
    > Plus, this only gets worse as you get older and your eyesight starts to diminish. Yup, I'm at that point.
- tremon 10y ago
  As another commenter noted, it's not (just) about screen width. It's about having a text width that allows your eyes to track both column boundaries as achoring points. If a text is too wide, your eyes will have trouble finding the start of the next line. For the same reason, newspapers use multiple columns, even though the paper itself would allow for 200-character lines.
  - strictnein 10y ago
    I don't think we read code the same way we read normal text. If you have this in your code: qry.setParameter("a", a); qry.setParameter("b", b); qry.setParameter("foo", foo); qry.setParameter("bar", bar); After the first "qry.setParameter" you're no longer reading anything but the parameters and your eyes are moving vertically. Or if you have something like this: Query qry = getEntityManager().createNamedQuery("User.findUserBySomething", Long.class); You're only reading the "User.findUserBySomething". The rest of it is mainly fluff.
gremy0 10y ago
> For car width, I think that that's also a pretty reasonable width, since it's the perfect width to fit two people side-by-side comfortably, with a bit of room in the middle. How do you know the width of a standard human isn't determined by 2000 years of people choosing partners that would fit beside them on a cart comfortably.
- knodi123 10y ago
  oh my god, you just uncovered the cause of the obesity epidemic in america- the spread of SUVs and wide multi-lane highways
s_kilk 10y ago
Agreed, 80-chars may be an accident of history, but it's an accident which happens to line up quite well with the human eyes ability to track horizontal lines of text. It gets tiring listening to devs rage about the 80-char limit, then go on to produce code that's basically unreadable because it scrolls way off the screen.
- arethuza 10y ago
  I was looking at some C code of mine that is ~30 years old - it was written on 80x24 serial terminal in vi and I was fairly pleased with how readable my code was. I suspect a large part of that was the short line lengths!
- jahewson 10y ago
  > it's an accident which happens to line up quite well with the human eyes ability to track horizontal lines of text. Citation needed.
  - fao_ 10y ago
    From observation, people on HN tend to discourage small replies that say nothing (such as this). It is likely that you would not have got downvoted if you had said what evidence you have to the contrary, given your opinion on it and why you think that, or even made an effort to debunk or state why you think a few common arguments for the line length being 80 chars are incorrect. Hacker News keeps clean discourse by downvoting comments that are not relevant or do not stimulate debate.
- int_19h 10y ago
  It goes both ways. If you break in the middle of the line just because you need to follow the standard, you may end up breaking in the middle of a construct that is really meant to be read as a whole; and having to move your focus to from the end of one line to the beginning of another is quite disruptive to the flow. I'm also not convinced that 80 chars "happens to line up quite well with the human eyes ability to track horizontal lines of text". It's claimed often, but in the absence of any actual studies, the best you can really say on this is that it is your subjective experience. Mine is different - I find 100-120 columns per line to be eminently more readable. Until the aforementioned study determines what the average peak readability length of _code_ (which I think is likely to be different from regular text, because the semantic units are different between the two), we'll just have to agree to disagree.

DanBC 10y ago

> It's very annoying when I read code that doesn't use the 80-character limit, because my terminal is not guaranteed to be as wide as theirs, and I really don't like resizing my terminal window to fit their line length. Considering the numbers of programmers in the world, and how long they've been working with text, and how much annoyance text breaks / line wrapping / format flowing causes it's kind of surprising that there isn't better ways of wrapping lines without line breaks. What's current best practice? Or is it just down to the project style guide?

andrey_utkin 10y ago
I guess these are enough general: put operator sign before line break; don't break inside of the most nested expression; don't break between variable type and name... There are more such rules which differ between standards (like Linux kernel style vs. PHP PSR-2 style), e.g. how to pad trailing lines of function call. Linux style says to align trailing lines at offset next to the opening brace. (This doesn't look good in case of long function name, though, but most of time readability of this way is very good.) K&R is referenced as an original of such style, just as everywhere in Linux coding style. Also Linux coding style is not just what is told in Documentation/CodingStyle - there are some unwritten tools which you'll encounter when you run scripts/checkpatch.pl or get reviews on your patch submission.
zyxley 10y ago
gofmt comes to mind here. It renders the particulars of what you do while writing a non-issue by taking any valid Go input and producing a "canonical" final formatted version.

simplicio 10y ago

It used to seem natural to me, but as screens have gotten wider, it now seems like I usually have my terminals set wider when I have two set side-by-side. Even on my relatively small laptop screen. I actually was just contemplating ditching the 80-char limit the other day, at least for personal projects.

strictnein 10y ago

80 characters seems really narrow. IDEs like IntelliJ put a guideline at 120 characters, which basically allows two full width editing windows side by side (depending on your font size) at the pretty standard resolution of 1920x1080. We've all got widescreen monitors now, right? So it makes sense that people are going well past 80 characters.

s_kilk 10y ago
> We've all got widescreen monitors now, right? Sure we do, but some/many of those widescreen monitors are only eleven or thirteen inches diagonally, and can't reasonably fit two buffers of text 120-chars wide without shrinking the font to eye-straining sizes (yes, even on retina screens). Plus, this only gets worse as you get older and your eyesight starts to diminish.
- epalmer 10y ago
  > Plus, this only gets worse as you get older and your eyesight starts to diminish. Yup, I'm at that point.
tremon 10y ago
As another commenter noted, it's not (just) about screen width. It's about having a text width that allows your eyes to track both column boundaries as achoring points. If a text is too wide, your eyes will have trouble finding the start of the next line. For the same reason, newspapers use multiple columns, even though the paper itself would allow for 200-character lines.
- strictnein 10y ago
  I don't think we read code the same way we read normal text. If you have this in your code: qry.setParameter("a", a); qry.setParameter("b", b); qry.setParameter("foo", foo); qry.setParameter("bar", bar); After the first "qry.setParameter" you're no longer reading anything but the parameters and your eyes are moving vertically. Or if you have something like this: Query qry = getEntityManager().createNamedQuery("User.findUserBySomething", Long.class); You're only reading the "User.findUserBySomething". The rest of it is mainly fluff.

gremy0 10y ago

> For car width, I think that that's also a pretty reasonable width, since it's the perfect width to fit two people side-by-side comfortably, with a bit of room in the middle. How do you know the width of a standard human isn't determined by 2000 years of people choosing partners that would fit beside them on a cart comfortably.

knodi123 10y ago
oh my god, you just uncovered the cause of the obesity epidemic in america- the spread of SUVs and wide multi-lane highways

s_kilk 10y ago

Agreed, 80-chars may be an accident of history, but it's an accident which happens to line up quite well with the human eyes ability to track horizontal lines of text. It gets tiring listening to devs rage about the 80-char limit, then go on to produce code that's basically unreadable because it scrolls way off the screen.

arethuza 10y ago
I was looking at some C code of mine that is ~30 years old - it was written on 80x24 serial terminal in vi and I was fairly pleased with how readable my code was. I suspect a large part of that was the short line lengths!
jahewson 10y ago
> it's an accident which happens to line up quite well with the human eyes ability to track horizontal lines of text. Citation needed.
- fao_ 10y ago
  From observation, people on HN tend to discourage small replies that say nothing (such as this). It is likely that you would not have got downvoted if you had said what evidence you have to the contrary, given your opinion on it and why you think that, or even made an effort to debunk or state why you think a few common arguments for the line length being 80 chars are incorrect. Hacker News keeps clean discourse by downvoting comments that are not relevant or do not stimulate debate.
int_19h 10y ago
It goes both ways. If you break in the middle of the line just because you need to follow the standard, you may end up breaking in the middle of a construct that is really meant to be read as a whole; and having to move your focus to from the end of one line to the beginning of another is quite disruptive to the flow. I'm also not convinced that 80 chars "happens to line up quite well with the human eyes ability to track horizontal lines of text". It's claimed often, but in the absence of any actual studies, the best you can really say on this is that it is your subjective experience. Mine is different - I find 100-120 columns per line to be eminently more readable. Until the aforementioned study determines what the average peak readability length of _code_ (which I think is likely to be different from regular text, because the semantic units are different between the two), we'll just have to agree to disagree.