Hi all, I think the consensus is forming to have 80-character line limits as per PEP-8. So far I only heard 1 vote in favor of anything else, with several in favor of 80 characters and some abstaining to vote.
FWIW: I strongly prefer 80-character lines as well, both for readability and maintainability. So the line length exception will not be adopted, except as pointed out by Sebastian there are good reasons to break that rule. The Google Style guide lists some reasonable exceptions and also provides guidance how to break up longer lines. Gedare On Thu, Mar 19, 2020 at 9:25 AM Joel Sherrill <j...@rtems.org> wrote: > > > > On Thu, Mar 19, 2020 at 6:27 AM Thanassis Tsiodras (external) > <thanassis.tsiod...@esa.int> wrote: >> >> > I think we should stay with the traditional 80 characters per line. >> >> Seconded. >> >> <rant> >> >> When I was younger I thought this was a silly requirement, a remnant from >> the age of serial terminals.... >> So I allowed myself to relax these checks - and indeed, the tools allow >> developers to do so. >> >> But with experience, I realised the side effects - and in reverse, the >> positive impact this limit has on the code and its maintainability... >> It forces people to avoid writing lengthy one-liners that only they >> themselves comprehend.... (and given the power of Python's expressiveness, >> this can become quite an issue, real fast) >> It e.g. forces the introduction of "interim" variables, holding interim >> results of a big computation... instead of huge expressions with insane >> nesting levels. >> >> </rant> >> >> My vote is on PEP8 as-is - that is, 80 columns.. > > > Agreed. 80 columns. > > As discussed, there are multiple reasons for this, some of which are > historical. > When I started, there was a recommendation that function bodies fit on a > screen > as well (try to stay less than 25 lines). That has disappeared but we still > try to > write small methods or at least blocks within a function. > > People also forget that sometimes you want to print (more rarely now) or > include > code as an example in a manual or presentation. Anything over 80 is hideous in > those modes. > > Books tend to have lines which are approximately this length. Wider paper > tends > to go to columns. There are human factors. I can't cite studies but I would > contend that longer lines are harder for a human to parse and understand. > > But as Chris stated, the most common reason is the one we both share. > Multiple terminals side by side.is by far the most common use case. > > If we want hideous code, let's rewrite RTEMS as one-line of Perl <sarcasm> > > --joel >> >> >> Thanassis Tsiodras >> Real-time Embedded Software Engineer >> System, Software and Technology Department >> >> ESTEC >> Keplerlaan 1, PO Box 299 >> NL-2200 AG Noordwijk, The Netherlands >> thanassis.tsiod...@esa.int | www.esa.int >> T +31 71 565 5332 >> >> >> >> From: "Sebastian Huber" <sebastian.hu...@embedded-brains.de> >> To: "Christian Mauderer" <christian.maude...@embedded-brains.de>, >> "Chris Johns" <chr...@rtems.org>, "Christian Mauderer" <l...@c-mauderer.de>, >> devel@rtems.org >> Date: 19/03/2020 07:24 >> Subject: Re: RFC: Exceptions to PEP-8 Adoption for RTEMS Tools >> Sent by: "devel" <devel-boun...@rtems.org> >> ________________________________ >> >> >> >> On 19/03/2020 07:07, Christian Mauderer wrote: >> I think we will have a really hard time to set up tools like formatters >> or pylint to check and use these rules. I think setting a line length to >> 120 should be easy to possible for nearly any tool. But I expect that >> setting it to 120 for code and 80 for comments can be _very_ difficult >> depending on the tool. >> >> >> PS: Reason for me being not a fan of long lines: While programming I >> often use a split window. In that configuration my editor can show 112 >> columns in each window on my current screen. That fits well for nearly >> all code that follows the 80 character convention. But for example your >> proposed length of 120 the code will lead to either a smaller font, a >> lot of random line breaks done by the editor or to loosing one window. >> Again: It's not a strong opinion and I'll accept 120 too. But expect >> that some others have stronger opinions about 80 characters. >> >> I run everything in text mode under tmux and in Emacs I split vertically and >> variable length is painful and prefer we settle on 80. >> >> Maybe let's wait whether there are more opinions. Currently we have >> >> - one clear vote for 120 lines (Amar) >> - one clear vote for 80 lines (Chris) >> - one a bit undecided with tendency to shorter lines (myself) >> I think we should stay with the traditional 80 characters per line. It is >> also recommended by the Google Python Style Guide: >> http://google.github.io/styleguide/pyguide.html#32-line-length >> It allows some exceptions which all make sense from my point of view. >> _______________________________________________ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel >> >> This message is intended only for the recipient(s) named above. It may >> contain proprietary information and/or >> protected content. Any unauthorised disclosure, use, retention or >> dissemination is prohibited. If you have received >> this e-mail in error, please notify the sender immediately. ESA applies >> appropriate organisational measures to protect >> personal data, in case of data privacy queries, please contact the ESA Data >> Protection Officer (d...@esa.int). >> >> _______________________________________________ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
