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

[Seth Cantrell]

I think an auto-formatter that understands the language and is sufficiently smart could probably avoid many situations where overriding the dumb formatting in standard code editors is required. It could take into account more factors than just 'this is a switch statement.' It could consider how many case labels, how long they are, how long case bodies are, how much fall-through is used, etc.

And though there may be some cases where people still want to deviate I think in those situations other mechanisms for formatting parts of files rather than whole files would be better. For example I think being able to tie into revision control so a user can instruct the tool to just format the lines he's touching is valuable.


On Dec 7, 2012, at 1:10 PM, Daniel Jasper <djasper at google.com> wrote:

> 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
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev