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

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
}

In lambda expressions, spaces should be used aroun 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 instaed of declaring the parameter explicitly. In nested lambdas with parameters, parameters should be always declared explicitly.

Classes with a few arguments can be written in a single line:

class Person(id: Int, name: String)

Classes with longer headers should be formatted so that each primary constructor argument is in a separate line with indentation. Also, the closing parenthesis should be on a new line. If we use inheritance, then the superclass constructor call or list of implemented interfaces should be located on the same line as the parenthesis:

class Person(
    id: Int, 
    name: String,
    surname: String
) : Human(id, name) {
    // ...
}

For multiple interfaces, the superclass constructor call should be located first and then each interface should be located in a different line:

class Person(
    id: Int, 
    name: String,
    surname: String
) : Human(id, name),
    KotlinMaker {
    // ...
}

Constructor parameters can use either the regular indent or the continuation indent (double the regular indent).

Like classes, functions with few arguments and a small body can be written in a single line:

fun add(x: Int, y: Int): Int = x + y

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

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

In some cases, functions with no arguments might be interchangeable with read-only properties. Although the semantics, 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 O(1) complexity
• is cheap to calculate (or cached on the run)
• returns the same result over invocations