RFC: Exceptions to PEP-8 Adoption for RTEMS Tools

[Christian Mauderer]

Hello Amar,

On 18/03/2020 19:24, Amar Takhar wrote:
> The only one I would like to propose is the 80 character limit.  This should be 
> moved to something more reasonable such as 120.
> 
> Code comments should remain below 80 however.
> 

I'm not a big fan of long lines (reason further below) but I won't block
it either. But what I think is really a bad idea is to have different
rules for different parts of the code.

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. At least it
have been 80 chars since at least punch hole cards:

https://softwareengineering.stackexchange.com/questions/148677/why-is-80-characters-the-standard-limit-for-code-width#148678


PPS: Also note one of the first rules in PEP-008: "A Foolish Consistency
is the Hobgoblin of Little Minds":
https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds

It explicitly tells you to not follow the standard if your code gets
less readable by doing it. So if we only have few cases with long lines,
we can use exceptions and it is conform to PEP-008. Of course it might
could be tricky to tell our tools that this line is an exception.


Best regards

Christian

> Python itself has not followed this rule for a long time you can see many lines 
> over 80 in the Python source itself.
> 
> Also, due to the nature of the language most lines end up below 80 characters 
> anyway.  Python is not an easy language to read when you have to break long 
> lines into 2 especially when you start breaking up strings.
> 
> I'm with most of the developers here -- 80 characters as been the norm for a 
> very long time however this is no longer true for new developers.  There are 
> already examples in our own rtems-tool codebase that make no sense being split:
> 
>   https://git.rtems.org/rtems-tools/tree/rtemstoolkit/execute.py?id=274981f77d648ceb87f84cdeaec33a58dfd37385#n579
> 
> I've ran into this more than once where a Python developer ends up in confusion 
> when reading source that has line breaks to keep under line lengths.
> 
> I'd like to go the direction the wind is blowing on this and relax this rule to 
> 120 for source, 80 for documentation where possible.
> 
> This is of course applied to cases where leaving the line long makes sense.  A 
> function with 20 parameters shouldn't be in a long line that is a disaster in 
> any language.
> 
> 
> Amar.
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>