There's a semantic thing going on with this expression that is rather interesting. First, consider this reworking: boolean a = this.doesSomethingWithA();

There's a semantic thing going on with this expression that is rather interesting. First, consider this reworking: boolean a = this.doesSomethingWithA(); if (a) {a = a && !this.doesSomethingWithB();} if (a) {a = a && !this.fooBar2000.isEmpty();} if (a) {a = a && !this.anotherLongAttribute;} if (a) {a = a && !this.anotherMethod();} return a; And then this one: boolean a = this.doesSomethingWithA(); a = a && !this.doesSomethingWithB(); a = a && !this.fooBar2000.isEmpty(); a = a && !this.anotherLongAttribute; a = a && !this.anotherMethod(); return a; In the first version and your original, it's clear that there's short circuiting and it can return early, but automatic formatting will bloat up the vertical size of the code. In the one-liner there's also short circuiting, but it doesn't format well. In my second version you get the formatting, but it will always evaluate every possibility. In general, when I'm favoring code formatting, the variable declarations come out. Quickly aliasing something into a name when it could exist purely as an expression adds a degree of conceptual flexibility. It keeps the code local(no new function name and jumping over into it). But it does also result in this kind of unnecessary computation.