Choose C++ style guideline

[tigrannajaryan]

C++ is a big language that can be used in many different ways. We need to choose a style and stick to it.

A couple popular starting points (can be chosen as is or as the starting point for our own style):

• https://google.github.io/styleguide/cppguide.html
• http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

Other style suggestions are welcome.

[maxgolov]

I think we should definitely embrace CppCoreGuidelines.

Re. coding style - we should add clang-format to the build. It's a popular tool accessible from most of the most common editors (vim, Visual Studio, vscode, eclipse), as well as we can use git cl format to reformat command-line, following about what the Chromium source code repo is doing:
https://chromium.googlesource.com/chromium/src/+/master/docs/clang_format.md

We should discuss what's the best fit - LLVM, Google, Chromium, or other styles. Maybe we should also allow for specific exporter dev to have their own preferred style (formatting-wise) via .clang-format file in their module sub-directory.

My personal preference would be something in the middle between Linux and LLVM formatting style. Others may have a different opinion. We should use automated process (e.g. clang-format) to enforce whatever we agree upon..

[g-easy]

I agree re: automatic formatting and enforcing it.

[maxgolov]

I wrote some quick script for adding a mini version of .clang-format'ter without needing Python (Windows, Linux, Mac), i.e. lightweight wrapper for git cl format , a bit less sophisticated than Chromium clang-format command. I can send a PR with the script, plus 4-5 coding style examples, as well as how-to doc with links to IDE plugins for auto-formatting using that file. We can review the styles, agree on what seems reasonable to majority, and check-in the .clang-format file in workspace root.

[rnburn]

Since the core cpp guidelines don't have a full naming convention, which one should we adopt?

My preference would be to take one of the standard conventions (or at least start there) so that we don't have to go through debating how to name each component in the language.

Two that we might consider:

• Google's naming convention
• Envoy's naming convention -- similar to Google but with some differences in capitalization (e.g. function names are doFoo() instead of DoFoo())

Anyone have a preference? or other convention they want to consider?

[g-easy]

I prefer the Google one.

[g-easy]

#5 (comment) Regarding autoformat, OpenCensus used to have a relatively simple script: tools/format.sh

It runs clang-format + buildifier + cmake-format. The user can then review and commit the results. Importantly, it also runs during CI.

[meastp]

#5 (comment) Regarding autoformat, OpenCensus used to have a relatively simple script: tools/format.sh

It runs clang-format + buildifier + cmake-format. The user can then review and commit the results. Importantly, it also runs during CI.

If you do this, please write it in a language that also supports Windows.

I would prefer a CI verification step that created/added a commit if something was missing (according to the clang-format, buildifer and cmake-format) because users that do not care about cmake don't necessarily have it installed and similarly for bazel (and thus can not run the script locally).