There are currently no frequently asked questions associated with this exercise – that’s where you come in! You can contribute to this section by offering your own questions, answers, or clarifications on this exercise. Ask or answer a question by clicking reply () below.
If you’ve had an “aha” moment about the concepts, formatting, syntax, or anything else with this exercise, consider sharing those insights! Teaching others and answering their questions is one of the best ways to learn and stay sharp.
Join the Discussion. Help a fellow learner on their journey.
Ask or answer a question about this exercise by clicking reply () below!
Agree with a comment or answer? Like () to up-vote the contribution!
You are correct in that assessment. The author wrote it into the SCT so we have no choice but to humor them. Technically, there is no break in the default case since it is the last expression in the switch statement.
Remember to add the break keyword at the end of the default case.
But apart from that, there was a confusing line in the explanation part:
Without the break keyword at the end of each case, the program would execute the code for all matching cases and the default code as well.
Why matching? Wouldn’t it just run till the next break or to the end of the block, if no breaks are met on the way, no matter if case is matched or not?
When a case action does not include return, the switch is still being parsed for other possible matches. Even if none are found, the default case will execute, on top of whatever action was carried out on the first match. break directs control flow to the next statement AFTER the switch body.
Recall that case must match the given switch expression in order for control flow to enter that branch. Only in cases where we wish to include the default case in all instances would we omit the break on each case branch, which is highly unusual.
How would you make the test of each case case-insensitive? In other words, if I want both ‘first place’ and ‘First Place’ to return ‘You get the gold medal!’, what is the neatest way to code this?
The break keyword is not required in the default condition.
Without the break keyword at the end of each case, the program would execute the code for all matching cases and the default code as well.
Also incorrect, it will execute for all cases, matching or not. You can even try it in the editor: remove the break keywords from all cases, you will notice it outputs to the console for ALL cases.
Yes, there are no actions in the case branches, but it is more the absence of ‘break’ that results in flow traveling all the way down to the default branch.
Now let’s set the case branches…
function foo (bar) {
switch (bar) {
case 'faz': break;
case 'baz': break;
case 'foo': break;
case 'bar': break;
default: return false;
}
return true
}
Now the four statements will all result in true being returned since break interrupts the switch and the line following it is executed (return true).
Hi!
I’d like to know whether it’s possible to use comparison operators within cases.
I wrote this to practice, and it works fine.
let a = 11
switch (a)
{
case 11: {console.log('eleven')};
break;
case 12: {console.log('twelve')};
break;
default: {console.log('other number')};
break;
}
But then I thought, what if I want to check not a specific value, but any value that is higher than, e.g., 5? It looks like it’s not possible. Should I use if/else instead?
Codecademy says switch statements are a good alternative syntax to multiple else if statements, but now with ES6, can the ternary operator replace switch statements?
Ternary expressions are ES5, and unchanged in ES6. We could always nest ternaries but most teachers would discourage using them in complex situations.
> randint = (h, k) => Math.floor(Math.random() * h) + k
<- (h, k) => Math.floor(Math.random() * h) + k
> [a, b] = [randint(10, 1), randint(10, 1)]
<- (2) [5, 6]
> console.log(a < b ? -1 : a > b ? 1 : 0)
-1
<- undefined
>
We can create readable expressions, all the same, so long as we break them up…
> double = x => 2 ** x
<- x => 2 ** x
> halve = x => x / 2
<- x => x / 2
> square = x => x ** 2
<- x => x ** 2
> root = x => x ** 0.5
<- x => x ** 0.5
> [a, b] = [randint(100, 1), randint(100, 1)]
<- (2) [92, 71]
> console.log(
a < b ? double(a) :
a > b ? halve(a) :
a % 2 ? square(a) : // known state: a === b
root(a)
)
46
<- undefined
>
Doesn’t matter, pick one that gets the job done and spend the brain cycles elsewhere.
Also, if some language feature doesn’t really add anything to your toolkit then you may as well pretend it doesn’t exist.