Области видимости и scope-функции — бесплатный тест онлайн

Вопрос 1 из 25

Какой результат даст код «Последовательное преобразование let»?

// Проследите фактическое выполнение без изменения кода.
fun main() {
    val length = " Kotlin ".let { it.trim() }.let { it.length }
    println(length)
}

Возникнет ошибка из-за изменения типа между двумя вызовами. Будет выведено `1`, поскольку второй let получает первый блок как функцию. Будет выведено `6`: `let` передаёт объект как `it` и возвращает результат последней строки блока. Будет выведено `8`, потому что первый let возвращает исходную строку. Код не компилируется: два let нельзя соединять.

Вопрос 2 из 25

Что в семантике Kotlin или используемого API объясняет «Receiver и результат run»?

// На ревью требуется объяснить причину поведения.
class Config { var host = ""; var port = 0 }
fun main() {
    val address = Config().run {
        host = "localhost"; port = 8080
        "$host:$port"
    }
    println(address)
}

Контракт здесь понимают так: Возникнет ошибка из-за отсутствия явного `this`. Поведение связывают с правилом: Она напечатает `:0`, поскольку присваивания видны только внутри лямбды-копии. Причина результата в том, что она напечатает представление Config, потому что run возвращает receiver. `run` сочетает receiver-контекст и возвращаемый результат блока; top-level `run` может просто ограничить область локальных имён. Семантика фрагмента приводит к тому, что код не компилируется: свойства val объекта нельзя менять в run.

Вопрос 3 из 25

Что изменить в «Настройка объекта через apply», чтобы скрытое допущение стало явным контрактом?

// Сохраните назначение фрагмента, но укрепите его контракт.
data class Request(var method: String = "GET", var path: String = "/")
fun main() {
    val r = Request().apply { method = "POST"; path = "/items" }
    println("${r.method} ${r.path}")
}

Не прятать в `apply` операции, которые могут неочевидно бросить исключение или запускать внешние эффекты. Вынести участок в отдельный метод, считая верным следующее: Будет выведено `GET /`, так как изменения применяются к копии. Обернуть операцию проверкой и не менять основной контракт: Возникнет ошибка из-за двух присваиваний внутри лямбды. Оставить структуру прежней, документировав утверждение: Код не компилируется: apply работает только с builder-классами. Перенести проверку в вызывающий код, исходя из того, что будет выведено `kotlin.Unit`, потому что apply возвращает результат блока.

Вопрос 4 из 25

Какой дополнительный сценарий нужен для «Наблюдение через also»?

Считать опасной границей ситуацию, где сначала `sorted=6`, затем `6`, потому что also выполняется после sum. Добавить граничный тест на утверждение: Сначала исходный `[3, 1, 2]`, затем `6`, потому что sorted ленивый. Проверить крайний ввод, при котором будет только список: also заменяет последующую цепочку на Unit. Проверить, сохраняется ли контракт, когда код не компилируется: List не поддерживает also. Изменение mutable receiver внутри `also` допустимо синтаксически и может сделать дальнейший конвейер неожиданным.

Вопрос 5 из 25

Что может усложниться в сопровождении после изменения «Границы цепочки scope-функций»: Дать промежуточным значениям имена, если цепочка затрудняет локализацию ошибки, и оставить тесты на каждую смысловую границу?

Сопровождение усложнится, если окажется, что заменить все случаи случайной строкой и проверять лишь, что результат не null. Новый риск связан с тем, что сравнить число вызовов let/apply в байткоде без проверки результата. Решение оправдано лишь при условии: Проверить только обычное имя и считать require недостижимым. Компромисс состоит в утверждении: Проверить только `null`, потому что все scope-функции работают одинаково после safe call. Проверки поведения переживают косметический рефакторинг, тогда как тесты структуры быстро становятся обузой.

Вопрос 6 из 25

Какая правка устраняет причину риска в «Receiver и результат run», а не только его проявление?

// Сохраните назначение фрагмента, но укрепите его контракт.
class Config { var host = ""; var port = 0 }
fun main() {
    val address = Config().run {
        host = "localhost"; port = 8080
        "$host:$port"
    }
    println(address)
}

Добавить защитную проверку перед фрагментом, поскольку код не компилируется: свойства val объекта нельзя менять в run. Перенести проверку в вызывающий код, исходя из того, что она напечатает `:0`, поскольку присваивания видны только внутри лямбды-копии. Оставить реализацию без изменений и закрепить тестом предположение: Возникнет ошибка из-за отсутствия явного `this`. Спрятать участок за вспомогательной функцией, сохранив предположение: Она напечатает представление Config, потому что run возвращает receiver. Использовать `run`, когда конфигурация и вычисленный результат образуют одну короткую операцию, а не как универсальный контейнер.

