80 characters? In this economy?
These things don't grow on binary trees you know!
Summary
In 2025, it is still recommended to have an 80-character limit in Python. This seems anachronistic, but it has many benefits:
It fits how the human eyes work.
It makes it practical when many tools are opened side by side.
It transfers easily across very different types of media and formats.
It unifies the community around a standard.
It encourages good programming practices.
80 and still got it
In this day and age of automatic formatting, PEP 8 is still the reference document on how to format Python code. It’s been updated several times since 2001, but one thing that hasn’t changed in 2025 is that the maximum line length is still recommended to be set to 79 characters.
Most people have the number 80 in mind, and ruff and black will attempt to wrap at that, but will give you some breathing room and only complain if they can’t do so at 88, by default.
Why 79 and not 77 or 82?
It’s a historical thing. Early terminals and editors typically displayed 80 columns, and some added, sometimes, an indicator in the first columns, leaving you 79 characters before the line would wrap. If you want to go back further, this is a relic they inherited from punch cards!
But we have gigantic screens now, terminals can resize on the fly, and Emacs/Vims are certainly not limited to 80 columns.
So why would it still be relevant today?
I have an absolutely gigantic screen myself, and as you can see in this picture, typing this article in Obsidian means the text takes only 25% of the total width:
And yet, I say, you should ignore the fact that most formatters, including very rigid ones, make this configurable. Keep the default limit at 80.
So what gives?
How the eyes work
Typographers have been at this game way longer than there have been computers, and yet, printed text has kept more or less the same format for centuries: the content unfolds through the height more than the width.
You could think it’s because it’s easier to turn pages, but before books, we had scrolls, and we had various ways to open them, vertically or horizontally. But apart from some artistic endeavor or when graphics were involved (like a map), text kept being stubbornly mostly written to flow vertically. This is true even in languages that allow reading from top to bottom, or left to right.
As research shows, it’s just easier for humans to read that way. Long lines can even make a text overwhelming.
One of the reasons for this is how our eyes move. When lines are too long, readers’ eyes struggle to focus, and it becomes difficult to quickly find the start of the next line. The eye movement from the end of one line to the beginning of the next is called a “saccade”, and it affects how you can comfortably scan the text. Something you do again and again while reading code.
But it’s not just that.
Side by side
Nowadays, it’s very common to have a lot of tools side by side when editing code. You have the code, the file explorer, one terminal, maybe an AI chat, or some object hierarchy tree displayed.
Most probably, you have a Web browser open as well, either to check the result of the UI you are coding, or to search for something, read documentation, and whatnot.
Then, of course, there is code comparison, something you do on many git merge . You might as well have the code editor to be spitted into 2 editing panels for easier reference or copy/pasting stuff.
Having code flow mostly vertically and not taking too much width in that context is a very good thing. Does it need to be 79 characters precisely? Of course not.
To quote the PEP8 itself (quoting Emerson):
A foolish consistency is the hobgoblin of little minds
And later on:
it is okay to increase the line length limit up to 99 characters
That’s why Ruff let you set max-line-length.
But I find personally it’s best to let it be at 80. It gives you more margin to cram more tools side by side without turning writing code into an impractical Tetris exercise. It makes diffing much easier, and since it’s a standard, no need to configure anything, no need to argue. You will already be aligned with most tooling and teams. That itself is a win.
Different medium
Even if we were not constantly having more stuff than code open in our dev machines, this is not the only place where code is going to be read.
Here are some of the places someone may be reading code:
In a blog article, from a phone.
In a screenshot on social media.
In a video during a tutorial.
In a web interface, inside a small widget to edit bug tickets.
In a KVM window, while trying to frantically debug this very bad Friday deployment at 3 am.
In a meeting while screen sharing.
While doing an SSH session on a BusyBox machine that has VI, but not VIM.
In the GitHub code review buckets.
In your Web server or CI logs.
In a serialized stack trace sent to a Saas like Sentry.
Those are all situations where having long lines would make the experience more painful that it needs to be.
Look at this very blog, making lines too long is wrapping code is a way that makes me cringe:
def size_matters_jokes_are_still_a_thing(explicit_content_name=”this_is_great_value”) -> ThatsMyType:But to be frank, my favorite reason for asking all my teams to stick to 80 (when reasonable), is because implicitly, it makes it harder to create clever one-liners, and forces to create intermediary variables which, in reviews, I can ask to have self self-documenting name.
Besides, when you can’t have a long line, you can’t have too many nested blocks in a language that uses indentation for them. This mechanically restricts cyclomatic complexity, instills habits like the use of early returns or context managers, encourages you to abstract big chunks into testable stand standalone functions, and in the end, makes adding a breakpoint during debugging a no-brainer.
Better code, that’s why I stick to 80 chars.
I think that reading code is different enough from reading text that I'll stick with my 100-character limit, though most lines fall well short of that (I'm not one for clever one-liners; they're much worse than dad jokes).
With code, the syntax highlighting changes the equation (to the point I now find working with code without it something of a challenge). I use a lot of alignment and whitespace for readability, and I do prefer to work vertically rather than horizontally. Comments definitely have to fit in a narrower range because doc pages.
But 80 is just too restrictive for me. (In retirement, I only ever write my own hobby code anyway, so I'm free to follow any standard that works for me. 😎)
I tried to stick to 80 columns as much as possible for a long time, but I realized that I had the tendency to use more and more very short function and variable names because of that.
Of course I try to decompose complex operations that could fit in a single line for readability and ease of maintenance, but since a few years ago, I added another practice that is sacrilege to PEP8 advocates: I align on equal signs (and colon for dicts).
It is contrary to PEP8 and makes the 80 column rule almost impossible to reasonably conform to, but since then, I find my code way, way easier to read and maintain. I generally do a pass on my fresh new code to fix PEP8 warnings and with a multiple cursor IDE (thanks PyCharm) it's done in an instant to adjust the alignment this way.
To each his own I guess ;)