Re: [RFC] clang-format: outline the git project's coding style
- Date: Thu, 10 Aug 2017 14:30:13 -0700
- From: Brandon Williams <bmwill@xxxxxxxxxx>
- Subject: Re: [RFC] clang-format: outline the git project's coding style
On 08/10, Junio C Hamano wrote:
> Brandon Williams <bmwill@xxxxxxxxxx> writes:
> > On 08/10, Junio C Hamano wrote:
> >> I vaguely recall that there was a discussion to have SubmitGit wait
> >> for success from Travis CI; if that is already in place, then I can
> >> sort of see how it would help individual contributors to have the
> >> style checker in that pipeline as well.
> >> I have a mixed feelings about "fixing" styles automatically, though.
> > I still think we are far away from a world where we can fix style
> > automatically. If we do want to keep pursuing this there are a number
> > steps we'd want to take first.
> > 1. Settle on a concrete style and document it using a formatter's rules
> > (in say a .clang-format file). This style would most likely need to
> > be tuned a little bit, at least the 'Penalty' configuration would
> > need to be tuned which (as far as I understand it) is used to
> > determine which rule to break first to ensure a line isn't too long.
> Yes. I think this is what you started to get the ball rolling.
> Together with what checkpatch.pl already diagnoses, I think we can
> get a guideline that is more or less reasonable.
> > 2. Start getting contributors to use the tool to format their patches.
> > This would include having some script or hook that a contributor
> > could run to only format the sections of code that they touched.
> This, too. Running checkpatch.pl (possibly combined with a bit of
> tweaking it to match our needs) already catches many of the issues,
> so a tool with a similar interface would be easy to use, I would
> > 3. Slowly the code base would begin to have a uniform style. At
> > some point we may want to then reformat the remaining sections of the
> > code base. At this point we could have some automated bot that fixes
> > style.
> I suspect I am discussing this based on a different assumption.
> I think the primary goal of this effort is to make it easier to
> cleanse the new patches that appear on the list of trivial style
> issues, so that contributors and reviewers do not have to spend
> bandwidth and brain cycles during the review. And I have been
> assuming that we can do so even without waiting for a "tree wide"
> code churn on existing code to complete.
Yes that's one of the steps I missed we can call it 2.5 ;) (3) could be
a long term goal which is what I was trying to get at by saying:
> > 3. Slowly the code base would begin to have a uniform style.