[llvm-dev] [cfe-dev] [RFC] Adding support for clang-format making further code modifying changes

[Sam McCall via llvm-dev]

I'm cautiously +1 on const reordering, having previously opposed it and
been convinced.
I think anyone who's worked on a large shared codebase both before and
after clang-format can understand the value here, so I'll focus mostly on
the risks and why I think they're acceptable.

*Risk: *clang-format will become a grab-bag of features with no clear line
- just anything implemented on top of its pseudo-AST.
Clang-format's brand is low-level formatting details and I think it's
important to preserve this. Const order fits here in users' minds. (So does
brace addition/removal).

*Risk*: The feature will break code and clang-format will no longer be
(seen as) reliable. This can make it harder socially or technically to
deploy, and cause real damage.
I think we need to work hard on mitigating this:
 - the feature needs careful design and extra scrutiny, like
security-critical code
 - it should be clearly and temporarily marked as experimental, with opt-in
required
 - it should be clearly and permanently marked as "makes assumptions about
coding style", with opt-in required.
 - bugs need to be thoughtfully addressed
>From what I can see MyDeveloperDay is serious about doing all of this.

*Risk*: clang-format will be overtaken by the complexity of such features,
which will outweigh the benefits (if few use them), hurting maintenance,
causing bugs etc.
However this isn't different from other optional features. Editing tokens
tends to be done as a separate pass which is relatively easy to isolate
(compared to something like supporting a new language). With complexity
isolated, this is mostly just about how maintainers prioritize their
time/attention, which must be left up to them.

Regarding include-ordering: I think this is a valuable feature if you
follow a coding style that allows it to be correct, and it fits well in
clang-format's brand. However it wasn't clearly labeled to emphasize its
caveats, and in hindsight it shouldn't have been made part of the Google
style without further opt-in required.

Cheers, Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210810/4e2556c6/attachment.html>