:one: and :two: ... properties on a new line to av...

# codingconventions

[uhe]

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

[bdawg.io]

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?

[thyberg]

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

[bdawg.io]

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

[thyberg]

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.

[uhe]

@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 (...) {?

[uhe]

you wouldn't write

if (...)
{
    // stuff

either

[bdawg.io]

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()
) {

[bdawg.io]

Now I can do whatever I want to the if statement and deep alignment is not a concern

val someReallyLongVal = if (
    conditionA()
    && conditionB()
) { ...

[uhe]

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.

[thyberg]

@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.

[bdawg.io]

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()
) {
    ...
}