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

Вопрос 1 из 20

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

val label = if 7 % 2 == 0 then "even" else "odd"
println(label.toUpperCase)

`match` проверяет варианты сверху вниз и выбирает первый подходящий `case`; более общий шаблон может сделать нижние варианты недостижимыми `if` возвращает значение, поэтому обе ветви должны образовать общий тип, пригодный для дальнейшего использования Guard после шаблона уточняет уже сопоставленное значение; при ложном guard поиск продолжается со следующего `case` Компилятор откладывает выбор типа до первого использования значения, поэтому объявленная форма выражения здесь ничего не ограничивает Неявное числовое преобразование всегда выбирает ближайший тип без потери диапазона, поэтому явная проверка границ не требуется

Вопрос 2 из 20

Для темы «if как выражение» после рефакторинга код по-прежнему компилируется, однако его статический тип стал шире. Какой дефект остаётся возможным при корректном синтаксисе?

// Дополнительный контекст: Публичную сигнатуру слегка изменили, но большая часть вызывающего кода осталась прежней.
val label = if 7 % 2 == 0 then "even" else "odd"
println(label.toUpperCase)

Отсутствующая ветвь `else` даёт `Unit` в ложном случае и часто расширяет итоговый тип до неожиданного объединения. Локальное изменение сигнатуры не способно повлиять на поиск перегрузки, given или вывод типа в вызывающем коде. Guard с побочным эффектом или дорогим вычислением усложняет порядок проверки и может выполняться чаще, чем кажется. Ранний шаблон `_` или широкий тип перехватывает данные, которые разработчик рассчитывал обработать специализированным случаем. Общий тип ветвей `if` всегда сохраняет все методы, доступные в каждой ветви по отдельности.

Вопрос 3 из 20

При исправлении темы «if как выражение» на ревью уже воспроизвели проблему: Отсутствующая ветвь `else` даёт `Unit` в ложном случае и часто расширяет итоговый тип до неожиданного объединения. Какую правку стоит принять?

val label = if 7 % 2 == 0 then "even" else "odd"
println(label.toUpperCase)
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.

Для вычисляющего `if` задавайте обе ветви; отдельный `if` без `else` оставляйте только для осознанного побочного эффекта. Оставляйте guards короткими и чистыми; тяжёлую проверку вынесите в заранее названный предикат. Оставить публичный тип результата выведенным из тела: это позволит API автоматически подстраиваться под будущие правки. Располагая случаи, идите от узких к широким, а общий вариант оставляйте последним. Расширить спорный тип до `Any`, а точные проверки перенести во все места использования, чтобы не менять текущую реализацию.

Вопрос 4 из 20

В контракте темы «if как выражение» какое решение не превращает частный успешный случай в общее обещание?

`match` проверяет варианты сверху вниз и выбирает первый подходящий `case`; более общий шаблон может сделать нижние варианты недостижимыми. Отдельная граница — guard с побочным эффектом или дорогим вычислением усложняет порядок проверки и может выполняться чаще, чем кажется. `If` возвращает значение, поэтому обе ветви должны образовать общий тип, пригодный для дальнейшего использования. Отдельная граница — ранний шаблон `_` или широкий тип перехватывает данные, которые разработчик рассчитывал обработать специализированным случаем. `If` возвращает значение, поэтому обе ветви должны образовать общий тип, пригодный для дальнейшего использования. Отдельная граница — одного успешного запуска достаточно, чтобы подтвердить контракт на всех входах. Guard после шаблона уточняет уже сопоставленное значение; при ложном guard поиск продолжается со следующего `case`. Отдельная граница — отсутствующая ветвь `else` даёт `Unit` в ложном случае и часто расширяет итоговый тип до неожиданного объединения. `If` возвращает значение, поэтому обе ветви должны образовать общий тип, пригодный для дальнейшего использования. Отдельная граница — отсутствующая ветвь `else` даёт `Unit` в ложном случае и часто расширяет итоговый тип до неожиданного объединения.

Вопрос 5 из 20

При проверке темы «if как выражение» какой контроль остаётся полезным после рефакторинга и переименования кода?

