Could somebody tell me if he has some experience with commercials or public do
main software tool for checking source code against coding conventions ?

 4 months ago, we decided to establish a (asshort a possible) list of conventio
ns people should follow in writting C++ source code in our project.
    We had at that time the very good ELLEMTEL book, which provided some input to
 our own standards

 Well, people are following the conventions, but we are looking at some tool wh
ich could help us in providing some help both to the developer and to the QA ma
nger in our project, for checking the compliance of the produced software
against the set of rules.

 We alreday saw a demonstration of a tool called
    QA C++, distributed by 'QA systems' (NL)
 which analyses your C++ source code and generate a report on such compliance t
o your own in-house standard, to ANSII C++: it seems to be configurable enough
so that you can catch or ignore specific deviation from the standard. For insta
nce, you would like to be warned
 o- if the type of a method is explicitely written
 in front of the method (if it is 'int' then we would like to know it) or
 o- that any macro is included into brackets when used)       T
 o- ...

 It works like a compiler by analysing the code and making comparison with the
set of rules: you can select/unselect the rule you want to be applied and add n
ew rules to the predefined ones

 Also one big advantage is that you can be reported using <n> knid of metrics (
such as nb of method per class, nb of children of a class, level of hierarchy..
.) which has some interest for QA manager.

 Did somebody already has some experience with that tool in a C++ environment ?

Do you know any other packages (and who is distributing it / them) which provi
de the same service ? and may be also what it costs ?

 Thanks very much for your answer

(Q: I am trusting vendors when they say QA metrics provide some help in getting
better quality on your project - but I do not have yet this experience.
 Should you have this experience, could you convince me ? Or: how can I REALLY
convince the finance to invest n K$US in some QA metrics tool ?)




Bien a vous,
 ERIC

In article <93203.141830EPERDRIX@ESOC.BITNET>, <EPERDRIX@ESOC.BITNET>
writes:
>  Could somebody tell me if he has some experience with commercials or
> public do
> main software tool for checking source code against coding conventions
> ?
>

The problem is that there is not, yet, an ANSI standard. So it is
difficult to see how any tool can comply with it. Of course, it could
comply with the latest ANSI draft; but then, what is the point of
complying with something that is still moving?

A serious problem, in the absence of a language standard, is finding an
inspection tool which "understands" the same variant of C++ as your
compiler.

Even assuming your search is successful, another problem is being *sure*
both tools understand the same variant of C++. Your programmers will not
be happy if the inspection tool suddenly starts rejecting good C++ which
is acceptable to the compiler.

Pat

