On 8/10/2017 5:30 PM, Brandon Williams wrote:
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
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.
Just adding my "Yes!" vote.
Consistent formatting makes the code easier to read and maintain. I've
been in religious wars debating whether the opening brace should be on
the same line or the next line and while I have my personal preferences,
I can work with just about anything as long as it is consistent. When it
comes to dealing with a tool, I am willing to live with some "I would
have wrapped that differently" if I can stop spending so much time
manually wrapping code.
I think the goals should be to 1) increase readability of the code 2)
reduce the time spent by reviewers and 3) reduce the time spent by
contributors. A pre-commit hook that checked for errors (and gave the
instructions on how to automatically have the tool correct them) would
be very helpful.
Please continue to push this forward!
