RFC: Exceptions to PEP-8 Adoption for RTEMS Tools

Thu Mar 19 11:27:06 UTC 2020

> 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..

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).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200319/3e6f0212/attachment.html>