--
Pat Dey               Email:    dey@us-es.sel.de
Alcatel SEL AG. Lorenzstrasse 10, D-70435 Stuttgart, Germany
(Opinions are mine, not necessarily SEL's)

In article <1993Jul23.062141.13891@us-es.sel.de> dey@us-es.sel.de (Pat
Dey (+49 711 821 6140)) writes:

|> In article <93203.141830EPERDRIX@ESOC.BITNET>, <EPERDRIX@ESOC.BITNET>
|> writes:
|> >  Could somebody tell me if he has some experience with commercials or
|> > public do
|> > main software tool for checking source code against coding conventions
|> > ?
|> >

|> The problem is that there is not, yet, an ANSI standard. So it is
|> difficult to see how any tool can comply with it. Of course, it could
|> comply with the latest ANSI draft; but then, what is the point of
|> complying with something that is still moving?

|> A serious problem, in the absence of a language standard, is finding an
|> inspection tool which "understands" the same variant of C++ as your
|> compiler.

|> Even assuming your search is successful, another problem is being *sure*
|> both tools understand the same variant of C++. Your programmers will not
|> be happy if the inspection tool suddenly starts rejecting good C++ which
|> is acceptable to the compiler.

You should say, "acceptable to one compiler."  Which may be part of
the problem.  I would be very happy to have a tool that would tell me,
for example, that my code would only work under one interpretation of
the ARM, and so might cause problems with another compiler.

BTW, things are not as bleak as you paint them.  There *is* a subset
of the language which is sort-of usable, on most compilers.  If you
eliminate exceptions, templates, nested classes, pointers to members,
and multiple inheritance, most of your code should be portable to most
existing compilers.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <KANZE.93Jul23153955@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
>
>BTW, things are not as bleak as you paint them.  There *is* a subset
>of the language which is sort-of usable, on most compilers.  If you
>eliminate exceptions, templates, nested classes, pointers to members,
>and multiple inheritance, most of your code should be portable to most
>existing compilers.

 "And the innocent shall be slaughtered first.  Yea, but
  by their own hand."

    - from the Book of Ron
     Chapter 12, verse 17

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <KANZE.93Jul23153955@slsvhdt.us-es.sel.de>,
kanze@us-es.sel.de (James Kanze) writes:
> In article <1993Jul23.062141.13891@us-es.sel.de> dey@us-es.sel.de
> (Pat
> Dey (+49 711 821 6140)) writes:
>
> |> In article <93203.141830EPERDRIX@ESOC.BITNET>,
> <EPERDRIX@ESOC.BITNET>
> |> writes:
> |> >  Could somebody tell me if he has some experience with
> commercials or
> |> > public do
> |> > main software tool for checking source code against coding
> conventions
> |> > ?
> |> >
>
> |> The problem is that there is not, yet, an ANSI standard. So it is
> |> difficult to see how any tool can comply with it. Of course, it
> could
> |> comply with the latest ANSI draft; but then, what is the point of
> |> complying with something that is still moving?
>
> |> A serious problem, in the absence of a language standard, is
> finding an
> |> inspection tool which "understands" the same variant of C++ as
> your
> |> compiler.
>
> |> Even assuming your search is successful, another problem is being
> *sure*
> |> both tools understand the same variant of C++. Your programmers
> will not
> |> be happy if the inspection tool suddenly starts rejecting good C++
> which
> |> is acceptable to the compiler.
>
> You should say, "acceptable to one compiler."  Which may be part of
> the problem.  I would be very happy to have a tool that would tell
> me,
> for example, that my code would only work under one interpretation of
> the ARM, and so might cause problems with another compiler.
>
Agreed.

> BTW, things are not as bleak as you paint them.  There *is* a subset
> of the language which is sort-of usable, on most compilers.  If you
> eliminate exceptions, templates, nested classes, pointers to members,
> and multiple inheritance, most of your code should be portable to
> most
> existing compilers.

Such a subset is available for human programmers, yes. But I would
maintain the situation is pretty bleak if you want automated inspection
help for it. Inspection tools I've seen target the (moving) ANSI
standard instead of a (stable) subset. Don't ask me why :)

(All this assumes, of course, that automated inspection help is a good
idea: in the past, James, you have reminded me of the benefits of simple
manual inspection as part of a joint learning experience.)


Pat

--
Pat Dey               Email:    dey@us-es.sel.de
Alcatel SEL AG. Lorenzstrasse 10, D-70435 Stuttgart, Germany
(Opinions are mine, not necessarily SEL's)

In article <1993Jul26.131515.19433@us-es.sel.de> dey@us-es.sel.de (Pat
Dey (+49 711 821 6140)) writes:

|> > BTW, things are not as bleak as you paint them.  There *is* a subset
|> > of the language which is sort-of usable, on most compilers.  If you
|> > eliminate exceptions, templates, nested classes, pointers to members,
|> > and multiple inheritance, most of your code should be portable to
|> > most
|> > existing compilers.

|> Such a subset is available for human programmers, yes. But I would
|> maintain the situation is pretty bleak if you want automated inspection
|> help for it. Inspection tools I've seen target the (moving) ANSI
|> standard instead of a (stable) subset. Don't ask me why :)

|> (All this assumes, of course, that automated inspection help is a good
|> idea: in the past, James, you have reminded me of the benefits of simple
|> manual inspection as part of a joint learning experience.)

I believe strongly in the role of an interactive code review as a
means of information exchange, and as a valuable learning experience
for both the programmer and the reviewers.  But it is normal that I
compile my code before submitting it to review, and correct the errors
that the compiler reports.  The compiler is, in this sense, an
automatic code review tool.  What I would look for in a good
inspection tool would be something that would do what the compiler
does in reporting errors, only better, by warning about non-portable
constructs.  (In C++, that includes about half of the language.)  If
it could also warn about simple violations of a coding guideline
(perhaps because of a typo), so much the better.  But none of this
eliminates the need of an interactive review.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung