https://kotlinlang.org logo
Join Slack
Powered by
Does anyone remember - there was a bug caused by h...
# getting-started
u
Does anyone remember - there was a bug caused by having operators are the end of a line instead of the start of a line - in a multiline if condition
Copy code
if (foo &&
    bar &&
    quax
) {
   ...
}
vs
Copy code
if (foo
    && bar
    && quax
) {
   ...
}
m
Copy code
fun main() {
    val x = 5
      -1
    println(5)
}
The -1 will not be applied to 
x
. There's shouldn't be any problem with the if statements because of the 
()
.
u
I faintly remember someone reporting issues with the first variant
m
kotlin playground seems to be happy with it
u
which do you prefer?
v
Iirc the official style guide does not explicitly mention where they go, but a few examples show them before the line break. I prefer that too in languages with optional semicolons to avoid ambiguous parsing situations.
h
Putting the line break after the operator (first variant) seems to be more common (e.g. KtLint prefers it like that) and safer wrt ambiguous parsing (as a result of optional semicolons). I would suggest to go with that, even though I have originally always liked them at the start of the next line: For me, when I'm reading code the start of lines tend to get more attention than the end. I like it if I can get the overall structure of the code without having to look at too many ends of lines. But consistency and avoiding ambiguity wins..
v
Yep, same for me. In languages where some end-of-statement token is required (e. g. Java) operator to next line, in languages where this could lead to wrong parsing (e. g. Groovy or Kotlin) operator to end of line.
u
operator at end of the line looks weird to me, feels like doing this
Copy code
val x = foo.
	bar.
	quax
but I didnt meant to get into this - I just remember a googler reporting a bug caused by the end of line operator variant .. and wondering if I made it up in my head or someone else remebers it as well
v
That indeed looks strange. I've seen that also being done and greatly dislike it. A line starting with 
.
or 
?.
usually does not cause a parsing ambiguity and for those the official coding conventions indeed say they should be on the start of the next line.
w
Interestingly, PEP 8 claims that the latter is more readable. https://peps.python.org/pep-0008/#should-a-line-break-before-or-after-a-binary-operator
👍 2
u
I also agree, if operator is at the start it gets more attention than end
v
@Wout Werkman why "interestingly"? We agreed to that. It just can lead to ambiguous, or rather wrong, parsing in languages like Kotlin. Of course you can always use parenthesis to fix the parsing, but this can also easily be forgotten and thus introduce hard to find bugs and if consistently at line end this simply cannot happen. :-)
u
I'm also curious why does 
+
have an issue while 
|| &&
dont, boolean operators work fine in start or end
v
+ 1
is a valid statement, 
|| true
not
u
because of unary operator?
v
Yes
u
I'm yet to see someone use unary plus
v
Then 
- 1
🤷‍♂️
u
that's very different 😄
v
Oh, btw. I recently have seen a valid use of unary plus. Let me think where it was.
Hm, I don't remember where it was. :-(
u
never happened ever 😄
v
It was some DSL where the operator was overloaded and had some semantic meaning
Maybe some UI framework or something like that
u
jetpack compose has them and ditched them since its stupid 😄
v
Unlikely, as I don't do Android. :-D But maybe I nevertheless have seen it there. 🤷‍♂️
In JavaScript it makes sense to use it to cover "something" into a number
e
kotlinx.html DSL uses unary plus, so does Kotlin compiler plugin registration
v
Ah, thanks, I think the former was what I had in mind.
Open in Slack
PreviousNext
Powered by