Switch
<h2>Introduction to the syntax and context of applicability of the switch construct</h2> <p>Now let's examine the switch construct more closely, and also compare it with the intuitive and popular if-else-if-else construct. If you recall the conditionals example in the conditionals-2 course, we cited a scenario where a person had to travel from Brooklyn Bridge to the Statue of Liberty by bus, and wanted to know how to make use of the change available. The pseudo-code illustrating their decision-making appeared something like:</p> <i>if(denomination == "quarters"){ </i> <i>Change = 2Q; </i> <i>}else if(denomination == "dimes"){ </i> <i>Change = 5D; </i> <i>}else if(denomination == "nickels"){ </i> <i>Change = 10N; </i> <i>}else if(denomination == "pennies"){ </i> <i>Change = 50P; </i> <i>}else{</i> <i>assWalk = true; </i> <i>}</i> <p>So here we have a case where a single identifier / <a href="/courses/video/5/157/Using-Variables.html">variable</a> which has some content, is being successively compared to several values in a cascading if-else-else-if construct. One has the chance to get smart here, and the language designers understand this too. Now don't get me wrong: there is no logical <a href="/courses/video/4/155/Error-1067-Implicit-Coercion.html">error</a> in this piece of code whatsoever. It's perfectly fine. But correctness in logic is not the only criteria for judging software.</p> <p>Often software is developed by a team of architects, managers, developers, testers and deployment engineers. Frequently, code that's written has to be reviewed by others; it also turns out that initial developers might not be the ones maintaining or enhancing it. People come and go; that's how life is... we cannot change that!</p> <p>We were talking about the switch construct. The only problem with the above code chunk is that it's a bit of an eyesore! There is a lot of cluttering, what with repeated usage of the <a href="/courses/video/5/157/Using-Variables.html">variable</a> name, multiple explicit comparisons, and what not!</p> <p>The switch construct comes in handy here. The syntax of a switch statement is:</p> <i>switch(condition) </i> <i>{</i> <i>//blah blah blah</i> <i>}</i> <p>We could rewrite our change denomination example as:</p> <i>switch(denomination) </i> <i>{</i> <i>case 'Q' : change = 2Q; break; </i> <i>case 'D' : change = 5D; break; </i> <i>case 'N' : change = 10 N; break; </i> <i>case 'P' : change = 50 P; break; </i> <i>default : assWalk = true; </i> <i>}</i> <p>Aah! Looks much much cleaner to read and understand, doesn't it? That's the advantage of having a language construct like the switch in certain contexts. I know, there are a few points that are still not clear; yes, the 'break' keyword! What is it doing here? Don't worry, we'll find out very soon, in the <a href="/courses/video/9/71/Breaking-The-switch-Down.html">next summary</a>.</p> <p>A point that deserves mention is the 'default' keyword : it represents the same logical construct as the final '<a href="/video/8/64/else.html">else</a> ' in an 'if-else if-else' cascading construct, which we covered in the <a href="/course/basics/conditionals-ifz">conditionals 1 course</a>. The code above <a href="/courses/video/7/199/Explicit-Equality.html">explicitly</a> displays the relationship between the two styles of programming.</p>