[Top][All Lists]

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

Policy for automated code reformatting?

From: Jean Abou Samra
Subject: Policy for automated code reformatting?
Date: Sat, 5 Sep 2020 14:54:45 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0


We talked several times about automated code reformatting these times,
the last instance being 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.

- 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?


reply via email to

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