uhe
10/25/2017, 8:08 AM) {
on the same line as the last property because it's just a wasted line otherwisebdawg.io
10/25/2017, 5:36 PMthyberg
10/25/2017, 6:05 PMbdawg.io
10/25/2017, 6:08 PMthyberg
10/25/2017, 6:39 PMuhe
10/26/2017, 7:51 PMclass Foo (..) {
and if (...) {
?if (...)
{
// stuff
eitherbdawg.io
10/26/2017, 7:53 PMif
statements multi-line, I break them up for the same reason if (
conditionA()
&& conditionB()
) {
val someReallyLongVal = if (
conditionA()
&& conditionB()
) { ...
uhe
10/26/2017, 7:54 PMthyberg
10/29/2017, 9:41 AMclass 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
10/29/2017, 9:46 AMif (
conditionOne()
&& conditionTwo()
|| conditionThree()
) {
...
}