[cfe-dev] clang-format and "ASCII art" formatting

Daniel Jasper djasper at google.com
Fri Dec 7 10:10:57 PST 2012


Well in this case yes, but it is only one of many. And even in this
case the question is, how does a formatter know when to not use the
usual style of break-before-return or even align all of the return
statements to the same column.

An alternative argument might be that the benefit of automated
formatting just outweighs the cost of a few cases that could be made
"more readable". But these are decisions that have to be made for
projects and I wanted to get input. So far, we have 3 votes against it
and I am happy not to implement :-).

On Fri, Dec 7, 2012 at 7:03 PM, Nico Weber <thakis at chromium.org> wrote:
> On Fri, Dec 7, 2012 at 9:54 AM, Daniel Jasper <djasper at google.com> wrote:
>> First of all, I personally agree and I would not use this feature.
>> Obviously, if companies / projects decide not to it, they don't have
>> to (we can build style / runtime / compile options into clang-format
>> to forbid it).
>>
>> I guess, I am actually asking more specifically about the LLVM project
>> itself and whether it would benefit from such an option. I want to
>> prevent a situation where an LLVM/Clang developer would like to use
>> clang-format, "but it always messes up this one part so badly".
>
> Wouldn't that just be a bug in the formatter though? Do you think
> there are many cases it just won't be able to get right? The code you
> linked to looks like something an automated formatter should be able
> to produce.
>
>>
>> On Fri, Dec 7, 2012 at 6:49 PM, Manuel Klimek <klimek at google.com> wrote:
>>> On Fri, Dec 7, 2012 at 6:40 PM, Nico Weber <thakis at chromium.org> wrote:
>>>>
>>>> On Fri, Dec 7, 2012 at 8:18 AM, Daniel Jasper <djasper at google.com> wrote:
>>>> > Hi all,
>>>> >
>>>> > although I think we can make clang-format (clang/lib/Format) format more
>>>> > and
>>>> > more pieces of C++ according to a specific style, I am convinced that
>>>> > there
>>>> > are cases where automatic formatting is not the right solution.
>>>> >
>>>> > An example is:
>>>> > http://clang.llvm.org/doxygen/ParseExpr_8cpp-source.html line 60-90.
>>>> > Here,
>>>> > careful human thought leads to much more readable code then simply
>>>> > following
>>>> > a style guide.
>>>> >
>>>> > In order to handle such cases and still be able to auto-format entire
>>>> > files,
>>>> > I propose to add certain markers around areas of a file that
>>>> > clang-format
>>>> > should not touch.
>>>>
>>>> In my opinion, the main advantage of an autoformatter is that its
>>>> output can be declared as canonical and that in organizations that do
>>>> that nobody needs to argue about indentation anymore. If you provide a
>>>> formatting escape hatch, you lose that property.
>>>
>>>
>>> This feature would not benefit organizations as much as it might benefit
>>> small open source projects.
>>>
>>> Cheers,
>>> /Manuel



More information about the cfe-dev mailing list