Add .clang-format file

[ffoulkes]

No description provided.

[5abeel]

Does this require clang-format installed in dev environment?

[ffoulkes]

Does this require clang-format installed in dev environment?

No, it doesn't. It specifies the defaults to use if you run clang-format without explicit options.

I've begun running clang-format on newly developed files (unit tests). We'll need to choose the right time to begin reformatting existing files. (Probably not before 23.07, especially if it makes wrenching changes to a file.)

This particular file was copied from stratum.

[5abeel]

LGTM

[nupuruttarwar]

@ffoulkes I remember our conversation about clang format as a recommended for stratum codebase. Should we make it as part of some guideline?

[nupuruttarwar]

LGTM

[5abeel]

@ffoulkes I remember our conversation about clang format as a recommended for stratum codebase. Should we make it as part of some guideline?

Might be good to do that (if you have the time, based on priority list)

[nupuruttarwar]

@ffoulkes I remember our conversation about clang format as a recommended for stratum codebase. Should we make it as part of some guideline?

Might be good to do that (if you have the time, based on priority list)

Sure, we can take this as part of documentation update.

[ffoulkes]

@ffoulkes I remember our conversation about clang format as a recommended for stratum codebase. Should we make it as part of some guideline?

Yes, we should.

As I see it, the process would be something along the lines of:

• Develop a guideline
• Commit .clang-format files where appropriate
• Develop a GitHub action to run clang-format in check mode
• Pick an appropriate moment to put the policy into effect
• Let people know that it's going into effect
• Reformat and push updates in batches
• Enable the GitHub checker
• Advise developers to
  • Update their working repositories
  • Run clang-format before pushing updates

Basically, we want reformatting changes to be separate from content changes.

A developer can:

• Run clang-format on their work in progress
• Stash their work
• Pull a fresh copy of the repository
• Pop or apply the stashed copy
• Deal with merge errors and commit

If you want to take out some insurance, you can

• git stash your WIP
• git stash apply to get your WIP back without removing the stashed copy
• clang-format for reformat your WIP
• git stash again, so save your reformatted WIP
• pull fresh copies of the repos
• git stash apply (or git stash pop) to merge your WIP with the repo code
• Deal with merge errors and commit
• Push and then git stash drop to clean up

The stash on top of the stack should merge fairly cleanly.
If something goes wrong, you've still both formatted and unformatted copies of your WIP to fall back on.