RFC: Exceptions to PEP-8 Adoption for RTEMS Tools

[Gedare Bloom]

On Wed, Mar 18, 2020 at 12:25 PM Amar Takhar <amar at rtems.org> 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.
>
Thank you for kicking off this discussion. As with most style issues,
a lot of personal preferences came out, but also some good reasoning
was given on both sides.

> 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.
>
Possibly, although as pointed out by others, some nasty Python can be
written in one line, especially if you allow nested list
comprehensions. There is certainly a balance to strike.

> 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

I do realize new/young developers use and enjoy long lines. I'm sure
this is a result of increasing screen sizes/resolutions over the last
2 decades. I understand it may bother such developers to adhere to
line length limits that seem arbitrary and arcane. However, reasons
given elsewhere for 80-character limit are also compelling. I see this
trend of relaxing the line limit as purely for the convenience of
personal preferences, other than the possible argument that breaking
apart long lines is more confusing than leaving them intact. That
argument I can't really debate or judge; it would make an interesting
study though.

> 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
>
Maybe. I sent a patch to do exactly that as a simple POC. I actually
think it is more readable with it split, since there is embedded
control flow in that long line.

> 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 understand this also. Hopefully we can find good ways to break apart
long lines or refactor long lines to several lines to reduce
confusion. In general I think we can all agree that simplicity reduces
confusion. That isn't to say shorter lines are simpler (e.g., some of
John Carmack's nasty C code), but they should encourage less
complexity on average I would imagine.

> 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.
>
One question raised, which is really valid, is whether existing
formatters/checkers can be easily configured to filter for this hybrid
rule on line length for source vs comments. But, since it seems the
majority vote is for 80-character limit, the question isn't terribly
relevant now.

> 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