'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:
http://www.talkphp.com/absolute-beginners/4237-curly-
brackets.html#post23720
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
HTHs
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
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
