Which one do you like more? 2 is more concise but ...

# codingconventions

[Florian]

Which one do you like more? 2 is more concise but I don't really like the unnecessary else

[Matteo Mirk]

definitely the second one! But this doesn’t apply just to Kotlin, I also follow the same style in Java and other languages: unnecessary repetition creates noise and hinders readability.

[Matteo Mirk]

Upon further reading your code, if you make those BiometricManager constants into an enum you won’t need an else branch.
Turns out that you won’t need a “when” either, since the text matches the constant name:

val message = biometricManager.canAuthenticate().toString()

[Florian]

Thank you very much that makes sense

[Florian]

the text is just a placeholder but I didn't mention that

[Matteo Mirk]

oh okay fine, then to match the text you can either use one of these:
• when
• enum with a “message” field
• EnumMap

[Florian]

But BiometricManager is a class of the Android system

[Matteo Mirk]

No problem you can still use “when” or an EnumMap. Oh and don’t forget Kotlin has extension functions, so you could define an extension on BiometricManager to retrieve the message, maybe private only in the relevant scope

[Florian]

Thank you very much 👍

[codeslubber]

Neither. Why not have a simple mapping if all you are doing is getting a message (enum)?

[Hullaballoonatic]

The first one is also more tedious in about every way. Say you needed to change the function acting on all the results. Copy/paste code is industry standard dirty code

[Daniel]

when(...) {
  ... -> showToast.value = "Success"
  ... -> showToast.value = "Error"
}

showToast is a live data and the toast is shown by the view

[Daniel]

If you want to keep it like now make a showToast(message: String) method instead

[Daniel]

To be extra clean of course : showToast.value = R.string.success

[darkmoon_uk]

Please don't do [1], ever, I seem to spend half my life at work cleaning up these redundancy messes. Besides being redundant in both program space and screen space, these copy/paste affairs often cloud the intent of the code.

[darkmoon_uk]

Since often, the intent is that every branch should result in a message being displayed, but repeating the Toast in every branch then returning doesn't fully enforce this. Working with an uninititalised message first means the compiler will fail fast if you leave any branches uncovered e.g. in case you introduce a new enum value later on.