Hello! Is there any recommended convention for No-Op in case of conditionals like `when` ? I tend to...

# codingconventions

[diego-gomez-olvera]

Hello! Is there any recommended convention for No-Op in case of conditionals like when ? I tend to use Unit but I don't recall if there is an official convention.

enum class Type { A,B,C }

1️⃣

when (type) {
    A -> doA()
    B -> doB()
    C -> Unit // No-op
}

2️⃣

when (type) {
    A -> doA()
    B -> doB()
    C -> {} // No-op
}

I guess that typealias could be used as well, but it seems overkill

[ephemient]

I prefer empty blocks - IMO it's more descriptive of "do nothing" rather than having the appearance of "load the singleton object instance of Unit" (even though it doesn't really do that, of course), and is consistent with how I prefer to write no-op functions,

fun noOp() {
    // no-op
}

instead of = Unit

[ephemient]

one minor point is that https://developer.android.com/kotlin/style-guide#empty_blocks says empty blocks need additional spacing

[ephemient]

but I don't think there's a community-wide agreement on this

[Tgo1014]

I prefer Unit I hate the auto formating for `{}`😆

[Joffrey]

I prefer Unit for the consistency with the other non-block expressions. I basically eliminate all braces from when expressions this way, as it's less noise for parsing with the eyes IMO.

[pablisco]

I have a weird 3rd option 🤭
I often define a global function like:
doNothing(because: String): Unit
with the because parameter describing why we are doing nothing there. It gets removed on compilation but adds an opportunity to explain rather than just have something like // NO-OP without much context regarding why there is no operation.

[diego-gomez-olvera]

that's interesting, what's the advantage compared to the comment?

[diego-gomez-olvera]

I guess that it encourages the explanation

[pablisco]

What I like is how semantic it looks:

doNothing(because = "blah")

And yeah, also it can nudge the user to have to provide a description.
Also, we can quite easily search for all the usages. Handy if we want to audit that we are not getting into an unstable state due to a dead logical branch in the code.

[pablisco]

Also have created something like doReturn. To provide descriptions for magic numbers that don't scream at you hehe

[diego-gomez-olvera]

why not a constant?

[diego-gomez-olvera]

for consistency with some other doX functions?

[pablisco]

Sorry for the off topic...
I personally find screaming snake case naming gives me mild headaches 🤭
And often it's single use. But also, this way we can provide a long and clear description of why we are returning such value.
Also, I saw someone defining a global:

val DOUBLE_ZERO = 0.0

This reminded me that using constants for "magic numbers" has kind of been reduced to the action and we have forgotten about why we do it. Which happens a lot on tech.

Damn, I am chatty today 🤭

[diego-gomez-olvera]

using constants for "magic numbers" has kind of been reduced to the action and we have forgotten about why we do it

I guess that the naming convention comes from C macros, but this is more #random than #codingconventions not kotlin but kotlin colored

[pablisco]

Very true, sorry for the tangent 🤭🤐