'Twas brillig, and O. Lavell at 08/06/09 16:33 did gyre and gimble:
adam.timberlake wrote:

Im reading this post and i donnot understand how i should write my code:
Does it mean that i am to not write else statements in my ifs? or is it
just saying it is something i should avoid to rite better code?

please help me...

I happen to not agree completely with the post, because it seems to propose the use of things like "continue", "break" and "return" within control structures (the latter as opposed to at the end of a function, exclusively). Very bad practice in my opinion. Think of everything that has ever been said of "goto", it's just as bad for structured programming.

(however the use of "break" in "switch .. case" statements is an unfortunate necessity in PHP)

And in C. And there is nothing inherently *wrong* with goto. Sure it *can* lead to less readable code, but by going out of your way to avoid it's use can lead to equally unreadable code.

Just like the break statement which is a fundamental part of switch statements but also very useful to get out of infinite loops (our old favourite for (;;)) etc.

For this reason early return should not be completely discounted out of hand as a "bad programming practice" as this is simply not true.

If early return is ugly for you then you can never use other constructs in OOP like exceptions. These interrupt the code flow execution in interesting ways too (and the same for the whole break and continue statements in controlled loops)

So personally I like early return. I use it mostly to cut down brace and indentation churn. I try to keep code into 80 cols and if 40 of them are used up with indents that doesn't leave much room for the actual code!

I think with any programming structure, you just have to make sure your code is clear, obvious and readable. If you've got a function that sprawls four+ screenfulls and has returns littered throughout it, then this is obviously not very readable. Re-factoring should solve this, but just re-factoring to avoid early return will probably do very little to improve it's overall readability IMO.

In many cases early return can improve readability.

e.g. consider

$rv = false;
if ($condition)
  // ... several pages of code.
return $rv;

When reading this function, I *could* be interested in what happens if the condition is not met. In this scenario I have to scroll down and track where the brace is closed and then follow the code on from there.

Now consider this:

if (!$condition)
  return false;

$rv = false;
// ... several pages of code.
return $rv;

With this code, considering I'm interested in what happens if the condition is not met, I can satisfy my curiosity immediately without looking further.

In both cases if I was interested in the opposite, it's the same amount of tracking to look through the code itself.

As with everything in programming style, this mostly comes down to personal preference. So just stick with a style you like :)

People get almost as emotive about this topic as top-posting on mailing lists :) I'm not overly fussed. I know what i like and it doesn't offend anyone in public :p




Colin Guthrie

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to