Условия и циклы — бесплатный тест онлайн

Вопрос 1 из 20

Какой риск не исчезает после правки «Убывающая прогрессия»: Выбирать форму диапазона по контракту границ и закреплять тестом пустой диапазон, одну точку и последний допустимый индекс?

Диапазоны выразительны для дискретных границ, но ручное условие цикла яснее при сложном или меняющемся шаге. Практическое ограничение подхода: Будет напечатан `[10, 6, 4]`, потому что шаг пересчитывается для попадания в конечную точку. После внедрения придётся исходить из того, что будет напечатан `[4, 7, 10]`, поскольку `toList()` сортирует диапазон. Граница полезности решения описывается условием: Будет напечатан `[10, 7]`, потому что правая граница диапазона исключается. Цена упрощения проявится, если код не компилируется: `step` нельзя применять после `downTo`.

Вопрос 2 из 20

Чем завершится выполнение «Метка внешнего цикла»?

// Проследите фактическое выполнение без изменения кода.
fun main() {
    var sum = 0
    outer@ for (row in 1..3) {
        for (col in 1..3) {
            if (row * col == 4) break@outer
            sum += row * col
        }
    }
    println(sum)
}

Она выведет `9`, поскольку внешний цикл продолжится с `row = 3`. Она выведет `8`: после 1+2+3 и затем 2 цикл добавляет 8, а на паре 2×2 завершает оба цикла. Она выведет `4`, так как произведение 2×2 сначала добавляется в сумму. Код не компилируется: метки разрешены только у `when`. Она выведет `12`, потому что метка завершает только внутренний цикл.

Вопрос 3 из 20

Как превратить неявное предположение в проверяемый контракт «if как выражение»?

// Сохраните назначение фрагмента, но укрепите его контракт.
fun price(age: Int): Int {
    val discount = if (age < 18) 20 else if (age >= 65) 30 else 0
    return 100 - discount
}

fun main() = println(price(65))

Сохранить API и считать достаточным условие: Код не компилируется без явного типа у `discount`. Добавить локальную обработку результата, потому что будет выведено `80`, поскольку первая ветвь сравнения проверяется повторно. Зафиксировать текущее поведение регрессионным тестом: Будет выведено `100`, потому что `if` нельзя присваивать переменной. Спрятать участок за вспомогательной функцией, сохранив предположение: Будет выведено `30`, потому что функция возвращает выбранную ветвь, игнорируя последнюю строку. Для нескольких диапазонов вынести правила цены в ясно упорядоченные условия и покрыть тестами значения на границах 17/18 и 64/65.

Вопрос 4 из 20

Где упрощённое объяснение «Исчерпывающий when» перестаёт работать?

Добавить граничный тест на утверждение: Компилятор не требует `else`, когда `when` возвращает `String`. Воспроизвести редкий сценарий, где `data object` автоматически становится ветвью по умолчанию. Отдельно воспроизвести случай, в котором ветка `is Reply.Ok` неявно покрывает все реализации интерфейса. При работе с обычным открытым интерфейсом или платформенным типом исчерпывающий анализ может быть невозможен. Проверить границу полезности утверждения: `else` нужен только в `when`, который используется как инструкция, а не как выражение.

Вопрос 5 из 20

Какое правило определяет поведение фрагмента «Метка внешнего цикла»?

// На ревью требуется объяснить причину поведения.
fun main() {
    var sum = 0
    outer@ for (row in 1..3) {
        for (col in 1..3) {
            if (row * col == 4) break@outer
            sum += row * col
        }
    }
    println(sum)
}

Поведение связывают с правилом: Она выведет `4`, так как произведение 2×2 сначала добавляется в сумму. Контракт здесь понимают так: Она выведет `9`, поскольку внешний цикл продолжится с `row = 3`. Причину поведения формулируют так: Код не компилируется: метки разрешены только у `when`. Немаркированные `break` и `continue` действуют на ближайший цикл; метка позволяет явно выбрать внешний цикл. Семантика фрагмента приводит к тому, что она выведет `12`, потому что метка завершает только внутренний цикл.

Вопрос 6 из 20

Какой дополнительный сценарий нужен для «if как выражение»?

Зафиксировать сценарий, где ожидается: Будет выведено `80`, поскольку первая ветвь сравнения проверяется повторно. Считать опасной границей ситуацию, где будет выведено `100`, потому что `if` нельзя присваивать переменной. Добавить граничный тест на утверждение: Будет выведено `30`, потому что функция возвращает выбранную ветвь, игнорируя последнюю строку. Проверить, сохраняется ли контракт, когда код не компилируется без явного типа у `discount`. Если ветви возвращают разные типы, общий выведенный тип может стать слишком широким, например `Any`, и скрыть ошибку модели.

Вопрос 7 из 20

Какой риск не исчезает после правки «Исчерпывающий when»: Сохранять `when` исчерпывающим без общего `else`, если добавление нового состояния должно приводить к заметной ошибке компиляции?

Практическое ограничение подхода: `else` нужен только в `when`, который используется как инструкция, а не как выражение. Главный риск формулируют так: Ветка `is Reply.Ok` неявно покрывает все реализации интерфейса. Граница полезности решения описывается условием: Компилятор не требует `else`, когда `when` возвращает `String`. Исчерпывающий `when` делает эволюцию модели безопаснее, но связывает потребителей с полным набором состояний. Цена упрощения проявится, если `data object` автоматически становится ветвью по умолчанию.

Вопрос 8 из 20

Какой список будет напечатан?

// Проследите фактическое выполнение без изменения кода.
fun main() {
    val values = (10 downTo 4 step 3).toList()
    println(values)
}

Будет напечатан `[4, 7, 10]`, поскольку `toList()` сортирует диапазон. Будет напечатан `[10, 7]`, потому что правая граница диапазона исключается. Будет напечатан `[10, 7, 4]`: `downTo` включает обе границы, а шаг равен трём. Код не компилируется: `step` нельзя применять после `downTo`. Будет напечатан `[10, 6, 4]`, потому что шаг пересчитывается для попадания в конечную точку.

Вопрос 9 из 20

Предложенная правка для «if как выражение» звучит так: Для нескольких диапазонов вынести правила цены в ясно упорядоченные условия и покрыть тестами значения на границах 17/18 и 64/65. Какой недостаток важнее обсудить?

После правки останется ограничение: Код не компилируется без явного типа у `discount`. Главная цена решения — необходимость учитывать, что будет выведено `30`, потому что функция возвращает выбранную ветвь, игнорируя последнюю строку. Обратная сторона изменения состоит в том, что будет выведено `100`, потому что `if` нельзя присваивать переменной. Выражение `if` убирает временное присваивание, но длинная цепочка условий хуже читается, чем таблица правил или `when`. Сопровождение усложнится, если окажется, что будет выведено `80`, поскольку первая ветвь сравнения проверяется повторно.

Вопрос 10 из 20

Почему функция `text` компилируется без ветви `else`?

// Проследите фактическое выполнение без изменения кода.
sealed interface Reply {
    data class Ok(val body: String) : Reply
    data object Retry : Reply
    data class Failed(val code: Int) : Reply
}

fun text(r: Reply) = when (r) {
    is Reply.Ok -> r.body
    Reply.Retry -> "повтор"
    is Reply.Failed -> "ошибка ${r.code}"
}

`data object` автоматически становится ветвью по умолчанию. `else` нужен только в `when`, который используется как инструкция, а не как выражение. Иерархия `Reply` запечатана, а `when` перечисляет все известные непосредственные варианты. Ветка `is Reply.Ok` неявно покрывает все реализации интерфейса. Компилятор не требует `else`, когда `when` возвращает `String`.

Вопрос 11 из 20

Почему пример «Убывающая прогрессия» даёт именно такой результат?

// На ревью требуется объяснить причину поведения.
fun main() {
    val values = (10 downTo 4 step 3).toList()
    println(values)
}

Причину поведения формулируют так: Код не компилируется: `step` нельзя применять после `downTo`. Объяснение опирается на утверждение: Будет напечатан `[10, 6, 4]`, потому что шаг пересчитывается для попадания в конечную точку. Контракт здесь понимают так: Будет напечатан `[4, 7, 10]`, поскольку `toList()` сортирует диапазон. Семантика фрагмента приводит к тому, что будет напечатан `[10, 7]`, потому что правая граница диапазона исключается. `..` и `downTo` задают включённые прогрессии, `until` исключает верхнюю границу, а `step` должен быть положительным.

Вопрос 12 из 20

Какое изменение лучше всего защищает границу «Метка внешнего цикла»?

// Сохраните назначение фрагмента, но укрепите его контракт.
fun main() {
    var sum = 0
    outer@ for (row in 1..3) {
        for (col in 1..3) {
            if (row * col == 4) break@outer
            sum += row * col
        }
    }
    println(sum)
}

Зафиксировать текущее поведение регрессионным тестом: Она выведет `4`, так как произведение 2×2 сначала добавляется в сумму. В сложном поиске вынести обход в функцию и вернуть найденный результат, чтобы не строить управление из нескольких меток. Ограничиться поясняющим комментарием о том, что код не компилируется: метки разрешены только у `when`. Сохранить API и считать достаточным условие: Она выведет `9`, поскольку внешний цикл продолжится с `row = 3`. Передать ответственность владельцу вызова, предполагая, что она выведет `12`, потому что метка завершает только внутренний цикл.

Вопрос 13 из 20

Почему поведение «Исчерпывающий when» не является случайностью?

// На ревью требуется объяснить причину поведения.
sealed interface Reply {
    data class Ok(val body: String) : Reply
    data object Retry : Reply
    data class Failed(val code: Int) : Reply
}

fun text(r: Reply) = when (r) {
    is Reply.Ok -> r.body
    Reply.Retry -> "повтор"
    is Reply.Failed -> "ошибка ${r.code}"
}

Для исчерпывающего `when` над sealed-иерархией компилятор проверяет покрытие известных вариантов и требует обновления при расширении модели. Объяснение опирается на утверждение: Компилятор не требует `else`, когда `when` возвращает `String`. Здесь действует следующее правило: `data object` автоматически становится ветвью по умолчанию. Наблюдаемое поведение выводят из того, что ветка `is Reply.Ok` неявно покрывает все реализации интерфейса. Такой результат объясняют тем, что `else` нужен только в `when`, который используется как инструкция, а не как выражение.

Вопрос 14 из 20

Какую точечную правку стоит принять на ревью фрагмента «Убывающая прогрессия»?

// Сохраните назначение фрагмента, но укрепите его контракт.
fun main() {
    val values = (10 downTo 4 step 3).toList()
    println(values)
}

Выбирать форму диапазона по контракту границ и закреплять тестом пустой диапазон, одну точку и последний допустимый индекс. Обернуть операцию проверкой и не менять основной контракт: Будет напечатан `[10, 6, 4]`, потому что шаг пересчитывается для попадания в конечную точку. Вынести участок в отдельный метод, считая верным следующее: Будет напечатан `[4, 7, 10]`, поскольку `toList()` сортирует диапазон. Оставить структуру прежней, документировав утверждение: Код не компилируется: `step` нельзя применять после `downTo`. Оставить реализацию без изменений и закрепить тестом предположение: Будет напечатан `[10, 7]`, потому что правая граница диапазона исключается.

Вопрос 15 из 20

На каком входе или состоянии граница «Метка внешнего цикла» становится заметной?

Считать опасной границей ситуацию, где она выведет `12`, потому что метка завершает только внутренний цикл. Зафиксировать сценарий, где ожидается: Она выведет `9`, поскольку внешний цикл продолжится с `row = 3`. Проверить, сохраняется ли контракт, когда код не компилируется: метки разрешены только у `when`. Проверить крайний ввод, при котором она выведет `4`, так как произведение 2×2 сначала добавляется в сумму. `return` внутри inline-лямбды может быть нелокальным и завершить окружающую функцию, а не только текущий обход.

Вопрос 16 из 20

Какой результат даст код «if как выражение»?