Вопрос 7 из 25

Какой пограничный сценарий обязательно добавить к проверкам «Настройка объекта через apply»?

Добавить тест на состояние, при котором код не компилируется: apply работает только с builder-классами. Проверить соседний случай: Возникнет ошибка из-за двух присваиваний внутри лямбды. Проверить границу полезности утверждения: Будет выведено `GET /`, так как изменения применяются к копии. Воспроизвести редкий сценарий, где будет выведено `kotlin.Unit`, потому что apply возвращает результат блока. Возврат receiver не означает неизменяемость: частично настроенный объект может утечь, если блок вызывает внешний код.

Вопрос 8 из 25

Решение для «Наблюдение через also»: Оставлять в `also` наблюдение, не меняющее смысл исходного конвейера; бизнес-переход выразить отдельной операцией. Что в нём остаётся не бесплатным?

Главная цена решения — необходимость учитывать, что сначала исходный `[3, 1, 2]`, затем `6`, потому что sorted ленивый. Сопровождение усложнится, если окажется, что будет только список: also заменяет последующую цепочку на Unit. Решение оправдано лишь при условии: Сначала `sorted=6`, затем `6`, потому что also выполняется после sum. Промежуточная диагностика не разрывает цепочку, но скрытые побочные эффекты уменьшают локальную понятность. После правки останется ограничение: Код не компилируется: List не поддерживает also.

Вопрос 9 из 25

Какой набор тестов выявит различия между преобразованием и побочным контролем?

// Проследите фактическое выполнение без изменения кода.
fun normalize(raw: String?): String = raw
    ?.trim()
    ?.takeIf { it.isNotEmpty() }
    ?.also { require(!it.contains('/')) }
    ?: "guest"

Сравнить число вызовов let/apply в байткоде без проверки результата. Проверить только `null`, потому что все scope-функции работают одинаково после safe call. Проверить только обычное имя и считать require недостижимым. Заменить все случаи случайной строкой и проверять лишь, что результат не null. Проверить null, пробелы, обычное имя и имя со слешем; последний случай должен бросить ошибку, а остальные дать ожидаемую строку.

Вопрос 10 из 25

Что в семантике Kotlin или используемого API объясняет «Последовательное преобразование let»?

// На ревью требуется объяснить причину поведения.
fun main() {
    val length = " Kotlin ".let { it.trim() }.let { it.length }
    println(length)
}

`let` использует аргумент `it` и возвращает результат лямбды; особенно полезен для преобразования и nullable-цепочки. Семантика фрагмента приводит к тому, что будет выведено `1`, поскольку второй let получает первый блок как функцию. Контракт здесь понимают так: Возникнет ошибка из-за изменения типа между двумя вызовами. Механика примера описывается утверждением: Будет выведено `8`, потому что первый let возвращает исходную строку. Причина результата в том, что код не компилируется: два let нельзя соединять.

Вопрос 11 из 25

В «Настройка объекта через apply» выбрали решение: Не прятать в `apply` операции, которые могут неочевидно бросить исключение или запускать внешние эффекты. Какова его реальная цена?

Сопровождение усложнится, если окажется, что будет выведено `kotlin.Unit`, потому что apply возвращает результат блока. Главная цена решения — необходимость учитывать, что код не компилируется: apply работает только с builder-классами. `apply` делает создание компактным, но длинная конфигурация со множеством эффектов хуже явной фабрики. Граница полезности решения описывается условием: Возникнет ошибка из-за двух присваиваний внутри лямбды. После правки останется ограничение: Будет выведено `GET /`, так как изменения применяются к копии.

Вопрос 12 из 25

Какие строки будут выведены?

// Проследите фактическое выполнение без изменения кода.
fun main() {
    val result = listOf(3, 1, 2)
        .sorted()
        .also { println("sorted=$it") }
        .sum()
    println(result)
}

Будет только список: also заменяет последующую цепочку на Unit. Сначала исходный `[3, 1, 2]`, затем `6`, потому что sorted ленивый. Код не компилируется: List не поддерживает also. Сначала `sorted=6`, затем `6`, потому что also выполняется после sum. Сначала `sorted=[1, 2, 3]`, затем `6`: `also` выполняет побочное наблюдение и возвращает исходный список.

Вопрос 13 из 25

Какой принцип лежит в основе поведения «Границы цепочки scope-функций»?

// На ревью требуется объяснить причину поведения.
fun normalize(raw: String?): String = raw
    ?.trim()
    ?.takeIf { it.isNotEmpty() }
    ?.also { require(!it.contains('/')) }
    ?: "guest"

