多行函数声明参数的 Clang 格式问题

Question

Clang Format is consistently doing this:

bool importSomethingIn( const boost::property_tree::ptree& inBoostTree,
                        int inSomeIndex,
                        std::shared_ptr<Something>
                            inSomething,
                        int x,
                        int y );

When I want it to do this:

bool importSomethingIn( const boost::property_tree::ptree& inBoostTree,
                        int inSomeIndex,
                        std::shared_ptr<Something> inSomething,
                        int x,
                        int y );

Note that it is adding a newline and indent before the symbol inSomething . It seems to always be the templated types that cause this behaviour.

How can I stop it from doing this?

Here is my current .clang-format:

BasedOnStyle: LLVM
Language: Cpp
AccessModifierOffset: -4
AlignEscapedNewlinesLeft: false
AlignTrailingComments: true
AllowAllParametersOfDeclarationOnNextLine: true
AllowShortFunctionsOnASingleLine: false
AllowShortIfStatementsOnASingleLine: false
AllowShortLoopsOnASingleLine: false
AlwaysBreakAfterDefinitionReturnType: true
AlwaysBreakBeforeMultilineStrings: false
AlwaysBreakTemplateDeclarations: false
BinPackParameters: false
BreakBeforeBinaryOperators: false
BreakBeforeBraces: Allman
BreakBeforeTernaryOperators: false
BreakConstructorInitializersBeforeComma: false
ColumnLimit: 120
CommentPragmas: ''
ConstructorInitializerAllOnOneLineOrOnePerLine: false
ConstructorInitializerIndentWidth: 4
ContinuationIndentWidth: 4
Cpp11BracedListStyle: true
DerivePointerAlignment: false
DerivePointerBinding: false
ExperimentalAutoDetectBinPacking: false
IndentCaseLabels: true
IndentFunctionDeclarationAfterType: true
IndentWidth: 4
IndentWrappedFunctionNames: false
KeepEmptyLinesAtTheStartOfBlocks: false
MaxEmptyLinesToKeep: 2
NamespaceIndentation: All
ObjCBlockIndentWidth: 4
ObjCSpaceAfterProperty: true
ObjCSpaceBeforeProtocolList: true
PenaltyBreakBeforeFirstCallParameter: 19
PenaltyBreakComment: 300
PenaltyBreakFirstLessLess: 120
PenaltyBreakString: 1000
PenaltyExcessCharacter: 1000
PenaltyReturnTypeOnItsOwnLine: 60
PointerAlignment: Left
PointerBindsToType: true
SpaceBeforeAssignmentOperators: true
SpaceBeforeParens: ControlStatements
SpaceInEmptyParentheses: false
SpacesBeforeTrailingComments: 1
SpacesInAngles: false
SpacesInContainerLiterals: true
SpacesInCStyleCastParentheses: false
SpacesInParentheses: true
Standard: Cpp11
TabWidth: 8
UseTab: Never

Edit: I am using the clang format Xcode plugin which I obtained here on github July 2016 (first installed Alcatraz then clang format plugin with Aclatraz). I'm not entirely sure where the clang-format binary is, thus haven't seen the version number for the one that came with the plugin.

However, based on the suggestions below I installed clang-format using Homebrew which gave me version 3.9.0. I then set the Xcode plugin to "use system clang-format" and I got the desired result, so I guess it must have been a bug.

Answer 1

Your case seems fine to me on ubuntu 16.04 with clang-format 3.8

• Install clang-format-3.8

   sudo apt-get install clang-format-3.8

• In ~/.vimrc

   map <F3> :pyf /usr/share/vim/addons/syntax/clang-format-3.8.py<cr> imap <F3> <Co>:pyf /usr/share/vim/addons/syntax/clang-format-3.8.py<cr>

• Use @OP's .clang-format and source code

   mkdir ~/test vim ~/test/.clang-format vim ~/test/test.cpp

• Format test.cpp in vim (using F3), then the result:

   bool importSomethingIn( const boost::property_tree::ptree& inBoostTree, int inSomeIndex, std::shared_ptr<Something> inSomething, int x, int y );

Answer 2

I think it is caused by ColumnLimit . I think it's a bug...I had this problem ones and I solved it by changing this variable. Try to set:

 ColumnLimit: 0

Reason

The length of bool importSomethingIn( const boost::property_tree::ptree& inBoostTree, int inSomeIndex, std::shared_ptr<Something>" has 117+-3 chars in dependence of computing invisible chars. is 117+-3 in dependence of computing invisible characters. ColumnLimit: 120 has been set and it is one of possible reasons, I think, it has been cut.