Closed jayvdb closed 8 years ago
AFAIK (a user here) green
currently has no published coding style.
It has no checks on commit for it (travis
).
That means it has lots of different pep8
/pyflake
/flake8
style errors as can be seen from the ignored error list in your patch.
I think the next step would be choosing a coding style and adjusting the code/infrastructure for it.
Could you provide some argument why is covering up yet unknown stylistic errors important at this point?
This PR, using flake8-putty, provides the maintainers with a tool to decide which pep8 rules (and flake8 extensions) should be ignored globally as undesirable, with exceptions for specific cases where the desirable rules should be ignored.
This patch provides a clearly documented list of existing 'violations' in a way that they can be discussed.
I've pre-selected a global ignore list for codes which appear to be undesirable based on existing coding style. I am more than happy to amend this patch as required to match the maintainers rough coding style preferences.
This approach allows the gradual improvement of coding style, instead of large numbers of style-only changes to immediately implement a coding style. If the maintainers would prefer a big bang approach to adopting a coding style, I am happy to abandon this. If the maintainers dont want to pick a coding style, then they can close this.
My reason for initiating this PR (and creating the flake8 extensions) is that I find it a waste of my time to contribute large patches to projects without any clear direction on coding style. As I'd like to contribute to the project, I'd prefer to get some baseline decisions in place regarding coding style.
Records existing errors per file, for many common flake8 plugins, preventing new flake8 errors.