Writing bulletproof code

[The Directive]

How do you make your code bulletproof? For example, I make my function
bulletproof by validating every argument passed to the function. I
ensure the arguments are within the expected ranges. This causes
multiple validation at different levels and so there's a slight
decrease in performance (since these checks ship with release code). I
could turn off these checks (asserts) for release code but it would
not protect the code from unexpected conditions since it's impossible
to test every possible condition. My professor says that this is bad
design. He says I should design according to specs and not include so
much validation. What do you think? How do you make your code solid?
How do you test your code and ensure quality? Any advice or ideas are
appreciated.

 

[Jack Klein]

How do you make your code bulletproof? For example, I make my function
bulletproof by validating every argument passed to the function. I
ensure the arguments are within the expected ranges. This causes
multiple validation at different levels and so there's a slight
decrease in performance (since these checks ship with release code). I
could turn off these checks (asserts) for release code but it would
not protect the code from unexpected conditions since it's impossible
to test every possible condition. My professor says that this is bad
design. He says I should design according to specs and not include so
much validation. What do you think? How do you make your code solid?
How do you test your code and ensure quality? Any advice or ideas are
appreciated.

Notice that there is absolutely no mention of the C++ language in your
post, and in fact the issue you raise is 100% completely programming
language independent. Since it is a general programming question and
not a C++ language one, it really isn't topical here.

Ask it in:


....where this type of language independent discussions belong.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

 

[The Directive]

[Snip]

Notice that there is absolutely no mention of the C++ language in your
post, and in fact the issue you raise is 100% completely programming
language independent. Since it is a general programming question and
not a C++ language one, it really isn't topical here.

What about: How do you make your C++ code bulletproof? Honestly,
the question was asked within the context of C++. I expect the readers
to have common sense. For example, in C++ exceptions are a form of
error handling to make the code bulletproof and etc. Therefore, I'm
expecting to get C++ related responses.

Ask it in:


...where this type of language independent discussions belong.

Now, I must correct you. Notice that your response is not technically
100% C++ related. Therefore, it really isn't topical here.

Post it in:


My good friend, Happy New Year to you and all. eom.

 

[Marko Becirevic]

How do you make your code bulletproof? For example, I make my function
bulletproof by validating every argument passed to the function. I
ensure the arguments are within the expected ranges. This causes
multiple validation at different levels and so there's a slight
decrease in performance (since these checks ship with release code). I
could turn off these checks (asserts) for release code but it would
not protect the code from unexpected conditions since it's impossible
to test every possible condition. My professor says that this is bad
design. He says I should design according to specs and not include so
much validation. What do you think? How do you make your code solid?
How do you test your code and ensure quality? Any advice or ideas are
appreciated

Your approach is called 'Design by Contract', which is very usefull while
developing project. It always checks conditions before each method and
conditions after the method is finished, thus decreasing performance. In
release version nothing of this is checked, so there is no lack in
performance. It is very useful for checking your design model and in rapid
bug discoverings. Your profesor says that if user has to enter, let's say
number between 1 and 10, and he enters 11, then it is not your problem what
will happen.

 

[Cy Edmunds]

How do you make your code bulletproof? For example, I make my function
bulletproof by validating every argument passed to the function. I
ensure the arguments are within the expected ranges. This causes
multiple validation at different levels and so there's a slight
decrease in performance (since these checks ship with release code). I
could turn off these checks (asserts) for release code but it would
not protect the code from unexpected conditions since it's impossible
to test every possible condition. My professor says that this is bad
design. He says I should design according to specs and not include so
much validation. What do you think? How do you make your code solid?
How do you test your code and ensure quality? Any advice or ideas are
appreciated.

I think you need to distinguish between logic errors and input errors. I try
to put an exception-based error checking protocol into my code which I
expect to remain in place for the production release. I also put in a lot of
assertions which I take out for the production release.

The distinction isn't really very hard to make. There is no excuse for not
checking data you get from outside of your code -- user input, things read
from files or over the network, etc. But checks for errors which can only
arise from program bugs can be excised from the final product after a
prodigous amount of testing has been done. This will improve performance
without really compromising robustness. After all, if your program is buggy
what are you going to do about it in a released product anyway? Bad input
can be translated into user actions, but your users aren't going to debug
your program for you.

How to test code is too big a topic to cover here. The key thing is to do
it. I have come to believe that testing should actually drive code
development rather than being tacked on at the end.

 

[E. Robert Tisdale]

[Snip]

Notice that there is absolutely no mention of the C++ language in your
post, and in fact the issue you raise is 100% completely programming
language independent. Since it is a general programming question and
not a C++ language one, it really isn't topical here.

What about: How do you make your C++ code bulletproof? Honestly,
the question was asked within the context of C++. I expect the readers
to have common sense. For example, in C++ exceptions are a form of
error handling to make the code bulletproof and etc. Therefore, I'm
expecting to get C++ related responses.

Ask it in:


...where this type of language independent discussions belong.

Now, I must correct you. Notice that your response is not technically
100% C++ related. Therefore, it really isn't topical here.

Post it in:

news:comp.idon'tcare

I thought that Jack Klein's advice was appropriate.
He was trying to be helpful and polite.
You could post your question to the newsgroups that he mentions
and get very good advice about programming in general.

 

[E. Robert Tisdale]

How do you make your code bulletproof? For example, I make my function
bulletproof by validating every argument passed to the function. I
ensure the arguments are within the expected ranges. This causes
multiple validation at different levels and so there's a slight
decrease in performance (since these checks ship with release code). I
could turn off these checks (asserts) for release code but it would
not protect the code from unexpected conditions since it's impossible
to test every possible condition. My professor says that this is bad
design. He says I should design according to specs and not include so
much validation. What do you think? How do you make your code solid?
How do you test your code and ensure quality?
Any advice or ideas are appreciated.

First, you should design your code
so that the compiler can detect the most common errors.

1. Don't improvise with existing types.
Define new types that have exactly the properties
that are required and cause the compiler to issue
diagnostic messages if you attempt to abuse them.

2. Distinguish between programming errors (bugs) and exceptions.
Exceptions are expected but unpredictable [random] events
that cannot be prevented and must be "handled" at run time.
Programming errors are unexpected but predictable events
which can only be prevented by the programmer fixing the bug
after it is detected. You can use the assert C preprocessor macro
to help you detect and locate bugs.
You should try to handle exceptions
at the point where they are first detected.
If you can't handle the exception completely
at the point where it is first detected,
you *must* return or throw and exception object which contains
all of the information required to handle the exception.
You cannot use a function which returns an exception
in an expression. You must throw (and subsequently catch)
the exception instead.

 

[Bob Jacobs]

How do you make your code bulletproof? For example, I make my function
bulletproof by validating every argument passed to the function. I
ensure the arguments are within the expected ranges. This causes
multiple validation at different levels and so there's a slight
decrease in performance (since these checks ship with release code). I
could turn off these checks (asserts) for release code but it would
not protect the code from unexpected conditions since it's impossible
to test every possible condition. My professor says that this is bad
design. He says I should design according to specs and not include so
much validation. What do you think? How do you make your code solid?
How do you test your code and ensure quality? Any advice or ideas are
appreciated.

Two books that discuss defensive programming that you might want to take a
look at:

Code Complete, Steve McConnell

Software Exorcism, Bill Blunden