I'm been using kotlin for more than 3 years. I alw...
# getting-started
f
I'm been using kotlin for more than 3 years. I always use str?.let for null checking. I read a article today and I'm confused. Doesn't this recommendation really make sense?
Copy code
// NOT RECOMMENDED
fun process(str: String?) {
    str?.let { /*Do something*/   }
}

// -> decompile will get
public final void process(@Nullable String str) {
   if (str != null) {
      boolean var4 = false;
      /*Do something*/
   }
}


// RECOMMENDED
fun process(str: String?) {
    if (str != null) {
        // Do Something
    }
}
decompiled code did have extra code like
boolean var3 = false
something
e
It does not make sense. Period.
๐Ÿ‘ 7
k
It's scary that articles like this can get so many ๐Ÿ‘s on medium.
๐Ÿ‘† 1
a
"You've reached the end of your free subscription for the month" wasn't a good start.
t
Last time someone wrote an article/recorded a video to advocate against using a language feature for performances reasons (I look at you, enums on Android !), it made that feature a forbidden fruit for more than 5 years. So please developers, let tools like Proguard and the JIT do their work of optimizing the bytecode and focus on the business logic ๐Ÿ˜‰
k
For enums there probably was some truth to it, but an unused boolean variable? That's the easiest thing to optimize away!
r
I believe there was a discussion about this a while ago, and all the unused booleans had something to do with debugging inline functions iirc.
r
Thanks @karelpeeters, You always seem to have my back ๐Ÿ™‚
k
Haha it took 6m of seaching but I wanted to know too!
๐Ÿ˜† 1
a
JVM bytecode is intended to be very simple, all optimizations come later, it's not asm bytecode like in C/C++. This recommendation has nothing to do with performance
k
Well the blog does say it's about performance though.