Как сделать код на Kotlin более понятным для чтения

В этой статье я дам несколько советов с примерами, как сделать код на Kotlin более понятным для чтения.

Другие полезные статьи на тему Kotlin:

Практические советы

Используйте require и check:

require(arg.length < 10) {

"message"

}

val result = checkNotNull(bar(arg)) {

"message"

}

/// вместо ///

if (arg.length < 10) {

throw IllegalArgumentException("message")

}

val result = bar(arg)

?: throw IllegalStateException("message")

Используйте функции вместо комментариев:

val user = getUser(id)

validate(user)

activate(user)

private fun validate(user: User) {

// код валидации

}

private fun activate(user: User) {

// код активации

}

/// вместо ///

val user = getUser(id)

* Validate user

// код валидации

* Activate user

// код активации

А лучше — функции-расширения:

private fun User.validate(): User {

// код валидации

return this

}

private fun User.activate(): User {

// код активации

return this

}

...

val user = getUser(id)

.validate()

.activate()

Инфиксные функции делают код более легким для чтения:

val x = mapOf(1 to "a")

val range = 1 until 10

val loop = listOf(...) zip listOf(...)

/// вместо ///

val x = mapOf(1.to("a"))

val range = 1.until(10)

val loop = listOf(...).zip(listOf(...))

Делайе функции инфиксными, если:

функция не имеет побочных эффектов;
имеет простую логику;
имеет короткое имя;
используется в местах, где скобки будут мешать чтению.

Используйте функции with, apply и also:

...какой-то код...

with(foo.id) {

LOGGER.info("id is $this")

doSomething() // method of id

doSomethingElse(this)

}

...какой-то код...

/// вместо ///

...какой-то код...

val id = foo.id

LOGGER.info("id is $id")

id.doSomething()

doSomethingElse(id)

...какой-то код...

Не указывайте тип там, где его можно не указывать:

val x = "a"

override fun foo() = 1

/// вместо ///

val x: String = "a"

override fun foo(): Int = 1

Исключения:

возвращаемый функцией тип слишком сложный, например Map<Int, Map<String, String>>;
когда вызываешь функции, не имеющие nullable-аннотации (например, обычные функции Java).

Используйте присваивание при создании функции, состоящей из одного выражения:

fun foo(id: Int) = getFoo(id)

.chain1()

.chain2()

.chain3()

.chain4 {

// лямбда

}

/// вместо ///

