Another vote for the above
> if (fast_path_applicable) {
> result = fast_path();
> } else {
> result = slow_path();
> }
>
> return (result);
on the grounds of maintainability and clarity. I am not a bigot about
single-exits but this would actually be more debuggable too. Hugo's
original B was just *bizarre* if not outright dangerous for all sorts
of reasons.
On Hugo's second question, well yes different languages have different
capabilities.
So in perl one could boil the whole thing down to
my $result = ($fast_path_applicable?) $fast_path() : $slow_path() ;
return $result;
Of course if 'fast_path' was specified to always be present and
executable, simply returning failure if fast_path_applicable was not
true, then the perl jester is tempted to say
return fast_path() || slow_path() ; # ;-)
And in a Quantum language you would just say what the heck and execute
both of them in parallel anyway ;-)
On 08/06/2009, Simon Capstick <si...@pscomputer.co.uk> wrote:
> Vic wrote:
>>> Assume that the fast path is a single expression, and the slow path
>>> is at least tens of lines of code. Why would you pick one style over
>>> the other?
>>
>> I wouldn't use either of the above.
>>
>> Style A has multiple returns from the function. That's one of those things
>> that's just fine right up until it isn't; code grows as different people
>> work on it, and sooner or later, you can't see both returns on the same
>> page. That's when mistakes happen.
>>
>> Style B evaluates both fast_path and slow_path results if fast_path is not
>> applicable. This might be an error (side effects are not mentioned), might
>> cause other problems (*Why* is fast_path not applicable? Because it
>> hangs?), but will almost certainly be slower than not evaluating the
>> fast_path result.
>>
>> So, given that we *have* to have one branch operation, I'd do a very
>> simple
>>
>> if (fast_path_applicable) {
>> result = fast_path();
>> } else {
>> result = slow_path();
>> }
>>
>> return (result);
>>
>> It might be dull to read, but it's clear, it's accurate, and it will
>> compile down to one branch taken - which is optimal for the general case -
>> unless the particular architecture can do non-branching conditionals.
>>
>> Vic.
>>
>>
>
> Thanks Vic - you saved me from typing it myself. I use the above style
> whenever possible. So much easier to maintain in the long run.
>
> Simon
>
> --
> Please post to: Hampshire@mailman.lug.org.uk
> Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire
> LUG URL: http://www.hantslug.org.uk
> --------------------------------------------------------------
>
--
regards,
Victor Churchill, Qonnectis
--
Please post to: Hampshire@mailman.lug.org.uk
Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire
LUG URL: http://www.hantslug.org.uk
--------------------------------------------------------------
