automated coding standard validation?

[Konrad Palczynski]

I am looking for tool to validate conformity to defined coding standard.
I have already found Parasoft's C++ Test, but it is quite expensive. Is
there any Open Source alternative? I do not need GUI, fancy reports nor
predefined sets of rules.

 

[Richard G. Riley]

I am looking for tool to validate conformity to defined coding
standard. I have already found Parasoft's C++ Test, but it is quite
expensive. Is there any Open Source alternative? I do not need GUI,
fancy reports nor predefined sets of rules.

Just out of interest, if you dont have rules, how will you define your
particular coding standards?

If you're interested in static checking of C/C++ then take a look at
splint at:

http://www.splint.org

Its free and its multi-platform.

"Splint is a tool for statically checking C programs for security
vulnerabilities and coding mistakes. With minimal effort, Splint can be
used as a better lint. If additional effort is invested adding
annotations to programs, Splint can perform stronger checking than can
be done by any standard lint."

 

[Jack Klein]

I am looking for tool to validate conformity to defined coding standard.
I have already found Parasoft's C++ Test, but it is quite expensive. Is
there any Open Source alternative? I do not need GUI, fancy reports nor
predefined sets of rules.

http://www.gimpel.com

 

[Konrad Palczynski]

Just out of interest, if you dont have rules, how will you define your
particular coding standards?

Sorry. I meant I do not need sets of rules to be included. I will define
them myself to follow my (client's) coding standard.

If you're interested in static checking of C/C++ then take a look at
splint at:

http://www.splint.org

Its free and its multi-platform.

Splint + Indent will probably be my choice. Thanks!

 

[Robert Gamble]

Just out of interest, if you dont have rules, how will you define your
particular coding standards?

If you're interested in static checking of C/C++ then take a look at
splint at:

FYI: Splint doesn't support C++.

Robert Gamble

 

[Robert Gamble]

Just out of interest, if you dont have rules, how will you define your
particular coding standards?

If you're interested in static checking of C/C++ then take a look at
splint at:

FYI: Splint doesn't support C++.

Robert Gamble

 

[Roberto Waltman]

http://www.gimpel.com

PC-Lint, (which I purchased) is an excellent product, but if I
understood the OP correctly, this is not what is requested.
"lints" does not cover naming conventions.

Rules such as:
* All global variables must have names ending in "_g"
* All function names in package XYZ must begin with "XYZ_"
* All structures declarations must have a matching typedef
ending with "_t"
can not be verified by lint, pc-lint, etc.

The only tool I know that could do this was Programming Research's
QA-C. ( http://www.programmingresearch.com/ )
It is *very* expensive.

I was thinking of writing my own, based on the LCC parser. Like many
of my ideas/projects this one is at the beginning of its eight year
gestation period.

 

[Walter Roberson]

"lints" does not cover naming conventions.

Rules such as:
* All global variables must have names ending in "_g"
* All function names in package XYZ must begin with "XYZ_"
* All structures declarations must have a matching typedef
ending with "_t"
can not be verified by lint, pc-lint, etc.

The _t suffix is reserved in current standards, so one might want
to check for the exact opposite ;-)

One difficulty is that the rules need to be different for "user"
definitions and "implementation" definitions; perhaps even turned off
for implementation include files, but on for user include files.
Then one hits the question of what to do with third-party libraries
(say, openssl), which also have to be exempted but not in a way
that allows the local coders to bypass checking by simply putting
the include files into another directory...

 

[Richard G. Riley]

PC-Lint, (which I purchased) is an excellent product, but if I
understood the OP correctly, this is not what is requested.
"lints" does not cover naming conventions.

Rules such as:
* All global variables must have names ending in "_g"
* All function names in package XYZ must begin with "XYZ_"
* All structures declarations must have a matching typedef
ending with "_t"
can not be verified by lint, pc-lint, etc.

True, but "coding standards" are frequently "development standards"
which do require a "purification process" : nothing wrong in being aware
of it for C anyway. I see that van Der Linden espouses regular and
thorough use of Lint'like checks : its certainly something that would
benefit any processes being put in place with multiple programmers and
large legacy/developing/distributed code base.

Ive never used splint with c++ : I know it can check for c++ keywords and
there was a project for a C++ front end in the works sometime back.

 

[Robert Gamble]

Sorry. I meant I do not need sets of rules to be included. I will define
them myself to follow my (client's) coding standard.


Splint + Indent will probably be my choice. Thanks!

Don't plan on using Splint if you will be writing C99 code, much of C99
doesn't appear to be supported in the latest version of splint (which
was updated 3 years ago which brings us to the fact that Splint is no
longer actively maintained).

Robert Gamble

 

[Roberto Waltman]

The _t suffix is reserved in current standards, so one might want
to check for the exact opposite ;-)

