type | layout | category | title | url |
---|---|---|---|---|
doc |
reference |
Basics |
Стилистика кода |
Данная страница содержит описание текущего стиля написания кода на языке Kotlin.
При возникновении сомнений по умолчанию используется следующие правила Соглашение о стилистике кода для языка Java:
- используйте camelCase в названиях (а также избегайте подчёркиваний)
- названия типов пишутся с заглавной буквы
- названия методов и свойств начинаются со строчной буквы
- используйте отступ из 4 пробелов
- функции, объявленные как public, желательно снабжать документацией в стиле документации языка Kotlin
В тех случаях, когда двоеточие разделяет тип и подтип, перед двоеточием ставится пробел. Если же двоеточие ставится между сущностью и типом, то пробел опускается:
interface Foo<out T : Any> : Bar {
fun foo(a: Int): T
}
В лямбда-выражениях фигурные скобки, а также стрелка и параметры отделяются пробелами. Желательно передавать лямбду за пределами скобок.
list.filter { it > 10 }.map { element -> element * 2 }
В коротких лямбда-выражениях, не являющихся вложенными, рекомендуется использовать соглашение it
вместо явного объявления параметра. Во вложенных лямбдах с параметрами последние всегда должны быть объявлены.
Классы с небольшим количеством аргументов можно писать на одной строчке:
class Person(id: Int, name: String)
Классы с более длинными сигнатурами должны быть отформатированны так, чтобы каждый параметр располагался с новой строки
class Person(
id: Int,
name: String,
surname: String
) : Human(id, name) {
// ...
}
Если класс расширяет несколько интерфейсов, конструктор суперкласса (если он есть) должен располагаться на первой строке, а после него, список расширяемых интерфейсов: каждый интерфейс с новой строки.
class Person(
id: Int,
name: String,
surname: String
) : Human(id, name),
KotlinMaker {
// ...
}
Для параметров конструктора может использоваться как обычный отступ, так и двойной.
Если возвращаемым типом является Unit, то его можно явно не указывать:
fun foo() { // здесь пропущено ": Unit"
}
В некоторых случаях, функции без аргументов могут быть взаимозаменяемы с неизменяемыми (read-only) свойствами. Не смотря на схожую семантику, есть некоторые стилистические соглашения, указывающие на то, когда лучше использовать одно из этих решений.
Использование свойства перед функцией предпочтительнее когда лежащий в основе алгоритм:
- не выбрасывает исключений
- имеет
O(1)
сложность - не требует больших затрат на выполнение (или результат вычислений кэшируется при первом вызове)
- возвращает одинаковый результат