Giters

Paebbels / pyVHDLParser

Streaming based VHDL parser.

Home Page:https://paebbels.github.io/pyVHDLParser/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Code formatting style.

m-kru opened this issue · comments

commented

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?

commented

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

commented

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

commented

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?

commented

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