[SR-Users] rfc: clang format the code

Daniel-Constantin Mierla miconda at gmail.com
Thu Nov 23 17:20:48 CET 2017


Hello,

it was discussed during the last irc devel meeting and everyone there
agreed to use clang-format to format the source code:

  - https://clang.llvm.org/docs/ClangFormat.html

Is any developer (maybe not present during the irc devel meeting)
opposing this?

It is not going to be all at once, because some of the structures and
initialization of them may be preferred to be kept with a custom format
for being easier to read -- to have a section in the file not formatted,
it has to be enclosed in between comments:

/* clang-format off */

...

/* clang-format o. */

But for the rest of the code (i.e., functions) I think it will be better
to agree on a format and try to use it. The clang-formatting should be
done when one needs to update code in some files.

Over the years, developers come and go, having each one with a custom
formatting style is hard to maintain properly in long term. There are
modules that do not indent coherently code inside blocks, using a
mixture, more or less no style. This makes it hard for other developers
to review in case of reported issues, but also for new comers to get
familiar with the code.

In the source tree there is already a .clang-format file which defines
the options for formatting.

It was used by me and other developers already -- I did it mainly in my
modules or those components that do not have an active maintainer. But I
plan to do it also on the components that have currently a maintainer at
the moment I need to work on that code (e.g., fix some issue or export
functions to kemi framework).

My process of clang-formatting a module is like:

  - edit the files to add clang-format off/on comments around the parts
I want to preserve as they are (typically mod exports -- params,
functions, kemi -- and intialization of structures that are aligned to a
specific indentation that makes it easier to read).

  - run: clang-format -i src/modules/modname/*.{c,h}

  - commit with these changes, no new feature or bug fix must be done in
the same commit (can be combined with removing the history comments)

If one wants different options inside .clang-format, please propose and
let's discuss which one is preferred by the majority of the current
developers.

If no one shows anything against in a matter of few days, it will be
considered accepted (after all, one can re-indent on own style if the
rule is not accepted or overturned).

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com




More information about the sr-users mailing list