<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 19, 2020 at 6:27 AM Thanassis Tsiodras (external) <<a href="mailto:Thanassis.Tsiodras@esa.int">Thanassis.Tsiodras@esa.int</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:10pt;font-family:sans-serif"><i>> I think we
should stay with the traditional 80 characters per line.</i></span>
<br>
<br><span style="font-size:10pt;font-family:sans-serif">Seconded. </span>
<br>
<br><span style="font-size:10pt;font-family:sans-serif"><rant></span>
<br>
<br><span style="font-size:10pt;font-family:sans-serif">When I was younger
I thought this was a silly requirement, a remnant from the age of serial
terminals....</span>
<br><span style="font-size:10pt;font-family:sans-serif">So I allowed myself
to relax these checks - and indeed, the tools allow developers to do so.</span>
<br>
<br><span style="font-size:10pt;font-family:sans-serif">But with experience,
I realised the side effects - and in reverse, the positive impact this
limit has on the code and its maintainability...</span>
<br><span style="font-size:10pt;font-family:sans-serif">It forces people
to avoid writing lengthy one-liners that only they themselves comprehend....
(<i>and given the power of Python's expressiveness, this can become quite
an issue, real fast</i>)</span>
<br><span style="font-size:10pt;font-family:sans-serif">It e.g. forces
the introduction of "interim" variables, holding interim results
of a big computation... instead of huge expressions with insane nesting
levels.</span>
<br>
<br><span style="font-size:10pt;font-family:sans-serif"></rant></span>
<br>
<br><span style="font-size:10pt;font-family:sans-serif">My vote is on
PEP8 as-is - that is, 80 columns..</span>
<br></blockquote><div><br></div><div>Agreed. 80 columns.</div><div><br></div><div>As discussed, there are multiple reasons for this, some of which are historical. </div><div>When I started, there was a recommendation that function bodies fit on a screen</div><div>as well (try to stay less than 25 lines). That has disappeared but we still try to</div><div>write small methods or at least blocks within a function.</div><div><br></div><div>People also forget that sometimes you want to print (more rarely now) or include </div><div>code as an example in a manual or presentation. Anything over 80 is hideous in</div><div>those modes.</div><div><br></div><div>Books tend to have lines which are approximately this length. Wider paper tends</div><div>to go to columns. There are human factors. I can't cite studies but I would </div><div>contend that longer lines are harder for a human to parse and understand.</div><div><br></div><div>But as Chris stated, the most common reason is the one we both share.</div><div>Multiple terminals side by <a href="http://side.is">side.is</a> by far the most common use case.</div><div><br></div><div>If we want hideous code, let's rewrite RTEMS as one-line of Perl <sarcasm></div><div><br></div><div>--joel</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br><span style="font-size:10pt;color:rgb(0,0,128);font-family:sans-serif"><b>Thanassis
Tsiodras</b></span>
<br><span style="font-size:10pt;font-family:sans-serif">Real-time Embedded
Software Engineer </span>
<br><span style="font-size:10pt;font-family:sans-serif">System, Software
and Technology Department</span>
<br>
<br><span style="font-size:10pt;font-family:sans-serif"><b>ESTEC</b></span>
<br><span style="font-size:10pt;font-family:sans-serif">Keplerlaan 1,
PO Box 299</span>
<br><span style="font-size:10pt;font-family:sans-serif">NL-2200 AG Noordwijk,
The Netherlands</span>
<br><span style="font-size:10pt;font-family:sans-serif"><a href="mailto:Thanassis.Tsiodras@esa.int" target="_blank">Thanassis.Tsiodras@esa.int</a>
| </span><a href="http://www.esa.int" target="_blank"><span style="font-size:10pt;color:blue;font-family:sans-serif">www.esa.int</span></a>
<br><span style="font-size:10pt;font-family:sans-serif">T +31 71 565 5332</span>
<br>
<br>
<br>
<br><span style="font-size:9pt;color:rgb(95,95,95);font-family:sans-serif">From:
</span><span style="font-size:9pt;font-family:sans-serif">"Sebastian
Huber" <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>></span>
<br><span style="font-size:9pt;color:rgb(95,95,95);font-family:sans-serif">To:
</span><span style="font-size:9pt;font-family:sans-serif">"Christian
Mauderer" <<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>>, "Chris
Johns" <<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>>, "Christian Mauderer" <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>,
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a></span>
<br><span style="font-size:9pt;color:rgb(95,95,95);font-family:sans-serif">Date:
</span><span style="font-size:9pt;font-family:sans-serif">19/03/2020
07:24</span>
<br><span style="font-size:9pt;color:rgb(95,95,95);font-family:sans-serif">Subject:
</span><span style="font-size:9pt;font-family:sans-serif">Re:
RFC: Exceptions to PEP-8 Adoption for RTEMS Tools</span>
<br><span style="font-size:9pt;color:rgb(95,95,95);font-family:sans-serif">Sent
by: </span><span style="font-size:9pt;font-family:sans-serif">"devel"
<<a href="mailto:devel-bounces@rtems.org" target="_blank">devel-bounces@rtems.org</a>></span>
<br>
<hr noshade>
<br>
<br>
<br><span style="font-size:12pt">On 19/03/2020 07:07, Christian Mauderer
wrote:</span>
<br><tt><span style="font-size:12pt">I think we will have a really hard
time to set up tools like formatters<br>
or pylint to check and use these rules. I think setting a line length to<br>
120 should be easy to possible for nearly any tool. But I expect that<br>
setting it to 120 for code and 80 for comments can be _very_ difficult<br>
depending on the tool.<br>
<br>
<br>
PS: Reason for me being not a fan of long lines: While programming I<br>
often use a split window. In that configuration my editor can show 112<br>
columns in each window on my current screen. That fits well for nearly<br>
all code that follows the 80 character convention. But for example your<br>
proposed length of 120 the code will lead to either a smaller font, a<br>
lot of random line breaks done by the editor or to loosing one window.<br>
Again: It's not a strong opinion and I'll accept 120 too. But expect<br>
that some others have stronger opinions about 80 characters.<br>
</span></tt>
<br><tt><span style="font-size:12pt">I run everything in text mode under
tmux and in Emacs I split vertically and<br>
variable length is painful and prefer we settle on 80.<br>
</span></tt>
<br><tt><span style="font-size:12pt">Maybe let's wait whether there are
more opinions. Currently we have<br>
<br>
- one clear vote for 120 lines (Amar)<br>
- one clear vote for 80 lines (Chris)<br>
- one a bit undecided with tendency to shorter lines (myself)</span></tt>
<br><span style="font-size:12pt">I think we should stay with the traditional
80 characters per line. It is also recommended by the Google Python Style
Guide:</span>
<br><a href="http://google.github.io/styleguide/pyguide.html#32-line-length" target="_blank"><span style="font-size:12pt;color:blue"><u>http://google.github.io/styleguide/pyguide.html#32-line-length</u></span></a>
<br><span style="font-size:12pt">It allows some exceptions which all make
sense from my point of view.</span>
<br><tt><span style="font-size:10pt">_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
</span></tt><a href="http://lists.rtems.org/mailman/listinfo/devel" target="_blank"><tt><span style="font-size:10pt">http://lists.rtems.org/mailman/listinfo/devel</span></tt></a>
<br>
<br><pre>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 (<a href="mailto:dpo@esa.int" target="_blank">dpo@esa.int</a>).
</pre>_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>