<@U5HT6HNF2> A few thoughts here: <http://beust.c...
# getting-started
c
@tulio A few thoughts here: http://beust.com/weblog/2016/01/14/a-close-look-at-kotlins-let/ tldr: I tend to stick to
if
d
cedric:
let
is good for
var
, which must generally be avoided but it is needed sometimes.
c
Can you elaborate?
d
var
can change, and
let
extracts a local constant value (
it
). I just saw in the comments the one from ‘Justin Lee’, which gives the same reason
c
Ah yes indeed
t
if you want to avoid
it
and avoid renaming can’t you just shadow it?
thing?.let { thing -> thing.doStuff() }
c
Yes shadowing works too. Usually not recommended but it's basically the exact same variable, just transtyped from
T?
to
T
, so purists might give this infraction a pass
t
I do agree with what you are saying about if without else branch is typically a smell. it usually implies a stateful soupy mess imo
c
I don't connect the abence of
else
with statefulness (nor that statefulness is necessarily bad) but I do agree that the absence of a
let
is suspicious in my blog post
r
I tend to stick with
if
also. I find it much more readable in the long run when I go back to read the code.
c
Swift has a if let that allows for the else. Maybe in a new kotlin version
d
nullable?.let { doSomethingNotNull(it) } ?: doSomesingElse()
Is the construct for the else branch in Kotlin if i am not mistaken