Ryan Smith
08/10/2022, 12:36 AMelse
is there to be exhaustive, but is a no-op
?
e.g.
when {
thing is OneThing -> // do something
thing is SomethingElse -> // do something else
else -> { /* no-op */ }
}
It doesn't exactly fit this case from the style guide especially since the app is still under development and there could be more cases:
Prefer usingIs a barefor binary conditions instead ofif
when
return
better? Or just sticking with no-op
? Personal preference?Chris Lee
08/10/2022, 1:24 AMthing
- if it is guaranteed to only be OneThing
or SomethingElse
, the second conditional can be replaced with the else clause. If the else is required to be exhaustive it should do something - throw an assertion or UnsupportedOperation, perhaps.
The no-op else statement is a code-smell.ephemient
08/10/2022, 5:13 AMelse -> {} // no-op
but it's really equivalent to what you wrote. return
isn't always.thanksforallthefish
08/10/2022, 6:03 AMelse -> Unit
is also an option right? because sonar does not like no-op (don’t remember if comments prevent sonar analysis for triggering, but I don’t like “dummy” comments) and Unit
is the middle ground that makes both me and Sonar not unhappy 😄Chris Lee
08/10/2022, 1:18 PMelse -> { throw AssertionError("Invalid Thing") }
ephemient
08/10/2022, 2:39 PMerror(“invalid")
throws IllegalStateException
and TODO("invalid")
throws NotImplementedError
, which are more specific and appropriate IMOChris Lee
08/10/2022, 4:56 PMRyan Smith
11/01/2022, 2:41 PM