I know I’m super late to this party, but I recommend taking a look at the clang-format style options, because for all of your examples there are options that can get you a) exactly what you want (with some manual formatting required, e.g. for internal spacing alignment in some of the examples - but it won’t be overwritten), or b) a suitably close output. The web documentation is nice because it gives output examples for the various options, making it much easier to grok.
Going in order of the images provided, here are the appropriate options that enable the desired output. Note that none require you to disable formatting to get the same or a suitably close output!
- AlignConsecutiveAssignments + AlignTrailingComments (the separation between elements in the enum is fine)
- AlignTrailingComments (extra newline before max is fine)
- AlignConsecutiveDeclarations (spacing is fine, you have the option for whether the broken spacing causes the alignment to reset or not)
- AlignConsecutiveMacros (can work across empty lines and comments)
- AlignEscapedNewlines
- AlignOperands
- AlignTrailingComments (the two values per line doesn’t cause trouble)
- AlignConsecutiveAssignments
- AlignArrayOfStructures
- AlignOperands + AlignTrailingComments
- The if parentheses locations might be auto-formatted differently depending on other options, but I don’t really think that impacts readability at all.
- AlignConsecutiveAssignments
- AlignConsecutiveAssignments, and then the spacing following that is able to be manually specified and not overridden (unless you turn on some option that changes that).
- AlignOperands, though they may be moved closer in by the formatter. The first line may be moved up to the opening paren - personally, a non-issue to me. Might be an option to change that behavior though.
- AllowShortCaseLabelsOnASingleLine + AlignTrailingComments
- AlignConsecutiveAssignments, AlignTrailingComments, AlignOperands - the internal spacing is fine and won’t be formatted (unless you turn on some rule that changes that)
Now, are there cases where you might specify an option that causes conflicts with the above? Yeah, totally. but there are always sane options to take, such as a) locally disabling the formatting check, b) just being ok with it, or c) just adjusting how you specify things. For example, in the image where UINT16_MAX is doubled up on some lines - if there is an option that forces all values on different lines, you could simply change how the array is commented, e.g. where combined values are not two per line but instead commented as mbir_JP3_Fault_Code_MSB and mbir_JP3_Fault_Code_LSB (my own preference since the interpretation is clearer).