Is there a valid reason for enforcing a maximum width of 80 characters in a code file, this day and age? [closed]

Question

I think the practice of keeping code to 80 (or 79) columns was originally created to support people editing code on 80-column dumb terminals or on 80-column printouts. Those requirement have mostly gone away now, but there are still valid reasons to keep the 80 column rule:

• To avoid wrapping when copying code into email, web pages, and books.
• To view multiple source windows side-by-side or using a side-by-side diff viewer.
• To improve readability. Narrow code can be read quickly without having to scan your eyes from side to side.

I think the last point is the most important. Though displays have grown in size and resolution in the last few years, eyes haven't.

The origin of 80-column text formatting is earlier than 80-column terminals -- the IBM punch card dates back to 1928, and its legacy to paper tapes in 1725! This is reminiscent of the (apocryphal) story that the US railway gauge was determined by the width of chariot wheels in Roman Britain.

I sometimes find it a bit constricting, but it makes sense to have some standard limit, so 80 columns it is.

Here's the same topic covered by Slashdot.

And here's an old-school Fortran Statement:

80 characters is a ridiculous limit these days. Split your code lines where it makes sense, not according to any arbitrary character limit.

You should just do it for the sake of everyone who doesn't have a 22 inch widescreen monitor. Personally, I work on a 17 inch 4:3 monitor, and I find that more than sufficiently wide. However, I also have 3 of those monitors, so I still have lots of usable screen space.

Not only that, but the human eye actually has problems reading text if the lines are too long. It's too easy to get lost in which line you are on. Newspapers are 17 inches across (or somethign like that), but you don't see them writing all the way across the page, same goes for magazines and other printed items. It's actually easier to read if you keep the columns narrow.

When you have a sequence of statements that repeat with minor variations it can be easier to see the similarities and differences if the they are grouped into lines so that the differences align vertically.

I'd argue that the following is much more readable than it would have been if I'd split it over multiple lines:

switch(Type) {
case External_BL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_BR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_TR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case External_TL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_TR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case Internal_TL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
}

Update: In the comment's it's been suggested that this would be a more succinct way of doing the above:

switch(Type) {
  case External_BL: dxDir = - 1; dyDir = - 1; break;
  case External_BR: dxDir = + 1; dyDir = - 1; break;
  case External_TR: dxDir = + 1; dyDir = + 1; break;
  case External_TL: dxDir = - 1; dyDir = + 1; break;
  case Internal_BL: dxDir = + 1; dyDir = + 1; break;
  case Internal_BR: dxDir = - 1; dyDir = + 1; break;
  case Internal_TR: dxDir = - 1; dyDir = - 1; break;
  case Internal_TL: dxDir = + 1; dyDir = - 1; break;
}
mpstrd["X"] = pt1.x + dxDir * RadialClrX;
mpstrd["Y"] = pt1.y + dyDir * RadialClrY; 

although it now fits in 80 columns I think my point still stands and I just picked a bad example. It does still demonstrate that placing multiple statements on a line can improve readability.

Printing a monospaced font at default sizes is (on A4 paper) 80 columns by 66 lines.

I use the the advantage of bigger screens to have multiple pieces of code next to eachother.

You won't get any ammo from me. In fact, I'd hate to see it changed since in emergencies I still see rare cases where I need to change code from a text-console.