Re: Policy for automated code reformatting?

[Jonas Hahnfeld]

Am Samstag, den 05.09.2020, 14:54 +0200 schrieb Jean Abou Samra:
> Hi,
> 
> We talked several times about automated code reformatting these times,
> the last instance being 
> https://gitlab.com/lilypond/lilypond/-/merge_requests/375.
> There is general agreement (I think) that we need some way of 
> maintaining the quality
> of Python code in particular. I feel it'd be hard to impose a certain 
> formatting tool
> to be run on each Merge Request. On the other hand, automated 
> reformattings, if not
> practised by everyone, affect other parts of the same file, which 
> doesn't facilitate
> review, and there is the git blame issue. I propose a compromise here, 
> with a policy to
> harmonize things a bit:
> 
>     New code is required to comply with the project's coding style; 
> older code *can* be
>     updated to follow this style. Developers *may* use ``fixcc``, 
> ``fixscm`` and ``autopep8``
>     to reformat code automatically as part of a Merge Request. In doing 
> so, developers *may*
>     reformat other parts of the same file that would otherwise be left 
> untouched by their
>     patch. In this case, the reformatting *must* be done in a separate 
> commit. Under normal
>     circumstances, reformattings *should* be limited to single files.
> 
> Rationale:
> - Those who so like can use these tools freely on the code they write.
> - Reviewers can review commits, so they may skip the reformatting.
> - There does not need to be a countdown just for the reformatting.
> - Don't hamper the usability of git blame too much, only reformat code 
> when it
>    is modified.
> 
> What do you think?

I think there's a policy for C++ formatting that we just run fixcc.py
from time to time, and the same happens for fixscm.py. We should do the
same for Python with autopep8. I certainly don't get the benefit of
introducing formatting changes into merge requests.

Jonas

signature.asc
Description: This is a digitally signed message part