tbh using Objects/Maps instead of switch usually is much more readable and convenient. You can use ?? to implement defaults, some prototype key collision(like valueOf) is not an issue 99% of the time(and can be avoided with null prototype or Map), having multiple values match the same case can also be fixed with Map. You can't really implement a case without a break tho unless you get really verbose but then just actually use a switch - but honestly how often do you even need this in a switch statement? If anything it makes your code even less readable when you have to consider that some cases don't cause a break. using switch over if else doesn't bring any benefits really - I find them both to be quite unreadable and verbose and I think performance-wise they're literally the same.
In php I sometimes do this: switch(true) { case ($myVar1 < 5): {echo "case 2 " ;break;} case ($myVar2 != "foo" ): {echo "bar" ;break;} case ($myVar3+2 < 5): {echo "foo bar" ;break;} }
You can also do the same in the JS since CASE checks for TRUE, btw Kyle should've been mentioned this also that CASE has STRICT comparison. So once you put some datatype in the switch's parentheses the same type of data expected in the CASE.
But you can use switch statements to check if, say, a number is less than 5. You just need to gently abuse what a switch is used for. The expression in a switch statement is the value you are testing your cases against, and if the derived value of the case matches the derived value of the expression then a Boolean true happens which runs the code inside the matching case. So, you can shortcut a switch by setting the expression to be a Boolean true and then do whatever you want in the cases const x = 50; switch (true) { case x < 50: console.log("Less than 50"); break; case x > 50: console.log("Greater than 50"); break; case x === 50: console.log("Exactly 50"); break; default: console.log("x isn't a Number"); }
that's actually how I write many of my switch statements :D you can then also compare to function results; each case becaomes like a stripped down if statements
@@Lernschau I rarely need and if...else these days, but when I do there's usually a couple of else ifs in there so I rewrite as a switch block like the above. However if I have a lot of conditions I actually iterate over an array of objects and return whatever matches my incoming condition first.
@@MB-zj3er abuse is probably too strong a word, but it's not strictly how a switch block is intended to be used. But using a Boolean as the expression is well documented at MDN, so it's not like it's a super bad thing.
if you want to use greater than, less than in your switch statement try this: switch (true) { case x < 5: console.log('small');break; case x >= 5 && x < 10: console.log('medium');break; case x >= 10: console.log('large');break;
Not adding a break;/return; statement after your logic is complete is a bad practice. You want the logic under a specific case to be executed and proceed with the rest of the code outside of the switch~case block. Always add a break; statement after you're done with your case logic. Additionally, I know this is JavaScript, but make sure to manipulate the input string into something generic, such as all lowercase to make sure user input won't be a problem. Where applicable, use Enums and other values you can directly control when using switch~case. Performance-wise, it's much better than an if~else if block. You should really be using if~else if when you have multiple mutually exclusive conditions that can be fulfilled within the same program loop (such as whether the user has admin rights and is logging on with certain options enabled). If it's a single variable that can contain multiple values you need to check for, switch~case is better.
For this case I use switch statements like this: function getAnswer(animal) { switch (animal) { case 'cat': return 'Cats are great' case 'dog': return 'Dogs are kinda loud' case 'shark': return 'That's an interesting choice' default: return 'I have never heard of that animal' } } I like to use oneliners in these kind of cases because every line belongs to a value. It's also easy to test because it's a pure function.
Kyle, what is your opinion on use of switch statements versus objects with keys being the case constants and values being the case blocks wrapped in functions? Of course readability will take a hit, but will that not make the code more declarative and hence reactive?
Kyle is super awesome at teaching stuff. That being said, I just don't see the need to get into Switch Statements unless there is a huge performance increase. It can't do anything else other than equals, needs breaks... whereas if/else is much easier for a newb like myself to understand and all Comparison Operators work with it. Can anyone please share the more advantages to Switch?
Switch statements are operational sorters. Give it a list of objects or arrays with a noun key (type, make, model, gender, etc) that the statement is designed to sort through and perform a logical operation on. You can also encapsulate switch statements into functions and use functions, with switch statements in them, as case operations to create cascading sorting operations.
This is one instance I actually prefer VBs implementation where there is no need for a break statement. I can’t think of a single instance where I didn’t want the break in each case, so why not just make that the default behavior?
@@darz6012 To me that is still an ugly implementation as you have to write “case” multiple times. In VB you can do the same thing you just have a list of values “cat”, “jaguar”, “bobcat” for one case. I don’t think I have ever had to use that though. I would go a different route at that point, as I think switch can get ugly quick if it gets too complex.
I fail to understand how the switch case statement is any better than if/else statements. The syntax complexity seems a bit higher, and the length of code seems about the same if not requiring more lines of code for switch case statements than if/else statements. So, what am I missing? I don't understand how switch case statements are any better, it just seems like a redundant alternative at best.
JS has ?? as of recently which only "triggers" on undefined & null unlike || which triggers on all falsy values. So 0 ?? 5 => 0 but 0 || 5 => 5. Unfortunately it ignores NaN so NaN ?? 5 => NaN.
I don't like the switch syntax, usually i do this let favoriteAnimal = { "cat": ()=>{ console.log("Cats...")}, "dog": ()=>{ console.log("Dogs...")} } favoriteAnimal["jaguar"] = favoriteAnimal["cat"]; favoriteAnimal["jaguar"]();
This is decent info to know how these work, but really should not be used anymore. Switches generally does not lead more maintainable/readable code. Heck there is proof with someone showing that you can write conditionals of less than and greater than.
But scope wise, it much more optimise, especially when you need to use in function wich require multiple use, for example if using dice function and result of this function for future value. the only thing you can get lazy with writing breake, but common, cntrl+c cntrl+v, or even pretier special config set up done, tell me you point in details if its not hard?
Absolutely disagree. In case you have certain ENUM values you can force yourself (via eslint) to handle each case. Adding another value the enum will automatically produce an error - perfect for you to known where you need to handle the new case.
Objects are better: const favoriteAnimals = { cat: "Cats are great", dog: "Dogs are kinda loud", shark: "That's an interesting choice", } function getAnimal(animal) { const animalDescription = favoriteAnimals[animal] ?? "I've never heard of this animal"; // For beginners: read more about short if statements, short circuiting, and nullish coalescing. console.log(animalDescription); } If you want multiple animals to match the same result, such as Cat, Bobcat, and Jaguar all matching "Cats are great", you can use multiple techniques. If can get pretty verbose, and switch is bad imo. I used an array with the allowed values, and return "cat" if the animal exists in the array function getCat(animal) { const cats = ["jaguar", "bobcat", "cat"]; return cats.find(cat => cat === animal) ? "cat" : undefined; }
or you can rewrite it to: const favoriteAnimal = "shark"; const favoriteAnimalList = { cat: () => console.log("Cats are great"), dog: () => console.log("Dogs are kinda loud"), shark: () => console.log("That's an interesting choice"), }; favoriteAnimalList[favoriteAnimal] ? favoriteAnimalList[favoriteAnimal]() : console.log("I have never heard of that animal");
thanks! this helped me realize a switch block was NOT the correct way to handle what i was doing 😂
tbh using Objects/Maps instead of switch usually is much more readable and convenient.
You can use ?? to implement defaults, some prototype key collision(like valueOf) is not an issue 99% of the time(and can be avoided with null prototype or Map), having multiple values match the same case can also be fixed with Map.
You can't really implement a case without a break tho unless you get really verbose but then just actually use a switch - but honestly how often do you even need this in a switch statement? If anything it makes your code even less readable when you have to consider that some cases don't cause a break.
using switch over if else doesn't bring any benefits really - I find them both to be quite unreadable and verbose and I think performance-wise they're literally the same.
never used switch statements in a real project saw no reason too. best to not have so many if/switch statements in the first place
Yeah maps are way better, way less lines of code
mother in heaven you're a great teacher. Your voice also is really calming. Thanks brother!
In php I sometimes do this:
switch(true) {
case ($myVar1 < 5): {echo "case 2 " ;break;}
case ($myVar2 != "foo" ): {echo "bar" ;break;}
case ($myVar3+2 < 5): {echo "foo bar" ;break;}
}
You can also do the same in the JS since CASE checks for TRUE, btw Kyle should've been mentioned this also that CASE has STRICT comparison. So once you put some datatype in the switch's parentheses the same type of data expected in the CASE.
your teaching style is so great, thank you very much!
But you can use switch statements to check if, say, a number is less than 5. You just need to gently abuse what a switch is used for. The expression in a switch statement is the value you are testing your cases against, and if the derived value of the case matches the derived value of the expression then a Boolean true happens which runs the code inside the matching case.
So, you can shortcut a switch by setting the expression to be a Boolean true and then do whatever you want in the cases
const x = 50;
switch (true) {
case x < 50:
console.log("Less than 50");
break;
case x > 50:
console.log("Greater than 50");
break;
case x === 50:
console.log("Exactly 50");
break;
default:
console.log("x isn't a Number");
}
that's actually how I write many of my switch statements :D
you can then also compare to function results;
each case becaomes like a stripped down if statements
@@Lernschau I rarely need and if...else these days, but when I do there's usually a couple of else ifs in there so I rewrite as a switch block like the above.
However if I have a lot of conditions I actually iterate over an array of objects and return whatever matches my incoming condition first.
Is this abuse though? It follows the logic. I use it quite a bit.
@@MB-zj3er abuse is probably too strong a word, but it's not strictly how a switch block is intended to be used. But using a Boolean as the expression is well documented at MDN, so it's not like it's a super bad thing.
Your videos are so easy to understand thanks Bro👌👌
Your videos are the best in TH-cam. But this one was simple and trivial.
By the way, Thank you
if you want to use greater than, less than in your switch statement try this:
switch (true) {
case x < 5: console.log('small');break;
case x >= 5 && x < 10: console.log('medium');break;
case x >= 10: console.log('large');break;
looks worse than if else
Never tired watching and executing your tutorial ❤
Thank you so much, you explain magnificantly
Lifesaver!!!! always thankful. ))
Not adding a break;/return; statement after your logic is complete is a bad practice. You want the logic under a specific case to be executed and proceed with the rest of the code outside of the switch~case block.
Always add a break; statement after you're done with your case logic.
Additionally, I know this is JavaScript, but make sure to manipulate the input string into something generic, such as all lowercase to make sure user input won't be a problem.
Where applicable, use Enums and other values you can directly control when using switch~case. Performance-wise, it's much better than an if~else if block.
You should really be using if~else if when you have multiple mutually exclusive conditions that can be fulfilled within the same program loop (such as whether the user has admin rights and is logging on with certain options enabled). If it's a single variable that can contain multiple values you need to check for, switch~case is better.
For this case I use switch statements like this:
function getAnswer(animal) {
switch (animal) {
case 'cat': return 'Cats are great'
case 'dog': return 'Dogs are kinda loud'
case 'shark': return 'That's an interesting choice'
default: return 'I have never heard of that animal'
}
}
I like to use oneliners in these kind of cases because every line belongs to a value.
It's also easy to test because it's a pure function.
Kyle, what is your opinion on use of switch statements versus objects with keys being the case constants and values being the case blocks wrapped in functions? Of course readability will take a hit, but will that not make the code more declarative and hence reactive?
amazing explanation thank you
Kyle is super awesome at teaching stuff. That being said, I just don't see the need to get into Switch Statements unless there is a huge performance increase. It can't do anything else other than equals, needs breaks... whereas if/else is much easier for a newb like myself to understand and all Comparison Operators work with it. Can anyone please share the more advantages to Switch?
Switch statements are operational sorters. Give it a list of objects or arrays with a noun key (type, make, model, gender, etc) that the statement is designed to sort through and perform a logical operation on. You can also encapsulate switch statements into functions and use functions, with switch statements in them, as case operations to create cascading sorting operations.
Thanks for always enlightening us!
I much rather a lookup table/dictionary but the problem is most people use object literal when they should be using map
great video 👍🏿
you can also drop the "break" if you add "return"
Thanks WDS!
Switch case is antipattern. Better way is to use hash (object)
i love this channel
dogs are actually awesome animals
and they can be taught to not make loud sounds while being at home
dont hate them Kyle
This is one instance I actually prefer VBs implementation where there is no need for a break statement. I can’t think of a single instance where I didn’t want the break in each case, so why not just make that the default behavior?
because you can stack multiple cases on top of each other so that the same exact code will run for multiple different values.
@@darz6012 To me that is still an ugly implementation as you have to write “case” multiple times. In VB you can do the same thing you just have a list of values “cat”, “jaguar”, “bobcat” for one case.
I don’t think I have ever had to use that though. I would go a different route at that point, as I think switch can get ugly quick if it gets too complex.
Hey bro, how are you changing multiple words at once for example you highlighted cat and changed it to bobcat twice
any discount for your courses ?
Can you repeat this example using object literals instead?
Object or Map is better than switch statements in my opinion
Hi, is there any way to change
a=×
b=y
If(a=× and b=y){} to switch statement?
I guess no
you can put the default case first btw
Hey bro I had developed a simple react website it's running properly in firefox but lagging in chrome and other browser
Thank you
I fail to understand how the switch case statement is any better than if/else statements. The syntax complexity seems a bit higher, and the length of code seems about the same if not requiring more lines of code for switch case statements than if/else statements. So, what am I missing? I don't understand how switch case statements are any better, it just seems like a redundant alternative at best.
Switch would be great if it behaved like Select Case without the breaks.
how bout using object literal for simple cases like this one.
id rather use json objects as map
console.log(message[faveAnim] || "unheard")
JS has ?? as of recently which only "triggers" on undefined & null unlike || which triggers on all falsy values.
So 0 ?? 5 => 0 but 0 || 5 => 5. Unfortunately it ignores NaN so NaN ?? 5 => NaN.
@@huge_letters in that case || is still better.
Thanks
Thanks for the video. It was difficult following you because you talk fast
Best youtuber
I prefer if over switch.
only things i have against this video is how cats are better than dogs
I don't like switch statements. I really wish they were exhaustive or more like match statements in rust
I don't like the switch syntax, usually i do this
let favoriteAnimal = {
"cat": ()=>{ console.log("Cats...")},
"dog": ()=>{ console.log("Dogs...")}
}
favoriteAnimal["jaguar"] = favoriteAnimal["cat"];
favoriteAnimal["jaguar"]();
im doing this too sir
This is decent info to know how these work, but really should not be used anymore. Switches generally does not lead more maintainable/readable code. Heck there is proof with someone showing that you can write conditionals of less than and greater than.
In my opinion, switch statements is bad style. It's hard to read and maintain
But scope wise, it much more optimise, especially when you need to use in function wich require multiple use, for example if using dice function and result of this function for future value. the only thing you can get lazy with writing breake, but common, cntrl+c cntrl+v, or even pretier special config set up done, tell me you point in details if its not hard?
@@Ray_Roele for example you might confuse another developer reading your code with purposefully leaving out a break statement when it's really needed.
@@dimitridoroshko then comment are come into play
Absolutely disagree. In case you have certain ENUM values you can force yourself (via eslint) to handle each case. Adding another value the enum will automatically produce an error - perfect for you to known where you need to handle the new case.
I agree! I was taught to not put logic inside switches tens of years ago
someone show this video to yanderedev
Some say, switch is an anti-pattern.
It's not if it's implemented the right way, like in Rust for example, which forces you to explicitly declare all case and uses pattern matching.
swith-case is a bad programming practice.
I still think switch statements are useless compared to ifs
First comment.
That's Kyle
Make youreself a favor and dont use switch at all. Its bad practice. There are other, more readable ways
Objects are better:
const favoriteAnimals = {
cat: "Cats are great",
dog: "Dogs are kinda loud",
shark: "That's an interesting choice",
}
function getAnimal(animal) {
const animalDescription = favoriteAnimals[animal] ?? "I've never heard of this animal";
// For beginners: read more about short if statements, short circuiting, and nullish coalescing.
console.log(animalDescription);
}
If you want multiple animals to match the same result, such as Cat, Bobcat, and Jaguar all matching "Cats are great", you can use multiple techniques. If can get pretty verbose, and switch is bad imo. I used an array with the allowed values, and return "cat" if the animal exists in the array
function getCat(animal) {
const cats = ["jaguar", "bobcat", "cat"];
return cats.find(cat => cat === animal) ? "cat" : undefined;
}
I'm first comment...
your third comment
or you can rewrite it to:
const favoriteAnimal = "shark";
const favoriteAnimalList = {
cat: () => console.log("Cats are great"),
dog: () => console.log("Dogs are kinda loud"),
shark: () => console.log("That's an interesting choice"),
};
favoriteAnimalList[favoriteAnimal] ? favoriteAnimalList[favoriteAnimal]() : console.log("I have never heard of that animal");
Bro did you see my email.