Re: Audit
On Jul 7, 5:16 pm, Richard Herring <junk@[127.0.0.1]> wrote:
In message
<fe63b3c3-2c69-4f66-a929-4c389e34b...@k1g2000yqf.googlegroups.com>,
Jonathan Lee <cho...@shaw.ca> writes
To be a good little coder I want to ensure all of my
functions pass a checklist of "robustness". To keep things
simple, I want to document each function with a string that
will indicate which of the checklist items the function has
been audited for. Something like
abcdefghiJklMnopqRsTuvwxyz
which would show that items J, M, R, and T have been checked.
Off the top of my head I came up with the list below. I
wonder if anyone has items they think should be added to the
list. Any advice welcome,
[...]
F - Floating point comparisons are safe (eg., don't check against 0.0)
There's nothing intrinsically "unsafe" about comparing
floating-point values with 0.0, if that's what your algorithm
requires.
And there's nothing intrinsically "safe" about any of the
alternatives.
What's unsafe is programming floating-point arithmetic if you
don't understand the floating-point data model or the
algorithm.
Which is generally (not just with regards to floating point) an
important issue: did the author understand the techniques he
used? Not too sure how to make that a check point, however:-).
(One important point with regards to floating point: if any code
uses floating point, one of the code reviewers should be an
expert in numeric processing.)
[...]
P - Wrap non-portable code in "#if"s and warn user with #else
The only #if's that code should contain are include guards
(which should normally automatically be inserted by the editor).
Non-portable code belongs in a separate file, in a target
dependent directory.
R - Reentrant
Q - Const Qualify object arguments
T - Thread safe
V - Virtual destructor
For the rest, there is some value in having a list of
checkpoints---in many cases, one could even arrange to check
them automatically. But they won't cover everything, and more
or less vague statements like "thread safe" don't belong in
them. On the other hand, he seems to have missed one or two
important ones:
-- All variables are initialized before use (preferrably in the
definition).
-- Functions which return a value have a return statement.
-- Don't return a reference or a pointer to a local variable or
a temporary.
(Good compilers will warn about these. Sometimes incorrectly,
however.)
I'd also set a fairly low limit to the cyclometric complexity
(with an exception for functions which consist of a single
switch with a lot of entries).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34