Coding style enforcement

While porting Broker to the latest CAF version, I am realizing that the
current pre C++11 coding style is not very conducive. Since the
introduction of lambdas, and in particular with CAF's asynchronous and
template-heavy programming model, the Whitesmiths style isn't very

Once can consider Broker a separate project, and perhaps a style change
wouldn't be as complicated as in the main Bro code, I still wanted to
check in with you whether anyone would object to changing the style. In
particular, I'm planning to use CAF's coding style [1], which provides a
unified style for meta programming as well as "regular" programming.

There exists also a clang-format style file for this [2], which makes it
really easy to enforce this style globally. Unfortunately, clang-format
currently doesn't support the Whitesmiths style, so using this tool for
Bro is not (yet) an option. (There exists an unmerged patch that needs
some cleanup [3], if anyone wants to go for it.)

On a related note: I'd also like to see stricter git commit message
guidelines, at least putting strict rules on the first line [4]. Would
you be in favor of such rules on commit messages?



As I had mentioned to Matthias already, I don't have strong feelings
regarding Broker coding style. Changing that to match CAF sounds
reasonable to me, as a lot of the code's structure is driven by CAF as
well. Jon is the one most invested into the style, so as long as he's
ok with it, I don't see a problem.

(For the record, for Bro itself my preference remains staying with the
current style. Ideally somebody will be able to teach that to
clang-format eventually.).

Regrading commit messages, these are our current guidelines:

I wouldn't want to be too religious about that, but having a succinct
first line certainly makes sense. Not sure I'd remember not to put a
period at the end though. :slight_smile:


I’m fine w/ any style or naming convention changes in order to cause less friction for Matthias/others.

- Jon

I’m fine w/ any style or naming convention changes in order to cause
less friction for Matthias/others.

Good to know Jon, thanks for chiming in.

My goal is to leverage clang-format to the best degree possible such
switching styles is not a big undertaking. Since no tool has (yet) good
support for lambdas and template meta programming, I'll make sure to
document the style for these constructs explicitly.

Ideally this gives us some experience for future application throughout
the entire Bro code base.