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

Jan Schneider jan at horde.org
Fri Mar 6 10:58:38 UTC 2009


Zitat von Michael M Slusarz <slusarz at horde.org>:

> 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.

FWIW, I've used both over the years, and I find the exit-early style  
much more readable and easier to follow. Both, because of the reduced  
indention, and because you don't have to remember which condition  
currently matches. I follow this paradigm pretty strictly now and is  
one of the first things I do during refactoring.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/



More information about the dev mailing list