// Проследите фактическое выполнение без изменения кода.
fun price(age: Int): Int {
    val discount = if (age < 18) 20 else if (age >= 65) 30 else 0
    return 100 - discount
}

fun main() = println(price(65))

Будет выведено `100`, потому что `if` нельзя присваивать переменной. Будет выведено `80`, поскольку первая ветвь сравнения проверяется повторно. Будет выведено `30`, потому что функция возвращает выбранную ветвь, игнорируя последнюю строку. Код не компилируется без явного типа у `discount`. Будет выведено `70`: `if` является выражением, а для возраста 65 выбирается ветвь со скидкой 30.

Вопрос 17 из 20

Где поведение «Убывающая прогрессия» требует отдельной проверки?

Добавить регрессию на гипотезу: Будет напечатан `[10, 6, 4]`, потому что шаг пересчитывается для попадания в конечную точку. Большой шаг не гарантирует попадание в правую границу; последовательность заканчивается последним значением, не выходящим за неё. Проверить границу полезности утверждения: Будет напечатан `[10, 7]`, потому что правая граница диапазона исключается. Добавить тест на состояние, при котором будет напечатан `[4, 7, 10]`, поскольку `toList()` сортирует диапазон. Отдельно проверить предположение, что код не компилируется: `step` нельзя применять после `downTo`.

Вопрос 18 из 20

Решение для «Метка внешнего цикла»: В сложном поиске вынести обход в функцию и вернуть найденный результат, чтобы не строить управление из нескольких меток. Что в нём остаётся не бесплатным?

Метка точна и дёшева, но при нескольких уровнях вложенности функция с ранним возвратом обычно проще для ревью. Решение оправдано лишь при условии: Она выведет `12`, потому что метка завершает только внутренний цикл. Сопровождение усложнится, если окажется, что она выведет `9`, поскольку внешний цикл продолжится с `row = 3`. Главная цена решения — необходимость учитывать, что код не компилируется: метки разрешены только у `when`. Обратная сторона изменения состоит в том, что она выведет `4`, так как произведение 2×2 сначала добавляется в сумму.

Вопрос 19 из 20

Какое объяснение результата «if как выражение» выдерживает проверку соседними случаями?

// На ревью требуется объяснить причину поведения.
fun price(age: Int): Int {
    val discount = if (age < 18) 20 else if (age >= 65) 30 else 0
    return 100 - discount
}

fun main() = println(price(65))

В Kotlin `if` возвращает значение; при использовании как выражения обе ветви должны образовывать совместимый тип. Механика примера описывается утверждением: Код не компилируется без явного типа у `discount`. Причина результата в том, что будет выведено `30`, потому что функция возвращает выбранную ветвь, игнорируя последнюю строку. Такой результат объясняют тем, что будет выведено `100`, потому что `if` нельзя присваивать переменной. Из правил языка или API следует, что будет выведено `80`, поскольку первая ветвь сравнения проверяется повторно.

Вопрос 20 из 20

Какая правка устраняет причину риска в «Исчерпывающий when», а не только его проявление?

// Сохраните назначение фрагмента, но укрепите его контракт.
sealed interface Reply {
    data class Ok(val body: String) : Reply
    data object Retry : Reply
    data class Failed(val code: Int) : Reply
}

fun text(r: Reply) = when (r) {
    is Reply.Ok -> r.body
    Reply.Retry -> "повтор"
    is Reply.Failed -> "ошибка ${r.code}"
}

Вынести участок в отдельный метод, считая верным следующее: `else` нужен только в `when`, который используется как инструкция, а не как выражение. Добавить защитную проверку перед фрагментом, поскольку компилятор не требует `else`, когда `when` возвращает `String`. Оставить реализацию без изменений и закрепить тестом предположение: `data object` автоматически становится ветвью по умолчанию. Сохранять `when` исчерпывающим без общего `else`, если добавление нового состояния должно приводить к заметной ошибке компиляции. Перенести проверку в вызывающий код, исходя из того, что ветка `is Reply.Ok` неявно покрывает все реализации интерфейса.