Re: attack of silly coding standard?
In article <8m5h5eFmrqU10@mid.individual.net>,
Ian Collins <ian-news@hotmail.com> wrote:
On 12/ 7/10 01:55 PM, Keith H Duggar wrote:
On Dec 6, 5:29?????pm, Ian Collins<ian-n...@hotmail.com> wrote:
On 12/ 7/10 11:08 AM, Bob wrote:
On Dec 6, 7:07 pm, Ian Collins<ian-n...@hotmail.com> ?????wrote:
On 12/ 7/10 05:27 AM, James Kanze wrote:
SESE is used to make it easier to reason about programming logic.
If there's only one return, for example, it's easier to verify
that the post-conditions are met.
By inspection yes, by testing, no.
Inspection is important in writing, understanding and maintaining
code, is it not?
I was probably too strong there, I should have said "By inspection
maybe". ?????Checking preconditions and retuning early can make the
code easier to inspect and verify.
Let's bring some concreteness to the debate. Give me an example from
your /real world/ code of a function having at least several
interesting lines and multiple returns that you think is "better" for
having multiple returns.
I'm not really fussed one way or the other. All I am arguing against
is the dogmatic position that single return is better. In my own code
I use what I consider best fits the problem.
Anyway, here's one where I used multiple returns:
const Entries&
Ldif::getEntriesByOu( const std::string& ou ) const
{
if( ou == "all" )
{
return entries;
}
EntriesByName::const_iterator i = entriesByOu.find( ou );
if( i != entriesByOu.end() )
{
return i->second;
}
else
{
throw std::runtime_error( ou+": entries not present" );
}
}
I think there was an earlier post in this thread that was a fairly good
example of when to use multiple returns as well.
To Kieth, challenging someone to come up with a function where using
multiple returns is more reasonable than a single return is only useful
if you are ready to assert that no such function exists. Only the most
dogmatic of us would go that far.
That said, and without specifically calling out the above as poor in any
way, and without fully understanding what this function is supposed to
do conceptually. I likely wouldn't have written it that way. I would
likely have written something like:
// The Assert function is from TC++PL section 24.3.7.2
class MissingEntry : public std::exception { };
const Entries&
Ldif::getEntriesByOu(const std::string& ou) const
{
EntriesByName::const_iterator i = entriesByOu.find(ou);
Assert<MissingEntry>(ou == "all" || i != entriesByOu.end());
return ou == "all" ? entries : i;
}
I grant that this version requires the find to be called every time,
even if ou == "all", and this version uses the conditional operator
which is hated by many, but there you go.
One problem I have with the above function as a concept is that it
requires the calling function(s) to keep track of, or otherwise know
what is contained in, entriesByOu (unless it always sends "all" to the
function.) This seems like an inappropriate distribution of
responsibilities to me. But maybe the contents of entriesByOu is
embodied in some program wide invariant, or maybe this function is
private within the class.