How break line when "as" or ":" is present?

[MyDogTom]

Should library forbid any of these cases? I would prefer forbid "break before operator".

as, as?

val field = someFunction(valueA, valueB) as SpecificType

Break before operator

val field = someFunction(valueA, valueB)
      as SpecificType

Break after operator

val field = someFunction(valueA, valueB) as
      SpecificType

Don't break at all

val field = someFunction(
    valueA,
    valueB) as SpecificType

Same question for:

class ClassA(paramA: String, paramB: String) : ClassB()

Break before operator

class ClassA(paramA: String, paramB: String) 
      : ClassB()

Break after operator

class ClassA(paramA: String, paramB: String) :
      ClassB()

Don't break at all

class ClassA(
    paramA: String
    paramB: String) : ClassB()

[shyiko]

Hi @MyDogTom. This is a good question. Personally I prefer not to have a newline inserted in a situations like these. e.g.

val field = someFunction(
    valueA,
    valueB
) as SpecificType

class ClassA(
    paramA: String
    paramB: String
) : ClassB()

BUT. This is just one opinion. Would you be willing to open a ticket at https://github.com/yole/kotlin-style-guide/issues to gather some additional feedback?

[vanniktech]

I do think that's the wanted behavior though and I also prefer it a lot. Also kotlinpoet emits classes that way. (I'm not sure about function calls).

[MyDogTom]

@shyiko Good idea. Kotlin/kotlin-style-guide#45

Just to clarify. I think it's hard to select only one allowed approach here. Making such decision can take a lot of time and there is a chance, that consensus won't be achieved at all.

But, I do believe that approach "Break before operator" should be forbidden. This allows to block "bad" approach right now and stay opened for further discussion about recommended approach.

[roschlau]

@MyDogTom I'm curious, why do you seem to have such a strong opinion on "Break before operator"? I find it pretty easy to read, "Break after operator" is much worse in my opinion, as it is needlessly separating a term that should be unseparable as to not confuse readers.

In the case of "Break before operator", my thoughts while reading would be "Okay, that line casts the expression on the line before it to SpecificType. Alright", and I don't even need to completely read the line before it to know what I'm getting. With "Break after operator", my thoughts will go "Whoops, there's a lonely type at that line, where does that come from? It's indented, so probably something to do with the line before it" < Read line before it > "Oh okay, that's a cast there, now that next line makes sense"

[MyDogTom]

@Hikaru755 my reasoning is just the opposite :)
For "break before operator". When I read first line, I see it as complete statement. It means, that I don't have to read second line. That can result in misunderstanding. With "break after operator" I see, that statement is not finished and it encourages me to read next line.

Another reason: I prefer to use same "parsing logic" when I'm reading code. In that case, I prefer to preserve similarity with assignment.

[roschlau]

@MyDogTom Valid concern, but I'd argue that the next line being indented already gives me an obvious clue that the previous line is not finished. If I see a bunch of indented lines, I often just skip to the last one to see where the chain ends, and whether or not I need to read the lines before to get the necessary information for whatever it is I'm doing right now, and having the whole cast on a seperate line helps hugely there.

I understand trying to preserve the similarity with assignment, but honestly, if in any way possible, I always try to avoid splitting assignments over multiple lines as well. It's just hard to read, for the aforementioned reasons.

[blcooley]

Just doing a little triage here. This ticket has been open a long time. Is it still an issue?

I followed up on this and did find a ticket Kotlin/kotlin-style-guide#45 on the kotlin-style-guide repo and am linking it here for reference. That ticket references Kotlin/kotlin-style-guide#2 which is also still open.

[paul-dingemans]

Closing issue as no progress is being made in last 3 years.