`run` vs `let` for this specific case :one: ``` ...

# codingconventions

[AlexD]

run vs let for this specific case
1️⃣

fun getFirstAddress(list: List<Coordinates>): Address? {
        // ... do something with list

        return list.firstOrNull { it.isValid() }?.run { Address(latitude, longitude) }
    }

2️⃣

fun getFirstAddress(list: List<Coordinates>): Address? {
        // ... do something with list

        return list.firstOrNull { it.isValid() }?.let { Address(it.latitude, it.longitude) }
    }

3️⃣

fun getFirstAddress(list: List<Coordinates>): Address? {
        // ... do something with list

        return list.firstOrNull { it.isValid() }?.let { coordinates ->
            Address(coordinates.latitude, coordinates.longitude)
        }
    }

4️⃣

fun getFirstAddress(list: List<Coordinates>): Address? {
    // ... do something with list

    return list.firstOrNull { it.isValid() }?.toAddress()
}

private fun Coordinates.toAddress() = Address(latitude, longitude)

5️⃣

fun getFirstAddress(list: List<Coordinates>): Address? {
        // ... do something with list

        val firstValidCoordinate = list.firstOrNull { it.isValid() } ?: return null
  
        return Address(firstValidCoordinate.latitude, firstValidCoordinate.longitude)
    }

[Joffrey]

I would go for a 4th option:

fun getFirstAddress(list: List<Coordinates>): Address? {
    // ... do something with list

    return list.firstOrNull { it.isValid() }?.toAddress()
}

private fun Coordinates.toAddress() = Address(latitude, longitude)

[Paul Griffith]

as long as we're skinning cats, could also add a constructor for Address that directly accepts Coordinates, then ?.let(::Coordinates)
I like 4 for readability, although it's a fairly minor gain in this case
I feel like I would probably actually write this as 2 first and only rewrite it to 4 if I was really bothered by it

[elizarov]

It is definitely let if you don’t have an extension function. With extension function it is much nicer, though.

[Matteo Mirk]

extensions FTW! 😁

[AlexD]

I need to deal with it all over the place when using let . The code would be more concise with run, wouldn't it?

[Joffrey]

It might, but it's not the intent of run IMO. I consider let to be "the map for single values", which would be the appropriate alternative here if not using an extension. If you really have a lot of `it`s (meaning the expression in the let is big), it might be worth using extensions

[AlexD]

if run is intended for some specific purposes I really wish we had another let function similar to run say letIt

[Matteo Mirk]

According to Kotlin docs:

run is useful when your lambda contains both the object initialization and the computation of the return value.

[Joffrey]

@AlexD If you really want the object as a receiver, of course you should use run. There is real no reason for an extra scope function in the stdlib here.

The point of let being considered as map for single objects is that it really does behave like map as well, with it in the lambda.

[Daniel]

fun getFirstAddress(list: List<Coordinates>): Address? {
        // ... do something with list

        val firstValidCoordinate = list.firstOrNull { it.isValid() } ?: return null
  
        return Address(coordinates.latitude, firstValidCoordinate .longitude)
    }

No need for nesting. This could be solved by a guard

[Daniel]

You even gain a name (firstValidCoordinate) so the reader does not need to care about understanding the firstOrNull

[AlexD]

so no run or let ? This brings me a question about the kotlin way. Are we more tolerant of using variables than the scope functions?

[Daniel]

Personally I would not use scopingin this case, no. Kotlin gives us the option to return early very cleanly (with elvis operator). This can be used here. In the end it goes down to personal preference - Would not be a blocker for a pull request approval 🙂

[AlexD]

makes sense

[gildor]

Agree with Daniel’s solution, it how we do most of code which allows early returns and usually we do not allow block functions just to handle nullability