[dev] [cvs] commit: framework/Horde/Horde ErrorHandler.php

[Michael M Slusarz]

Quoting Chuck Hagenbuch <chuck at horde.org>:

[snip]

> Why not so good? My reading is that you're bailing out as quickly as
> possible for irrelevant conditions - not so much for speed as for
> leaving the main method body clear (and not deeply indented) from
> preliminary checks.
>
>> function() {
>>  ...
>>  if (!$foo) {
>>    $foo2 = a;
>>  }
>> }
>>
>> (better).
>
> I get that you prefer it, and I don't really feel strongly about this,
> but I am curious *why* you think it's better.

Guess it goes back to when I first learned programming.  Especially  
when dealing with others looking at your code, the expectation should  
be a) the return value should be at the bottom of the function oand b)  
the code should execute all the way to the bottom of the function.   
The second you start short-circuiting higher in the function, it can  
become difficult to reliably and easily follow/debug code.  Somewhat  
of a principle of least astonishment issue.

Then again, my education went so far that we were never allowed to  
"cheat" by using any sort of break/continue/jump statement either -  
all code should be written such that the for/while expression should  
determine when the loop should be terminated.  Obviously there is a  
trade off between theory and readability - not calling return high up  
in the function might result in a gigantic nested block which is  
physically hard to read.  The education might be a lot more form over  
function in this regard.

But I still believe especially at the bottom of the function, it  
doesn't make sense to return when you are only going to do one more  
action.

michael

-- 
___________________________________
Michael Slusarz [slusarz at horde.org]