[GSoC 2012] Coding style checker proposal

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

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 //
[2] LLVM Coding Standards // http://llvm.org/docs/CodingStandards.html

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.

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:


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).



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

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 :slight_smile: