Add C++ autoformat style definition

[doug-a-brunner]

The C++ code includes some references to clang-format for autoformatting, but I couldn't find a .clang-format style definition, and it doesn't seem to use any of the styles bundled with clang-format.

I'm working on a branch that would add support for automatic pairing of devices on Windows (so users don't have to go through the awkward system dialog and manually disconnect their device after pairing), and it looks like it will require some significant changes to save and retry operations after pairing. These will be easier to review if formatting is tidy.

Can the preferred format style be added?

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[doug-a-brunner]

Any chance of getting this added?

[stoprocent]

Happy to put together a .clang-format for this. Before I do, two questions so the file matches what you actually want:

1. Brace style — the C++ in the repo is split. Files like lib/common/include/Emit.h, lib/common/src/Emit.cc, and lib/win/src/peripheral_winrt.h use Allman braces (open brace on its own line for classes/functions), while lib/win/src/ble_manager.{h,cc} uses attached braces. Which should be canonical? My read is Allman is slightly more common in the existing files, but it's close.
2. Scope of the change — would you prefer (a) just the .clang-format file added, leaving the existing code untouched and letting new contributions converge over time, or (b) the file plus a one-time reformat of the entire C++ tree in the same PR?

Other settings I'd default to based on the current style: 4-space indent, Pointer/ReferenceAlignment: Left, sorted #include blocks (system → project), and a generous column limit (~120) since the existing // clang-format off regions hold long N-API signatures intentionally — happy to flag any of these if you'd rather go a different direction.

---

Generated by Claude Code

[doug-a-brunner]

Thanks! Allman sounds good, as do the other settings you mentioned. If sorting includes causes build errors, though, I'd vote for turning it off rather than adding a bunch of work to fix include dependencies. Option 2(b) seems best, so that the benefits of cleaner merges show up immediately.