git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 1/2] clang-format: outline the git project's coding style

From
BWBrandon Williams <bmwill@google.com>
Date
Aug 15, 2017, 17:37 UTC
Message-ID
<20170815173735.GB21874@google.com>
In-Reply-To
<41c8c119-af98-f16f-1585-81b29429afe8@gmail.com>
On 08/15, Ben Peart wrote:
Show 59 quoted lines
> 
> 
> On 8/14/2017 6:02 PM, Stefan Beller wrote:
> >On Mon, Aug 14, 2017 at 2:30 PM, Brandon Williams <bmwill@google.com> 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@google.com>
> >
> >Applying this patch and running
> >     clang-format -i -style file *.c *.h builtin/*.c
> >produces a diff, that I'd mostly agree with.
> >This style guide is close to our current style.
> >
> 
> I'm happy to see progress being made in helping reduce the time
> spent manually reviewing and fixing style formatting errors.  In an
> effort to help, I installed this in Windows and tried it as well.
> The tools all appear to be working fine and are supported on
> Windows.
> 
> For the most part, the formatting rules look pretty consistent with
> the existing style.  I ran the same test and looked at the diffs and
> saw a couple of things that looked odd. For example, how it wrapped
> the "static int" on the function header below was different.  Not
> sure why as it didn't wrap all the other function headers the same
> even later in the file it didn't do that with "static void
> mute_routine"
> 
> diff --git a/apply.c b/apply.c
> index f2d599141d..bb77242e3d 100644
> --- a/apply.c
> +++ b/apply.c
> @@ -58,12 +59,11 @@ static int parse_whitespace_option(struct
> apply_state *state, const char *option
>         return error(_("unrecognized whitespace option '%s'"), option);
>  }
> 
> -static int parse_ignorewhitespace_option(struct apply_state *state,
> -                                                const char *option)
> +static int
> +parse_ignorewhitespace_option(struct apply_state *state, const char
> *option)
>  {
> -       if (!option || !strcmp(option, "no") ||
> -           !strcmp(option, "false") || !strcmp(option, "never") ||
> -           !strcmp(option, "none")) {
> +       if (!option || !strcmp(option, "no") || !strcmp(option, "false") ||
> +           !strcmp(option, "never") || !strcmp(option, "none")) {
>                 state->ws_ignore_action = ignore_ws_none;
>                 return 0;
>         }
> 
> 
> Later in the file it wraps some of them again: (add_line_info,
> prepare_image, find_name_common, etc).  Again, it appears to be
> inconsistent but there must be some rule that is causing this
> behavior.

These have to deal with setting the penalties. When a line gets to be too long the tool needs to find a place to break the line based on a penalty system. The current .clang-format file I sent out has values for the penalties which would most likely need to be tweaked through trial and error.

Show 18 quoted lines
> 
> 
> 
> Here is an example of how it wrapped bit fields differently.  Again,
> it didn't seem to be consistent with itself as just below this, it
> left them on separate lines.
> 
> 
> @@ -182,8 +185,7 @@ struct fragment {
>          * but some codepaths store an allocated buffer.
>          */
>         const char *patch;
> -       unsigned free_patch:1,
> -               rejected:1;
> +       unsigned free_patch : 1, rejected : 1;
>         int size;
>         int linenr;
>         struct fragment *next;

If the return type was replicated then it would probably format the different struct members on their own line.

Show 12 quoted lines
> 
> 
> Big thanks to those working on this!
> 
> >As noted in patch 2/2 we'd now need an easy way to
> >expose this for use in various situations, such as
> >* contributor wanting to format their patch
> >* reformatting code for readability
> >
> >Thanks,
> >Stefan
> >
-- 
Brandon Williams
Previous: Ben PeartNext: Jeff King
Message 50 of 64 in “[RFC] clang-format: outline the git project's coding style”
  1. Brandon WilliamsAug 8, 2017
  2. Johannes SchindelinAug 8, 2017
  3. Stefan BellerAug 8, 2017
  4. Brandon WilliamsAug 8, 2017
  5. Johannes SchindelinAug 9, 2017
  6. Stefan BellerAug 9, 2017
  7. Johannes SchindelinAug 10, 2017
  8. Junio C HamanoAug 10, 2017
  9. Brandon WilliamsAug 10, 2017
  10. Junio C HamanoAug 10, 2017
  11. Brandon WilliamsAug 10, 2017
  12. Ben PeartAug 11, 2017
  13. Johannes SchindelinAug 14, 2017
  14. Johannes SchindelinSep 28, 2017
  15. Brandon WilliamsSep 28, 2017
  16. Junio C HamanoAug 8, 2017
  17. Brandon WilliamsAug 8, 2017
  18. Junio C HamanoAug 8, 2017
  19. Junio C HamanoAug 9, 2017
  20. Brandon WilliamsAug 11, 2017
  21. Junio C HamanoAug 11, 2017
  22. Jeff KingAug 9, 2017
  23. Ævar Arnfjörð BjarmasonAug 9, 2017
  24. Stefan BellerAug 9, 2017
  25. Stefan BellerAug 9, 2017
  26. Jeff KingAug 9, 2017
  27. brian m. carlsonAug 15, 2017
  28. Jonathan NiederAug 15, 2017
  29. Brandon WilliamsAug 11, 2017
  30. Jeff KingAug 11, 2017
  31. Junio C HamanoAug 12, 2017
  32. Jeff KingAug 13, 2017
  33. Ramsay JonesAug 13, 2017
  34. Ramsay JonesAug 13, 2017
  35. Junio C HamanoAug 13, 2017
  36. Ramsay JonesAug 13, 2017
  37. 0/2 clang-formatBrandon Williams, Aug 14, 2017
  38. 2/2 Makefile: add style build ruleBrandon Williams, Aug 14, 2017
  39. Stefan BellerAug 14, 2017
  40. Junio C HamanoAug 14, 2017
  41. Stefan BellerAug 14, 2017
  42. Jeff KingAug 14, 2017
  43. Junio C HamanoAug 14, 2017
  44. Junio C HamanoAug 14, 2017
  45. Brandon WilliamsAug 15, 2017
  46. Jeff KingAug 15, 2017
  47. 1/2 clang-format: outline the git project's coding styleBrandon Williams, Aug 14, 2017
  48. Stefan BellerAug 14, 2017
  49. Ben PeartAug 15, 2017
  50. Brandon WilliamsAug 15, 2017
  51. Jeff KingAug 14, 2017
  52. Jeff KingAug 14, 2017
  53. Brandon WilliamsAug 14, 2017
  54. Jeff KingAug 14, 2017
  55. Johannes SchindelinAug 16, 2017
  56. Ben PeartAug 15, 2017
  57. Brandon WilliamsAug 15, 2017
  58. Stefan BellerAug 15, 2017
  59. Brandon WilliamsAug 14, 2017
  60. Jeff KingAug 14, 2017
  61. Stefan BellerAug 14, 2017
  62. Jeff KingAug 15, 2017
  63. Junio C HamanoAug 15, 2017
  64. Jeff KingAug 15, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.