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

Вопрос 1 из 20

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

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

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

Вопрос 2 из 20

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

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

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

Вопрос 3 из 20

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

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

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

Вопрос 4 из 20

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

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

Вопрос 5 из 20

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

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

Вопрос 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)

Неявное числовое преобразование всегда выбирает ближайший тип без потери диапазона, поэтому явная проверка границ не требуется. Guard после шаблона уточняет уже сопоставленное значение; при ложном guard поиск продолжается со следующего `case`. `match` проверяет варианты сверху вниз и выбирает первый подходящий `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)

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

Вопрос 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`; более общий шаблон может сделать нижние варианты недостижимыми. Пограничный сценарий: ранний шаблон `_` или широкий тип перехватывает данные, которые разработчик рассчитывал обработать специализированным случаем. Guard после шаблона уточняет уже сопоставленное значение; при ложном guard поиск продолжается со следующего `case`. Пограничный сценарий: отсутствующая ветвь `else` даёт `Unit` в ложном случае и часто расширяет итоговый тип до неожиданного объединения. `match` проверяет варианты сверху вниз и выбирает первый подходящий `case`; более общий шаблон может сделать нижние варианты недостижимыми. Пограничный сценарий: сборка и один штатный пример полностью доказывают корректность для пограничных данных. `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))

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

Вопрос 12 из 20

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

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

Вопрос 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))
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.

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

Вопрос 14 из 20

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

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

Вопрос 15 из 20

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

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

Вопрос 17 из 20

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

Одного обычного запуска недостаточно, поскольку guard с побочным эффектом или дорогим вычислением усложняет порядок проверки и может выполняться чаще, чем кажется. Одного обычного запуска недостаточно, поскольку локальное изменение сигнатуры не способно повлиять на поиск перегрузки, given или вывод типа в вызывающем коде. Одного обычного запуска недостаточно, поскольку широкий `case _` подавляет полезную проверку при добавлении нового состояния и превращает изменение модели в скрытый дефект. Одного обычного запуска недостаточно, поскольку добавление широкого типа или общего `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

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

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

Вопрос 20 из 20

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

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