kotlin-style-guide icon indicating copy to clipboard operation
kotlin-style-guide copied to clipboard

Modifier order

Open yole opened this issue 8 years ago • 10 comments

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

yole avatar May 31 '16 17:05 yole

I think you're missing the inline modifier.

cypressious avatar May 31 '16 17:05 cypressious

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)
}

AlexeyTsvetkov avatar May 31 '16 19:05 AlexeyTsvetkov

IMO public should be explicit in libraries and other APIs.

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

voddan avatar Jun 08 '16 07:06 voddan

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.

yole avatar Jun 08 '16 07:06 yole

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

zeljkot avatar Mar 30 '17 13:03 zeljkot

Needs to add ~~header and impl~~ expect and actual.

JakeWharton avatar Aug 14 '17 19:08 JakeWharton

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

antoniolg avatar Dec 05 '17 08:12 antoniolg

agree with @antoniolg

arturbosch avatar Dec 05 '17 13:12 arturbosch

suspend should also be included

mkobit avatar Dec 06 '17 22:12 mkobit

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

mtopolnik avatar Dec 17 '17 11:12 mtopolnik