Re: switch vs elseif

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2009-01-13 at 22:12 +0100, Jochem Maas wrote:
> Robert Cummings schreef:
> > On Tue, 2009-01-13 at 15:50 +0100, Jochem Maas wrote:
> >> Ashley Sheridan schreef:
> >>> On Mon, 2009-01-12 at 15:15 -0500, Frank Stanovcak wrote:
> >>>> I've googled, and found some confusing answers.
> >>>> I've tried searching the history of the news group, and only found info on 
> >>>> switch or elseif seperately.  :(
> >>>>
> >>>> Strictly from a performance stand point, not preference or anything else, is 
> >>>> there a benefit of one over the other?
> >>>>
> >>>>
> >>>> for($i=0;$i<3;$i++){
> >>>>     switch($i){
> >>>>         case 0:
> >>>>             header pg1 code
> >>>>         break;
> >>>>         case 1:
> >>>>             header pg2 code
> >>>>         break;
> >>>>         case 3:
> >>>>             header pg3 code
> >>>>         break;
> >>>>     };
> >>>> };
> >>>>
> >>>>
> >>>> or would that be better served using an if...elseif structure?
> >>>>
> >>>> Frank 
> >>>>
> >>>>
> >>>>
> >>> And a switch is a lot neater for dealing with these sorts of things. I
> >>> tend never to use if...elseif's at all, and use switches. Like Rob said,
> >>> you can fall into further cases below, and it's very simple to add more
> >>> at a later date. There is one place where an if...elseif would work and
> >>> a switch could not, and that is where you were performing lots of
> >>> different logic tests on different variables. 
> >> switch (true) {
> >> 	case ($x === $y):
> >> 		// something
> >> 		break;
> >>
> >> 	case ($a != $b):
> >> 		// something
> >> 		break;
> >>
> >> 	case (myFunc()):
> >> 		// something
> >> 		break;
> >>
> >> 	case ($my->getChild()->hasEatenBeans()):
> >> 		// something
> >> 		break;
> >> }
> >>
> >> evil ... but it works.
> > 
> > What is your intent if both $x === $y and $a != $b? From the above
> > example only the code for $x === y will execute. 
> 
> no shit. that would be the intention too :-)
> 
> > This is hideous from a
> > readability point of view since the first case and second case are
> > matches, but only the first will get executed. This is better
> > represented using an if/elseif/else structure to indicate the exclusion
> > of later expressions.
> 
> that is just a matter of opinion. it's no different to an if/elseif/elseif/elseif
> block functionally ... you just don't like the way it looks

No, it's not just a matter of functionality in this case. It malforms
the semantic meaning of the named expressions so that they no longer
provide clearly readable meaning.

>  ... I'd point out though that you had no trouble determining the
> code's intention correctly, and I'm sure you didn't stare at it too
> long

I'm special though ;)

> ... so I'd hazard to say it's not *that* illegible.

Yes, that's right, it's a hazard alright. A hazard to avoid by any
self-respecting developer who's not competing in a code obfuscation
contest :)

Cheers,
Rob.
-- 
http://www.interjinn.com
Application and Templating Framework for PHP


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


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux