[style] Enforce clang-format style.

[turon]

• Adds github hook to confirm style conformance on each push and pull request
• Locks clang-format tool to version 9
• Updates code tree to enforce style guide

[rwalker-apple]

I'm personally a fan of the updates, but these are arbitrary choices that we should agree on and stop changing.

Can we agree to stop moving this around soon?

[turon]

I'm personally a fan of the updates, but these are arbitrary choices that we should agree on and stop changing.

Can we agree to stop moving this around soon?

I agree. We can certainly use this PR to get final agreement.

Note that even running make pretty with the existing style guide currently results in many changes to the sources which we need to apply before enabling the pretty-check github hook.

The style guide in this PR takes the one OpenThread uses with two minor modifications carried over from the old one:

PointerAlignment: Middle  (OT uses Right)
SpaceAfterCStyleCast: true (OT uses false)

[rwalker-apple]

I'm personally a fan of the updates, but these are arbitrary choices that we should agree on and stop changing.
Can we agree to stop moving this around soon?

I agree. We can certainly use this PR to get final agreement.

Note that even running make pretty with the existing style guide currently results in many changes to the sources which we need to apply before enabling the pretty-check github hook.

The style guide in this PR takes the one OpenThread uses with two minor modifications carried over from the old one:

PointerAlignment: Middle  (OT uses Right)
SpaceAfterCStyleCast: true (OT uses false)

That shouldn't have been the case, unless a lot of code has been introduced since I landed .clang-format and a pretty-fied tree last week. invoking the build in the tree should have automatically updated the code to the standard... I suppose if one made a PR without building the code (or including the reformattting in the commit, or building without clang-format being installed), one could sneak in unformatted code :-(

[turon]

I'm personally a fan of the updates, but these are arbitrary choices that we should agree on and stop changing.
Can we agree to stop moving this around soon?

I agree. We can certainly use this PR to get final agreement.
Note that even running make pretty with the existing style guide currently results in many changes to the sources which we need to apply before enabling the pretty-check github hook.
The style guide in this PR takes the one OpenThread uses with two minor modifications carried over from the old one:

PointerAlignment: Middle  (OT uses Right)
SpaceAfterCStyleCast: true (OT uses false)

That shouldn't have been the case, unless a lot of code has been introduced since I landed .clang-format and a pretty-fied tree last week.

Perhaps it's related to the version of clang-format being used. OpenThread and the current build system enforce that clang-format-6.0 is always used to guarantee the results are always the same.

Regardless of that, it does appear that sources in master are not all following the .clang-format that is there. Just PointerAlignment for example, some files have Right (AsyncDNSResolver.h), some Middle, and some Left (InitEndPointBasis in EndPointBasis.h).

[rwalker-apple]

I think it's actually that a lot of code has come in on machines without clang-format, then we changed the build system over to nlbuild-autotools, which removed support for auto-reformatting altogether.

I don't see this being an issue going forward if we can get hooks running on this repo soon.

[rwalker-apple]

OpenThread and the current build system enforce that clang-format-6.0 is always used to guarantee the results are always the same.

Where does clang-format 6.0 come from for MacOS? I'd really like to keep my editor<->format integration intact.

Could we use the latest (since it's arbitrary and easily update-able)?

[jwhui]

Perhaps it's related to the version of clang-format being used. OpenThread and the current build system enforce that clang-format-6.0 is always used to guarantee the results are always the same.

Where does clang-format 6.0 come from for MacOS? I'd really like to keep my editor<->format integration intact.

OpenThread uses: brew install llvm@6

Could we use the latest (since it's arbitrary and easily update-able)?

I think it's important to pick a version and stick to it - different versions can have different output. I agree, the particular version chosen is arbitrary.

[woody-apple]

I think it's important to pick a version and stick to it - different versions can have different output. I agree, the particular version chosen is arbitrary.

Can I propose we use the current latest version, since we're here now? :)

Oh, and please document how to install it :)

[turon]

I think it's important to pick a version and stick to it - different versions can have different output. I agree, the particular version chosen is arbitrary.

Can I propose we use the current latest version, since we're here now? :)

By "current latest" are you proposing hot-off-the-presses (v11) or "latest available to package managers in common, stable OS distributions"?

My gMac laptop ships with v7. Ubuntu 18.04 I believe defaults to v6.0 after apt install clang-format.

So the benefits of choosing v6.0 would be:

1. standard availability as packages via apt-get and brew.
2. toolchain alignment for developers creating CHIP-over-OpenThread accessories.

[turon]

Ok. To address comments, this PR has been updated in two ways:

1. .clang-format is unchanged (no actual style changes are introduced)
2. Version of clang-format required was moved to 9.0.
   This version appears to be the newest readily available via apt-get on common debian / ubuntu distributions.

It appears from the diffs that the only files that needed style updates applied were new QR code, tests, and many of the headers.

[woody-apple]

Thanks @turon for dealing with the style change discussion :)

[tpmanley]

Just one minor nit

[gerickson]

Some minor documentation issues to adjust.

[rwalker-apple]

I think it's important to pick a version and stick to it - different versions can have different output. I agree, the particular version chosen is arbitrary.

As tools advance, it'd be nice to avail ourselves of the features and capabilities.

I advocate:

1. building out continuous integration with containers that carry the required tools set to versions that the tree was developed against (implies building the containers and naming them in version control)
2. developing with the latest compilers, formatters, etc. available to the team, updating them as we go on dev boxes, and building new containers as we advance

Is this is a weird place for this discussion?