I think I'd go with this option too, unless the fast path was something very
simple like...
If (NULL == parameter) return NULL_POINTER_ERROR;
That way you don't have to have all the code below indented for this simple
case.
Stu.
2009/6/8 Vic <lug@???>
>
> > 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.
>
>
> --
> Please post to: Hampshire@???
> Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire
> LUG URL: http://www.hantslug.org.uk
> --------------------------------------------------------------
>
