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

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

 



Hi,

On Tue, 8 Aug 2017, Brandon Williams wrote:

> On 08/08, Stefan Beller wrote:
> > On Tue, Aug 8, 2017 at 5:05 AM, Johannes Schindelin
> > <Johannes.Schindelin@xxxxxx> wrote:
> > > Hi Brandon,
> > >
> > > On Mon, 7 Aug 2017, Brandon Williams wrote:
> > >
> > >> Add a '.clang-format' file which outlines the git project's coding
> > >> style.  This can be used with clang-format to auto-format .c and .h
> > >> files to conform with git's style.
> > >>
> > >> Signed-off-by: Brandon Williams <bmwill@xxxxxxxxxx>
> > >> ---
> > >>
> > >> I'm sure this sort of thing comes up every so often on the list but back at
> > >> git-merge I mentioned how it would be nice to not have to worry about style
> > >> when reviewing patches as that is something mechanical and best left to a
> > >> machine (for the most part).
> > >
> > > Amen.
> > >
> > > If I never have to see a review mentioning an unwrapped line, I am quite
> > > certain I will be quite content.
> > >
> > > Ciao,
> > > Dscho
> > 
> > As a thought experiment I'd like to propose to take it one step further:
> > 
> >   If the code was formatted perfectly in one style such that a formatter for
> >   this style would not produce changes when rerun again on the code, then
> >   each individual could have a clean/smudge filter to work in their preferred
> >   style, and only the exchange and storage of code is in a mutual agreed
> >   style. If the mutually agreed style is close to what I prefer, I don't have to
> >   use clean/smudge filters.
> > 
> > Additionally to this patch, we'd want to either put a note into
> > SubmittingPatches or Documentation/gitworkflows.txt to hint at
> > how to use this formatting to just affect the patch that is currently
> > worked on or rather a pre-commit hook?
> 
> I'm sure both of these things will probably happen if we decide to make
> use of a code-formatter.  This RFC is really just trying to ask the
> question: "Is this something we want to entertain doing?"
> My response would be 'Yes' but there's many other opinions to consider
> first :)

I am sure that something even better will be possible: a Continuous
"Integration" that fixes the coding style automatically by using
`filter-branch` (avoiding the merge conflicts that would arise if `rebase
-i` was used).

Ciao,
Dscho



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux