Hey,
We recently checked in and formatted the code with clang-format. It was brought to our attention that some of the changes we made were vague or absent in our published standard. I thought I would bring them up here so we could discuss. Sorry for the length of this post. The clang-format file is lengthy. My suggestions are mine alone, not representative of Altair. For more information than I provide: Clang-Format Style Options — Clang 13 documentation
AlignAfterOpenBracket
This controls what to do with a line continuation. Should it be aligned with the open bracket/paren or a static indent. We chose to align with the open bracket, but this has a problem. One of the things our standard specifies is that we use tabs as our indent. This was because someone could change change the tab-width in their editor if they want. The only way for clang-format to align brackets properly is to assume a tab width (we chose the default of 8). This causes line continuations to not look right if you change the tab width to lets say 4.
With that in mind, I suggest we change this to a static indent of one tab.
AlignConsecutiveAssignments/AlignConsecutiveDeclarations
This controls if you align the declaration assignments. We were inconsistent on this, so we chose false. All assignments will come right after the variable name.
AlignEscapedNewlines
This talks about what happens with an escaped newline. Most likely this is for a preprocessor macro. The options are to align them close or far from the macro in a line or don’t align them at all. Currently this is set to align them on the right far from the macro. It does add some space between the macro and the escapes, so it makes it obvious they are escaped. If we want to save on some horizontal space, we can change this.
AlignTrailingComments
This controls whether or not we align single line comments on lines after each other. This usually comes into play when there is a list of declarations at the top of a scope with comments describing each one. Currently this is set to true. This means things line up nicely, but it also adds horizontal space. I also noticed it isn’t perfect, so if you have a bunch of variables with comments, then one without, then more with comments, the second set will be at a different indent level.
I suggest we turn this off.
AllowShortFunctionsOnASingleLine
This will control if short one line functions are merged onto a single line. This is set to all functions.
AllowShortIfStatementsOnASingleLine
Similarly this controls if short if statements are merged onto one line. This is set to never.
AllowShortLoopsOnASingleLine
Similarly this controls if short loops are merged onto one line. This is set to false.
BinPackArguments/BinPackParameters
This controls if function arguments/parameters are bunched on one line or split one argument per line. This is set to true. I suggest we leave it. Having one line per function argument will eat up a lot of vertical space.
IndentCaseLabels
This means we’ll indent a case from the base switch (so indent the case, and then indent the block from that). It uses up more horizontal space, but I think it makes it easier to read.
It is set to true and I think we should leave it.
KeepEmptyLinesAtTheStartOfBlocks
This keeps empty lines if they exist at the start of a block. This is set to true
MaxEmptyLinesToKeep
This specifies the max number of empty lines to keep. It squishes things together. It is currently set to 1. That seems fine to me.
SpaceAfterLogicalNot
This will add a space after a logical not (e.g. ! foo vs !foo). It is currently set to false and I think we should keep it that way.
Sorry for the lengthy email. I listed the parts of the clang-format file that I felt were not expressed in our standard. We should clarify them if our clang-format file is going to format them that way.
Bhroam