Correct, that was a typo. (I've used _s for structures, _u for unions
and _e for enums.)

One difficulty is that the rules need to be different for "user"
definitions and "implementation" definitions; perhaps even turned off
for implementation include files, but on for user include files.
Then one hits the question of what to do with third-party libraries
(say, openssl), which also have to be exempted but not in a way
that allows the local coders to bypass checking by simply putting
the include files into another directory...

pc-lint address this problem by allowing embedding commands in regular
C comments.

For example, "//lint -e41" will disable reporting of: "41:
Redefinition of symbol 'Symbol' -- A parameter of either a function or
a macro is being repeated."

"//lint !e41" disables is for the current line only.

"//lint -e(41,960)" disables warnings 41 and 960 for the following
expression only.

"//lint -e{41,960}" ditto for the next statement.

So this three patterns will squelch warnings in a "foreign" header
file:

A)
#include "offensive_code.h" //lint !e(xxx,yyy,zzz...)

B)
//lint -e(xxx,yyy,zzz...)
#include "offensive_code.h"
//lint +e(xxx,yyy,zzz...)

C)
#include "offensive_code_lint_switches.h" /* header file containing
relaxed lint settings for foreign headers */
#include "offensive_code.h"

#include "normal_code_lint_switches.h" /* header file containing
standard lint settings for production code */
....

 

[Al Balmer]

The _t suffix is reserved in current standards, so one might want
to check for the exact opposite ;-)

Can you point to a reference for that? I can't seem to find it, except
for the restriction on names beginning with int or uint and ending
with _t.

 

[Walter Roberson]

Can you point to a reference for that? I can't seem to find it, except
for the restriction on names beginning with int or uint and ending
with _t.

Not offhand; I'm relying on an earlier thread,
http://groups.google.ca/group/comp.lang.c/msg/4f081cf41ecbb11b

 

[Al Balmer]

Not offhand; I'm relying on an earlier thread,
http://groups.google.ca/group/comp.lang.c/msg/4f081cf41ecbb11b

That provided the clue. It's reserved by POSIX.1. I don't think it's
reserved by the C standard.

 

[Roberto Waltman]

Not offhand; I'm relying on an earlier thread,
http://groups.google.ca/group/comp.lang.c/msg/4f081cf41ecbb11b

This is the only one I am aware of. Still, it sounds like good advice
to avoid such names to avoid potential conflicts in the future.

-----------------------------------------------

7.26.8 Integer types <stdint.h>

Typedef names beginning with int or uint and ending with _t may be
added to the types defined in the <stdint.h> header. Macro names
beginning with INT or UINT and ending with _MAX, _MIN, or _C may be
added to the macros defined in the <stdint.h> header.

 

[Keith Thompson]

Can you point to a reference for that? I can't seem to find it, except
for the restriction on names beginning with int or uint and ending
with _t.

I *think* it's a POSIX thing (which could be relevant for the original
poster, even though it's strictly off-topic here).

 

[Keith Thompson]

