Skip to content

Conversation

@OmniBlade
Copy link

Create an agreeable clang-format file and the workflow/instructions for using it appropriately

Fixes #485

@xezon xezon added Build Anything related to building, compiling Refactor Edits the code with insignificant behavior changes, is never user facing labels Mar 24, 2025
@OmniBlade OmniBlade force-pushed the feature/clang-format branch 3 times, most recently from c715a98 to b32be3c Compare March 28, 2025 12:13
@xezon xezon added this to the Code foundation build up milestone Mar 31, 2025
@OmniBlade OmniBlade force-pushed the feature/clang-format branch from b32be3c to 52199c0 Compare August 23, 2025 23:35
.clang-format Outdated
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this correct?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needed to get the correct spacing in nested templates to compile correctly with VC6.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indentation is meant to be width 2. So either a tab or 2 spaces.

I suggest we keep leading tabs for starters, because it will make the diff smaller.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've changed it to 2 spaces. I think if we are going to standardise on a size we should use spaces to ensure it. The fact the code looks incorrectly indented in a lot of places when viewed with tab sizes other than 2 reinforces this in my opinion.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem with the 2 spaces is that it now creates this huge diff. I expect the diff will be just half or less big if using leading tabs. Perhaps do the 2 spaces another time?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I've changed this to tabs and set the indent to 2 to match the original as much as possible and try and reduce the diff.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we please use Struct* instead of Struct *?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A somewhat random sampling of files suggests that the prevelant existing style is Type *var and Type &var rather than Type* var and Type& var.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current style does favor Type *var and Type &var, but I also prefer Type* var and Type& var.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does indeed. I ran python script

import glob
import os

def main():
    current_dir = os.path.dirname(os.path.abspath(__file__))
    root_dir = os.path.join(current_dir, "..", "..")
    root_dir = os.path.normpath(root_dir)
    core_dir = os.path.join(root_dir, "Core")
    generals_dir = os.path.join(root_dir, "Generals")
    generalsmd_dir = os.path.join(root_dir, "GeneralsMD")
    fileNames = []
    fileNames.extend(glob.glob(os.path.join(core_dir, '**', '*.h'), recursive=True))
    fileNames.extend(glob.glob(os.path.join(core_dir, '**', '*.cpp'), recursive=True))
    fileNames.extend(glob.glob(os.path.join(core_dir, '**', '*.inl'), recursive=True))
    fileNames.extend(glob.glob(os.path.join(generals_dir, '**', '*.h'), recursive=True))
    fileNames.extend(glob.glob(os.path.join(generals_dir, '**', '*.cpp'), recursive=True))
    fileNames.extend(glob.glob(os.path.join(generals_dir, '**', '*.inl'), recursive=True))
    fileNames.extend(glob.glob(os.path.join(generalsmd_dir, '**', '*.h'), recursive=True))
    fileNames.extend(glob.glob(os.path.join(generalsmd_dir, '**', '*.cpp'), recursive=True))
    fileNames.extend(glob.glob(os.path.join(generalsmd_dir, '**', '*.inl'), recursive=True))

    countLeftPointer = 0
    countRightPointer = 0

    for fileName in fileNames:
        with open(fileName, 'r', encoding="cp1252") as file:
            try:
                lines = file.readlines()
            except UnicodeDecodeError:
                continue # Not good.

        for line in lines:
            for i in range(0, len(line)):
                if i > len(line) - 3:
                    break
                if i < 1:
                    continue
                if line[i-1] == '&' or line[i+1] == '&' or line[i-1] == '*' or line[i+1] == '*' or line[i-1] == '/' or line[i+1] == '/':
                    continue
                if line[i] == '&' or line[i] == '*':
                    if line[i-1].isspace() and not line[i+1].isspace():
                        countRightPointer += 1
                    if line[i+1].isspace() and not line[i-1].isspace():
                        countLeftPointer += 1

    return

if __name__ == "__main__":
    main()

And it returned

countLeftPointer = 25260
countRightPointer = 111217

I also prefer left side pointer because right side pointer makes no logical sense. The pointer is part of the type, not the variable, aka int* is a type, whereas *var is a dereference.

int* var looks like a type
int *var looks like a type/dereference abomination

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with the argument that pointer is part of the type, however for the sake of the diff right aligned is a better match for the original style of the code.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To keep the diff small, right pointer is ok for now. In the future we can change to left pointer.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I very much preferred the original formatting of the array lists. Can we preserve this?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a trailing , needs to be added to make it keep the list as it originally was but I'll play around with a couple of settings and see what happens.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is another example where multiline formatting does not help readability.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what controls this just for macros to be honest.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This enum has very strange formatting in regards to the curly brackets.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After some testing, it appears that the CPP_11 macro used on a lot of enums breaks clang-format's ability to handle this correctly. until we are VC6 free and the macros are removed, clang format won't get enums correct 😞

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way this is auto formatted is not great.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be better if this was not cramped into one line.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not a good formatting.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those are the annoying cases where the comment eceeds the line limit.
But this is a function definition right? Shouldn't they have doc strings above them instead of inline?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updating clang-format with these values:

PenaltyBreakComment: 0  # modified; was 300
PenaltyBreakOpenParenthesis: 1  # modified; was 0

will give this output

  virtual void loadIntoDirectoryTree(
      const ArchiveFile *archiveFile,
      const AsciiString &archiveFilename,
      Bool overwrite = FALSE); ///< load the archive file's header information and apply it to the global archive directory
                               ///< tree.

Is this more in line with what you expect?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I applied this suggestion.

@OmniBlade OmniBlade force-pushed the feature/clang-format branch 3 times, most recently from d56bb1a to 18f8a3b Compare August 27, 2025 15:12
@OmniBlade
Copy link
Author

Made a few changes, but I'm not sure its actually improved anything. I think the issue with the enums might be the CPP_11 macro messing up detection of it being an enum but there isn't much we can do about that for now I guess. Most of the other list formatting changes can be prevented by a trailing , but that involves a bit of manual fixing once an otherwise agreeable format has been accepted.

@OmniBlade OmniBlade force-pushed the feature/clang-format branch from 18f8a3b to 5b56098 Compare August 28, 2025 08:29
@OmniBlade OmniBlade force-pushed the feature/clang-format branch from 5b56098 to 7f5530d Compare August 28, 2025 08:39
@xezon
Copy link

xezon commented Sep 11, 2025

I was experimenting with uncrustify and was barely unable to isolate minimal formatting. It has huge issues with tab spacings, but gives finer controls than clang format.

@bobtista bobtista mentioned this pull request Nov 5, 2025
@Skyaero42
Copy link

Closing this in favor of #1807

@Skyaero42 Skyaero42 closed this Nov 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Build Anything related to building, compiling Refactor Edits the code with insignificant behavior changes, is never user facing

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add clang format to project

5 participants