lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Policy for automated code reformatting?


From: Jonas Hahnfeld
Subject: Re: Policy for automated code reformatting?
Date: Sat, 05 Sep 2020 15:08:50 +0200
User-agent: Evolution 3.36.5

Am Samstag, den 05.09.2020, 15:03 +0200 schrieb 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.

Nah, that was ambiguous: I don't see the benefit of introducing
*automated* formatting changes in *unrelated* parts of a file into
reviewed merge requests. Even in a separate commit, that still comes
with disadvantages for the bot trying to understand if there was a
change between two versions of a merge request.
Warning about modified parts that don't follow the style might be a
good addition. For everything else, just running the tools once in a
while should do the job.

Jonas

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]