PC-Lint, (which I purchased) is an excellent product, but if I
understood the OP correctly, this is not what is requested.
"lints" does not cover naming conventions.

Rules such as:
* All global variables must have names ending in "_g"
* All function names in package XYZ must begin with "XYZ_"
* All structures declarations must have a matching typedef
ending with "_t"
can not be verified by lint, pc-lint, etc.

I doubt that the OP has any real control over what rules are to be
enforced, but the requirement for matching typedefs for structures
is, IMHO, a bad idea. If you want a structure type named "foo",
declare it and refer to it as "struct foo" (likewise for "union bar"
and "enum baz"). A typedef merely creates an alias for something
that already has a perfectly good name.

The only exception would be for a structure implementing a truly
abstract type, where code using the type should not depend on the fact
that it's a structure. In that case only, I would use a typedef for a
structure.

(Disclaimer: This viewpoint is not universally accepted.)

 

[Ian Collins]

I am looking for tool to validate conformity to defined coding standard.
I have already found Parasoft's C++ Test, but it is quite expensive. Is
there any Open Source alternative? I do not need GUI, fancy reports nor
predefined sets of rules.

Why use a tool at all? Just adopt some agile practices such as
collective code ownership and pair programming. Way more effective than
a tool.

 

[Roberto Waltman]

Why use a tool at all?

To produce fast, consistent, reliable results, (at least between the
tools capabilities,) without wasting programmers time.

I'd rather see that the time spent in code reviews is used to find
logical errors, non-conformance with specs, etc. while leaving
anything that could be automated to verification tools.

Just adopt some agile practices such as
collective code ownership and pair programming.
Way more effective than a tool.

Not at all. Unlike a tool, no programmer duet, (or trio, or quintet,)
can guarantee that it will always detect violations to rules such as:

--> "struct tag names must be unique identifiers"
(MISRA C Guidelines 2004,
Rule 5.4),

--> "Identifiers will not differ by:
* Only a mixture of case
* The presence/absence of the underscore character
* The interchange of the letter 'O', with the number '0' or the
letter 'D'
* The interchange of the letter 'I', with the number '1' or the
letter 'l'
* The interchange of the letter 'S' with the number '5'
* The interchange of the letter 'Z' with the number '2'
* The interchange of the letter 'n' with the letter 'h'. "
(Joint Strike Fighter Air Vehicle C++ Coding Standards 2005,
Rule 48)


Or that it will never fail to spot problems such as

for (i=here; i<there; i++);
{
...
}

(Violates MISRA 14.8)

 

[Ian Collins]

To produce fast, consistent, reliable results, (at least between the
tools capabilities,) without wasting programmers time.

I'd rather see that the time spent in code reviews is used to find
logical errors, non-conformance with specs, etc. while leaving
anything that could be automated to verification tools.

An XP team doesn't wast any time on code reviews, the practices
(collective code ownership and pair programming) take care of them.

Not at all. Unlike a tool, no programmer duet, (or trio, or quintet,)
can guarantee that it will always detect violations to rules such as:

--> "struct tag names must be unique identifiers"
(MISRA C Guidelines 2004,
Rule 5.4),

If they weren't, how would the code compile?

--> "Identifiers will not differ by:
* Only a mixture of case
* The presence/absence of the underscore character
* The interchange of the letter 'O', with the number '0' or the
letter 'D'
* The interchange of the letter 'I', with the number '1' or the
letter 'l'
* The interchange of the letter 'S' with the number '5'
* The interchange of the letter 'Z' with the number '2'
* The interchange of the letter 'n' with the letter 'h'. "
(Joint Strike Fighter Air Vehicle C++ Coding Standards 2005,
Rule 48)

What a daft rule! I'd like to see a tool that can enforce that one.

Or that it will never fail to spot problems such as

for (i=here; i<there; i++);
{
...
}

Your unit tests will flush this one.