Hi all noticed this little thing and got curious why awesome kotlin team decided to do this conside...

# announcements

[vach]

Hi all noticed this little thing and got curious why awesome kotlin team decided to do this

consider this kotiln code

fun enter(key: String) {

      if (disabled) {
         return
      }
      // lots of code
}

when i decompile kotlin bytecode to see what is the underlying java code i see this

public final void enter(@NotNull String key) {
      Intrinsics.checkParameterIsNotNull(key, "key");
      if(!disabled) {
          // lots of code moved inside inverted if      
      }
}

not a big deal just curious why inverting the if statement? i cant think of some low level performance trick that may be the reason for this

[elizarov]

vach: I think this is the question to the authors of decompiler

[vach]

i shall post somwhere else?

[elizarov]

both ways to represent this logic are equivalent from any performance point of view. Why do you care?

[sigurdsa]

It might be the decompiler tries to reduce nesting to make the code easier to understand. In your case it looks a bit silly, but it would do this for larger methods as well. http://codebetter.com/patricksmacchia/2008/03/07/a-simple-trick-to-code-better-and-to-increase-testability/

[sigurdsa]

also see: http://stackoverflow.com/questions/268132/invert-if-statement-to-reduce-nesting/8493256#8493256

[vach]

Siguard compiler exactly does the oposite

[vach]

it nests my code inside if

[vach]

but thanks for the link thats good stuff

[vach]

@elizarov i dont 🙂 Usually when i find stuff like this it turns out to be some sneaky jit jvm level trick… so i was wondering if thats the case...

[vach]

My guess is it tries to remove multiple returns by restructuring ifs…

[vach]

anyhow if there is nothing interesting here just ignore guys 🙂

[orangy]

Kotlin compiler doesn’t generate Java, it generates bytecode. There is no such thing as if in bytecode, they are lower level constructs. So decompiler tries to reconstruct Java from bytecode it sees, and there are potentially a lot of ways to represent particular bytecode in equivalent Java syntax.

[vach]

Ah right thanks Ilya