I propose to forbid any white-space changes and reformatting in existing code - with the sole exception of "severe" cases. Even if a line is changed, the code should not be reformatted beyond what is required to keep the code in good style.
The development-guideline will get a statement like this:
Commits including white-space changes or reformatting will not be accepted. This is also true for commits consisting of only white-space changes or reformatting. The only exceptions are "severe" formatting issues or issues in strings. For rational please refer to issue #…(this one)
We try to enforce this rule.
We try to enforce some white-space rules (e.g. newline at end of file, no while-space at end of line).
We verify code-quality of any change. Only a few rules should be enforced here, since code-formatting often depends on
All of the aforementioned checks should be done as early as possible (using a hook, some online service or whatever).
Currently we accept white-space changes and reformatting, as long as they are kept in separate commits – as written in the development guideline. Some reasons for changing this rule:
Time-consuming: It's time-consuming to review these commit and verify they are non-functional changes only.
Makes it hard to merge or rebase: Every unrelated change makes it harder to merge the pull-request or to rebase the commits. Smaller commits contain less conflicts and conflicts are easier to solve in smaller commits.
Bad in the long-run: Experience shows, that in the long-run both of these change make it hard to follow changes:
In git blame the "last change" for the lines effected will be a non-functional change. If one wants to know "Why has this line been changed?", he/she would need step through reformatting and white-space changes. This is simply one thing: disgusting. This can be eased a bit by using gut gui blame or the github weg-ui, but it still adds additional steps.
The same is true when using git log -p ot git log --grep, since these will yield additional entries which do not help to understand the code.
There is no need for re-formatting again: PyInstaller's code quality and formatting are quite acceptable already. Larger re-formatting has been done in the past, so there is no urgent need for another re-formatting. The only thing I'm aware are some long lines, but all I'm aware of are still within an acceptable range.
PEP-8 is a recommendation: PEP-8 is an important document, but it's only a recommendation, and often it recommends several alternatives. We already follow PEP-8, but obeying PEP-8 only for PEP-8's sake is idiocy. This would upraise PEP-8 to some kind of religious rule.
Experience shows that often the code is easier to understand when not strictly following PEP-8.
If we'd want to enforce a concrete formatting style, we'd need to provide a .pylint file (or something like this) defining our rules. Otherwise each developer would have his/her own notion of the "correct" formatting style. But again: This can only be recommendations.
Why should the code be reformatted at all?
Other project have this policy, too. I contributed reformatting changes to some other projects and they have been rejected. (Sorry, I can't remember which ones this have been.)
Why not simply accept white-space changes and reformatting?
Why not run a reformatting all over the code once (and forever)?
We already did this several times, see git log --grep PEP8 -- PyInstaller.
The text was updated successfully, but these errors were encountered: