Can we also add a uncrustify or clang formatting configuration

[reejosamuel]

If someone has already managed to tweak their uncrustify or clang to format as per this style. Adding it to the repo would be great help

Please share :+1:

[harlanhaskins]

+1 This would be fantastic.

[JamesMcMahon]

:+1:

[mikelelorz]

I follow a code style very similar to the one used by NYTimes (only difference: I use tabs), I tweaked a .clang-format file like this:

---
Language:        Cpp
# BasedOnStyle:  LLVM
AccessModifierOffset: -2
ConstructorInitializerIndentWidth: 4
AlignEscapedNewlinesLeft: false
AlignTrailingComments: true
AllowAllParametersOfDeclarationOnNextLine: true
AllowShortIfStatementsOnASingleLine: false
AllowShortLoopsOnASingleLine: false
AllowShortFunctionsOnASingleLine: false
AlwaysBreakTemplateDeclarations: false
AlwaysBreakBeforeMultilineStrings: false
BreakBeforeBinaryOperators: false
BreakBeforeTernaryOperators: true
BreakConstructorInitializersBeforeComma: false
BinPackParameters: true
ColumnLimit: 0
IndentWidth: 4
ConstructorInitializerAllOnOneLineOrOnePerLine: false
DerivePointerBinding: false
ExperimentalAutoDetectBinPacking: false
IndentCaseLabels: true
MaxEmptyLinesToKeep: 1
NamespaceIndentation: None
ObjCSpaceAfterProperty: true
ObjCSpaceBeforeProtocolList: true
PenaltyBreakBeforeFirstCallParameter: 19
PenaltyBreakComment: 300
PenaltyBreakString: 1000
PenaltyBreakFirstLessLess: 120
PenaltyExcessCharacter: 1000000
PenaltyReturnTypeOnItsOwnLine: 60
PointerBindsToType: false
SpacesBeforeTrailingComments: 1
Cpp11BracedListStyle: true
Standard: Cpp11
TabWidth: 4
UseTab: ForIndentation
BreakBeforeBraces: Attach
IndentFunctionDeclarationAfterType: true
SpacesInParentheses: false
SpacesInAngles:  false
SpaceInEmptyParentheses: false
SpacesInCStyleCastParentheses: false
SpacesInContainerLiterals: true
SpaceBeforeAssignmentOperators: true
ContinuationIndentWidth: 4
CommentPragmas:  '^ IWYU pragma:'
SpaceBeforeParens: ControlStatements

This is the closest I could get. The only difference I've see so far is that the else is being placed in the same line as the if's closing bracket

if (foo) {
    // Statements
} else {
   // Moar tatements
}

If someone could help me with that I would appreciate it

[mbbischoff]

If someone could help me with that I would appreciate it

@Twigz may have some thoughts here as I believe he’s looked into this.

[sjrmanning]

Another issue I've found with (a slightly modified version of) the above .clang-format is the indentation of when splitting a method call is quite different to how Xcode handles it.

Even with ObjCBlockIndentWidth: 4, something like this:

// Default Xcode indentation when splitting method call
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    [[ADPCoordinator defaultCoordinator]
     fetchActivities:^(NSArray *activities, NSError *error) {
         dispatch_async(dispatch_get_main_queue(), ^{
             self.allActivities = activities;
             [self.tableView reloadData];
         });
     }];
});

becomes:

// After clang-format
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    [[ADPCoordinator defaultCoordinator]
        fetchActivities:^(NSArray *activities, NSError *error) {
            dispatch_async(dispatch_get_main_queue(), ^{
                self.allActivities = activities;
                [self.tableView reloadData];
            });
        }];
});

It's arguable which is really better and it's not a huge deal, but I prefer the first as the closing }]; of the method with the block lines up, which I think makes it clearer and easier to read. This also probably doesn't affect people who aren't worried about column limits :)

[patsybond172]

Another issue I've found with (a slightly modified version of) the above .clang-format is the indentation of when splitting a method call is quite different to how Xcode handles it. like this https://patsybond172.github.io/kitchen-cabinets