Из правил языка или API следует, что сравнить число вызовов let/apply в байткоде без проверки результата. Тестировать нужно итоговый контракт и эффекты, а не выбор конкретной scope-функции; рефакторинг между ними допустим только при сохранении семантики. Механика примера описывается утверждением: Проверить только обычное имя и считать require недостижимым. Причина результата в том, что заменить все случаи случайной строкой и проверять лишь, что результат не null. Ключевым считают контракт: Проверить только `null`, потому что все scope-функции работают одинаково после safe call.

Вопрос 14 из 25

Какая правка устраняет причину риска в «Последовательное преобразование let», а не только его проявление?

// Сохраните назначение фрагмента, но укрепите его контракт.
fun main() {
    val length = " Kotlin ".let { it.trim() }.let { it.length }
    println(length)
}

Спрятать участок за вспомогательной функцией, сохранив предположение: Будет выведено `8`, потому что первый let возвращает исходную строку. Вынести участок в отдельный метод, считая верным следующее: Возникнет ошибка из-за изменения типа между двумя вызовами. Оставить реализацию без изменений и закрепить тестом предположение: Будет выведено `1`, поскольку второй let получает первый блок как функцию. Не оборачивать каждую операцию в `let`; использовать его, когда он сокращает область имени или выражает преобразование. Добавить защитную проверку перед фрагментом, поскольку код не компилируется: два let нельзя соединять.

Вопрос 15 из 25

Где поведение «Receiver и результат run» требует отдельной проверки?

Нелокальный return из inline `run` способен завершить внешнюю функцию, если не использовать метку. Добавить тест на состояние, при котором код не компилируется: свойства val объекта нельзя менять в run. Проверить соседний случай: Она напечатает `:0`, поскольку присваивания видны только внутри лямбды-копии. Добавить регрессию на гипотезу: Возникнет ошибка из-за отсутствия явного `this`. Проверить границу полезности утверждения: Она напечатает представление Config, потому что run возвращает receiver.

Вопрос 16 из 25

Какой контракт снимает спор о причине поведения «Наблюдение через also»?

// На ревью требуется объяснить причину поведения.
fun main() {
    val result = listOf(3, 1, 2)
        .sorted()
        .also { println("sorted=$it") }
        .sum()
    println(result)
}

Семантика фрагмента приводит к тому, что сначала исходный `[3, 1, 2]`, затем `6`, потому что sorted ленивый. Из правил языка или API следует, что сначала `sorted=6`, затем `6`, потому что also выполняется после sum. Механика примера описывается утверждением: Будет только список: also заменяет последующую цепочку на Unit. Причина результата в том, что код не компилируется: List не поддерживает also. `also` передаёт объект как аргумент и возвращает его же; обычно подходит для журналирования, проверки или дополнительного действия.

Вопрос 17 из 25

Какой рефакторинг делает поведение «Границы цепочки scope-функций» предсказуемее?

// Сохраните назначение фрагмента, но укрепите его контракт.
fun normalize(raw: String?): String = raw
    ?.trim()
    ?.takeIf { it.isNotEmpty() }
    ?.also { require(!it.contains('/')) }
    ?: "guest"

Добавить защитную проверку перед фрагментом, поскольку заменить все случаи случайной строкой и проверять лишь, что результат не null. Спрятать участок за вспомогательной функцией, сохранив предположение: Проверить только обычное имя и считать require недостижимым. Сохранить API и считать достаточным условие: Проверить только `null`, потому что все scope-функции работают одинаково после safe call. Ограничиться поясняющим комментарием о том, что сравнить число вызовов let/apply в байткоде без проверки результата. Дать промежуточным значениям имена, если цепочка затрудняет локализацию ошибки, и оставить тесты на каждую смысловую границу.

Вопрос 18 из 25

Какой контрпример точнее всего показывает границу «Последовательное преобразование let»?

Проверить границу полезности утверждения: Возникнет ошибка из-за изменения типа между двумя вызовами. В длинной цепочке несколько `it` скрывают, к какому объекту относится операция; именованный параметр делает код надёжнее. Отдельно воспроизвести случай, в котором код не компилируется: два let нельзя соединять. Проверить, сохраняется ли контракт, когда будет выведено `8`, потому что первый let возвращает исходную строку. Воспроизвести редкий сценарий, где будет выведено `1`, поскольку второй let получает первый блок как функцию.

Вопрос 19 из 25

Что станет новой точкой внимания после изменения «Receiver и результат run»: Использовать `run`, когда конфигурация и вычисленный результат образуют одну короткую операцию, а не как универсальный контейнер?

