But really, can you give me a legit use case?
I cannot think of one single thing that is not a bad pattern switch(true) or could not be solved with an if and early return.
Switch cases are syntactic sugar for writing repetitive if and else if statements, not a language feature. Just like the for loop, you could write a while loop that does exactly the same thing.
I mean I think in finite lists they can have some application. Think like cardinal directions(Noth, East, South, West), basically TRUE Enums, absolutely finite ones. They can be useful sometimes in those cases. You could in theory use a strategy pattern or something even then, and be a more robust solution but it could be seen as over-engineering. If you MUST use one or have a case like above, I always like to throw an exception in the default case. If it shouldn't occur and does, I for sure want to know about it, and I don't want something weak like it being logged. I want it to be a mini-crisis.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
swtichstatements have no real use case that could not be implemented using other simpler features of the language.Following that logic, there is no use case for a for loop.
But really, can you give me a legit use case?
I cannot think of one single thing that is not a bad pattern
switch(true)or could not be solved with an if and early return.Switch cases are syntactic sugar for writing repetitive
ifandelse ifstatements, not a language feature. Just like the for loop, you could write a while loop that does exactly the same thing.I will die on this hill with you. Back to back, mini gun aiming down the hill, mowing down anything that comes our way except food delivery.
have you ever had a legit use case for
switch?I mean I think in finite lists they can have some application. Think like cardinal directions(Noth, East, South, West), basically TRUE Enums, absolutely finite ones. They can be useful sometimes in those cases. You could in theory use a strategy pattern or something even then, and be a more robust solution but it could be seen as over-engineering. If you MUST use one or have a case like above, I always like to throw an exception in the default case. If it shouldn't occur and does, I for sure want to know about it, and I don't want something weak like it being logged. I want it to be a mini-crisis.