Elliot Garbus
Jayne80 character column limits in code are a legacy from 80 column text displays which are a legacy of IBM's 80 column punch cards which are a legacy of Roman chariots which had two side-by-side 40 column horses
ok maybe that last bit is a bit silly but it's no sillier than using a nearly 100 year old punch card standard on today's wide screen monitors
coincidentally the Roman Colosseum, completed in year 80 AD, has 80 archways & thus 80 columns around the outer perimeter
https://www.thecolosseum.org/facts
https://www.thecolosseum.org/facts
Adam Austin@dotjayne
Wow all roads really DO lead to Rome
Wow all roads really DO lead to Rome
RodneyPetersonTalentAgencyNever mind that, where can I buy season tickets to The Christians vs. The Lions?
tbh I try and stick to 80 character line lengths, but believe going up to 120 is nbd if it improves overall readability. I just think it's silly how people can get so worked up about it (see also: vi vs emacs)
C-27733@dotjayne to be fair I use (neo)vim and have kinda strong opinions on another common argument , as I highly prefer tabs
Bruno Baketarić@minekpo1 @dotjayne The only option other readers can have influence on the indentation in terms of visual representation without modifying the file.
Why should another person force someone to a specific visual representation of the indent width? That should be a sole decision of the one currently viewing the code.
John Kaniarz@dotjayne I like to use use 132 columns as my limit. It’s the other common line printer size. 14” paper in landscape at 10 CPI. (plus margin)
aardvark
kasperdAn often overlooked aspect of readability is how readable a side-by-side diff between two versions of the code is. I find that I am reading such a diff just as often (if not more) as I am reading the code itself.
If you are working from a laptop and the UI is also displaying something else next to the code, then it's hard to fit more than 80 characters on each panel.
Another consideration is that diff and merge tools are often line based. If you make two nearby changes in code which happen to be on the same or adjacent lines they will generally show up as a single change in diff tools and would cause a conflict if those changes happened to be made in different branches.
By increasing the number of characters per line you are increasing the risk that two independent changes in the code end up on adjacent lines.
These are some of the reasons for me to stick with 79 characters per line. (I have come across style conventions using 78, 79, and 80 characters and among those I personally prefer 79.)
If you are working from a laptop and the UI is also displaying something else next to the code, then it's hard to fit more than 80 characters on each panel.
Another consideration is that diff and merge tools are often line based. If you make two nearby changes in code which happen to be on the same or adjacent lines they will generally show up as a single change in diff tools and would cause a conflict if those changes happened to be made in different branches.
By increasing the number of characters per line you are increasing the risk that two independent changes in the code end up on adjacent lines.
These are some of the reasons for me to stick with 79 characters per line. (I have come across style conventions using 78, 79, and 80 characters and among those I personally prefer 79.)
David Mankins@dotjayne I don't get worked up about it, but as age begins to affect my vision those wide screens no longer fit so many columns..... But then I aggravate the situation by turning my display to portrait-mode.
thinkberg@dotjayne would be nice if viewers and editors would break lines syntactically and format style correct. But right now, viewing code on mobile is a pain.
Dragon-sided D@dotjayne The issue is not line length; it is wetware cache size for parsing
Stuart Longland (VK4MSL)@dotjayne I prefer 80 characters because even on a "modern" full-HD monitor, once I adjust the font size to make reading comfortable… 80 characters winds up being a practical limit because I often view two files side-by-side on the same monitor.
That said, it's a guide and not gospel, break the rule if there's a good reason to do it.
It's like indentation… e.g. Python is space-indented normally because text editors had shocking tab compatbility back in the day… but for example NVDA (a screen reader) uses tabs even in Python code, because it's easier to count 3 tabs than 12 spaces.
clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛@dotjayne Yeah I'm a 78-character person except when I'm a 120-character person.
or 78-character character perhaps
And I do enjoy the discipline that is forced upon me when at least *trying* to keep the commit message first line within 60 characters.
Jima 
@dotjayne I've standardized on 160x48 for the last decade or so, or 161x50 where I want to consolidate four 80x24 terminal sessions using tmux (there's a 1-column/1-row separator, and a 1-row status bar at the bottom).
dharris@dotjayne and going too wide decreases readability. My team fought this battle a while back (I was on the 80 column team) and settled on a happy middle ground of 100 columns. It works well for me, esp with the easy ability to have two files side by side.
Luke Channings@dotjayne gotta display those Java class names somehow.
ctrl the gender goblin@dotjayne idk it fits neatly, I can have my terminal emulator, and some browser opened side to side, and I can read the code easily without having to scroll laterally
Ian Douglas Scott@ctrl @dotjayne Yeah, 80 characters can be pretty good for fitting on half the screen... for some screen sizes and fonts.
Really it might make more sense to automatically reflow for viewing. In some ways its quite odd that `man` will happily reflow formatted text for the size of terminal I'm using, but for source code we expect a certain width baked into the file.
Text files formatted for a specific width are pretty archaic and uncommon at this point.
@dotjayne to be fair , I like sticking to 80ish , since it makes it easy to have code split vertically (especially useful if you split header/implementation code ) and "punishes" code which is too nested .
@dotjayne While that's true, I still prefer to have a whole line of any text in sight without the need to move my eyes or head; this also makes it easier to find the next line when doing a 'CR/LF' when reading. To me that resolves around 120 characters.
eestileib (she/hers)
Lightning Duck@dotjayne Sopeqaking of Roman chariots, today's railroad gauge (space between rails, 4'8.5") is indirectly descended from the width of Roman chariots
Canageek@LightningDuck @dotjayne That is a myth actually, I can look up the full post about it if you want.
@Canageek @dotjayne I looked it up on snopes and it's not intentional but it traces back connections of "because of this, than that, because of that than more..."
Not direct now intentional but a series of happenstances that you can trace the link
Correct me if they're wrong because I thought it was an urban myth as well
Yimby Earth has moved!@LightningDuck @Canageek @dotjayne
It is indeed a myth.
There were several gauges in play in early railways, this one won out due to being wide spread. Was wide spread due to being used in mines Stephenson had worked for. Was not at all a standard. If there was a real connection to Rome it'd be a standard thing since then. It wasn't.
It was due to plateways in the UK mining industry.
https://youtu.be/zrq2_koM1zg?si=jK08qMjkPCyiNb3E
It is indeed a myth.
There were several gauges in play in early railways, this one won out due to being wide spread. Was wide spread due to being used in mines Stephenson had worked for. Was not at all a standard. If there was a real connection to Rome it'd be a standard thing since then. It wasn't.
It was due to plateways in the UK mining industry.
https://youtu.be/zrq2_koM1zg?si=jK08qMjkPCyiNb3E
Railway Gauges did NOT Evolve from a Roman Chariot.
RAK@YimbyEarth @LightningDuck @Canageek @dotjayne: And there are incompatible gauges not that far away; the gauge in the island of Ireland is 5'3", which only exists elsewhere in parts of Australia and Brazil.
abcderian@raktheundead @YimbyEarth @LightningDuck @Canageek @dotjayne
Agreed - there are examples all over the place of multiple gauges in use simultaneously, sometimes even in the same area: there are instances in the US where standard gauge and narrow gauge tracks shared parts of their lines, with a common rail on one side and two rails on the other side to accommodate each gauge.
Agreed - there are examples all over the place of multiple gauges in use simultaneously, sometimes even in the same area: there are instances in the US where standard gauge and narrow gauge tracks shared parts of their lines, with a common rail on one side and two rails on the other side to accommodate each gauge.
@raktheundead @YimbyEarth @Canageek @dotjayne
The Snopes article does mention multiple gauges but talks about why the current most common gauge became predominate
Major Denis Bloodnok@LightningDuck ... that's the joke, yes, that myth is _why_ there is a mention of Roman chariots in the OP.
Frost「
｜霜の狼｜人面獣心」@dotjayne We use 100x30 for our terminals!
Ben Evans@dotjayne This gives me an idea for a new syntax rule for esolangs: "Any line longer than 80 chars is a comment, regardless of content."
Francis George@kittylyst @dotjayne but this means _all_ comments have to be long… excellent!
Primo@dotjayne the last bit is silly, but I remember it being responsible for the size of our rocket and space ship parts 😅
Shine@dotjayne I worked in a company where it was enforced basically because of one senior dev, who refused to use anything but a 80 column terminal text editor with capabilities similar to Notepad bundled with the proprietary language we used (OpenEdge ABL)
@dotjayne I find a maximum of ~120 characters is the sweet spot for readability - if the lines are much longer I lose track of where I am.
Unless the code is so deeply indented the entire block is shifted over more than 120 characters... In which case I'd probably look to refactor
Word of Mouth @dotjayne I still keep it narrow because I like to have 2 files open at a time (or the same file in different locations). Sometimes I have both monitors going, so 4 files.
It's also just more readable than long lines, to me. If a line is longer than like 120 char or so, then I start looking for ways to split it. Usually in long
It's also just more readable than long lines, to me. If a line is longer than like 120 char or so, then I start looking for ways to split it. Usually in long
if expressions
Tanguy ⧓ Herrmann@dotjayne same for most keyboard physical layouts which are still staggered despite the fact that none need to activate some physical mechanism anymore.
Torbjörn Andersson@dotjayne Back in the 90s, I was told a cautionary tale that went something like this, though I've forgotten the specifics:
A mining company had three mines that they had been operating for years. A decision was made to close down one of them, leaving the panicked programmers to figure out which of the hard-coded 3s in their code referred to the number of mines.
Moral: If a whopping big hole in the ground can just go away overnight, the width of a monitor can change too. Define your constants.
Dave Jacoby@dotjayne well, yes, but do you like reading code that wide?
__Miguel_@dotjayne That last part would make @lowqualityfacts proud :P
jasonkarns@dotjayne this explains why some countries stick to 72 char limits. The horses in that region were smaller
r-hold@dotjayne Disagree, on a technical level this might be true.
Excessive line lengths are an anti-pattern and might be a hint that there are design problems with your code: too deeply nested and/or too big methods.
Long lines are hard to read and a cognitive burden. There are reasons the ancient terminals were designed the way they are and printed text / books also limit their width to a certain size that's easy to scan for the eyes.
(It's hard to follow/fibd lines when things get too long)
Jyrgen N
cuan_knaggs@dotjayne i think the punch cards are a little bit older than the roman two side-by-side 40 column horse chariots though
David JašaI've just watched this video... https://youtu.be/zrq2_koM1zg 😂
(now I'm going to look if the author bothered to link sources because while it's more plausible than horses' butts story, I don't know authors credibility yet...)
Railway Gauges did NOT Evolve from a Roman Chariot.
main source, looks real: https://garethdennis.medium.com/the-not-so-glamourous-origins-of-standard-track-gauge-2b5f1ae7e3bc , including the difference between track gauge and loading gauge. 🙂
trdebunked@dotjayne yeah but back when ebcdic still used roman numerals that was like, recursive.
Michael Gemar@dotjayne @jmcrookston The more you know…
@dotjayne The one for me is languages like COBOL where the language hard-codes a maximum line length and certain columns have specific meaning
Steven Lipton@LightningDuck @dotjayne I'm such a strong typing language person, adding the formatting as type like COBOL seems elegant to me, which was what those declarations were doing. var date:Date<yyyymmdd> would be cool. Does run into localization problems though.
@MakeAppPie @dotjayne I cur my teeth on Ada so I can appreciate a well designed statically typed approach but learning COBOL in the early 90s (Air Force tech school ) and later having to reverse engineer it dud feel a bit like archeology