SASDOE asks, “by convention if everyone of my cases returns, should default break and there be a return after the switch or should the default return?”
If the behavior and style is consistent throughout an all-cases switch, I’d perform the return in the `default` case. Only break if there’s a significant difference in how the default case is handled. For example, when you need to perform clean-up work, workarounds, or recovery.
I promised to throw this out there for other opinions and guidance. What do you do?
8 Comments
I prefer case, when default is return.
But if looking deeply, “default break” is more flexible, because case can be break in some conditions, i.e.:
func showMeSomething(num: Int) -> String {
switch num {
case 0..<20: return "await for 20 parts"
case 0..<40: return "await for 40 parts"
case 0..<50: break
case 0..<60: return "await for 60 parts"
default: break
}
return "Maxed for me"
}
showMeSomething(42)
showMeSomething(24)
showMeSomething(54)
showMeSomething(68)
I would generally break in the default case and have the return outside of the switch. It leaves more flexibility should the function need to be modified in the future. (Of course, you could just move the return at that point.) It just feels right to me that the function should return something at the end, regardless of any logic structures that occur within it.
For the examples in the article, return in switch for me. I prefer the readability of having cases aligned.
When a function is essentially a switch with returns, it’s safer to keep the entire default return in the case. That way the compiler checks that you return from each and every case. With a break and return outside the default case, you might accidentally do some intermediate computation and not return in one case, falling back to the default return.
This actually sounds like a really good idea. I generally would prefer to add a return at the end of the function simply because I feel a function should return regardless of its logic (as @room34 said), but having that extra compiler check more than makes up for it IMO.
For something like this — where I’m uncomfortable with both options, I’m drawn to a single return, at the expense of more code.
Also, mild OCD makes me re-sequence the cases to avoid having to divert any remaining neurons to doing the compiler’s job. (On the other hand, this keeps the Falcon 9 from exploding when you call test1(.max) and get back “single digit”… 🙂
This also seems like a great choice, but I’d change result from var to let so that the compiler can warn me if I forget to initialize it (if I change this code later).
Ah, yes, “let”. Thanks. (Swift n00bie mistake. 🙂