INN indentation

[Julien ÉLIE]

Hi Russ,

> For my personal projects, I've started using clang-format to just reformat
> all of the source code and keep it consistently formatted.  It requires
> some work up-front to mark some code blocks to not reformat, because it
> messes up a lot of code that's carefully laid out to make it easier to
> read

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 */).

Sometimes, some headers need being included before other ones for 
portability reasons, so changes need careful review.

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.



> For the record, here's the .clang-format file I use for my personal
> projects:
> 
> ---
> Language: Cpp
> BasedOnStyle: LLVM
> AlignConsecutiveMacros: true
> AlignEscapedNewlines: Left
> AlwaysBreakAfterReturnType: AllDefinitions
> BreakBeforeBinaryOperators: NonAssignment
> BreakBeforeBraces: WebKit
> ColumnLimit: 79
> IndentPPDirectives: AfterHash
> IndentWidth: 4
> IndentWrappedFunctionNames: false
> MaxEmptyLinesToKeep: 2
> SpaceAfterCStyleCast: true
> ---

Maybe we could just use the same to start?
We could otherwise spend months discussing each personal coding style. 
I see the list is quite extensive:
   https://clang.llvm.org/docs/ClangFormatStyleOptions.html

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;



I've tried it on a few files to see how they look like with this format.

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



> My personal style is slightly different than INN's, but they're relatively
> close.  (INN has some unusual conventions for comment formatting.)  The
> biggest thing that it changed in my other projects was using four-space
> indentation for nested C preprocessor directives.

Yes, seen!

Any comments from others about the style we can start with?  (Let's 
begin with something!)

-- 
Julien ÉLIE

« Bis repetita placent. » (issu de Horace)