fun foo(id: Int): Bar {

return getFoo(id)

.chain1()

.chain2()

.chain3()

.chain4 {

// лямбда

}

Typealias упростит работу со сложными типами:

typealias CustomerId = Int

typealias PurchaseId = String

typealias StoreName = String

typealias Report = Map<CustomerId, Map<PurchaseId, StoreName>>

fun(report: Report) = // ...

/// вместо ///

fun(report: Map<Int, Map<String, String>>) = // ...

Используйте метки точности для уточнения типа присваиваемого значения:

val x = 1L

val y = 1.2f

/// вместо ///

val x: Long = 1

val y: Float = 1.2

Пользуйтесь подчеркиванием, чтобы сделать длинные числа более читаемыми:

val x = 1_000_000

/// вместо ///

val x = 1000000

Применяйте интерполяцию строк, чтобы сделать их более читаемыми:

val x = "customer $id bought ${purchases.count()} items"

val y = """He said "I’m tired""""

/// вместо ///

val x = "customer " + id + " bought " + purchases.count() + " items"

val y = "He said \"I’m tired\""

Используйте оператор ? для возврата управления:

val user = getUser()

?: return 0

/// вместо ///

val user = getUser()

if (user == null) {

return 0

}

Применяйте тип Sequence для оптимизации обработки очень длинных списков (более 1000 элементов):

listOf(1).asSequence()

.filter { ... }

.map { ... }

.maxBy { ... }

/// вместо ///

listOf(1)

.filter { ... }

.map { ... }

.maxBy { ... }

Используйте обратные кавычки при написании имен тестов:

fun `test foo - when foo increases by 3% - returns true`() { ... }

/// вместо ///

fun testFoo_whenFooIncreasesBy3Percent_returnsTrue() { ... }

Проблемы и решения Kotlin

Проблема номер 1: let. Многие программисты привыкли использовать let в качестве простой и удобной альтернативы if (x == null):

fun deleteImage(){

var imageFile : File ? = ...

imageFile?.let {

if(it.exists()) it.delete()

}

Так делать не стоит. Использование it — дурной тон, потому что множественные it могут смешаться, если в коде появится еще одна подобная лямбда. Ты можешь попробовать исправить это с помощью конструкции imageFile?.let { image ->, но в итоге сделаешь еще хуже, потому что в той же области видимости появится еще одна переменная, которая ссылается на то же значение, но имеет другое имя. И это имя надо будет придумать!

На самом деле в большинстве случаев исправить эту проблему можно простым отказом от let:

fun deleteImage(){

val imageFile : File ? = ...

if(imageFile != null) {

if(imageFile.exists()) imageFile.delete()

}

С этим кодом все в порядке. Умное приведение типов сделает свою работу, и ты сможешь ссылаться на imageFile после проверки как на не nullable-переменную.

Но! Такой прием не сработает, если речь идет не о локальной переменной, а о полях класса. Из‑за того что поля класса могут изменяться несколькими методами, работающими в разных потоках, компилятор не сможет использовать смарткастинг.

Как раз здесь и можно использовать let.

Но есть и более необычные способы. Например, выходить из функции, если значение поля null:

fun deleteImage() {

val imageFile = getImage() ?: return

...

}

Или использовать метод takeIf:

fun deleteImage() {

getImage()?.takeIf { it.exists }?.let {it.delete()}

}

Можно даже скомбинировать оба подхода:

fun deleteImage() {

val image = getImage()?.takeIf { it.exists } ?: return

image.delete()

}/pre>

<strong>Проблема номер 2: also и apply.</strong> Синтаксис Kotlin поощряет использование лямбд везде, где только возможно. Иногда это приводит к созданию весьма монструозных конструкций:

Intent(context, MyActivity::class.java).apply {

putExtra("data", 123)

addFlags(Intent.FLAG_ACTIVITY_REORDER_TO_FRONT)

}).also { intent ->

startActivity(this@FooActivity, intent)

}

Смысл такого кода в том, чтобы ограничить создание интента и его использование двумя различными областями видимости, что в теории должно благотворно повлиять на его модульность.

На самом деле такие конструкции только захламляют код. Гораздо красивее выглядит его более прямолинейная версия:

val intent = Intent(context, MyActivity::class.java).apply {

putExtra("data", 123)

addFlags(Intent.FLAG_ACTIVITY_REORDER_TO_FRONT)

})

startActivity(this@FooActivity,intent)

А еще лучше вынести код конфигурирования объекта в отдельную функцию:

fun startSomeActivity() {

startActivity(getSomeIntent())

}

fun getSomeIntent() = Intent(context, SomeActivity::class.java).apply {

// ...

}

Проблема номер 3: run. Распространенный прием — использовать функцию run для обрамления блоков кода:

val userName: String

get() {

preferenceManager.getInstance()?.run {

getName()

} ?: run {

getString(R.string.stranger)

}

Это абсолютно бессмысленное захламление кода. Оно затрудняет чтение простого по своей сути кода:

1 2	val userName: String get() = preferenceManager.getInstance()?.getName() ?: getString(R.string.stranger)

Если же кода в блоке «если null» больше одной строчки, то можно использовать такую конструкцию:

preferenceManager.getInstance()?.getName().orDefault {

Log.w(“Name not found, returning default”)

getString(R.string.stranger)

}

Проблема номер 4: with. В данном случае проблема не в самой функции with, а в ее игнорировании. Разработчики просто не используют эту функцию, несмотря на всю ее красоту: