clang-format: Proposal for a new style for constructor and initializers line break.

Hello,

I’m interested in adding support for another style for constructor colon and initializer.
An example of the style is above the value BCIS_AfterColonAndComma bellow.

BreakConstructorInitializers would replace ‘bool BreakConstructorInitializersBeforeComma;’ while maintaining backward compatibility, in a similar fashion it was done before.

I have the prototype for the code and would be really happy to finalize it and contribute a set of small patches.

Please let me know if this something that fits with the project and if you have any advice.

Best Regards,

Jean-Philippe

/// \brief Different ways to break initializers.
enum BreakConstructorInitializersStyle
{
/// Constructor()
/// : initializer1(),
/// initializer2()
BCIS_BeforeColonAfterComma,
/// Constructor()
/// : initializer1()
/// , initializer2()
BCIS_BeforeColonAndComma,
/// Constructor() :
/// initializer1(),
/// initializer2()
BCIS_AfterColonAndComma
};

/// \brief Breaking and alignment style for constructor initializers
BreakConstructorInitializersStyle BreakConstructorInitializers;

Not entirely sure what advise you are looking for.
My thoughts:

  • I am happy to accept a patch provided is has sufficient unit tests
  • I think this should go in as a single patch, I don’t see a need for “a set of small patches”
  • Personally, I think this style is bad as it makes it harder to distinguish wrapped constructor arguments from initializers
  • In particular, how do you indent:

Constructor( // Arguments too long to fit on the same line
SomeArgument some_argument,
SomeOtherArgument some_other_argument) :
some_argument_(some_argument),
some_other_argument_(some_other_argument) {
}

Is this style used in any large project or widely used style guide?

Cheers,
Daniel

Thank you very much for your input.

I’ve done some research and found http://pocoproject.org (https://github.com/pocoproject/poco http://www.appinf.com/download/CppCodingStyleGuide.pdf page 27/52) uses it.

For full disclosure, I’m hoping to adopt clang-format for the projects we develop at work.
The style we use has no indentation for the initializers, this is an option that already exist in clang-format, and address the style concern you had.

After the patch the following style will be allowed:

Constructor( // Arguments too long to fit on the same line
SomeArgument some_argument,
SomeOtherArgument some_other_argument) :

some_argument_(some_argument),
some_other_argument_(some_other_argument)
{
}

I’m new to the process and the tools. I’ve submitted a very small patch before, hopefully will be relatively uncontroversial. It updates the test and should ease the process and clarify the patch for the feature: http://reviews.llvm.org/D5346

For the feature itself, I’ll submit one patch after the process for this review is completed.

Cheers,

Jean-Philippe.

Not entirely sure what advise you are looking for.
My thoughts:

  • I am happy to accept a patch provided is has sufficient unit tests
  • I think this should go in as a single patch, I don’t see a need for “a set of small patches”
  • Personally, I think this style is bad as it makes it harder to distinguish wrapped constructor arguments from initializers
  • In particular, how do you indent:

Constructor( // Arguments too long to fit on the same line
SomeArgument some_argument,
SomeOtherArgument some_other_argument) :
some_argument_(some_argument),
some_other_argument_(some_other_argument) {
}

Is this style used in any large project or widely used style guide?

I’ve worked on a large (closed source) project that used this style. These lists got line continuation indent (4 space) rather than scope indent (2 space) on that project.

In article <CAK_tg0xYoOtEuHc3jaFO7-xF_hyTGFR+4D-+xK4MbNa9F6ZavA@mail.gmail.com>,
    Daniel Jasper <djasper@google.com> writes:

Is this style used in any large project or widely used style guide?

For clang-format to be useful as an adjunct to source-to-source
transformation tools (i.e. refactoring tools), it needs to move
towards supporting many varieties of formatting preferences, not just
those mentioned in any style guide or used in any large project.

For instance, to be useful in Visual Studio, a refactoring tool should
support all the existing formatting options available in VS so that
refactored code can conform to the user's formatting preferences and
doesn't need to be reformatted again after refactoring. (It's *way*
too easy to introduce a subtle bug while manually reformatting code
IMO.)

Daniel, did you raise this issue as a means of prioritizing changes to
clang-format, or did you mean to imply that clang-format should not
become as feature rich as the set of options provided by Visual Studio?

Both. Prioritizing styles that are used in large open-source projects is
obvious.

However, we simply cannot support any single format option that another
formatter/IDE has chosen to be valuable. The sheer number of combinatory
options will make maintenance impossible. I'd rather support a much
narrower set of styles well instead of trying to make everybody happy and
failing. If that makes people change their style or else they can't use
automatic refactoring tools, I can live with that (I see the problem, but I
believe this to be the right direction).

Now, there is a decision to make for each style option. As a rough
guideline, an option is acceptable if:
- It is trivial.
- Somebody is willing to contribute a patch complete with tests and
maintain it.
- The option is necessary for a widely used open style guide, in which case
the core clang-format team will eventually put in the time and implement it.

In article <CAK_tg0wGyXx1p+1ng2sHuAkH5doqd1Lmf=-1PBrG_kY2rAD0yg@mail.gmail.com>,
    Daniel Jasper <djasper@google.com> writes:

>
> In article <
> CAK_tg0xYoOtEuHc3jaFO7-xF_hyTGFR+4D-+xK4MbNa9F6ZavA@mail.gmail.com>,
> Daniel Jasper <djasper@google.com> writes:
>
> > Is this style used in any large project or widely used style guide?
>
> Daniel, did you raise this issue as a means of prioritizing changes to
> clang-format, or did you mean to imply that clang-format should not
> become as feature rich as the set of options provided by Visual Studio?
>

Both. Prioritizing styles that are used in large open-source projects is
obvious.

However, we simply cannot support any single format option that another
formatter/IDE has chosen to be valuable.

I think it is reasonable to say that clang-format should be able to
format code according to the default settings of popular IDEs. Surely,
those fall into the "widely used style" category. (For me, this means:
VS, Xcode, and Eclipse CDT, but I can become convinced that more IDEs
should be added to that list.)

In my experience, your average developer adapts more to the default
formatting provided by their IDE than they adapt the IDE to their
preferred formatting.

Now, there is a decision to make for each style option. As a rough
guideline, an option is acceptable if:
- It is trivial.
- Somebody is willing to contribute a patch complete with tests and
maintain it.
- The option is necessary for a widely used open style guide, in which case
the core clang-format team will eventually put in the time and implement it.

Yes, my thinking was that "if you want more fancy formatting options,
you should be willing to pay for them." as in your 2nd option listed
above. I say this as someone for whom the existing styles and
options provided by clang-format don't make me want to run my code
through it ;-).

I would love to see clang-format being so awesome that every refactoring
tool developer just uses it without thinking twice. What we have is a
great start, but we're not there yet IMO.