Re: Real world coding standards implementation feedback

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


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


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).


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.

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.