12

Possible Duplicate:
A free tool to check C/C++ source code against a set of coding standards?

I am starting a c++ project involving several people I have no direct access to. We agreed on a coding style guide, which e.g. defines the casing for class members depending on the accessibility (i.e. privates in pascal case, publics and protecteds in camel case. Please, don't start discussions about the style guide. I had enough. Thank you.).

What I want to do now is to generate some reporting of style guide violations. I don't want to enforce the style guide, e.g. at commit, but I want to provide a tool which each developer can use to see where his/her code violates the style guide (if he/she wants to check it).

Do you know a tool which can do the Job?

(It needs to be able to understand some C++, e.g. to detect the accessibility of class members.)

Community
  • 1
  • 1
Knowleech
  • 973
  • 1
  • 8
  • 15
  • 2
    Try cpplint: http://google-styleguide.googlecode.com/svn/trunk/cpplint/, http://code.google.com/p/google-styleguide/ – kol May 30 '12 at 15:31
  • http://www.inspirel.com/vera/ – Alessandro Pezzato May 30 '12 at 15:32
  • 1
    This is not a duplicate. The other question asked about a FREE tool. – Ira Baxter May 30 '12 at 19:29
  • @AlessandroPezzato: OP says, "It needs to understand some C++". Vera appears to understand nothing of C++ other than the shape of lexemes. Any other understanding must be hiding in a Vera rule, and C++ is a really complicated language. Any complex condition will not be practical to encode as a vera rule. – Ira Baxter May 30 '12 at 19:36
  • @Ira Baxter: Yes, that's true: vera++ provides more or less a lexer for the C++ tokens. I've mentioned that it sometimes was a bit painful to implement the rules in TCL. But TCL has a powerful REGEXP interface that can be used to match even complex C++ language constructs for verifying conditions. I successfully implemented that! – πάντα ῥεῖ May 30 '12 at 22:38
  • (continuation): You can choose if you like to pay (a lot of money) for professional tools, where the providers may even charge extra for customizing to your company specific guidelines, or spend some efforts to get into the opportunities provided with a free tool. At least it took me about 1 week to implement that stuff, including to get familiar with TCL. Depends on how much your employer or customer is willing to pay to get a solution (with my case it might have been a bad deal, but I'm available for my company anyway ;o) ...) – πάντα ῥεῖ May 30 '12 at 22:39

3 Answers3

1

well, you could run your code through AStyle or Uncrustify on commit, which would at least re-format bad code to some standard. I find that's the majority problem with code commits and standards - if you reformat after commmit, it shows up as a lot of delta changes that are entirely trivial.

Otherwise, check the other SO answer.

Community
  • 1
  • 1
gbjbaanb
  • 49,287
  • 10
  • 99
  • 143
  • _I don't want to enforce the style guide, e.g. at commit, but I want to provide a tool which each developer can use to see where his/her code violates the style guide (if he/she wants to check it)_ That's not what OP was asking about. – nietaki May 30 '12 at 15:43
  • 1
    @nietaki -I know but I didn't want to simply link to the SO answer with the answer to his question, so I added a little more for him, just in case it was helpful. The other answer has all he wants. – gbjbaanb May 30 '12 at 15:46
1

I've been successfully using the vera++ tool to do this for our projects. I've wrote a number of rules (in TCL) to adopt our company style guidelines. It was a bit painful, until I came around all the false positives reported from my checks. At least it's working well now and I have integrated the reports to the Jenkins build analysis.

The reports can also be easily adopted to a custom error analysis in the Eclipse IDE.

πάντα ῥεῖ
  • 83,259
  • 13
  • 96
  • 175
  • Unfortunately I can't give away the rules checking code because it's company proprietary. But I can give some hints how to write such checks with vera++. – πάντα ῥεῖ May 30 '12 at 17:34
  • Thanks for the info. I will take a look at vera++. Just a hint on the general idea on how to distinguish between private members and other class members would be nice. – Knowleech May 31 '12 at 10:53
  • @3of4: Since vera only knows about tokens, you have to formulate that question in terms of tokens. So, find a 'class' keyword, the ID following it is a class name. Search for '{' and starting counting nesting of '{' '}' to make sure you haven't fallen outside the class. Search for private; if the nested {} count is 1, you'e found it at class level, otherwise ignore. Continue searching knowing you are in private context; any members (whose syntax is difficult) will be private; if you encounter 'public' , go back to searching for private. ... – Ira Baxter May 31 '12 at 12:55
  • ... I suspect recognizing members will be hardest, because of the arcane syntax C and C++ use as declarators, and you have to dig around to figure out which identifier in the declarator is actually the member name. YOu'll have a hard time figuring out the type, because it is likely a typedef or a class name (a simple identifier) but you have no name lookup capability. Take my suggestion with a big grain of salt; I've never touched vera. Just don't see how you can do this otherwise given its fundamental "design". – Ira Baxter May 31 '12 at 12:59
  • Yes, it basically boils down Ira's answer. I'm collecting (concatenating) the tokens to form complete statements, while keeping track of the scope using a stack. The completed statements can be inspected using several regular expressions that cover all (hope so) the possible variants of variable declarations. – πάντα ῥεῖ May 31 '12 at 13:33
  • How did you integrate Vera with Jenkins? – dangerousdave Jul 12 '12 at 14:42
  • Vera is run by the ant build script of the project. I've installed my own error parser on jenkins (groovy script) to detect and classify vera's output messages. – πάντα ῥεῖ Jul 12 '12 at 15:02
1

Style guides tends to be company-specific, and one has to write company-specific checks to achieve them.

My company offers customizable C++ style checkers, in which one can check for deprecated idioms by syntax, check that variables and types have certain properties, or verify that certain commands occur in certain orders locally. These checkers use C++ dialect precise parsers on the source code. The customization isn't easy; you need the underlying engine and some knowledge of parsing C++ programs.

It is possible to write rules that check for layout, but it is a lot of unrewarding work, and resolving such complaints isn't a productive use of programmer resource IMHO. And if you aren't going to enforce your style, why are you annoying the programmer with complaints at all? IT seems easier (as another poster noted) to simply run a layout-formatter that produces the right result at no cost to the programmer.

One of the issues with generic formatters is that being language-imprecise, they may misinterpret the source code and sometimes break it as they format, leading to compilation errors, debugging and wasted time. We also offer C++ Formatters to accomplish the formatting using the same language precise parsers as the style checker; they can't break your code during reformatting.

Ira Baxter
  • 88,629
  • 18
  • 158
  • 311