[cfe-dev] [GSoC 2012] Coding style checker proposal

[Manuel Klimek]

On Fri, Apr 6, 2012 at 6:58 PM, Matthieu Monrocq
<matthieu.monrocq at gmail.com> wrote:
> Le 6 avril 2012 11:00, Holtgrewe, Manuel <manuel.holtgrewe at fu-berlin.de> a
> écrit :
>
>> Two cents from my side:
>>
>> A while back, I started to implement a code checker based on the Python
>> interface to libclang which was inspired by the Java Checkstyle tool. You
>> can find it here:
>>
>> https://github.com/holtgrewe/linty
>>
>> Meanwhile, I think, the official python bindings to libclang have been
>> replaced.
>>
>> I am in no position for mentoring a style checker based on clang but I
>> could offer for someone who wants to do this to pick my mind on my
>> experience (Mainly: Probably don't do it in Python since it's slow for large
>> programs and the interface exposed by libclang is not rich enough).
>>
>> Cheers!
>>
>> Manuel
>> ________________________________________
>> From: cfe-dev-bounces at cs.uiuc.edu [cfe-dev-bounces at cs.uiuc.edu] on behalf
>> of Henry Miller [hank at millerfarm.com]
>> Sent: Friday, April 06, 2012 3:33 AM
>> To: cfe-dev at cs.uiuc.edu
>> Subject: Re: [cfe-dev] [GSoC 2012] Coding style checker proposal
>>
>> I suspect you will get some negatives from those who know better than me,
>> appearantly there are things in work that would make the code much
>> different.
>>
>> Still on the off chance someone agrees to mentor you on this, I thought
>> I'd
>> give you some encouragement.  We really could use this where I work - some
>> people are big on style, which is nice in a lot of ways, but really a
>> pain.
>> It would be nice if something would tell us where things are wrong.
>>
>> I encourage you for the first part to start with a configuration that is
>> compatible with uncrustify.  A large part of our style problems
>> disappeared
>> once we forced a good uncrustify config on everyone.   What remains is
>> mostly
>> things like variable names.  (a class member starts with upper case and is
>> CamelCase, while a local starts with lowercase...)
>>
>> So please do continue this, but also pay attention to what others are
>> doing as
>> far as an indent type replacement so we don't end up with tools that don't
>> work well together.
>>
>> On Thursday 05 April 2012 14:31:09 ILya Pupatenko wrote:
>> > Dear LLVM/Clang community,
>> >
>> > I am awfully sorry to make my proposal so late but it was only
>> > yesterday when I was told about GSoC. So I decided that even if I have
>> > a little time before deadline, I should just give a try. I’ll describe
>> > the main idea of the proposal here and I would be thankful for any
>> > comments.
>> >
>> > One of the possible applications of Clang would be checking if the
>> > code is written well enough to be, for example, added to project
>> > codebase. Of course it is extremely difficult to determine code
>> > quality automatically, but at least it is possible to check if the
>> > code confirms the current coding standard (or may be just part of this
>> > standard). And this check is what I’d like to implement.
>> > Different coding style guides exist at the moment, for example Google
>> > has one [1], LLVM has own standard [2] and also many projects and
>> > companies have own coding rules, standards or style guides. Checking
>> > number of coding rules requires deep understanding of the code
>> > analyzed. It is not trivial even to check indentation of the code, and
>> > some checks can be really complicated. So the ability to use Clang
>> > preprocessor/parser/ASTs/etc. would be extremely useful.
>> >
>> > There are some tasks need to be done to implement the code style
>> > checker.
>> > 1) It is important to determine flexible and general way to declare
>> > coding standards as a collection of different rules. Some often-used
>> > basic rules should be determined.
>> > 2) Every check should be implemented separately and independently.
>> > That’s why some code to check standard selected, call corresponding
>> > checks (probably providing some parameters to them) and display/save
>> > check results is needed.
>> > 3) Several basic checks are to be implemented.
>> > 4) Also an automatic standard-compliant formatting algorithm may be
>> > implemented.
>> >
>> > This project is probably not very complicated but I suppose that
>> > smaller task has greater chances to be finished successfully.
>> >
>> > -- Ilya
>> >
>> > [1] Google C++ Style Guide //
>> > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
>> > [2] LLVM Coding Standards // http://llvm.org/docs/CodingStandards.html
>> >
>
>
> This is certainly a very good idea (especially the reformatting), having
> this run prior to commits would really help in avoiding "style-warts" and
> would greatly simplify the life of contributors since each project has its
> own guidelines...
>
> As said, the tooling architecture is being reworked to facilitate writing
> tool (automating most of the process), Manuel Klimek from Google is leading
> the effort. I have attempted to put him in copy so he can chip in and tell
> you how much is done/is left.

I have mailed with Doug and he thinks we'll get the tooling
infrastructure in shape before GSoC. If a proposal is accepted that
would fit within the overall tooling strategy, I'm happy to mentor or
consult and make sure everybody's running into the same direction :)

Cheers,
/Manuel