I find that 100 to 120 characters is ideal as far as line length goes. In my opinion, splitting lines is much worse in terms of cognitive burden than just a longer line. On top of that, it's not uncommon to reach 6, even 7 indentation levels. All it takes is a loop in a loop (looping through an array for instance), a condition and all of that inside a class' method. Just in that example, which is a very common occurence, an doesn't warrant refactoring, there is 5 indentation level, eg a quarter of the recommended line length. Defining decorators also goes up there in terms of number of indents by the way. As far as monitor size goes, I agree that on a laptop is not ideal for 100+ characters per line if you want two pieces of code side by side. And, fyi, I work on a 23" monitor at home and on a 15.6" monitor on the go. Both are perfectly fine with 100 characters a line. A good middle ground would be to enforce customization of that rule in the most used python linters. A simple setting to set the number of characters before a linting warning occurs would be acceptable. Envoyé depuis mon smartphone Samsung Galaxy. -------- Message d'origine --------De : David Mertz <me...@gnosis.cx> Date : 19/02/2019 07:28 (GMT+01:00) À : Anders Hovmöller <bo...@killingar.net> Cc : Simon <simon.borde...@gmail.com>, python-ideas <python-ideas@python.org> Objet : Re: [Python-ideas] PEP 8 update on line length 60, or 68, or 80 characters, is not per se a cognitive limit. Yes, sure whitespace counts much less towards that burden than do regular characters. And to a significant degrees, punctuation vs. letters vs. numbers matter. And sure familiar words such as keywords scan a bit easier than unfamiliar names of variables. And so on.But 80 characters in general is already too wide most of the time. 65 is a better goal as a rule of thumb, with 80 already being for exceptionally long lines. Python keywords are already short, there's not much improvement to be had there. Saving two characters for acryptic WHL isn't better than the word 'while', for example.Pretty much the only time my code how's more than 80 characters is when it includes string literally that occupy a large chunk of the width. But if that 50 character string is the last argument of a function call, the reader can mostly stop scanning at it's beginning, so it's not terrible. When I have many keyword arguments, I break them into multiple physical lines using parents too continue the logical line. Or if I have complex compound conditions, I give the subclauses short but descriptive names before the if/elif.On Tue, Feb 19, 2019, 1:11 AM Anders Hovmöller <bo...@killingar.net wrote:
> On 19 Feb 2019, at 05:48, David Mertz <me...@gnosis.cx> wrote: > > You either have much better eyes to read tiny fonts than I do, or maybe a > much larger monitor (it's hard for me to fit a 30"" monitor in my laptop bag). > > But that's not even the real issue. If the characters were in giant letters > on billboards, I still would never want more than 80 of them on a line (well, > rarely, I violate PEP 8 sometimes). Centuries if not millennia of experience > with writing show that cognitive burden goes up exponentially, not linearly, > as lines get to be more than about 60 characters. If that is the issue then we should be talking about non-space characters, not a 68 column limit right? No way does 40 spaces due to indent count towards the cognitive burden :) Also, if the cognitive burden is the issue then we should talk about short forms for keyword arguments again. The way the 68 column limit works in practice is that people avoid keyword arguments because of line length, plus the issues already mentioned. / Anders
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
