Coding Conventions

This page contains the current coding style for the Kotlin language.

Naming Style

If in doubt default to the Java Coding Conventions such as:

• use of camelCase for names (and avoid underscore in names)
• types start with upper case
• methods and properties start with lower case
• use 4 space indentation
• public functions should have documentation such that it appears in Kotlin Doc

Colon

There is a space before colon where colon separates type and supertype and there's no space where colon separates instance and type:

interface Foo<out T : Any> : Bar {
    fun foo(a: Int): T
}

Lambdas

In lambda expressions, spaces should be used around the curly braces, as well as around the arrow which separates the parameters from the body. Whenever possible, a lambda should be passed outside of parentheses.

list.filter { it > 10 }.map { element -> element * 2 }

In lambdas which are short and not nested, it's recommended to use the it convention instead of declaring the parameter explicitly. In nested lambdas with parameters, parameters should be always declared explicitly.

Unit

If a function returns Unit, the return type should be omitted:

fun foo() { // ": Unit" is omitted here

}

Functions vs Properties

In some cases functions with no arguments might be interchangeable with read-only properties. Although the semantics are similar, there are some stylistic conventions on when to prefer one to another.

Prefer a property over a function when the underlying algorithm:

• does not throw
• has a O(1) complexity
• is cheap to calculate (or caсhed on the first run)
• returns the same result over invocations