Для вычисляющего `if` задавайте обе ветви; отдельный `if` без `else` оставляйте только для осознанного побочного эффекта. В проверке воспроизвести ситуацию: отсутствующая ветвь `else` даёт `Unit` в ложном случае и часто расширяет итоговый тип до неожиданного объединения. В теме «if как выражение» исправить один показанный вызов по рекомендации «Располагая случаи, идите от узких к широким, а общий вариант оставляйте последним». Общий контракт и прежнюю границу отдельно не воспроизводить. Оставляйте guards короткими и чистыми; тяжёлую проверку вынесите в заранее названный предикат. В проверке воспроизвести ситуацию: отсутствующая ветвь `else` даёт `Unit` в ложном случае и часто расширяет итоговый тип до неожиданного объединения. `If` возвращает значение, поэтому обе ветви должны образовать общий тип, пригодный для дальнейшего использования. После правки ограничиться исходным примером без пограничного входа. Для вычисляющего `if` задавайте обе ветви; отдельный `if` без `else` оставляйте только для осознанного побочного эффекта. В проверке воспроизвести ситуацию: ранний шаблон `_` или широкий тип перехватывает данные, которые разработчик рассчитывал обработать специализированным случаем.

Вопрос 6 из 20

Какая характеристика конструкции «Ветви `match`» подтверждается показанным фрагментом?

val x: Any = 12
val out = x match
  case n: Int if n > 10 => "large"
  case _: Int => "small"
  case _ => "other"
println(out)

`match` проверяет варианты сверху вниз и выбирает первый подходящий `case`; более общий шаблон может сделать нижние варианты недостижимыми. Guard после шаблона уточняет уже сопоставленное значение; при ложном guard поиск продолжается со следующего `case`. Для `enum` и `sealed`-иерархий компилятор способен предупреждать о неисчерпывающем `match`, если видит все варианты. Неявное числовое преобразование всегда выбирает ближайший тип без потери диапазона, поэтому явная проверка границ не требуется. Любая конструкция, записанная через `val`, делает связанный объект неизменяемым, а все его методы — безопасными для параллельного вызова.

Вопрос 7 из 20

Для темы «Ветви `match`» что здесь требует отдельного теста или компиляционного примера?

// Дополнительный контекст: После рефакторинга код по-прежнему компилируется, однако его статический тип стал шире.
val x: Any = 12
val out = x match
  case n: Int if n > 10 => "large"
  case _: Int => "small"
  case _ => "other"
println(out)

Широкий `case _` подавляет полезную проверку при добавлении нового состояния и превращает изменение модели в скрытый дефект. Отсутствующая ветвь `else` даёт `Unit` в ложном случае и часто расширяет итоговый тип до неожиданного объединения. Если две ветви компилируются по отдельности, их общий тип обязательно сохранит методы обеих ветвей. Пограничное значение будет автоматически отклонено до выполнения, даже если код явно делает сужающее преобразование или приведение. Ранний шаблон `_` или широкий тип перехватывает данные, которые разработчик рассчитывал обработать специализированным случаем.

Вопрос 8 из 20

При исправлении темы «Ветви `match`» нужно устранить причину, а не замаскировать симптом. Какое изменение подходит лучше?

val x: Any = 12
val out = x match
  case n: Int if n > 10 => "large"
  case _: Int => "small"
  case _ => "other"
println(out)
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.

Оставляйте guards короткими и чистыми; тяжёлую проверку вынесите в заранее названный предикат. В доменной модели перечисляйте варианты явно; общий случай используйте только на действительно открытой внешней границе. Перенести локальное состояние в общий `object`, чтобы все экземпляры наблюдали одно и то же значение без передачи зависимости. Располагая случаи, идите от узких к широким, а общий вариант оставляйте последним, иначе он перехватит более точные шаблоны. Добавить общий `case _` и возвращать нейтральное значение: так новые варианты модели не будут останавливать сборку.

Вопрос 9 из 20

В контракте темы «Ветви `match`» после изменения окружения команда пересматривает контракт. Какой вариант корректен?

