Re: Real world coding standards implementation feedback
On May 20, 3:53 am, Phlip <phlip2...@gmail.com> wrote:
joshuamaurice wrote:
Profound irony: While some platforms are indulging in Mock
Abuse - using mocks to avoid improving their code
refactoring despite TDD...
...Some other platforms might not using enough Mocks for
one of their actual purposes: Simulating hardware errors so
you can TDD their handlers.
I hope you're not saying that c-style asserts killing the
process have no place in real code. I would disagree with
you sir. Are you?
My highest mission is to disagree (accurately) with anything
anyone says on the interthing. Even when I can't decipher
their polarities.
However, we might possibly find common ground somewhere in
here:
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 exceptions
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.
Am aware the count is off.
So you see that software's state is a flow, where the moment
point of software could conceivably have an assert() in live
code, in debug mode, possibly with a surprise awaiting the
end-users in production mode. Yet the flow of software
development must always trend away from that situation...
If the code has been carefully tested and reviewed, the
probability of an assertion triggering in the field is very,
very low. But you still have to keep it in there, just in
case---no process is perfect.
--
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