Re: Real world coding standards implementation feedback

From:

peter koch <peter.koch.larsen@gmail.com>

Newsgroups:

comp.lang.c++

Date:

Wed, 20 May 2009 16:36:30 -0700 (PDT)

Message-ID:

<f5a6a7c9-bd1f-424b-91e2-8ac2930f5677@z7g2000vbh.googlegroups.com>

On 20 Maj, 18:58, ytrem...@nyx.nyx.net (Yannick Tremblay) wrote:

In article <98a48e88-4dcd-4541-b375-11c5e7cef...@r13g2000vbr.googlegroups=

..com>,

James Kanze <james.ka...@gmail.com> wrote:

On May 20, 3:53 am, Phlip <phlip2...@gmail.com> wrote:

joshuamaurice wrote:

http://c2.com/cgi/wiki?DoNotUseAssertions

The author of which obviously doesn't understand software
engineering, or reliability issues.

I added the following verbiage, where "assertion" specifically
meant the C assert.h macro:

Step zero: Refactor comments into assertions

Good idea when possible. Preconditions, for example, should be
expressed as asssertions, when possible. Sometimes, it's not
practical for performance reasons. Something like a binary
search requires that the array passed to it be sorted; asserting
this more or less defeats the purpose of the binary search,
since it requires linear execution time. And of course, some
things simply cannot be verified from within the program. (A
precondition of, say, std::vector<>::push_back is that no other
thread is currently accessing the vector; that if other threads
can access the vector, then the accesses must be externally
synchronized.)

I'm not sure about your use of "refactor" here, though. Just
because you add assertions (in the implementation of the
function, thus in the source file) doesn't mean you should
remove the comments (in the header file).

Step one: Refactor assertions out of the code into unit tests

Again, I question the use of the word "refactor". And I'm not
too sure what you're really asking for: client code of the
function with assertions should definitely have unit tests to
ensure that it never triggers the assertion. But testing isn't
perfect, shit happens, and the exception should stay in so that
it triggers if an error occurs after delivery.

Step three: Escalate the remaining assertions into program exce=

ptions

If you're talking about C++ exceptions here, this is definitely
wrong. An assertion is a check for a possible software error.
If there is a software error, you want to terminate the program
as quickly as possible, executing as little additional code as
possible. The last thing you want to do is a stack walkback,
calling destructors on possibly corrupt objects.

I am with you until this last point. Here however, I have to disagree
that the only correct answer to a programming error is to terminate
the program. This is domain and requirement specific. If for
example you are writing a cash point sofware, you may decide that in
case of programming error, the best thing to do is to terminate the
program. Not wanting to chance corrupting anything more than they may
already have been. This might very well be the most common "best"
answer to a software error.

However, if you are writing say landing software for a
fly-by-wire Airbus, maybe terminating the software and making the
plane impossible to control would not be the correct answer.

Yannick

Which is why you have redundancy. A possible solution is to have three
systems: two identical systems in a master-slave configuration and an
independent backup system typically with far less features setting in
if both master and slave dies.

/Peter