`match` проверяет варианты сверху вниз и выбирает первый подходящий `case`; более общий шаблон может сделать нижние варианты недостижимыми. Пограничный сценарий: ранний шаблон `_` или широкий тип перехватывает данные, которые разработчик рассчитывал обработать специализированным случаем. `match` проверяет варианты сверху вниз и выбирает первый подходящий `case`; более общий шаблон может сделать нижние варианты недостижимыми. Пограничный сценарий: сборка и один штатный пример полностью доказывают корректность для пограничных данных. Guard после шаблона уточняет уже сопоставленное значение; при ложном guard поиск продолжается со следующего `case`. Пограничный сценарий: отсутствующая ветвь `else` даёт `Unit` в ложном случае и часто расширяет итоговый тип до неожиданного объединения. `match` проверяет варианты сверху вниз и выбирает первый подходящий `case`; более общий шаблон может сделать нижние варианты недостижимыми. Пограничный сценарий: широкий `case _` подавляет полезную проверку при добавлении нового состояния и превращает изменение модели в скрытый дефект. Для `enum` и `sealed`-иерархий компилятор способен предупреждать о неисчерпывающем `match`, если видит все варианты. Пограничный сценарий: ранний шаблон `_` или широкий тип перехватывает данные, которые разработчик рассчитывал обработать специализированным случаем.

Вопрос 10 из 20

При проверке темы «Ветви `match`» какая проверка связывает принятую правку с реальной границей решения?

Оставляйте guards короткими и чистыми; тяжёлую проверку вынесите в заранее названный предикат. В проверке воспроизвести ситуацию: ранний шаблон `_` или широкий тип перехватывает данные, которые разработчик рассчитывал обработать специализированным случаем. `match` проверяет варианты сверху вниз и выбирает первый подходящий `case`; более общий шаблон может сделать нижние варианты недостижимыми. Считать регрессию закрытой, если проект один раз собрался. Располагая случаи, идите от узких к широким, а общий вариант оставляйте последним. В проверке воспроизвести ситуацию: ранний шаблон `_` или широкий тип перехватывает данные, которые разработчик рассчитывал обработать специализированным случаем. В теме «Ветви `match`» исправить один показанный вызов по рекомендации «В доменной модели перечисляйте варианты явно; общий случай используйте только на действительно открытой внешней границе». Общий контракт и прежнюю границу отдельно не воспроизводить. Располагая случаи, идите от узких к широким, а общий вариант оставляйте последним. В проверке воспроизвести ситуацию: широкий `case _` подавляет полезную проверку при добавлении нового состояния и превращает изменение модели в скрытый дефект.

Вопрос 11 из 20

В теме «Условия-ограничители» проследите типы и порядок вычисления. Какой вывод выдерживает такую проверку?

def classify(n: Int) = n match
  case x if x % 6 == 0 => "six"
  case x if x % 2 == 0 => "two"
  case _ => "other"
println(classify(18))

Порядок ветвей и шаблонов несущественен: перед выполнением Scala автоматически переставляет их от частных к общим. `If` возвращает значение, поэтому обе ветви должны образовать общий тип, пригодный для дальнейшего использования. Успешная компиляция означает, что замена конкретного типа на `Any` не изменит доступные операции и результат программы. `match` проверяет варианты сверху вниз и выбирает первый подходящий `case`; более общий шаблон может сделать нижние варианты недостижимыми. Guard после шаблона уточняет уже сопоставленное значение; при ложном guard поиск продолжается со следующего `case`.

Вопрос 12 из 20

Какой риск нельзя снять одним успешным примером «Условия-ограничители»?

Guard с побочным эффектом или дорогим вычислением усложняет порядок проверки и может выполняться чаще, чем кажется. Отсутствующая ветвь `else` даёт `Unit` в ложном случае и часто расширяет итоговый тип до неожиданного объединения. Широкий `case _` подавляет полезную проверку при добавлении нового состояния и превращает изменение модели в скрытый дефект. Единственное последствие ошибки здесь — менее понятное сообщение компилятора; поведение собранной программы не меняется. Локальное изменение сигнатуры не способно повлиять на поиск перегрузки, given или вывод типа в вызывающем коде.

Вопрос 13 из 20

Какой вариант исправления соответствует механизму «Условия-ограничители»?

def classify(n: Int) = n match
  case x if x % 6 == 0 => "six"
  case x if x % 2 == 0 => "two"
  case _ => "other"
println(classify(18))
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.

