Re: INN indentation

Julien ÉLIE <[email protected]> writes:

> Yup, it otherwise reformats carefully laid out code like:

>  static CONFTOKEN PERMtoks[] = {
>     { PERMlbrace,               (char *) "{"                    },
>     { PERMrbrace,               (char *) "}"                    },
>     { PERMgroup,                (char *) "group"                },

> So it will need a bit of careful review of each converted file so as to
> ensure not to reformat such code (/* clang-format off */).

Yes, when I did this for my personal projects, I read through the whole
diff and sprinkled /* clang-format off */ everywhere it seemed needed.
It's kind of tedious.  A good thing to do while watching or listening to
something.  :)

> I see that HACKING recommends to include at the beginning of C files:

>     #include "config.h"
>     #include "clibrary.h"

> Yet clibrary.h already includes config.h; I bet it had not always been the
> case, which would explain it and why all or most of our files have both.
> Maybe we could drop the inclusion of config.h then.  And globally review
> the inclusions when clang-format re-orders them.

If we rename clibrary.h to portable/system.h, it will match the naming
convention in rra-c-util where it largely comes from and will also avoid
this problem.

> I would for instance suggest
> AllowShortEnumsOnASingleLine: false
> because the current layout

> typedef enum _SENDTYPE {
>     STarticle,
>     SThead,
>     STbody,
>     STstat
> } SENDTYPE;

> seems better to me than:

> typedef enum _SENDTYPE { STarticle, SThead, STbody, STstat } SENDTYPE;

Yes, agreed.  It looks like that doesn't force any change to existing
formatting either, so I'll adopt that for my own.

> AlignConsecutiveMacros: AcrossEmptyLinesAndComments
> may be better but only available in clang-format 13 (not yet released!)
> It think it would permit to have 62 at the same level here:

> #if defined(HAVE_OPENSSL) || defined(HAVE_SASL)
> #    define PERMrequire_ssl 62
> #    define PERMMAX         63
> #else
> #    define PERMMAX 62
> #endif

Oh, that will be very nice once that's released.  That's one of the
formatting decisions that always bugged me.

I'd be good to go with what's in rra-c-util right now, which is the one I
sent earlier plus the enum change, and I think there was another vote for
whatever as long as it's automated.  Any other thoughts or objections?

-- 
Russ Allbery ([email protected])             <https://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers