As per PEP, the maximum line length is still 79. Its time to update this.
Earlier it was a useful one, but nowadays its reducing the readability of the code
Most of the developers use system with descent spec.
1 Like
Other recommendations such as 66 or 40 columns, whilst better for
readability, are a bit narrow if one uses longer variable names.
80 columns is still the minimum textwidth for terminals.
In addition, PEP 8 is purely suggestive, Python projects need not
strictly follow it.
The 79 char limit is about readability, not screen size. There is a
reason that almost every book, magazine and newspaper on the planet has
converged to something around 55-65 characters per line. It is the
biology of vision, not the size of the paper.
It doesn’t matter how wide your screen is, human vision is still the
same as it was 40 years ago, or 400 years ago. 55-65 characters for
prose text is close to optimum. Doubling that to 110 or 130 characters
is less readable, causing more eyestrain, no matter how enormous your
screen is.
Programming code is not quite the same as reading prose text arranged in
paragraphs, so we can extend that line width a little bit: 79 chars is
okay, since most lines won’t come even close to that limit. It’s even
okay to occasionally go over the limit by a few extra characters. But if
you are regularly hitting 90 or 100 columns, then your code probably has
problems:
- your code may be too deeply indented;
- you may be squeezing too many operations into a single line;
- (trying to do too much in one line – Python is not Perl!);
- that includes violating the Law of Demeter;
- or you may be using unnecessarily verbose variable and function names.
It is difficult to come up with code that cannot be improved and made
more readable by keeping to 79 characters. But don’t be a zealot though:
if you occasionally hit 81 or 82 characters, who cares?
Possibly the main exception I can think of is when you have a big table
of data in a list or dict formatted right there in the source code,
where keeping the data neatly formatted is more important than squeezing
it into 79 columns.
Another exception is, ironically, exceptions frequently exceed 79
columns, including the indent, “raise SomeException(long message…)”.
But for general code, if you are frequently exceeding 79 columns by a
lot, that is a strong sign that your code could probably be improved by
refactoring.
And if you disagree? Okay, you disagree. For your private software
projects, you can use any line width you want.
There are other reasons why many people prefer to stick with a line
width of 79 columns. That lets them put three files side-by-side, or two
files and the interpreter, without needing horizontal scroll.
8 Likes
[…]
This is an excellent point, and one I hadn’t thought about. I have
visual processing impairments, leading to comprehension challenges,
and had never connected that with my choice to stick to 80-column
terminals. I had just chalked it up to being nostalgic for my early
days on green-screen serial terminals, but it’s quite likely it’s a
coping mechanism on my part.
And in case it’s not clear, I too consider the 79-column suggestion
to still be relevant. There are plenty of people like me who, for
whatever reason, standardize on an 80-column display. If your code
is so deeply nested or uses such verbose object names that you
frequently need longer lines than that, you’re probably not
sufficiently decomposing your logic into more digestible chunks. The
occasional longer line is okay if you have some sort of token which
can’t be reliably split or you’re embedding literal samples in
comments or something, but if you can keep lines shorter that does
make things more readable for a lot of folks.
2 Likes
My first programming course used PL/I, and our code was submitted to IBM mainframes on these:
That limited us to a maximum of 80 characters per line quite effectively.
I still experience a sense of going astray as one of my lines of code approaches that length.
I’d prefer not to change the PEP for all the reasons given by @steven.daprano. I find myself appreciating shorter lines more and more as I bump up my font sizes to match my diopter evolution 
. Other than in the stdlib (for which PEP 8 was originally written, even if it’s been adopted more widely thesedays), it’s just a suggestion. My $work consistently overrides that. The downside to overriding is that there is no other standard. I’ve seen 120, 140, and even 160 line length overrides. Aside from the lack of standards (an institutional problem perhaps), I have a hard time believing 160 character wide lines are readable by anybody, in any IDE, on any screen.
3 Likes
Totally agree with Barry, but also wanted to mention that occasionally a 160 character line is a useful way to hide unimportant information. For example, a long error message intended for users, where the developer reading the code is fine to just skip over it, can be the difference between seeing all the code on a single screen and having to regularly scroll to get the actual meaning of the function.
“A Foolish Consistency is the Hobgoblin of Little Minds”
1 Like
Please allow me to give my 2 cents.
The reason why PEP 8 encourages Python developers to restrict the length of characters on a line to 79 is that whoever reads longer lines of code (whether a fellow developer or yourself) can get bored. No one wants to read looooong lines because our brain interprets it as yada yada, and also no one wants to scroll to the right. The human brain is very lazy and easily gets bored. That’s the nature of our brain. It’s how it is.
Even more, the human brain can get intimidated by such things as long lines of text. Imagine reading a book where you’d have 1 meter (~39 inches) of text per line. Would you read such a book?
The reason that shorter lines are preferred is because our brain pauses for a bit while the eyes are searching for the start of the second line of text, then the third line, and so on. More such pauses mean less brain intimidation.
Imagine a teacher who would never pause while teaching a school subject. Just yada yada yada, non-stop. Well, that would certainly melt your brain and you would remember absolutely nothing from that session. You might even begin to start hating the teacher, the school subject, or both.
In general, no one likes people that talk all the time.
What I’m trying to say is that our brain need to be spoon-fed with information. Anything more than that is immediately intimidating. Give the brain some time to swallow information.
Likewise, paragraphs in text were introduced just for this same reason: give the brain some time to process a chunk of information.
How would you feel if I haven’t given this reply any paragraphs? Your brain would immediately start screaming Blah blah blah, I’m not in the mood of reading this giant blob of text!
But if the structure is right, the overall text is appealing and invites people to read it. Also, images in text are there for the same reason: pause torturing the brain with text and give it something else than characters, give it some nice shapes and some appealing colors for it to relax on that, then it won’t be intimidated and will continue accepting more of the remaining textual information. The thing is that our brain is constantly bored and it needs to be entertained, yet not in a non-stop basis.
Why are the pauses good, you ask? Well, think of music. No music is considered good without its pauses between notes. Pauses create tension and contrast. That’s what makes it enjoyable.
Now, let’s talk some more about images, mentioned before. The thing is, we software developers can’t have images in computer code, so we compensate this brain entertainment part with shorter lines of code and also some blank lines to induce relaxing the brain. Who would read code that is crammed in one giant blob? I certainly wouldn’t. That’s why it is also recommended to have short functions (i.e., not too many lines of code in them, even though their length may be of 79 characters).
The nature of the human brain is such that it wants concise things, things that are short and simple. May it be short conversations by not stretching a certain topic to its death, or may it be short lines of computer code.
The reason for the 79-character restriction is psychological. We could call Guido van Rossum a psychologist. 
Why 79? Well, maybe it was discovered before Guido even proposed this in PEP 8 that this particular line length restriction is how long the human brain can last before it considers a line as being too long and boring. Maybe, not sure on that one.
I hope my reply was not too long for your brain to get intimidated. If you read it to this point, I salute you!
I do definitely agree with all the reasons said to motivate max line widths, but just for the sake of it, let’s still embrace that there are also advantages with long lines or even no line restrictions. Here are some from the top of my head:
-
Code is most often not read like a book as implied above. Many times, the start of the line is the most important when quickly scanning code. You see conditions and functions called, but don’t pay too much attention to all the parameters and the exact conditional logic until you find the area you are interested in.
-
Like mentioned above, it is a way to hide unimportant information. For example, a long error message intended for users (Ex:
raise HttpError(HTTPStatus.CONFLICT, 'User does yada yada yada...'). -
Searching in an IDE typically shows you the line of the search result, half a statement may not let you find what your are searching for.
-
Searching in IDE often supports regular expressions that are line based. Show me all
logger.debug(calls that may expose this or that data becomes a very hard exercise if lines are split. -
Most editors can introduce soft wraps, giving you line breaks fitting your exact desires. If you want to see three files in columns, 79 characters may even be too much. Adding soft wrap to a file with hard wrap at 79 will make the text harder to read of the soft wraps kicks in on n<79.
1 Like