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?

// 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
    }
}

It does not make sense. Period.

It's scary that articles like this can get so many 👏s on medium.

"You've reached the end of your free subscription for the month" wasn't a good start.

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 😉

For enums there probably was some truth to it, but an unused boolean variable? That's the easiest thing to optimize away!

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.

Thanks @karelpeeters, You always seem to have my back 🙂

Haha it took 6m of seaching but I wanted to know too!

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

Well the blog does say it's about performance though.