RFC: Exceptions to PEP-8 Adoption for RTEMS Tools

Thu Mar 19 15:40:05 UTC 2020

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 <joel at rtems.org> wrote:
>
>
>
> On Thu, Mar 19, 2020 at 6:27 AM Thanassis Tsiodras (external) <Thanassis.Tsiodras at 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.Tsiodras at esa.int | www.esa.int
>> T +31 71 565 5332
>>
>>
>>
>> From:        "Sebastian Huber" <sebastian.huber at embedded-brains.de>
>> To:        "Christian Mauderer" <christian.mauderer at embedded-brains.de>, "Chris Johns" <chrisj at rtems.org>, "Christian Mauderer" <list at c-mauderer.de>, devel at rtems.org
>> Date:        19/03/2020 07:24
>> Subject:        Re: RFC: Exceptions to PEP-8 Adoption for RTEMS Tools
>> Sent by:        "devel" <devel-bounces at 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 at 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 (dpo at esa.int).
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel