-
Notifications
You must be signed in to change notification settings - Fork 118
WIP Create clang-format workflow #493
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
c715a98 to
b32be3c
Compare
b32be3c to
52199c0
Compare
.clang-format
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this correct?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 *?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 😞
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I applied this suggestion.
d56bb1a to
18f8a3b
Compare
|
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 |
18f8a3b to
5b56098
Compare
Creates a format target using clang-format.
5b56098 to
7f5530d
Compare
|
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. |
|
Closing this in favor of #1807 |
Create an agreeable clang-format file and the workflow/instructions for using it appropriately
Fixes #485