Оставляйте guards короткими и чистыми; тяжёлую проверку вынесите в заранее названный предикат. Спрятать несовместимость за `asInstanceOf`, сохранив прежнюю сигнатуру и добавив тест только для рабочего примера. Ввести неявное преобразование между типами, чтобы вызывающий код продолжил компилироваться без явной миграции. Располагая случаи, идите от узких к широким, а общий вариант оставляйте последним. Для вычисляющего `if` задавайте обе ветви; отдельный `if` без `else` оставляйте только для осознанного побочного эффекта.

Вопрос 14 из 20

В контракте темы «Условия-ограничители» какая формулировка учитывает и семантику конструкции, и реальный риск?

Опираться на семантику «guard после шаблона уточняет уже сопоставленное значение; при ложном guard поиск продолжается со следующего `case`», но отдельно проверять ограничение «guard с побочным эффектом или дорогим вычислением усложняет порядок проверки и может выполняться чаще, чем кажется». Опираться на семантику «`match` проверяет варианты сверху вниз и выбирает первый подходящий `case`; более общий шаблон может сделать нижние варианты недостижимыми», но отдельно проверять ограничение «широкий `case _` подавляет полезную проверку при добавлении нового состояния и превращает изменение модели в скрытый дефект». Опираться на семантику «guard после шаблона уточняет уже сопоставленное значение; при ложном guard поиск продолжается со следующего `case`», но отдельно проверять ограничение «если основной сценарий прошёл, отрицательные и конкурентные случаи можно не проверять». Опираться на семантику «guard после шаблона уточняет уже сопоставленное значение; при ложном guard поиск продолжается со следующего `case`», но отдельно проверять ограничение «отсутствующая ветвь `else` даёт `Unit` в ложном случае и часто расширяет итоговый тип до неожиданного объединения». Опираться на семантику «`if` возвращает значение, поэтому обе ветви должны образовать общий тип, пригодный для дальнейшего использования», но отдельно проверять ограничение «guard с побочным эффектом или дорогим вычислением усложняет порядок проверки и может выполняться чаще, чем кажется».

Вопрос 15 из 20

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

В теме «Условия-ограничители» исправить один показанный вызов по рекомендации «Для вычисляющего `if` задавайте обе ветви; отдельный `if` без `else` оставляйте только для осознанного побочного эффекта». Общий контракт и прежнюю границу отдельно не воспроизводить. Guard после шаблона уточняет уже сопоставленное значение; при ложном guard поиск продолжается со следующего `case`. Не добавлять отрицательный сценарий: текущего успешного вызова достаточно. Оставляйте guards короткими и чистыми; тяжёлую проверку вынесите в заранее названный предикат. В проверке воспроизвести ситуацию: guard с побочным эффектом или дорогим вычислением усложняет порядок проверки и может выполняться чаще, чем кажется. Оставляйте guards короткими и чистыми; тяжёлую проверку вынесите в заранее названный предикат. В проверке воспроизвести ситуацию: отсутствующая ветвь `else` даёт `Unit` в ложном случае и часто расширяет итоговый тип до неожиданного объединения. Располагая случаи, идите от узких к широким, а общий вариант оставляйте последним. В проверке воспроизвести ситуацию: guard с побочным эффектом или дорогим вычислением усложняет порядок проверки и может выполняться чаще, чем кажется.

Вопрос 16 из 20

В теме «Исчерпывающий разбор» какое утверждение не переносит в Scala правило из другого языка или другой конструкции?

enum State:
  case Draft, Published, Archived
def visible(s: State) = s match
  case State.Published => true
  case State.Draft | State.Archived => false

Выражение с побочным эффектом не может влиять на выведенный тип блока: компилятор всегда берёт первую содержательную строку. Компилятор откладывает выбор типа до первого использования значения, поэтому объявленная форма выражения здесь ничего не ограничивает. Guard после шаблона уточняет уже сопоставленное значение; при ложном guard поиск продолжается со следующего `case`. `match` проверяет варианты сверху вниз и выбирает первый подходящий `case`; более общий шаблон может сделать нижние варианты недостижимыми. Для `enum` и `sealed`-иерархий компилятор способен предупреждать о неисчерпывающем `match`, если видит все варианты.

Вопрос 17 из 20

После рефакторинга код по-прежнему компилируется, однако его статический тип стал шире. Какое ограничение темы «Исчерпывающий разбор» становится существенным?

