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

Matthieu Monrocq matthieu.monrocq at gmail.com
Fri Apr 6 09:58:59 PDT 2012


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.

-- Matthieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120406/d3426b32/attachment.html>


More information about the cfe-dev mailing list