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.
50  4653 
Konrad Palczynski <ka****@interia.pl> writes: 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."
Richard G. Riley wrote: Konrad Palczynski <ka****@interia.pl> writes:
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?
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!
Richard G. Riley wrote: Konrad Palczynski <ka****@interia.pl> writes:
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:
FYI: Splint doesn't support C++.
Robert Gamble
Richard G. Riley wrote: Konrad Palczynski <ka****@interia.pl> writes:
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:
FYI: Splint doesn't support C++.
Robert Gamble
Jack Klein <ja*******@spamcop.net> wrote:
Konrad Palczynski <ka****@interia.pl> wrote in comp.lang.c: 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
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.
In article <qm********************************@4ax.com>,
Roberto Waltman <us****@rwaltman.net> wrote: "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...
--
There are some ideas so wrong that only a very intelligent person
could believe in them. -- George Orwell
Roberto Waltman <us****@rwaltman.net> writes: Jack Klein <ja*******@spamcop.net> wrote:
Konrad Palczynski <ka****@interia.pl> wrote in comp.lang.c: 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
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.
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.
Konrad Palczynski wrote: Richard G. Riley wrote: Konrad Palczynski <ka****@interia.pl> writes:
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?
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!
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
On Mon, 26 Jun 20 (Walter Roberson) wrote: Roberto Waltman <us****@rwaltman.net> wrote:
...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 ;-)
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 */
....
On Mon, 26 Jun 2006 17:02:15 +0000 (UTC), ro******@ibd.nrc-cnrc.gc.ca
(Walter Roberson) wrote: In article <qm********************************@4ax.com>,
Roberto Waltman <us****@rwaltman.net> wrote:
"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 ;-)
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.
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...
--
Al Balmer
Sun City, AZ
In article <a0********************************@4ax.com>,
Al Balmer <al****************@att.net> wrote: On Mon, 26 Jun 2006 17:02:15 +0000 (UTC), ro******@ibd.nrc-cnrc.gc.ca
(Walter Roberson) wrote:
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.
Not offhand; I'm relying on an earlier thread, http://groups.google.ca/group/comp.l...081cf41ecbb11b
--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes
On Mon, 26 Jun 2006 19:05:41 +0000 (UTC), ro******@ibd.nrc-cnrc.gc.ca
(Walter Roberson) wrote: In article <a0********************************@4ax.com>,
Al Balmer <al****************@att.net> wrote:On Mon, 26 Jun 2006 17:02:15 +0000 (UTC), ro******@ibd.nrc-cnrc.gc.ca
(Walter Roberson) wrote:
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.
Not offhand; I'm relying on an earlier thread,
http://groups.google.ca/group/comp.l...081cf41ecbb11b
That provided the clue. It's reserved by POSIX.1. I don't think it's
reserved by the C standard.
--
Al Balmer
Sun City, AZ
Walter Roberson wrote: Al Balmer <al****************@att.net> wrote:Walter Roberson wrote:
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.
Not offhand; I'm relying on an earlier thread,
http://groups.google.ca/group/comp.l...081cf41ecbb11b
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.
Al Balmer <al******@att.net> writes: On Mon, 26 Jun 2006 17:02:15 +0000 (UTC), ro******@ibd.nrc-cnrc.gc.ca
(Walter Roberson) wrote:
In article <qm********************************@4ax.com>,
Roberto Waltman <us****@rwaltman.net> wrote:
"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 ;-)
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 (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Roberto Waltman <us****@rwaltman.net> writes: Jack Klein <ja*******@spamcop.net> wrote:
Konrad Palczynski <ka****@interia.pl> wrote in comp.lang.c: 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
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.)
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Konrad Palczynski wrote: 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.
--
Ian Collins.
Ian Collins <ia******@hotmail.com> wrote: Konrad Palczynski wrote: 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?
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)
Roberto Waltman wrote: Ian Collins <ia******@hotmail.com> wrote:
Konrad Palczynski wrote:
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?
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.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),
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.
--
Ian Collins.
Ian Collins said: Roberto Waltman wrote:
<snip> --> "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.
int casetest(const char *s, const char *t)
{
int diff = 0;
while(diff == 0 && *s != '\0' && *t != '\0')
{
if(tolower((unsigned char)*s++) != tolower((unsigned char)*t++))
{
diff = 1;
}
}
if(*s != '\0' || *t != '\0')
{
diff = 1;
}
return diff;
}
int underscoretest(const char *s, const char *t)
{
int diff = 0;
while(diff == 0 && *s != '\0' && *t != '\0')
{
while(*s == '_')
{
++s;
}
while(*t == '_')
{
++t;
}
if(*s++ != *t++)
{
diff = 1;
}
}
return diff;
}
etc etc ad nauseam.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Richard Heathfield wrote: Ian Collins said:
Roberto Waltman wrote:
<snip>
--> "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.
[comparison code snipped]
etc etc ad nauseam.
That's the easy bit, parsing the source for identifiers and comparing
them all would be more fun.
--
Ian Collins.
Ian Collins schrieb: Roberto Waltman wrote:Ian Collins <ia******@hotmail.com> wrote:Konrad Palczynski wrote:
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?
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.
Please use only C related or standard usenet abbreviations.
I assume that you are talking about eXtreme Programming.
As there are no reliable statistics or universal / general
experiences that say "'XP' is always better than the good old
way (whatever this may be, with or without code reviews)", let
us not waste time with an off-topic debate which has nothing
to do with te OP's request.
If someone is stuck with MISRA because the only customer (say,
a large automobile manufacturer) dictates the conformance, then
one uses a MISRA checker -- independently of the way the
software comes into existence. 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),
If they weren't, how would the code compile?
IIRC (I don't have the MISRA stuff at home) unique among all
legal identifiers throughout the whole programme in all
namespaces, i.e. the bad old
typedef struct foo foo;
or
struct foo {....} bar;
int foo;
are no longer is allowed. --> "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.
Parse all translation units, collect all macro and other identifiers,
throw out all underscores,
a) replace all '0'/'D' with 'O' and so on
b) uppercase them
c) sensible combination of a) and b).
Sort the whole thing for a), b), c), respectively and check for
uniqueness.
That bad? Or that it will never fail to spot problems such as
for (i=here; i<there; i++);
{
...
}
Your unit tests will flush this one.
Your lint tool or the compiler warnings do so much earlier.
Please don't misunderstand me:
Tools to check "coding standards" by no means replace proper
design, coding, and tests but they can check the stuff that
everyone else's time is too expensive for or where mechanical
dumb checking is sufficient.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Ian Collins schrieb: Richard Heathfield wrote:Ian Collins said:
Roberto Waltman wrote:
<snip>
--> "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.
[comparison code snipped]
etc etc ad nauseam.
That's the easy bit, parsing the source for identifiers and comparing
them all would be more fun.
You must be kidding. As long as you are not doing Very Bad Things
-- which you shouldn't in the first place, as we are discussing
about coding standards that disallow them ;-) -- a simple state
machine gives you
preprocessor directive lines
string literals
character literals
comments
"rest"
Throw out string literals, character literals, and comments, throw
out string and character literals from preprocessor directive lines.
Parse "rest" and preprocessor directive lines appropriately.
Use intelligent data structures and/or hashing to avoid high storage
or time consumption. Use out-of-the-box stuff for this.
This is a matter of hours if done with the right tool (say Perl or
python; heck, even awk can do that easily).
The only thing to decide is whether keywords/preprocessor directives
should be part of your identifier list and what kinds of comments etc.
are acceptable.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
In article <4g*************@individual.net>,
Ian Collins <ia******@hotmail.com> wrote: Roberto Waltman wrote:
--> "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!
Not daft in a safety critical environment: most of those rules
help prevent misreading of variables due to font representations.
--
Prototypes are supertypes of their clones. -- maplesoft
Michael Mair wrote: Ian Collins schrieb:
Richard Heathfield wrote:
Ian Collins said:
Roberto Waltman wrote:
<snip>
> --> "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.
[comparison code snipped]
etc etc ad nauseam.
That's the easy bit, parsing the source for identifiers and comparing
them all would be more fun.
You must be kidding. As long as you are not doing Very Bad Things
-- which you shouldn't in the first place, as we are discussing
about coding standards that disallow them ;-) -- a simple state
machine gives you
preprocessor directive lines
string literals
character literals
comments
"rest"
Throw out string literals, character literals, and comments, throw
out string and character literals from preprocessor directive lines.
Parse "rest" and preprocessor directive lines appropriately.
Use intelligent data structures and/or hashing to avoid high storage
or time consumption. Use out-of-the-box stuff for this.
This is a matter of hours if done with the right tool (say Perl or
python; heck, even awk can do that easily).
The only thing to decide is whether keywords/preprocessor directives
should be part of your identifier list and what kinds of comments etc.
are acceptable.
True, but the rule is from a C++ Coding Standard, which adds another
level of complexity to the parsing.
--
Ian Collins.
Michael Mair wrote: Ian Collins schrieb:
Roberto Waltman wrote:
Ian Collins <ia******@hotmail.com> wrote:
Konrad Palczynski wrote:
> 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?
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.
Please use only C related or standard usenet abbreviations.
I assume that you are talking about eXtreme Programming.
As there are no reliable statistics or universal / general
experiences that say "'XP' is always better than the good old
way (whatever this may be, with or without code reviews)", let
us not waste time with an off-topic debate which has nothing
to do with te OP's request.
Sorry if techniques for developing reliable C applications are
considered off topic here.
I was simply trying to point out there are often (but not always)
process techniques that can replace tools.
--
Ian Collins.
Ian Collins <ia******@hotmail.com> wrote: Michael Mair wrote: Ian Collins schrieb:
..... An XP team doesn't wast any time on code reviews, the practices
(collective code ownership and pair programming) take care of them.
Please use only C related or standard usenet abbreviations.
I assume that you are talking about eXtreme Programming.
As there are no reliable statistics or universal / general
experiences that say "'XP' is always better than the good old
way (whatever this may be, with or without code reviews)", let
us not waste time with an off-topic debate which has nothing
to do with te OP's request.
<OT>
I have never worked on projects using "extreme programming"
techniques, so my opinions are based only on readings on the subject
and other people reports.
Based on my inexperience, I don't accept the premise that pair
programming will have a significant impact on the quality of the code
produced. I can see that "four eyes are better than two" on spotting
logic errors, but I also believe that two people working together may
influence each other into making the same mistakes, and/or the code
may reflect compromises done to keep harmony in the team as opposed to
reflecting what each member though is the best solution for a problem.
A formal code review brings people with more of an "outsider" point
of view, more detachment and more impartiality.
Also there are projects or situations, especially in embedded systems,
(especially in *large* embedded systems,) were the extreme programming
principles of making frequent releases and involving customer feedback
are just impossible to follow. (The hardware does not exist yet, the
custom building were the hardware will be installed is not complete
yet, the wiring required to run a system simulation will be installed
2 months after the building is complete, and the customer will not
provide the 150 workers for half a day required to run a simulation
anyhow, except for a few pre-defined acceptance tests at project
milestones, determined when the contract was signed.
All this from a *real* project.)
</OT>
I was simply trying to point out there are often (but not always)
process techniques that can replace tools.
Process and tools should complement each other, but for the type of
validation I was referring to in my previous post, (syntax and naming
conventions believed to reduce the possibility of making mistakes) I
have no doubt that tools should take precedence.
Isn't "automate, automate, automate" one of the extreme programming
mottos?
With regards to the coding rule you called 'daft': ("Identifiers will
not differ by: ... The interchange of the letter 'I', with the number
'1' or the letter 'l')
1 int *port11;
2 int *port1l;
3 int *port1I;
4 int *portII;
5 int *portlI;
All this declarations are different yet, with the font my newsreader
is using, I can not tell the difference between lines 4 and 5. That
rule eliminates a potential source of errors that COULD NOT BE
DETECTED by visual inspection.
I would call it a life saver...
Roberto Waltman wrote: Ian Collins <ia******@hotmail.com> wrote:
Michael Mair wrote:
Ian Collins schrieb:
.....
An XP team doesn't wast any time on code reviews, the practices
(collective code ownership and pair programming) take care of them.
Please use only C related or standard usenet abbreviations.
I assume that you are talking about eXtreme Programming.
As there are no reliable statistics or universal / general
experiences that say "'XP' is always better than the good old
way (whatever this may be, with or without code reviews)", let
us not waste time with an off-topic debate which has nothing
to do with te OP's request.
<OT>
I have never worked on projects using "extreme programming"
techniques, so my opinions are based only on readings on the subject
and other people reports.
Based on my inexperience, I don't accept the premise that pair
programming will have a significant impact on the quality of the code
produced. I can see that "four eyes are better than two" on spotting
logic errors, but I also believe that two people working together may
influence each other into making the same mistakes, and/or the code
may reflect compromises done to keep harmony in the team as opposed to
reflecting what each member though is the best solution for a problem.
A formal code review brings people with more of an "outsider" point
of view, more detachment and more impartiality.
That's why we have collective code ownership and swap pairs every couple
of hours. Over a short time, several people will work on and thus
review the code.
Also there are projects or situations, especially in embedded systems,
(especially in *large* embedded systems,) were the extreme programming
principles of making frequent releases and involving customer feedback
are just impossible to follow. (The hardware does not exist yet, the
custom building were the hardware will be installed is not complete
yet, the wiring required to run a system simulation will be installed
2 months after the building is complete, and the customer will not
provide the 150 workers for half a day required to run a simulation
anyhow, except for a few pre-defined acceptance tests at project
milestones, determined when the contract was signed.
All this from a *real* project.)
That doesn't stop you following the other practices and you are in a
good position to release something once the hardware is ready. You can
also include the hardware developers as customers and provide them with
the code they require for their testing, when they require it.
I've managed three very successful embedded XP projects.
</OT>
I was simply trying to point out there are often (but not always)
process techniques that can replace tools.
Process and tools should complement each other, but for the type of
validation I was referring to in my previous post, (syntax and naming
conventions believed to reduce the possibility of making mistakes) I
have no doubt that tools should take precedence.
Not if your process make those mistakes far less likely. If you are
building the system test first lots of those conditions (the if (x=0)
scenario for example)just don't happen. You break a test, undo what you
did last, redo it and retest.
Isn't "automate, automate, automate" one of the extreme programming
mottos?
It is, all tests, both unit and acceptance tests are automated and run
often.
With regards to the coding rule you called 'daft': ("Identifiers will
not differ by: ... The interchange of the letter 'I', with the number
'1' or the letter 'l')
1 int *port11;
2 int *port1l;
3 int *port1I;
4 int *portII;
5 int *portlI;
All this declarations are different yet, with the font my newsreader
is using, I can not tell the difference between lines 4 and 5. That
rule eliminates a potential source of errors that COULD NOT BE
DETECTED by visual inspection.
But it would fail a test!
I would call it a life saver...
So is the test...
--
Ian Collins.
Ian Collins schrieb: Michael Mair wrote:Ian Collins schrieb:Roberto Waltman wrote:
Ian Collins <ia******@hotmail.com> wrote:
>Konrad Palczynski wrote:
>
>>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?
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.
Please use only C related or standard usenet abbreviations.
I assume that you are talking about eXtreme Programming.
As there are no reliable statistics or universal / general
experiences that say "'XP' is always better than the good old
way (whatever this may be, with or without code reviews)", let
us not waste time with an off-topic debate which has nothing
to do with te OP's request.
Sorry if techniques for developing reliable C applications are
considered off topic here.
That was not the point.
There are dumb checks computers are better at than humans.
As computer time is cheap nowadays, only the cost of buying
an appropriate tool or rolling your own counts.
The OP did not state much about the development process and
even for Extreme Programming, conformance to coding standards
controlled by tools and code reviews may be a point on the
agenda.
I was simply trying to point out there are often (but not always)
process techniques that can replace tools.
Which does not contradict what I said in
<4g*************@individual.net>.
The "off-topic debate" I wanted to avoid is the one about
the usefulness of Extreme Programming in all areas where
code is developed.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
On Wed, 28 Jun 2006 17:00:23 +1200, Ian Collins <ia******@hotmail.com>
wrote: I've managed three very successful embedded XP projects.
Would those projects not have been successful without XP?
--
Al Balmer
Sun City, AZ
"Roberto Waltman" <us****@rwaltman.net> wrote in message
news:1m********************************@4ax.com... Ian Collins <ia******@hotmail.com> wrote:Michael Mair wrote: Ian Collins schrieb: .... An XP team doesn't wast any time on code reviews, the practices
(collective code ownership and pair programming) take care of them.
Please use only C related or standard usenet abbreviations.
I assume that you are talking about eXtreme Programming.
As there are no reliable statistics or universal / general
experiences that say "'XP' is always better than the good old
way (whatever this may be, with or without code reviews)", let
us not waste time with an off-topic debate which has nothing
to do with te OP's request.
<OT>
I have never worked on projects using "extreme programming"
techniques, so my opinions are based only on readings on the subject
and other people reports.
Based on my inexperience, I don't accept the premise that pair
programming will have a significant impact on the quality of the code
produced. I can see that "four eyes are better than two" on spotting
logic errors, but I also believe that two people working together may
influence each other into making the same mistakes, and/or the code
may reflect compromises done to keep harmony in the team as opposed to
reflecting what each member though is the best solution for a problem.
A formal code review brings people with more of an "outsider" point
of view, more detachment and more impartiality.
<ot>
I have done lots of pair programming. It is one part of extreme program
that I am absolutely sure has a very solid payback.
If you have never tried it, try it.
</ot>
[snip]
Ian Collins wrote: Roberto Waltman wrote: 1 int *port11;
2 int *port1l;
3 int *port1I;
4 int *portII;
5 int *portlI;
All this declarations are different yet, with the font my newsreader
is using, I can not tell the difference between lines 4 and 5. That
rule eliminates a potential source of errors that COULD NOT BE
DETECTED by visual inspection.
But it would fail a test!
which test? i've heard rumors that not all developers achieve 100%
test coverage before the product ships.
Al Balmer wrote: On Wed, 28 Jun 2006 17:00:23 +1200, Ian Collins <ia******@hotmail.com>
wrote:
I've managed three very successful embedded XP projects.
Would those projects not have been successful without XP?
Two of them possibly, but I doubt we would have had such low defect
rates, or been able to add new features as quickly as we did.
The third, no, the requirements became very fluid and we ended up
releasing the product to one customer many months before it was
'finished' and updating their units as they required extra features.
--
Ian Collins.
tedu wrote: Ian Collins wrote:
Roberto Waltman wrote:
1 int *port11;
2 int *port1l;
3 int *port1I;
4 int *portII;
5 int *portlI;
All this declarations are different yet, with the font my newsreader
is using, I can not tell the difference between lines 4 and 5. That
rule eliminates a potential source of errors that COULD NOT BE
DETECTED by visual inspection.
But it would fail a test!
which test? i've heard rumors that not all developers achieve 100%
test coverage before the product ships.
If they are doing Test Drive Development correctly, they should.
--
Ian Collins.
On Thu, 29 Jun 2006 08:09:25 +1200, Ian Collins <ia******@hotmail.com>
wrote: tedu wrote: Ian Collins wrote:
Roberto Waltman wrote:
1 int *port11;
2 int *port1l;
3 int *port1I;
4 int *portII;
5 int *portlI;
All this declarations are different yet, with the font my newsreader
is using, I can not tell the difference between lines 4 and 5. That
rule eliminates a potential source of errors that COULD NOT BE
DETECTED by visual inspection.
But it would fail a test!
which test? i've heard rumors that not all developers achieve 100%
test coverage before the product ships.
If they are doing Test Drive Development correctly, they should.
If they implement the product correctly, they don't need to <g>.
--
Al Balmer
Sun City, AZ
Al Balmer wrote: On Thu, 29 Jun 2006 08:09:25 +1200, Ian Collins <ia******@hotmail.com>
wrote:
tedu wrote:
Ian Collins wrote:
Roberto Waltman wrote:
>1 int *port11;
>2 int *port1l;
>3 int *port1I;
>4 int *portII;
>5 int *portlI;
>
>All this declarations are different yet, with the font my newsreader
>is using, I can not tell the difference between lines 4 and 5. That
>rule eliminates a potential source of errors that COULD NOT BE
>DETECTED by visual inspection.
But it would fail a test!
which test? i've heard rumors that not all developers achieve 100%
test coverage before the product ships.
If they are doing Test Drive Development correctly, they should.
If they implement the product correctly, they don't need to <g>.
But how do they prove they have :)
--
Ian Collins.
On Thu, 29 Jun 2006 09:03:54 +1200, Ian Collins <ia******@hotmail.com>
wrote: Al Balmer wrote: On Thu, 29 Jun 2006 08:09:25 +1200, Ian Collins <ia******@hotmail.com>
wrote:
tedu wrote:
Ian Collins wrote:
>Roberto Waltman wrote:
>
>
>>1 int *port11;
>>2 int *port1l;
>>3 int *port1I;
>>4 int *portII;
>>5 int *portlI;
>>
>>All this declarations are different yet, with the font my newsreader
>>is using, I can not tell the difference between lines 4 and 5. That
>>rule eliminates a potential source of errors that COULD NOT BE
>>DETECTED by visual inspection.
>
>But it would fail a test!
which test? i've heard rumors that not all developers achieve 100%
test coverage before the product ships.
If they are doing Test Drive Development correctly, they should.
If they implement the product correctly, they don't need to <g>.
But how do they prove they have :)
Not by testing. As the old saying goes, testing can only prove the
presence of bugs, not the absence of bugs.
--
Al Balmer
Sun City, AZ
Al Balmer wrote: On Thu, 29 Jun 2006 09:03:54 +1200, Ian Collins <ia******@hotmail.com>
wrote:
Al Balmer wrote:
On Thu, 29 Jun 2006 08:09:25 +1200, Ian Collins <ia******@hotmail.com>
wrote:
tedu wrote:
>
>which test? i've heard rumors that not all developers achieve 100%
>test coverage before the product ships.
>
If they are doing Test Drive Development correctly, they should.
If they implement the product correctly, they don't need to <g>.
But how do they prove they have :)
Not by testing. As the old saying goes, testing can only prove the
presence of bugs, not the absence of bugs.
That's where we differ, when you use TDD, your units test /are/ your
live runnable specification. So if they pass, the code meets its
specification.
--
Ian Collins.
On Thu, 29 Jun 2006 09:34:53 +1200, Ian Collins <ia******@hotmail.com>
wrote: Al Balmer wrote: On Thu, 29 Jun 2006 09:03:54 +1200, Ian Collins <ia******@hotmail.com>
wrote:
Al Balmer wrote:
On Thu, 29 Jun 2006 08:09:25 +1200, Ian Collins <ia******@hotmail.com>
wrote:
>tedu wrote:
>
>>
>>which test? i've heard rumors that not all developers achieve 100%
>>test coverage before the product ships.
>>
>
>If they are doing Test Drive Development correctly, they should.
If they implement the product correctly, they don't need to <g>.
But how do they prove they have :)
Not by testing. As the old saying goes, testing can only prove the
presence of bugs, not the absence of bugs.
That's where we differ, when you use TDD, your units test /are/ your
live runnable specification. So if they pass, the code meets its
specification.
Little comfort to the customer who manages to break it, but a good
reason for making the customer responsible for the specification.
--
Al Balmer
Sun City, AZ
Al Balmer wrote: On Thu, 29 Jun 2006 09:34:53 +1200, Ian Collins <ia******@hotmail.com>
wrote:
Al Balmer wrote:
On Thu, 29 Jun 2006 09:03:54 +1200, Ian Collins <ia******@hotmail.com>
wrote:
Al Balmer wrote:
>On Thu, 29 Jun 2006 08:09:25 +1200, Ian Collins <ia******@hotmail.com>
>wrote:
>
>
>
>
>>tedu wrote:
>>
>>
>>>which test? i've heard rumors that not all developers achieve 100%
>>>test coverage before the product ships.
>>>
>>
>>If they are doing Test Drive Development correctly, they should.
>
>
>If they implement the product correctly, they don't need to <g>.
>
But how do they prove they have :)
Not by testing. As the old saying goes, testing can only prove the
presence of bugs, not the absence of bugs.
That's where we differ, when you use TDD, your units test /are/ your
live runnable specification. So if they pass, the code meets its
specification.
Little comfort to the customer who manages to break it, but a good
reason for making the customer responsible for the specification.
Yes, we normally do this by making the customer (or a proxy if there
isn't a single customer) responsible for the acceptance tests, which
validate the specification against the customer's requirements.
--
Ian Collins.
Ian Collins <ia******@hotmail.com> writes: Al Balmer wrote: On Thu, 29 Jun 2006 09:03:54 +1200, Ian Collins <ia******@hotmail.com>
wrote:Al Balmer wrote:
On Thu, 29 Jun 2006 08:09:25 +1200, Ian Collins <ia******@hotmail.com>
wrote:
>tedu wrote:
>>
>>which test? i've heard rumors that not all developers achieve 100%
>>test coverage before the product ships.
>
>If they are doing Test Drive Development correctly, they should.
If they implement the product correctly, they don't need to <g>.
But how do they prove they have :)
Not by testing. As the old saying goes, testing can only prove the
presence of bugs, not the absence of bugs.
That's where we differ, when you use TDD, your units test /are/ your
live runnable specification. So if they pass, the code meets its
specification.
I'm skeptical. I don't believe that tests of program behavior can
prove correctness.
For example, suppose the code works properly when plain char is
signed, but breaks when it's unsigned. No amount of testing can
detect such a bug *unless* (a) you test on a platform where plain char
is unsigned, or (b) you make the signedness of plain char one of the
acceptance criteria (which is possible only if you happen to think of
it).
There are plenty of potential system dependencies that are far more
subtle than the signedness of plain char. I don't see how you can
think of all of them, let alone test for all of them.
Remember that undefined behavior can always result in your program
behaving exactly as it should -- until it fails at the most
embarrassing possible moment.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Keith Thompson wrote: Ian Collins <ia******@hotmail.com> writes:
Al Balmer wrote:
On Thu, 29 Jun 2006 09:03:54 +1200, Ian Collins <ia******@hotmail.com>
wrote:
Al Balmer wrote:
>On Thu, 29 Jun 2006 08:09:25 +1200, Ian Collins <ia******@hotmail.com>
>wrote:
>
>>tedu wrote:
>>
>>>which test? i've heard rumors that not all developers achieve 100%
>>>test coverage before the product ships.
>>
>>If they are doing Test Drive Development correctly, they should.
>
>If they implement the product correctly, they don't need to <g>.
But how do they prove they have :)
Not by testing. As the old saying goes, testing can only prove the
presence of bugs, not the absence of bugs.
That's where we differ, when you use TDD, your units test /are/ your
live runnable specification. So if they pass, the code meets its
specification.
I'm skeptical. I don't believe that tests of program behavior can
prove correctness.
I agree that tests can only prove correctness on the platform where the
tests are run. That's where the Java/PHP/.NET crowd have a distinct
advantage when doing TDD.
For example, suppose the code works properly when plain char is
signed, but breaks when it's unsigned. No amount of testing can
detect such a bug *unless* (a) you test on a platform where plain char
is unsigned, or (b) you make the signedness of plain char one of the
acceptance criteria (which is possible only if you happen to think of
it).
In my shop, acceptance tests were always run on the target platform(s).
There are plenty of potential system dependencies that are far more
subtle than the signedness of plain char. I don't see how you can
think of all of them, let alone test for all of them.
No one can, that's why we use at least two levels of testing (developer,
customer acceptance and in my case, end user). Problems found in
acceptance testing require a unit test to be added in order to fix the
problem, so the unit tests become more comprehensive over time. the
signedness of char would be one of these conditions.
Remember that undefined behavior can always result in your program
behaving exactly as it should -- until it fails at the most
embarrassing possible moment.
I have too many bite marks to forget that one!
--
Ian Collins.
Keith Thompson <ks***@mib.org> wrote: Ian Collins <ia******@hotmail.com> writes: Al Balmer wrote: Not by testing. As the old saying goes, testing can only prove the
presence of bugs, not the absence of bugs.
That's where we differ, when you use TDD, your units test /are/ your
live runnable specification. So if they pass, the code meets its
specification.
I'm skeptical. I don't believe that tests of program behavior can
prove correctness.
Whereas I don't believe that correctness proofs can assert that the
program works correctly in practice.
Richard
On Fri, 30 Jun 2006 09:54:31 GMT, rl*@hoekstra-uitgeverij.nl (Richard
Bos) wrote: Keith Thompson <ks***@mib.org> wrote:
Ian Collins <ia******@hotmail.com> writes: > Al Balmer wrote:
>> Not by testing. As the old saying goes, testing can only prove the
>> presence of bugs, not the absence of bugs.
>>
> That's where we differ, when you use TDD, your units test /are/ your
> live runnable specification. So if they pass, the code meets its
> specification.
I'm skeptical. I don't believe that tests of program behavior can
prove correctness.
Whereas I don't believe that correctness proofs can assert that the
program works correctly in practice.
In the same sense - it meets the specification. Unfortunately,
specifications are often incorrect, and almost always incomplete.
--
Al Balmer
Sun City, AZ
Al Balmer wrote: On Fri, 30 Jun 2006 09:54:31 GMT, rl*@hoekstra-uitgeverij.nl (Richard
Bos) wrote:
Keith Thompson <ks***@mib.org> wrote:
Ian Collins <ia******@hotmail.com> writes:
Al Balmer wrote:
>Not by testing. As the old saying goes, testing can only prove the
>presence of bugs, not the absence of bugs.
>
That's where we differ, when you use TDD, your units test /are/ your
live runnable specification. So if they pass, the code meets its
specification.
I'm skeptical. I don't believe that tests of program behavior can
prove correctness.
Whereas I don't believe that correctness proofs can assert that the
program works correctly in practice.
In the same sense - it meets the specification. Unfortunately,
specifications are often incorrect, and almost always incomplete.
At least when you are using your tests as a runnable specification, it
will remain current and adapt to meet changes to requirements.
--
Ian Collins.
Ian Collins wrote:
Konrad Palczynski wrote:
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.
The usual hit-and-run tactics of agile/extreme programming
zealots. Great claims, no evidence.
Ian Collins wrote:
...
Sorry if techniques for developing reliable C applications are
considered off topic here.
Apology accepted.
I was simply trying to point out there are often (but not always)
process techniques that can replace tools.
When you find a more appropriate newsgroup for the
topic, please be sure to offer some substantation
rather than just argument by REPEATED ASSERTION. en******@yahoo.com wrote:
Ian Collins wrote:
>>Konrad Palczynski wrote:
>>>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.
The usual hit-and-run tactics of agile/extreme programming
zealots. Great claims, no evidence.
I'm happy with the evidence provided by the continued success of my
teams and their products. But as you said else thread, techniques for
developing reliable C applications are considered off topic here.
--
Ian Collins.
Ian Collins wrote:
en******@yahoo.com wrote:
Ian Collins wrote:
>Konrad Palczynski wrote:
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.
The usual hit-and-run tactics of agile/extreme programming
zealots. Great claims, no evidence.
I'm happy with the evidence provided by the continued success of my
teams and their products.
If you care only about whether _you're_ happy with
your conclusions, then kindly keep your opinions
to yourself. Other people are more discriminating.
But as you said else thread, techniques for
developing reliable C applications are considered off topic here.
Yes, that's why I'd added OT: in the Subject line. HELLO! This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Stefan Richter |
last post by:
Hi, after coding for days on stupid form validations -
Like:
strings (min / max length), numbers(min / max value), money(min / max
value), postcodes(min / max value), telefon numbers,
email...
|
by: Robert Baer |
last post by:
The homepage i have had up and seemingly working is:
http://oil4lessllc.com/
However, the validator has so many complaints, and being so
incompetent, i have no clue as to how to fix it all.
Would...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
| |
