STYLE and uncrustify

STYLE and uncrustify

[David Bremner]

[-- Attachment #1: Type: text/plain, Size: 880 bytes --]


I'm pondering running uncrustify on all/most of the notmuch codebase,
but I noticed a few things that uncrustify does are either not
documented in STYLE, or maybe contradicted.

1) Should block comments start with '*' ? Uncrustify thinks yes, STYLE
   is silent, the codebase says mostly yes.  I think update STYLE to
   match uncrustify here.

2) Should there be a space after '!'? Uncrustify says yes, STYLE is
   silent, the codebase is inconsistent. Updating STYLE would be the
   easy thing here, but I remember previous discussions being
   inconclusive.

3) Similar for space between '++' and '--' and operand

4) uncrustify wants to move 'const char* foo' to 'const char *foo'.

That's about all I have patience for at the moment.

When I say 'uncrustify', I really mean 'our current uncrustify
config'. I don't know offhand how hard any of these items are to change.

d

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: STYLE and uncrustify

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 1865 bytes --]

Hi Bremner--

Thanks for doing this kind of cleanup work.  Long-term consistency is
worth the short-term pain.  The main short-term pain comes from dealing
with changes that are in-flight.  As someone with a couple of series
that are in flight, of course i'd prefer that you merge my changes
first, before you apply this cleanup so i don't have to rebase.  :P But
i care more that we get the cleanup done, and i'm also fine with
rebasing if you do that. (rebasing against a consistent codebase is
easy, compared to planning and implementing features and fixes
correctly)

rip the band-aid off!

On Fri 2019-06-07 07:58:24 -0300, David Bremner wrote:
> I'm pondering running uncrustify on all/most of the notmuch codebase,
> but I noticed a few things that uncrustify does are either not
> documented in STYLE, or maybe contradicted.
>
> 1) Should block comments start with '*' ? Uncrustify thinks yes, STYLE
>    is silent, the codebase says mostly yes.  I think update STYLE to
>    match uncrustify here.
>
> 2) Should there be a space after '!'? Uncrustify says yes, STYLE is
>    silent, the codebase is inconsistent. Updating STYLE would be the
>    easy thing here, but I remember previous discussions being
>    inconclusive.

I'm fine going with uncrustify's decision for these two points.

> 3) Similar for space between '++' and '--' and operand

for whatever reason, i find myself preferring these attached without a
space between ++ and -- and the operand, whether as a prefix or postfix
operator.  If it's possible (i don't really know uncrustify) i'd like to
have the codebase say both "foo++" and "++foo".  But if it's hard to
convince uncrustify, or if anyone else has a preference for "foo ++"
i'll cope.

> 4) uncrustify wants to move 'const char* foo' to 'const char *foo'.

Yes, please.  I prefer keeping the * next to the variable.

     --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: STYLE and uncrustify

[Tomi Ollila]

On Fri, Jun 07 2019, David Bremner wrote:

> I'm pondering running uncrustify on all/most of the notmuch codebase,
> but I noticed a few things that uncrustify does are either not
> documented in STYLE, or maybe contradicted.
>
> 1) Should block comments start with '*' ? Uncrustify thinks yes, STYLE
>    is silent, the codebase says mostly yes.  I think update STYLE to
>    match uncrustify here.

agreed.

> 2) Should there be a space after '!'? Uncrustify says yes, STYLE is
>    silent, the codebase is inconsistent. Updating STYLE would be the
>    easy thing here, but I remember previous discussions being
>    inconclusive.

IIRC e.g (! foo) has been the agreed style. Unfortunately uncrustify also
replaces '!!' with '! ! ' and there is no option to suspend this. This
would be super-easy to post-process but then we could not use the checking
option of uncrustify -- one option is to 'ignore' that in config, then
uncrustify won't change...

> 3) Similar for space between '++' and '--' and operand

There perhaps is an uncrustify option for this. I cannot remember for that
either (perhame email/irc logs would tell something...)  I would have
guessed that no space there but ...

> 4) uncrustify wants to move 'const char* foo' to 'const char *foo'.

Again, would have guessed that char *foo is the syntax but...

> That's about all I have patience for at the moment.
>
> When I say 'uncrustify', I really mean 'our current uncrustify
> config'. I don't know offhand how hard any of these items are to change.


We do have quite a few things where we cannot configure uncrustify to 
indent like emacs does: one is:

    variable = function_call
        (arg1, arg2)

which will indent:

    variable = function_call
                   (arg1, arg2)

or, if    

    use_indent_continue_only_once  = true

is set

    variable = function_call
               (arg1, arg2)


(getting all above figured out took like 100 minutes, by checking
Uncrustify-0.68_f options and some trial/error runs...)

before going to sleep (and interrupting diffing *.c w/ corresponding
*.uncrustify files...) we could change all above cases to

    variable = function_call(
        arg1, arg2)

then (IIRC, too tired to re-check) should indent like emacs(1) does...


Tomi

>
> d