Одного обычного запуска недостаточно, поскольку локальное изменение сигнатуры не способно повлиять на поиск перегрузки, given или вывод типа в вызывающем коде. Одного обычного запуска недостаточно, поскольку ранний шаблон `_` или широкий тип перехватывает данные, которые разработчик рассчитывал обработать специализированным случаем. Одного обычного запуска недостаточно, поскольку широкий `case _` подавляет полезную проверку при добавлении нового состояния и превращает изменение модели в скрытый дефект. Одного обычного запуска недостаточно, поскольку guard с побочным эффектом или дорогим вычислением усложняет порядок проверки и может выполняться чаще, чем кажется. Одного обычного запуска недостаточно, поскольку добавление широкого типа или общего `case _` усиливает контроль, потому что компилятору становится известно больше допустимых вариантов.

Вопрос 18 из 20

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

enum State:
  case Draft, Published, Archived
def visible(s: State) = s match
  case State.Published => true
  case State.Draft | State.Archived => false
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.

Для вычисляющего `if` задавайте обе ветви; отдельный `if` без `else` оставляйте только для осознанного побочного эффекта. Добавить общий `case _` и возвращать нейтральное значение: так новые варианты модели не будут останавливать сборку. Располагая случаи, идите от узких к широким, а общий вариант оставляйте последним. В доменной модели перечисляйте варианты явно; общий случай используйте только на действительно открытой внешней границе. Перенести локальное состояние в общий `object`, чтобы все экземпляры наблюдали одно и то же значение без передачи зависимости.

Вопрос 19 из 20

В контракте темы «Исчерпывающий разбор» новый сценарий не отменяет основное правило, но делает заметной его границу. Какой ответ это отражает?

Guard после шаблона уточняет уже сопоставленное значение; при ложном guard поиск продолжается со следующего `case`. Пограничный сценарий: guard с побочным эффектом или дорогим вычислением усложняет порядок проверки и может выполняться чаще, чем кажется. `match` проверяет варианты сверху вниз и выбирает первый подходящий `case`; более общий шаблон может сделать нижние варианты недостижимыми. Пограничный сценарий: широкий `case _` подавляет полезную проверку при добавлении нового состояния и превращает изменение модели в скрытый дефект. Для `enum` и `sealed`-иерархий компилятор способен предупреждать о неисчерпывающем `match`, если видит все варианты. Пограничный сценарий: ранний шаблон `_` или широкий тип перехватывает данные, которые разработчик рассчитывал обработать специализированным случаем. Для `enum` и `sealed`-иерархий компилятор способен предупреждать о неисчерпывающем `match`, если видит все варианты. Пограничный сценарий: совпадение результата на одном наборе данных подтверждает все обещания публичного API. Для `enum` и `sealed`-иерархий компилятор способен предупреждать о неисчерпывающем `match`, если видит все варианты. Пограничный сценарий: широкий `case _` подавляет полезную проверку при добавлении нового состояния и превращает изменение модели в скрытый дефект.

Вопрос 20 из 20

При проверке темы «Исчерпывающий разбор» что нужно оставить после исправления, кроме комментария в исходном файле?

В доменной модели перечисляйте варианты явно; общий случай используйте только на действительно открытой внешней границе. В проверке воспроизвести ситуацию: широкий `case _` подавляет полезную проверку при добавлении нового состояния и превращает изменение модели в скрытый дефект. В доменной модели перечисляйте варианты явно; общий случай используйте только на действительно открытой внешней границе. В проверке воспроизвести ситуацию: ранний шаблон `_` или широкий тип перехватывает данные, которые разработчик рассчитывал обработать специализированным случаем. Располагая случаи, идите от узких к широким, а общий вариант оставляйте последним. В проверке воспроизвести ситуацию: широкий `case _` подавляет полезную проверку при добавлении нового состояния и превращает изменение модели в скрытый дефект. Для `enum` и `sealed`-иерархий компилятор способен предупреждать о неисчерпывающем `match`, если видит все варианты. Проверить только ветвь без ошибки и принять изменение. В теме «Исчерпывающий разбор» исправить один показанный вызов по рекомендации «Для вычисляющего `if` задавайте обе ветви; отдельный `if` без `else` оставляйте только для осознанного побочного эффекта». Общий контракт и прежнюю границу отдельно не воспроизводить.