131–140 of 180 posts
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!…
That gives me an effective working space of 110x37. Any concept that needs longer lines or more lines is going to be harder to follow.
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...
// Empty by choice
// Use the Prettier defaults
// No customized rules
Considering how easily I lose track of my position when reading long lines and how easy it is to read vertically when lines each have a single word on them, I seriously question the method by which most developers determine that they prefer >80 character line length limits.
How descriptive are your variable names and how how many of them are you passing around? Comparing x to y in a few different ways will easily fit into 80 columns, but you can only put something like machinePoolControllerGroup or webhookControllerRuntime a couple of times before hitting 80 chars with indentation.
Each column on a card indicates a single character or number, so a whole punch card is the equivalent to a single line of text (and was usually treated as such for programming).
Originally, there were only one or two holes punched in each column, providing just enough data for uppercase letters and numbers. But this slowly increased over the years, allowing more characters to be encoded. IBM introduced the EBCDIC standard in 1964, which enabled up to 6 different punched holes per column, encoded in eight bits. This corresponded with the development of the System/360.
When terminals were first introduced, they were designed to be compatible with 80 characters per line, as you would expect. Starting with 40 characters per line in the early 60s, eventually terminals like the IBM 3270 had 80 columns as the norm.
This was then copied by microcomputers. The Commodore PET launched with 80 x 25 character support right away. The Apple II originally had 40 characters per line, but they also sold an "Extended 80-Column Text Card" extension board to allow 80 characters (as requested by VisiCalc). This was built in to the business focused Apple III, and later into the IIe. The "e" in IIe stands for "extended".
The original IBM PC's Monochrome Display Adapter had a 720 x 350 display, with each character contained in a 9 x 14 box. 720/9 = 80.
As higher resolutions became the norm, editors began to put a line on the screen to visually indicate 80 characters. Certain programming languages have an 80 character per line limit like COBOL or FORTRAN, so the line did serve a purpose at first. But later it became sort of vestigial.
And here we are now, a century later, debating whether 80 characters is still a good line limit for code.
> 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
One minor advantage which wasn’t so relevant in 2008: 80 character lines are much easier to read on a smartphone. This is especially true for Safari on iOS, which always seems to make bad wrapping / sizing decisions with plain text. ETA: thinking back on it, several years ago I switched from 120 characters to 80 specifically because of this. I don’t have a car, so I read a lot of code on my phone while taking public…
On the other hand, horizontal scrolling on a touchscreen is more natural than with a mouse.
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.
Earlier quoted context omitted.
Since we’re already on a Holy War About Arbitrary Things topic (and at the risk of igniting the whitespace wars anew), do you mind expanding on this? > I hate tabs This opinion seems common but I haven’t seen a practical argument against tabs among practical arguments (for an admittedly niche situation) in favor of tabs. This seems an appropriate place to ask about it.
tabs are not great in Python because they can hide spaces, and that causes the code to break. in other code? i guess tabs are nicer because people can size them as they like on their devices.
This is the only case that has me thinking that tabs are an actual solution to a relatively uncommon problem.
I recall an anecdote about someone’s colleague whose eyesight was going bad, which required them to use a huge font size to the point that the width of the screen could fit just one or two words. Two spaces is less convenient than one tab when the text editor can be configured to render the tab as a one-character-width space.
(That’s the “admittedly niche situation” I mentioned initially. I call it “niche” but I’d still hope most teams would be accommodating for such a situation.)
Note that when we talk about line length limits, we're actually conflating two separate concepts: 1) The maximum width of our viewports 2) How long we want our lines to be WRT the second concept, the general rule of typography is that a line should be 60-80 characters long. But, crucially, this is not counting indentation; a "line" here begins at the start of the text, not at the start of the margin. In the modern da…