После внедрения придётся исходить из того, что она напечатает представление Config, потому что run возвращает receiver. Цена упрощения проявится, если код не компилируется: свойства val объекта нельзя менять в run. Новый риск связан с тем, что возникнет ошибка из-за отсутствия явного `this`. Компромисс состоит в утверждении: Она напечатает `:0`, поскольку присваивания видны только внутри лямбды-копии. `run` уменьшает повторение имени объекта, но скрытый receiver может конфликтовать с внешним `this`.

Вопрос 20 из 25

Что появится в выводе примера «Настройка объекта через apply»?

// Проследите фактическое выполнение без изменения кода.
data class Request(var method: String = "GET", var path: String = "/")
fun main() {
    val r = Request().apply { method = "POST"; path = "/items" }
    println("${r.method} ${r.path}")
}

Будет выведено `POST /items`: `apply` выполняет блок с receiver и возвращает сам объект. Возникнет ошибка из-за двух присваиваний внутри лямбды. Код не компилируется: apply работает только с builder-классами. Будет выведено `GET /`, так как изменения применяются к копии. Будет выведено `kotlin.Unit`, потому что apply возвращает результат блока.

Вопрос 21 из 25

Что добавить в регрессионный набор для «Границы цепочки scope-функций»?

Проверить соседний случай: Проверить только `null`, потому что все scope-функции работают одинаково после safe call. Считать опасной границей ситуацию, где заменить все случаи случайной строкой и проверять лишь, что результат не null. Отдельно проверить предположение, что сравнить число вызовов let/apply в байткоде без проверки результата. Замена `also` на `let` без возврата `it` изменит тип и значение всей цепочки, хотя тело блока может выглядеть одинаково. Добавить регрессию на гипотезу: Проверить только обычное имя и считать require недостижимым.

Вопрос 22 из 25

Решение для «Последовательное преобразование let»: Не оборачивать каждую операцию в `let`; использовать его, когда он сокращает область имени или выражает преобразование. Что в нём остаётся не бесплатным?

Обратная сторона изменения состоит в том, что будет выведено `8`, потому что первый let возвращает исходную строку. После правки останется ограничение: Будет выведено `1`, поскольку второй let получает первый блок как функцию. Главная цена решения — необходимость учитывать, что возникнет ошибка из-за изменения типа между двумя вызовами. Сопровождение усложнится, если окажется, что код не компилируется: два let нельзя соединять. `let` помогает локализовать значение, но чрезмерное применение превращает прямой код в вложенную цепочку контекстов.

Вопрос 23 из 25

Каков фактический результат выполнения фрагмента «Receiver и результат run»?

// Проследите фактическое выполнение без изменения кода.
class Config { var host = ""; var port = 0 }
fun main() {
    val address = Config().run {
        host = "localhost"; port = 8080
        "$host:$port"
    }
    println(address)
}

Возникнет ошибка из-за отсутствия явного `this`. Она напечатает `localhost:8080`: `run` использует receiver как `this` и возвращает строку последнего выражения. Код не компилируется: свойства val объекта нельзя менять в run. Она напечатает представление Config, потому что run возвращает receiver. Она напечатает `:0`, поскольку присваивания видны только внутри лямбды-копии.

Вопрос 24 из 25

Что точнее описывает механику фрагмента «Настройка объекта через apply»?

// На ревью требуется объяснить причину поведения.
data class Request(var method: String = "GET", var path: String = "/")
fun main() {
    val r = Request().apply { method = "POST"; path = "/items" }
    println("${r.method} ${r.path}")
}

Здесь действует следующее правило: Будет выведено `kotlin.Unit`, потому что apply возвращает результат блока. Ключевым считают контракт: Будет выведено `GET /`, так как изменения применяются к копии. Механика примера описывается утверждением: Возникнет ошибка из-за двух присваиваний внутри лямбды. `apply` возвращает receiver и удобен для настройки объекта, когда результат блока отдельно не нужен. Из правил языка или API следует, что код не компилируется: apply работает только с builder-классами.

Вопрос 25 из 25

Какую точечную правку стоит принять на ревью фрагмента «Наблюдение через also»?

// Сохраните назначение фрагмента, но укрепите его контракт.
fun main() {
    val result = listOf(3, 1, 2)
        .sorted()
        .also { println("sorted=$it") }
        .sum()
    println(result)
}

Оставить структуру прежней, документировав утверждение: Код не компилируется: List не поддерживает also. Передать ответственность владельцу вызова, предполагая, что сначала исходный `[3, 1, 2]`, затем `6`, потому что sorted ленивый. Оставить реализацию без изменений и закрепить тестом предположение: Сначала `sorted=6`, затем `6`, потому что also выполняется после sum. Оставлять в `also` наблюдение, не меняющее смысл исходного конвейера; бизнес-переход выразить отдельной операцией. Вынести участок в отдельный метод, считая верным следующее: Будет только список: also заменяет последующую цепочку на Unit.