1️⃣ and 2️⃣ ... properties on a new line to avoid too much indentation but

) {

on the same line as the last property because it's just a wasted line otherwise

I don’t know why it’s necessarily wasted just because it’s basic for now. What would you do in the case that there’s a large amount of extensions/implementations?

That is like putting an end curly brace on the same line as the last statement in block to avoid wasting a line.

@thyberg I thought the same thing haha https://kotlinlang.slack.com/archives/C4GKV43N2/p1508891409000121?thread_ts=1508889528.000165&cid=C4GKV43N2

Exactly! No one thinks that putting a curly brace after statements is good idea, but as soon as we are talking normal parens and arguments, people like to do that. I don’t understand why.

@thyberg No, I wouldn't put an end curly brace on the same line as the last statement. Can't you see a similarity between

class Foo (..) {

and

if (...) {

?

Right, but we’re talking about multi-line inside of the parenthesis. When I make my

if

statements multi-line, I break them up for the same reason

if (
    conditionA()
    && conditionB()
) {

As for @bdawg.io: in case of inheritance I would probably put that on a new line. But that's is infact a different scenario for me personally.

@uhe I sure can se the the similarity between

class Foo (..) {

and

if (...) {

They both treat the closing brace the same. Maybe I was bit unclear. Let me try to explain (this might be a bit long) TL;DR Basically Stroustrup style on all different kind of brackets (apperantly called that, I found out after some googling) Most people have nothing against the following:

fun simple() { statement() }

Intellij even displays it like this And when we get too many statements, people usually break it down like this:

fun notSoSimple() {
    statement1()
    statement2()
    statement3()
}

Not many would format it like this though:

fun notSoSimple() { statement1()
                    statement2()
                    statement3() }

Doesn’t look good, does it? But when there are too many arguments or conditions to fit one line. Lots of people happily do just that.

fun functionCall() {
    oneLongFunctionCall(withAlongArgument, andAnotherOne,
                        andStillAnotherOne, andTheLastOne)
}

or

fun functionCall() {
    oneLongFunctionCall(
        withAlongArgument, andAnotherOne,
        andStillAnotherOne, andTheLastOne)
}

That is definitely not Stroustrup-ing the parenthesis. This would be though:

fun functionCall() {
    oneLongFunctionCall(
        withAlongArgument,
        andAnotherOne,
        andStillAnotherOne,
        andTheLastOne
    )
}

Same goes for conditionals

fun conditional() {
    if (aReallyLongCondition &&
            condition2 &&
            condition3) {
        statement()
        statement1()
    }
}

In the above we also have to resort to the, in my option, kludgy extra indentation for the condition to make it easy to separate the conditionals from the statements. By Stroustrup-ing the if-statement we don’t have to do that.

fun easierToReadConditional() {
    if (
        aReallyLongCondition &&
        condition2 &&
        condition3
    ) {
        statement()
        statement1()
    }
}

I think that it is much easier to read code that are lined up in columns. More lines? Definitely, but a price I am willing to pay for readability. Compare the following two examples (a bit contrived) and answer the following questions. How many function calls are there in the if statement, how many arguments do they each take and how many conditions are there in total?

fun complicated() {
    if (importantFlag && someValue >= 2 && aFunctionCallTo(withArgument1,
        networkState, plusSomeFlags, andAnotherOne) &&
        anotherFlag && shortFunction(withSeveral, arguments, foo) && weird1 && weird4) {
        callSomthingWhenTheAboveIsTrue(weird1, anotherFlag)
        anotherSimilarLookingCall()
    }
}

compared to

fun easierToRead() {
    if (
        importantFlag &&
        someValue >= 2 &&
        aFunctionCallTo(
            withArgument1,
            networkState,
            plusSomeFlags,
            andAnotherOne
        ) &&
        anotherFlag &&
        shortFunction(withSeveral, arguments, foo) &&
        weird1 &&
        weird4
    ) {
        callSomthingWhenTheAboveIsTrue(weird1, anotherFlag)
        anotherSimilarLookingCall()
    }
}

I would argue that it is easier in the second example. Mind you that I don’t recommend anyone to write such a complicated condition at all. You should probably extract stuff into local variables and/or break code out to smaller functions. Another reason for doing it more line-oriented is that it is much easier to swap arguments/conditionls around and to inset/remove them.

I agree that it’s way easier to read them across multiple lines in all cases (including the closing parentheses). The only thing I personally would do different is having signal symbols in a multi-line if condition present at the beginning of the line as part of the logic for that particular condition

if (
    conditionOne()
    && conditionTwo()
    || conditionThree()
) {
    ...
}