Re: [RFC] clang-format: outline the git project's coding style

> On 08/10, Junio C Hamano wrote:
>> Brandon Williams <bmwill@google.com> 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
>> imagine.
>>
>>> 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.
>