Modifier order

[yole]

If a declaration has multiple modifiers, always put them in the following order:

public / protected / private / internal
final / open / abstract
override
inner
enum / annotation
companion
inline
infix
operator

[cypressious]

I think you're missing the inline modifier.

[AlexeyTsvetkov]

I think the style guide should discourage from using the public modifier. The only useful case is overriding supertype member visibility:

open class A {
    protected open val x: Int = 10
}

class B : A() {
    public override val x: Int = 20
}

fun main(args: Array<String>) {
    // error: println(A().x)
    println(B().x)
}

[voddan]

IMO public should be explicit in libraries and other APIs.

Also it makes sense to have more strict formatting rules for library writes.

[yole]

We did discuss having a separate set of style rules and inspections for library writers. Explicit public will likely be one of the rules. Explicitly declaring all return types will be another, and actually a more important one.

[zeljkot]

lateinit is missing.
BTW it would be nice if IntelliJ could fix this, like for Java (Inspections -> Java -> Missorted modifiers).

[JakeWharton]

Needs to add header and impl expect and actual.

[antoniolg]

What about const? I'd probably use it right after the visibility modifier.

[arturbosch]

agree with @antoniolg

[mkobit]

suspend should also be included

[mtopolnik]

IntelliJ currently generates overriding method declaration putting suspend in front, this seems like a wrong choice. suspend override fun(...) makes less sense than override suspend fun(...). You can't override a suspend with non-suspend and vice versa, but saying suspend override fun() sounds like you can. If it said override suspend fun(...), that would be the natural way of saying that we're "overriding this suspend fun".