Re: Job Interview, Did I Mess Up?
daniel_t@earthlink.net (Daniel T.) wrote (abridged):
However you make an important point. If it were the case that
"tolower(a)" represented something other than simply "lower case
a", if tolower() had side effects for example, then we would
be calling the function, in part, to cause those side effects.
If that were the case, then tolower(a) and lo_a would *not*
represent the same thing and you wouldn't be violating DRY,
that isn't the case though.
It sounds as though which version you think is clearer depends on what
tolower() does. That makes your argument a bit suspect, in my opinion.
To put it another way, there is no design rule that says
"prefer multiple exits from blocks of code," yet that is what
you seem to be advocating. (If I am wrong here, then we are
probably not that far apart in our positions.)
In my experience we are frequently faced with a choice between three
evils:
1. Adding duplicate code.
2. Adding spurious mutable state.
3. Adding extra multiple exits.
For example,
bool contains( const int *first, const int *last, int value {
while (first != last && *first != value)
++first;
return first != last;
}
this duplicates the test. We can avoid that by adding a variable to
remember the result of the test:
bool found = false;
while (first != last && !found)
found = (*first++ == value);
return found;
Or we can use multiple exits:
while (first != last)
if (*first++ == value)
return true;
return false;
So for me the dispute is over which of these is the lesser evil. I
dislike the first because it is duplicating code and because it is doing
unnecessary work. I dislike the second because it adds mutable state, and
also adds an extra test in the loop. The third sample I prefer. It seems
simplest to me: as soon as you know the answer, stop. It's simple and
efficient. It's only fault is that it offends the single-exit rule, which
is only an issue if you are dogmatic about it.
I imagine you'd prefer the first version. In this case the difference is
trivial because the test we are duplicating is trivial, but that doesn't
make it better; it just means it's worse by a trivial amount. In real
life the test to be duplicated may be more complex and expensive, which
leads us to the version with extra flags.
_Postconditions and Where to Check For Them_
Again we come back to not repeating ourselves. If the post
condition of a function can be checked by code, then it should be.
I think we can agree on that, but where should we do the
checking? Your suggestion was that this checking should be done
"at a caller site (as normally done in unit tests)."
Most functions are complex enough that they require multiple tests,
so they are generally called from multiple sites. If we want
to put the postcondition checking code in only one place (so we
don't repeat ourselves,) then the obvious place to put it is
just before the return within the function. If there is more than
one return, then we still must repeat ourselves; which is the
one thing that we have both agreed we should avoid.
In general, if there is something to be done after the loop regardless of
how it terminates, that is not part of the loop or dependent on the loop,
then it's doubtful that it belongs in the same function at all. This can
apply to post-conditions. For example:
bool contains( const int *first, const int *last, int value ) {
assert( first <= last );
bool result = contains_inner( first, last, value );
assert( result == (std::find( first, last, value ) != last) );
return result;
}
In a language like C, without exceptions, this pattern works well for
freeing resources:
bool process( const char *filename ) {
FILE *fp = fopen( filename, "r" );
if (!fp)
return false;
bool result = process_inner( fp );
fclose( fp );
return result;
}
It's an example of separation of concerns, putting the open/close in one
place and the real work in another. A benefit is that we can reuse
process_inner(), for example passing stdin.
In C++, the inner function may be virtual and the public one non-virtual.
That imposes the post-condition on derived classes, which is often what
we want from design by contract.
-- Dave Harris, Nottingham, UK.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]