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 transit.
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 been reading books on phone since palm pilot and 160x160 screen.
I do not want to type / create on my phone though, certainly not code, or even sign up for stuff / submit / do applications on phone. Makes me a rarity though.
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.
CWEB?
thanks!
I don’t know how “common” it is, but (like I said in my comment) the only reason I read code on my phone is that I am often on a bus or a subway. The comment about assuming I only read on my phone is bizarre: you are putting words in my mouth for reasons I do not understand. When it comes to books I like paper, and I usually read long PDFs on a tablet.
GP was not assuming you read only on the phone screen, but that you use phone just (only) for reading ("read-only") and not for editing.
Sibling post is correct. I meant that as a question on if you edit while on the phone.
“read-only” might have removed the ambiguity there
Agreed. I'll blame my phone. :)
In seriousness, apologies on the confusion.
Someone else is going to be weird and want to look this up so I'll save you the trouble.
Yes, aithrowawaycomm's claim about line lengths are supported by many, many different sources who recommend a 50 to 80 character line length.
https://duckduckgo.com/?q=reading+optimal+line+length
IMHO, 80 characters is too narrow, especially with Python, for most coding tasks so I settle more around 100 (+-20) characters. PEP-8 says up to 99 characters is okay.
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 background, unlike for tables. More likely an alternation between 3 or 4 subtly-different colors is best; maybe these can form a pattern across additional lines (e.g. 121312321). If the difference isn't subtle enough, editing will suffer whenever you break the line count, but for reference only the human eye is pretty good at aligning subtle things. Maybe even an outright paper-texture background image? (This is more often a gimmick, but it can be useful.)
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.
It's an interesting point.
You can't have it both ways though - support hard line limits because the mere discomfort of long lines is insufficent to convince the programmer to refactor to something clearer, and then argue that the mere discomfort of the line limit including indentation should convince the programmer to refactor deeply nested code into something simpler. Which is it? Do we want to force limits with say a linter (80 characters of width max, 5 levels of nesting max) or let the programmer choose based on comfort?
I've had to implement things like an arbitrary-JSON formatter. Setting a fixed width including indentation doesn't work - there would always be (deeply nested) values you simply cannot print according to the rules (excluding, of course, strings which have their own difficulty). I kinda feel 80 characters excluding indentation works out ok in practice in a variety of settings.
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.
> especially with Python
On the other hand, horizontal scrolling on a touchscreen is more natural than with a mouse.
It's not, with a mouse I can scroll vertically with a Shift to scroll horizontally On a phone touch screen horizontal scrolling is also less ergonomic than vertical due to less range (and less ergonomic than vertical mouse), but I can't replace it
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! And stop with the insanity-inducing compound names. If your name needs 5 subclauses to clarify its intent, your semantics are stupid and you should be beaten with a shoe.
And some people like me prefer using large fonts, because my vision is not very good. The code pane in the full-screen VSCode window I have open on a 27" display is 145x37. Full-screen mode would add one more line. And those 145-character lines are typically enough for ~110 characters of code, because the editor adds various annotations.
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.
It's hard if you don't know how to do it... and lots of people don't know how to do it.
I mean, spelling the word “CAT” is hard if you don’t know how to do it, but as spelling goes, it’s pretty easy.
It’s true that some people are illiterate and never learned to spell. That doesn’t mean it’s hard, it just means they never learned how.
I don't mind an 80 or 100 character limit on code, but it boggles my mind that we're still inserting line breaks in comment blocks. Like, if you can't figure out how to get your editor to line-wrap comments then you're in the wrong business.
There's still reason to use line breaks, because many editors / viewers will wrap at the viewport width, not earlier, which is not always desirable. Different content "wants" to be different max widths.
For instance, I think prose is hard to read when you have to scan long horizontal distances from line to line.
However, code often has indentation, syntax, and chains (e.g. nested property access) that take up a lot of width before the actual information is presented, so width is more helpful.
Code is not only used in modern editors. Sometimes it is used in HTML, sometimes it is used in emailed patches, sometimes it is read as plaintext in some other context, it may be read or manipulated over a remote shell session in a terminal that has only rudimentary tools available during a production problem. There are many contexts where source code should be cleanly and clearly formatted and comprehensible without assistance from modern GUIs.
Here you go, munch on a punch-card.
Delightful!
You know, there’s a reason cars and trains are the width that they are.
Is there? Or is that just a made up legend to justify rather arbitrary shit after the fact?
Enjoy your terminal troglodytis ;>
> 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.
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.
In my experience, people who use wide monitors are more OK to longer lines. The opposite is true for tall/vertical monitor users. The next question: What is the chicken and what is the egg? Do people prefer narrower lines because they prefer tall monitors? Or vice versa?
All of my main external displays are 27". The diffs fit perfectly on them with the 80 character limit
You must have your text size set to 18pt or something, because I can easily fit 3-4 columns of 80-char text on my 27" monitors.
It's whatever the default scaling is on GitHub. I could fit more in other contexts of course, but on the site, that's the perfect size with a 27" monitor
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 ...
In the case of Prettier, bikeshedding can still happen over the .prettierrc file, but it's not hard to make an argument for using the default configuration.
Formatters are something I miss whenever using languages without a widely-used formatting tool. For instance, in Common Lisp, code formatting is "whatever Emacs does when formatting the whole buffer". Depending on the exact package used (e.g. SLIME or SLY), the results of formatting the whole buffer may differ. Contrast this to languages like Go where there is one tool (gofmt) and it exposes no configuration, so there is no possibility of bikeshedding over code formatting.
In new projects I usually add an empty .prettierrc file with a single comment:
// Empty file. Use default Prettier settings. No rules here.
I like to put a haikus in spots like this:
// Empty by choice
// Use the Prettier defaults
// No customized rules
haiku: "empty by choice" is only 4 syllables
We probably need a CI job to count syllables.
Just add 'left' to the left.
"Left empty by choice" ...
aw, damn, the response I was looking for was "good bot"
Maybe even add a CI step that closes PRs if someone modifies formatter config files.
And fires them too, while we are at it!
I still play tennis with Black. But Black wins every time when I Ctrl+S. I still play tennis anyway because user-facing strings are " not '
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.
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.
I love how everytime this debate comes up, the 80 character gang keeps adding more stuff to put side by side.
Now we're shrinking the resolution/sizes of the devices we are using to justify it...
Gotta admit a three-way side by side diff/merge is glorious.
Have you ever tried it on three monitors at the same time? For me, it is a real game changer when trying to deal with a difficult, conflicting merge.
If you soft wrap you can avoid scrolling inn this case for any line length without negatively impacting the case of a single file
Is there any editor with an intelligent soft-wrap? I.e. it doesn't just wrap at the end the window. Line breaks should be introduced so that the tree structure of the code (think AST) becomes obvious. That improves readability a lot compared to breaking lines at a fixed column.
> formatting tennis
That's a paddling.
Seriously, professionals do this? If someone else wrote it and it does what it is supposed to do, it is not, NOT (no apologies for shouty emphasis), my job to change that.
(I hate tabs, but will never :retab someone else's code.)
My job is either/both to fix bugs and add new capabilities, not to be precious about, well, anything.
I would have serious reservations about any team member who wasted all our time on that.
I follow the coding conventions used by the project, whether it is tabs, 4 spaces, or other preferences. For my personal projects, I use 2 spaces for indentation and maintain an 80-column width, as it fits nicely in my XTerm windows, making both code and Git commit titles and messages easy to read.
I agree this is terrible primarily because it muddles up any git-blame based workflow for debugging regressions. I think an autoformatter with the config checked into git is a nice way around this.
> an autoformatter with the config checked into git is a nice way around this.
Yes. At my job we mainly use defaults of rustfmt in most repos. Some repos have rustfmt.toml in them. And the neat thing is that cargo picks up this automatically so there’s no per-repo config you have to do after cloning those repos in order to follow repo-specific formatting rules.
In CI we have a step that runs
cargo fmt --all --check
In order then to get your changes merged, you have to follow the same formatting rules that are already in use. Which in turn is as simple as having
cargo fmt --all
It’s nice and easy to set up, and it means that every Rust source file within each individual repo follow the same formatting as the other Rust source files in that same repo.
I don’t particularly care about what specific formatting rules each repo owner chose. (And the vast majority of our repos just use the defaults anyway.) All I care about when I’m working on code is that there is some kind of consistent formatting across the files in the project, and that formatting changes between commits from different people are kept to a minimum so that git log and git blame gives the info that you are interested in. So for me I am very happy that they do it this way at my job.
This approach comes with the benefit of automatically fixing those who simply don't realize their editor's settings disagreed with/didn't pick up on the conventions the project follows.
> I agree this is terrible primarily because it muddles up any git-blame based workflow for debugging regressions.
...it occurs to me, this feels like you're conforming to the tool instead of the other way around.
Is there a reason git blame doesn't have an "ignore whitespace" option? Is it harder than it seems?
I would think the issue is that if you format someone else's code, gitblame then sees you editing that code? Unless you can mark that commit as white space changes only somehow
You can tell `git blame` to ignore entire commits:
https://gist.github.com/kateinoigakukun/b0bc920e587851bfffa9...
It’s more than white space, autoformatters can change a lot, notable will often change line numbers by introducing or removing breaks
Consistency makes it easier to compare apples to apples and oranges to oranges.
Just like you don't want to allow both underscore_split, camelCase and TitleCase names in a single JSON object (or even different JSON objects returned by the same API), you might want more consistency overall to exactly avoid people's editors rewriting code someone else did (eg. you edit a module and your editor reformats the entire file).
Well I just want to fix the bug or write the feature and move on, but some want other things from their code.
That's the thing, without a standard formatter, a lot of IDEs use whatever their rules are. You can end up playing tennis because you just want to get that bug or feature done, you modify a couple lines of code in file X, Y, and Z, and now each of those files got reformatted by your IDE.
Instead of agreeing apriori on a standard format for all files forever, it's better to disable formatting in your IDE (except auto-indent which should follow their format). That's what mine does anyway.
Yours is a good attitude in an org with thousands of engineers, where every change gets mediated through some process tool simply to avoid chaos. You'll be messing up the system if you step out of your lane, and you statistically don't even care about some particular project's health and future anyway.
It's not a great one in smaller teams, which benefit from everybody quietly sweeping up whatever bit of the mess they run across. Not to say that justifies the petty and sometimes passive aggressive "tennis" that can happen in that world; that's just unprofessional ego-feeding behavior.
I mean I work on a team of (currently) three. Maybe I'm the toxic one, but I'd like to just not be persnickety.
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.
I wouldn't say, I hate tabs. But I strongly prefer not using tabs in source code. Let me explain why. There are some languages and coding styles where it doesn't really matter. E.g. when you are always indenting by multiples of some indentation length. But there also languages and coding styles where you want to align stuff.
Consider this example:
def someFunctionName(Int firstParameter, Boolean secondParameter, String thirdParameter)
def someFunctionName(Int firstParameter, Boolean secondParameter,
String thirdParameter)
def someFunctionName(Int firstParameter, Boolean secondParameter,
String thirdParameter)
def someFunctionName(Int firstParameter,
Boolean secondParameter,
String thirdParameter)
There are other similar situation when aligning in multiple columns, etc.
I simply find spaces easier to navigate. I don't always use vim-golf-winning movements, and when I am being lazy using hl or arrow keys, I expect to move a space at a time. Tabs violate that expectation.
It's a visceral rather than a rational thing (which I suppose is implied by the word "hate" :->). I also have trailing spaces and all tabs highlighted for similar reasons.
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.
I use tabs in python and it works fine, I just enable "show whitespace" in my editor.
> 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.)
Your comment is a bit strong, but, in my experience, it is normal to have a couple of average and below devs who only ever comment about formatting in a code review.
Very few professionals do this. Most people writing code are not professionals.
I largely prefer an 80 column limit. On my external monitors with no file tree open, I perhaps could utilise more columns comfortably, but that really falls apart if I need to work on my laptop's screen.
The side effect of this that I don't particularly love is having to split a function's arguments on to multiple lines. Usually if I'm at that point though, I'll probably end up having to split those arguments up event at a ~100 character column limit.
To me, splitting the arguments is the preferable of the two situations. I always want to be able to see the whole line.
80 characters is way, way too short. I think 120 is a decent spot for today's displays, although I don't mind even longer than that either.
No it's not, it's perfect.
You want to be able to do side-by-side diffs on your laptop using a normal sized (not tiny) font.
You want to be able to paste snippets into design documents and emails and blogs without accidental wrapping or truncating or scrolling.
80 is nicely legible. It works really well.
Actually no I don’t want to be able to work like that on a laptop monitor. I’d rather optimize my full screen real estate. There in lies the conflict.
Since in most cases, most lines don't even reach 80 characters, or they're long enough to still wrap at 120, there's not a lot of optimization going on.
Going from 80 to 120 will net you, what -- an extra 2 or 4 lines in your viewport?
It's not worth the optimization when you lose so much for the reasons I described.
If I wanted extra lines, I'd probably use my monitors in tall mode. I mainly just don't want to think about line wrapping at all, that's the optimization for me.
I also tend to work on a single file at a time versus trying to view multiple files side by side. But when I do want to do that, I'm not trying to work on a laptop monitor, so I have 2 monitors for that use case.
The white space I have available but typically don't use, simply doesn't bother me. I like some white space, I'm not seeking out density as some productivity hack, I can tab to another file when I want to see it, seeing them both at same time isn't a huge requirement of mine.
It sounds like you have a job that has you frequently doing code jams on a tiny monitor (why? you got pulled into someone's office? you coding on a train?) so this works for your normal situations. You're not understanding that I avoid those situations. I code from a desk with a full setup or I don't code, I take notes about what changes need to be done when I get back to coding.
On my laptop, with a normal font (12-14pt) I can have a side bu side diff of 100 char wide text just fine.
IMO 120 is the extreme limit but a good limit. Anything higher than 120 is to long and, personally, I'd ask for that to be fixed in a code review.
120 is way too small. IMO 180 is a good limit. We're not on 800x600 screens anymore
Lots of people are using split screen editors though. Tbh if you are butting up against the 120 limit, you're probably doing something wrong and could easily break the lines, or use less levels of indentation.
Over 120 and most likely something is wrong with the code. That many levels of indentation usually means that code's cyclomatic complexity is off the charts and is in desperate need of refactoring. It could indicate bad naming practices (to long) which also should trigger refactoring. This is all to say it is more about what long lines say about the code than anything to do with the display.
Some languages are just naturally worse at this (eg. Java), so there is always some flexibility. But for most languages that don't have multiple levels of indentation by default and the custom of overly long names, 120 is more than enough to be a good guidepost.
I have three 4K monitors and use a small font and think 180 is way too large.
Long lines are less readable and I want to have several terminal panes or editor windows side by side.
I just bought an ultrawide, and I just checked to see how wide my lines are in my code editor. 350 characters.
When I'm coding for myself, I use all of that at times. I love that there are some things I no longer have to break onto multiple lines any longer.
Also, if you have a ton of nested loops etc, then you don't end up with that problem where you can only see the first few characters of the deepest lines.
In the space you use for editing a single file I can fit four 80-column source files (which I do, I also have a giant monitor).
Also, excessive nesting is almost always a code smell.
I think the issue with a very long line is akin to writing without punctuation because code is usually much more information dense than prose it becomes hard to follow what it is supposed to mean than if there were pauses for you to consider points in isolation but otherwise I don't see a problem with long lines if you have for example some very long silly OOP getter chain which is essentially one expression as for tons of nested blocks the general argument is it's a hint that your single unit of base indentation is doing too much and there is possibly something to be done about it though like everything it is usually taken to a unhelpful extreme.
I suspect nested loops going that deep are very likely to be a design problem.
Loops nested deep enough that you need an ultrawide to avoid truncated lines!?
The idea of 350 characters worth of nested loops leaves me speechless.
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 variable names as much as it does to how many lines a function is. The smaller the unit of functionality it is, the easier it is to understand in its entirety.
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
e.g. the above could be rewritten as the following, removing a lot of ambiguity:
retail_margin = (retail_price - wholesale_cost) / retail_price
Perhaps instead of using highly descriptive variable names, use reasonably descriptive variable names?
Names that are too long impair readability rather than helping it. You want names that are as long as necessary to meaningfully, semantically distinguish identifiers in a given context, but not any longer.
I'm comfortable that I'm writing code that's easy to understand and modify years later.
It's not impossible if you're using an indent of two spaces and not doing a lot of nesting.
I think 100 characters would be a better limit, though.
Yes, not impossible, but in my opinion requiring a waste of energy.
One disadvantage about long lines is during debugging: 1) as you step through your code having one megaline is difficult and 2) when you're looking at a bug in your terminal it can be harder to tell where the issue is.
It's as relevant as the 4:3 aspect ratio still being the best as it correlates to the physical properties of our eyes. That said and knowing that nearly every modern day OS is capable of resolution independent functioning; we should start rendering interfaces based on the distance from the eyes to the screen and it's size. Someone probably already did the math on this.
Some other considerations:
1. Use of DOS programs.
2. Printing out on a paper.
3. Split screen.
4. Other people who view, with different screen resolutions, and preferences for font sizes, window sizes, etc.
These are also some reasons why you might still prefer to use a short line limit, too.
>at a comfortable 10 point font size.
How lovely for you. As someone with significantly impaired vision, even when corrected, I have my font size set to 18, thank you very much. A coding standard that assumes a 10 point font size would violate the Americans with Disabilities Act's 'reasonable accommodation' mandate. I wasn't pushy enough to act on it, but it sure pissed me off when my fellow team members blew off my complaints about how we formatted our code. (Including two space indents...grrrr.) My worse than 20/200 vision (Can't see the big E on an eye chart) lets me see code, but legally, I'm blind in one eye.
I admit, it's a classic 'no perfect solution' scenario, because I like very long variable and function names. I write tiny functions (5-10 lines) because they only need one or two levels of indent. Some programmers I've worked with really dislike such small functions.
> A coding standard that assumes a 10 point font size would violate the Americans with Disabilities Act's 'reasonable accommodation' mandate.
Would it? You can still set the size to 18, you just might have to scroll or line wrap. That's a mild inconvenience, not "inaccessible".
I try and maintain 100 char width in most code, because I feel like it makes people more concise.
I’m curious on several statements you made, please take these as genuine and well intended questions:
what’s wrong with two space indent?
Would a bigger monitor with higher DPI solve some of these issues?
Have you considered a horizontal scroll wheel or similar? I think this is a Band-Aid to a bad pattern, but may be a legitimate option
You may appreciate python PEP8, which discusses things like highly nested code and functions being considered bad. I first followed PEP8 kicking and screaming, but I think it forced me to remove some bad programming habits and I now lint check my code habitually.
Sorry to take so long to answer. Good questions. 2 space indents, in (say) 30 line functions, get harder to discern the more indent levels. This problem is exacerbated by bad eyesight.
Bigger monitor with higher DPI does help, yep.
Horizontal scroll: I suppose it could help. The more immediate tradeoff tends to be that I use a terminal full width on a large monitor when needed, and tolerate the fact that I'd prefer to have space to have a web browser open on the same screen.
I'm a big fan of Sandy Metz, who advocates 5 line routines. In Python and Ruby, this is possible, and the indentation problems go away. In C, it's more of a challenge.
So long as everyone adopts a consistent base it doesn't matter if the font ends up with the number 2 or 200, the actual size that'll appear for each user is tuned to the overall visual scale that they like best on their device.
It's one of the things that drives me nuts about shared Excel spreadsheets. Rather than just zoom in or out someone will mess with the font size to make it fit their screen and suddenly it's just screwy enough for someone else with different eyes on a different monitor when then goes to change... you get the idea.
> A coding standard that assumes a 10 point font size would violate the Americans with Disabilities Act's 'reasonable accommodation' mandate.
Would it? I don't think having to make all my lines 44% shorter than they should be is reasonable; that's going to be a massive impingement on productivity.
44% shorter: is your claim that limiting line lengths to 80 or 100 characters is going to 'massively impinge' your productivity? That seems unlikely to me.
It absolutely does. You might think it would just mean more lines, but that means your functions are longer so you have to break them up more, which means there's a hard limit on how big a coherent thing you can build. If you think it wouldn't matter, try limiting yourself to 60 or 40 character lines in a codebase and see how much it changes.
Write tiny functions because of aesthetics; not because the flow calls for it ಠ_ಠ
I use 120 or 132 (no idea why I picked that number), but I tend to break my lines well before that, especially on function signatures.
I'm that git that puts each param on a separate line (so I can quickly comment them out when I need to). It annoys other programmers, but once I explain why ...
They're still annoyed, but at least they're quiet about it.
Some old "dumb" terminals could be switched into 132-column mode, this corresponded to the 132 columns on the line printers that printed on wide fan-fold green-bar paper.
The 80 column standard for a line of code goes back to the 80 columns on a standard IBM punch card. Why 80 columns on a punch card? I don't know that one.
If you're that git that makes one param per line a standard that you can flunk code review for not adhering to, I'd seriously consider switching jobs were I under you.
I will do this, but only if it has many parameters.
It makes it easier to visually parse the function name, templates, outputs, etc. from the parameters than if they were all on one line
> I'm that git that puts each param on a separate line
I do that too :)
At home, if I put VS code on my 1080p 24" vertical monitor, I can see about 100 columns (at a reasonable font size, with the VS code sidebar up). I find that to be a little limiting at times but not too bad, and I can close the sidebar to get to 120 columns. Minor issues with horizontal character count are definitely worth it for the massive vertical space though (about 100 lines of code). I've been thinking about replacing it with a 27" 1440p monitor to get a few extra inches of monitor width at about the same pixel density.
One thing I find sad is that of the 4 IDEs that I work with, most of which have an option to break done long line into several multiple line equivalents, none allow to do a word wrap smarter than that of notepad. They already implemented the refactoring tool, using it in rendering would probably not be a far fetch. That would allow us to get past handling line breaks manually and the invariant discussions and review comments on how best to line up function parameters and comments in 2024.
That is a lot of IDEs! Why not use IntelliJ for everything... Or Eclipse or Visual Studio Code? I am pretty sure all three are uber polyglot at this point.
I use rider where I can, xcode for ios because you don't have a choice, VS for a few things where, similarly, I don't have a choice, and vs code for one of the projects because my company built a bunch of extensions to deal with the codebase
In my mind, it's a balance between expressing the flow of control/algorithm vs the details. You can have 20 long lines (admittedly, some blank because it helps readability) that show what is happening... or you can have 200 lines (because you broke out each argument to a function on it's own line, etc), making it much harder to look at the code and see what happening "overall".
Sometimes the details are more important, sometimes the flow of control/algorithm is.
I think 110 is a nice spot. You can still split screen but also fit a lot of content on one line
Honestly it depends of the language you're writing in too.
Some language are just long and wordy and having a 'fixed' size just leads to awkward line splits. e.g. all the languages that tend to favour 2 space tabs.
yes, for split screen - e.g. two files open at once.
I've got five files open on my monitor right now, side-by-side! Wouldn't be practical if the codebase used a lot of long lines.
Two files on a laptop
It's mentioned in the article..
I have a line length limit I personally stick with, because it works for the display setup I have. But - I don't actually care all that much! I have truncate-lines off, word wrap mode on - or whatever the text editor calls it - so I never miss anything. You could do this too, and now the question of the character line limit becomes much less relevant.
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)
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
no, for a literal page down, the first line on the next screen would become the new first line, with zero of the previous page still visible (which would be perfectly fine with me, I simply would like either that everything work the same way, or I get a visual indication of what just happened so I don't need to hunt for where to continue reading
A couple years ago I had a pinched nerve in my cervical spine that prevented me from doing desk work so I built a supine workstation that used an ipad as the screen. I found that the 80 character limit was very helpful in that situation and I wonder how many other disabled devs might agree, especially those with vision issues.
Why'd you use an iPad as a screen instead of a more traditional screen?
I think the answer is pretty clearly "no, but" (or "yes, if"). Of course it depends on what you're doing – if you're writing shell scripts, it might make sense to keep them at 80 characters in case you have to go down to the data center and edit them from a terminal because your network card failed. But for most code, there's no particular limit that makes sense (in my opinion).
I'm somewhat against code formatting "rules" in general. If it's about readability (/aesthetics), different code will have different properties that make it readable or unreadable. Sometimes, forcing a line break makes code less readable. In other situations, it can have the opposite effect. IMHO, it's a local decision – and the human that's working on that code is better at deciding what's readable than a linter is.
I agree with you that writing readable and aesthetically pleasing code is more art than science (that can be expressed with deterministic rules), I still find some of the rules and rule-checkers beneficial (though I dislike strict formatters).
As such, 80 is as good a limit as any, and makes you think carefully about avoiding deep nesting of blocks, which is usually a good idea anyway. It also allows putting many windows side-by-side on a modern big 4k screen.
I have to push back here a little bit. It really depends.
I mainly use Scala, and I think the majority of Scala code would be far less readable if forced to 80 columns, than if it were a larger number (or simply unconstrained).
My WFH monitor is an Apple Thunderbolt Display, which is woefully out-of-date now. Even on this display, and even though I use a much larger font than most people (16pt Hasklig), and even with a generous project/navigation/etc sidebar, I still get 180 characters. The display I have in the office is even wider, but I can't measure it right now because I'm not there.
My point is, displays are now wide enough where arbitrary line limits don't make sense. Nobody is going to cram stuff into one line unnecessarily, so just leave it up to the local decision about what makes the code most readable. If for some reason a 240-character line is more readable in some situation, then we should talk about that situation rather than why they didn't break the lines.
Unfortunately, while the monitor on my desk has gotten bigger, I've got this screen that I hold in my hand that's smaller than any desk monitor, and it's in portrait, not landscape mode, so while I don't write code on it, I do read code on it, so now, ideally, we'd accommodate that use case as well.
With 180 characters on your display and lines of more than 90 characters, you can't put two code windows side-by-side.
But it sure depends on the language too, though I wonder what's so peculiar about Scala to really benefit from long lines?
Method chaining, and a lot of it too. I honestly think it's a code smell, but some people love to do a dozen transformations in one line. You then need to make the line twice as long with .taps to debug it.
Fun fact: 80 characters comes from punch cards, specifically the IBM card format, introduced in 1928. It improved on competing card formats by having rectangular holes which allowing tighter packing of holes. The result was 80 columns and 10 rows per card.
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.
For accessibility, I prefer 80 characters. With a large screen, at a font I can read, there are about 83 characters before the line wrap.
There are formatters though. The issue then becomes the git diff. This seems awfully like the tabs vs spaces debate.
> This is because, back in the bad old days, most computer terminals could only display 25 rows of 80 columns of text on screen at once.
And this is because, back in the super old days, most computers used punched cards. Which had 80 columns.
> back in the super old days, most computers used punched cards.
Back in the super-super-super old days, looms were "programmed" using paper tape, which eventually influenced the 24-column Hollerith cards for the 1930 census, and ultimately resulted in a horrific application of technology.
I don’t care how ultra your wide is, reading anything horizontally is painful and unwieldy. It’s biological, your eyes can’t track horizontally without row guidance, and even then it’s not hard to get lost.
I have one rule: code flows vertically. I like reading books. Code should read as easily as a book. I have found that if you constrain your code to being shaped like a book, almost everything else follows naturally.
You can’t be indented 7 levels into hell if your code has a reasonable line limit. You can’t jam arbitrary numbers of statements onto a single line. You have to decompose your control flow at reasonable function breaks. Lines are a better primitive for editing and debugging. Etc. etc. etc.
Does it help readability? Sometimes a long line is crappy, and sometimes breaking it up is terrible. I HATE how my python looks after pep-8 gets ahold of it. Before Go, I was team 120-ish instead of 80 as it tends to not break as many otherwise legible lines. After Go, I removed my 120 char ruler in my editor.
How unfortunate that line lengths ended up being a source code concern instead of a text editor concern.
well I think the problem is that people use indentation to visually see the context of a block of code, so when you wrap text it messes that all up and if you have code with long variable names and a lot of indentation, there isn't much you can do to prevent the column from going over a certain amount of chars.
People (including torvalds) complain that some small limit like 80-chars does not make good use of screen width.
Maybe the solution in whitespace-independent code like C is just to "reset" the indentation after a certain amount, or just choose not to indent certain blocks?
I just use tabs and set my tab length to 2 or 3 chars.
IDK how text editors would adjust the source code to fit multiple screen widths. When I have a line that's too long for the line limit, I have to re-arrange the code in that line to get it under the limit.
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.
I use descriptive variable names and I do sometimes run into issues around that. Sometimes that means putting the variable which is on the right of the comparison on a separate line, indented, but I’ll admit that carries its own ugliness. It’s not perfect but I do have difficulty reading those really long variable names on one line so I’m not shy about splitting things on multiple lines. I assume others don’t lose their place as easily but I doubt I’m alone in that at the same time.
65-80 for readability however once you introduce indentation this naturally increases. I always felt that shorter lines were a good way to encourage less nested code. Alas after all these years the consensus is against me.
I still like 80 columns even on modern hardware and displays. It encourages me to keep my lines tidy and to break long lines apart. Sometimes I go a little over, but it's a nice target to reach for.
Completely agree on limiting yourself reducing the nesting of code.
There is more difficulty working with code such as
if x { //... } else { //... }
Than code like
if x { // returns from this block } // execution continues
In some legacy code I sometimes encounter very long chains of checks which nest 4-8 layers, which becomes very difficult to maintain a mental model of where you are in execution at any point. I try to refactor into the second pattern from above when possible.
agree. i think google python formatter kept lines at 65, i was surprised but it made you keep things concise & ended up much more skimmable.
i'm with you
For Python source code, where indentation is significant, I'm convinced that long lines should never be broken early. It should be the IDE's job to (optionally) fold long lines dynamically to the width of a viewer's editor.
If someone breaks a statement early at 72, or 79, or 99 characters (PEP8 recommendations), indentation no longer represents the structure of the program, it now represents the style of the author. Everyone who uses a wider screen suffers.
But if the IDE knows how to fold long lines dynamically, then any reader can use any width screen for viewing and editing. And users may choose not to enable folding at all, so that indentation exclusively represents program structure.
It still is relevant in 2024.
> An 80 character limit has no relevance any more with modern computer displays.
It's still nice to keep the code or anything readable on a vertical mobile screen.
I like the 80 limit. Makes me think harder about what I'm doing.
Some languages are naturally wider (Java, PHP, etc). I those, 120 is fine too.
Also, I tolerate comments past the 80th column but not code.
on a 1920x1080 display using bitmap fonts or their equivalent where each cell is 8x16, then three tiled windows without borders are 80 characters wide. font used is unifont, i3 window manger, xst terminal, vim, etc.
if i had a 2560x1440 display, i'd use four 80 character wide tiled windows.
Most of my code is pandas these days so chaining with a 40 char limit is usually fine ... Ducks.
I like 80 columns because I like to use multiple applications at once.
80 columns is about the sweet spot to have an editor on one vertical half of my laptop screen with the font set to a comfortable (read: large-ish) size, with something else (e.g. a browser) on the other side.
100 chars is the sweet spot for me. It allows you to have 2 files opened side-by-side in 1080p screen resolutions and even better for 2k res. 24"/27" monitors are the new standards.
I think 100 characters is called to replace the traditional 80 characters rule.
Yes. Vertical splits.
Sure, for JCL and COBOL...
Am I the only developer who preferS long lines?
it was not relevant in 2022. In 2024, with AI agents, it is relevant again.
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 day we could decouple these two concepts. Imagine a standard code format that assumed a maximum viewport of, say, 120 characters, but still wrapped lines when they reached 80 characters in length, not counting indentation. Then you could get the benefits of both enforcing a maximum viewport size while having a comfortable line length for reading.
Is there a single formatter capable enough for this?
Any formatter that already wraps on line length is capable enough for this, it's just a matter of taking the existing line length check and adding a single new conditional.
SavedYouAClick: no
Short answer - it is not.