Code formatting style.
m-kru opened this issue · comments
You use some custom style for formatting Python code. Your style differs significantly from PEP8. I know there is no obligation to format non core packages according to the PEP8, however a lot of developers use it and it is much easier to read new code if it has formatting style that you are used to.
Would you consider reformatting to PEP8?
A few years ago, Python changed it's own coding style to a style that does not reflect best practices and research for good coding style an fast text/code recognition. Thus, I do not follow all recommendation from PEP8.
If you have particular style rules, we can discuss or I can explain why I use it that way :).
Some PEP8 rules are also outdated like 80 characters per line. Since years we have 24" dual monitors :)
Btw. I also do not like that every language has it's own completely different set of coding style rules. When you work in >8 languages, this is a nightmare :).
@Paebbels, while I get your points, I think it is important to have any kind of automatic formatter. This is so useful for developers working in different projects, with different languages and different styles. I proposed using black
, which is a heavily opinionated formatter that will not let you take decissions. Should you not like that, there are other Python formatters available, which you can customize to fit your needs: https://www.kevinpeters.net/auto-formatters-for-python. Once any automatic formatter is used, it is up to each developer to customize the rules locally, as long as everything is converted to the default (through a hook?) before committing.
A few years ago, Python changed it's own coding style to a style that does not reflect best practices and research for good coding style an fast text/code recognition.
@Paebbels can you elaborate on this or point to some article that would reflect your opinion?
As I started Python years ago, Python sued mainly CamelCase style. You see it in old APIs and modules. Now it uses snake_case. There are studies showing, that text recognition in sourcecode is faster and also more accurate with CamelCase than other variants.
At the end it is important, that a project uses a coding style with discipline. That's what you'll find in my code, but it may not match all PEP8 rules :).
But still if you find parts in my code that look weird, I'm open for discussion (even if my option seems to be fixed and solid - I can be convinced based on arguments) and I'll explain my decisions :).
Yesterday I had a discussion with @eine about this example:
elif (isinstance(token, IndentationToken) and isinstance(token.PreviousToken, (LinebreakToken, SingleLineCommentToken))):
Yes, it's a long line, but is easier to understand then
elif (
isinstance(token, IndentationToken)
and
isinstance(
token.PreviousToken,
(LinebreakToken, SingleLineCommentToken)
)
):
The shown elif
is part of an if-statement with 8 branches. Currently, one parser state fits on a whole screen page. With the formatted version, it would need circa 3 screen pages. Thus a programmer can not overview a full state-change at once.