On Tue, Feb 19, 2019 at 05:37:29AM +0100, Simon wrote:
> Hello,
>
> I'd like to propose an update to PEP8. Indeed, the 80 characters per line
> guideline is, I feel, outdated.
I know this is not precisely what you are arguing, but the thought of
people arguing that the only problem with a 300-character Perl one-liner
is that their monitor is too narrow to view it amuses me :-)
> I understand the need for it, back when monitors were small, and everyone
> coded on terminals, but nowadays, I feel like that guideline is more of a
> hinderance, and that it promotes poor code.
The width of source code on old green-screen 80 column terminals may be
a factor, but it probably isn't the most important factor. You might
consider that even when broadsheet newspapers have up to 23 inches in
width, they still format their text in much narrower columns.
The typical line of text in a paperback is 60-70 characters including
spaces. We have many centuries of experience teaching us that 60-70
columns of text is typically as wide as people can comfortably read.
I'm not an expert, but my understanding is that the limiting factor is
not so much the cognitive burden of reading 100+ characters but the
physical motion of the eyes tracking back and forth across the long
lines. The wider the line, the greater the chances that the eye will run
off one line into the one below it, and the more eye-strain.
Source code isn't as dense as prose, and is more line-oriented than
paragraph-oriented, so we can afford to exceed 70 columns occasionally,
but not too often. If people are regularly exceeding 80 columns, I would
consider it a code smell and inspect the code carefully for these
problems:
- indents may be too wide (8 spaces instead of 4?);
- code may be too deeply nested (too many indents);
- variable names may be excessively long;
- possibly too many violations of the Law of Demeter:
paperboy.take_fee(customer.trousers.right_pocket.get_wallet().remove(fee))
- or just generally, too much complexity per line.
> Indeed, people abiding by this rule tend to choose shorter variable names,
> reduce the amount of indentation, and other tricks to just keep the
> character count under 80.
Do we? That's a rather sweeping generalisation. It may be true in some
cases, but in other cases, the discipline of keeping to the 79 column
limit can result in better code.
But don't go mad about it: Raymond Hettinger did a very good talk called
"Beyond PEP 8" which (correctly in my opinion) argues against worrying
about small violations of PEP 8, in favour of more substantial efforts
to beautify your code.
https://www.youtube.com/watch?v=wf-BqAjZb8M
In my own code, I take the 79 column limit as more of a guideline than a
law, if I have to go over by 2 or 3 characters, I just do it and don't
worry unless it is a more substantial violation.
All those "tricks" you mention are not necessarily bad things, they can
often be justified. If you have a function or method with eight levels
of indentation, you probably should reduce the amount of indentation by
refactoring. If you have variables like number_of_pages_in_current_section
you probably should consider a shorter name. Your IDE may make it easy
to write such long names, but it doesn't make it easy to read them.
--
Steven
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
