[petsc-dev] Style Guide: How to format single-line if/for/while-blocks?

[Karl Rupp]

Hi Barry,

>       Can it handle code with all the CPP crap we have (how does the CPP stuff fit in the AST)? Can you make a make clangify rule in the makefile similar to make uncrustify so we can verify how fantastic it is?

I spend quite some time in verifying that the CPP is handled within 
LibTooling. I'm still not 100% sure, but I found strong indications that 
it can deal with it - maybe even properly.

>       In my reading a few months ago the LLVM/clang pretty printers sucked and there was no serious effort to make them better. (I could have misunderstood).

The problem seems to be the output writers rather than the internal 
representation. The current Formatter is basically nothing but a 
quick-and-dirty iterator over the internal representations. Even the 
option-structs are currently simply hard-coded for GoogleStyle(), etc. 
rather than accessible from outside.


>       If the clang AST to source code pretty printer doesn't produce code that we can easily edit and manipulate then it isn't any good to us. It has to generate code pretty dang close to the code we have currently used to.

It has to produce exactly the code style we agree on ;-)
Why? Because we can access the internal representation. If we can't 
achieve a full match, the description is incomplete.

Best regards,
Karli


>
> On Jan 21, 2013, at 10:10 PM, Karl Rupp <rupp at mcs.anl.gov> wrote:
>
>> Hi guys,
>>
>>>>>> Yes, though
>>>>>>
>>>>>> if (y < 12) {
>>>>>>    ierr = Something();CHKERRQ(ierr);
>>>>>> }
>>>>>>
>>>>>> takes three times as many lines. I don't care much either way, but it's
>>>>>> nice to not waste vertical space.
>>>>>
>>>>> I agree here.
>>>>
>>>> I've prefered the 1 liners as well.
>>>
>>> So, am I the only one that like the uniformity of the three-liner?
>>
>> I think I'm currently on the best way towards a rabbit hole, with uncrustify lacking the full understanding of the code an thus bound to failure. Rather than tuning regular expressions and the like, I'll spend some time on investigate further what Clang can do for us.
>>
>> First and foremost, it gives us access to the abstract syntax tree (AST), see e.g.
>>   http://clang.llvm.org/docs/IntroductionToTheClangAST.html
>> and already contains a formatter for Chromium-Style, Google-Style, LLVM-Style. The formatter for multiple Languages is currently less than 2000 lines of code and eventually far more powerful than what we need.
>>
>> Via the C-interface LibClang
>> http://clang.llvm.org/doxygen/group__CINDEX.html
>> or LibTooling
>> http://clang.llvm.org/docs/LibTooling.html
>> it's much more natural to generate *the* PETSc-representation of code irrespective of the input, and from the same AST generate e.g. the Knepley-representation of code. At the same time, Clang remains an optional dependency: One can work directly with the PETSc-representation without Clang installed.
>>
>> Also, I found that they (Clang) are indeed aiming at a full code documentation generator:
>>   http://clang.llvm.org/OpenProjects.html
>> There is already a lot of parsing of Doxygen-style comments done in Clang and accessible via the AST, so it's mostly missing output generators only. It will take more time to reach maturity, though. It may, however, be just what it needs to replace sowing in terms of Fortran stubs generation and user manual generation.
>>
>> Best regards,
>> Karli
>>
>>
>>
>