Значения, переменные и вывод типов Scala — бесплатный тест онлайн

Вопрос 1 из 20

Во фрагменте проверяется тема «val и var». Какое правило точнее всего объясняет поведение кода?

val xs = scala.collection.mutable.ArrayBuffer(1, 2)
xs += 3
println(xs.mkString(","))

`val` запрещает повторное присваивание имени, а `var` допускает его; изменяемость самого объекта определяется его типом и методами. Scala не выполняет неявное сужение из `Long` в `Int`: разработчик должен явно выбрать преобразование и принять ответственность за диапазон. Любая конструкция, записанная через `val`, делает связанный объект неизменяемым, а все его методы — безопасными для параллельного вызова. В Scala блок, `if` и многие управляющие конструкции являются выражениями: результатом блока становится значение последней строки. Компилятор откладывает выбор типа до первого использования значения, поэтому объявленная форма выражения здесь ничего не ограничивает.

Вопрос 2 из 20

Для темы «val и var» что остаётся обязанностью вызывающего кода или окружения?

// Дополнительный контекст: После рефакторинга код по-прежнему компилируется, однако его статический тип стал шире.
val xs = scala.collection.mutable.ArrayBuffer(1, 2)
xs += 3
println(xs.mkString(","))

Риск возникает только при `var`; `val`, `case class` и неизменяемая коллекция полностью исключают скрытое состояние и ошибочный контракт. Побочный эффект в последней строке может случайно сделать результатом `Unit`, хотя вызывающий код ожидает вычисленное значение. Добавление широкого типа или общего `case _` усиливает контроль, потому что компилятору становится известно больше допустимых вариантов. Если ветви выражения возвращают несвязанные типы, результат может стать слишком общим, и ошибка проявится далеко от места выбора. Считать `val` глубокой неизменяемостью опасно: коллекция или объект под неизменяемой ссылкой всё ещё может менять внутреннее состояние.

Вопрос 3 из 20

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

val xs = scala.collection.mutable.ArrayBuffer(1, 2)
xs += 3
println(xs.mkString(","))
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.

На ревью разделяйте запрет переприсвоения и неизменяемость данных; для состояния предпочитайте неизменяемые типы и явное создание нового значения. Сужайте числа только в точке, где проверены диапазон и смысл; для денежных и идентификационных значений используйте предметные типы. Когда тип выражает контракт API, укажите его явно; локальные очевидные значения оставляйте выведенными компилятором. Расширить спорный тип до `Any`, а точные проверки перенести во все места использования, чтобы не менять текущую реализацию. Перенести локальное состояние в общий `object`, чтобы все экземпляры наблюдали одно и то же значение без передачи зависимости.

Вопрос 4 из 20

В контракте темы «val и var» что следует оставить в проектном решении после этого изменения контекста?

Опираться на семантику «Scala не выполняет неявное сужение из `Long` в `Int`: разработчик должен явно выбрать преобразование и принять ответственность за диапазон», но отдельно проверять ограничение «побочный эффект в последней строке может случайно сделать результатом `Unit`, хотя вызывающий код ожидает вычисленное значение». Опираться на семантику «`val` запрещает повторное присваивание имени, а `var` допускает его; изменяемость самого объекта определяется его типом и методами», но отдельно проверять ограничение «считать `val` глубокой неизменяемостью опасно: коллекция или объект под неизменяемой ссылкой всё ещё может менять внутреннее состояние». Опираться на семантику «в Scala блок, `if` и многие управляющие конструкции являются выражениями: результатом блока становится значение последней строки», но отдельно проверять ограничение «считать `val` глубокой неизменяемостью опасно: коллекция или объект под неизменяемой ссылкой всё ещё может менять внутреннее состояние». Опираться на семантику «`val` запрещает повторное присваивание имени, а `var` допускает его; изменяемость самого объекта определяется его типом и методами», но отдельно проверять ограничение «если ветви выражения возвращают несвязанные типы, результат может стать слишком общим, и ошибка проявится далеко от места выбора». Опираться на семантику «`val` запрещает повторное присваивание имени, а `var` допускает его; изменяемость самого объекта определяется его типом и методами», но отдельно проверять ограничение «прохождение happy path исключает ошибки сериализации на старых и неполных данных».

Вопрос 5 из 20

При проверке темы «val и var» какой итог можно проверить автоматически или воспроизводимым примером?

На ревью разделяйте запрет переприсвоения и неизменяемость данных; для состояния предпочитайте неизменяемые типы и явное создание нового значения. В проверке воспроизвести ситуацию: считать `val` глубокой неизменяемостью опасно: коллекция или объект под неизменяемой ссылкой всё ещё может менять внутреннее состояние. В теме «val и var» исправить один показанный вызов по рекомендации «Когда тип выражает контракт API, укажите его явно; локальные очевидные значения оставляйте выведенными компилятором». Общий контракт и прежнюю границу отдельно не воспроизводить. На ревью разделяйте запрет переприсвоения и неизменяемость данных; для состояния предпочитайте неизменяемые типы и явное создание нового значения. В проверке воспроизвести ситуацию: если ветви выражения возвращают несвязанные типы, результат может стать слишком общим, и ошибка проявится далеко от места выбора. Сужайте числа только в точке, где проверены диапазон и смысл; для денежных и идентификационных значений используйте предметные типы. В проверке воспроизвести ситуацию: считать `val` глубокой неизменяемостью опасно: коллекция или объект под неизменяемой ссылкой всё ещё может менять внутреннее состояние. `val` запрещает повторное присваивание имени, а `var` допускает его; изменяемость самого объекта определяется его типом и методами. Считать отсутствие исключения достаточным подтверждением контракта.

Вопрос 6 из 20

В теме «Базовые типы» что в этом примере определяется семантикой Scala, а не соглашением автора?

val total: Long = Int.MaxValue.toLong + 10
val clipped = total.toInt
println(total -> clipped)

Scala не выполняет неявное сужение из `Long` в `Int`: разработчик должен явно выбрать преобразование и принять ответственность за диапазон. Вывод типа учитывает правую часть и ожидаемый тип выражения; преждевременное расширение до общего супертипа лишает код более точных операций. `val` запрещает повторное присваивание имени, а `var` допускает его; изменяемость самого объекта определяется его типом и методами. Любая конструкция, записанная через `val`, делает связанный объект неизменяемым, а все его методы — безопасными для параллельного вызова. Неявное числовое преобразование всегда выбирает ближайший тип без потери диапазона, поэтому явная проверка границ не требуется.

Вопрос 7 из 20

Для темы «Базовые типы» после переноса кода в общий модуль проявилось скрытое допущение. Какое?

// Дополнительный контекст: Фрагмент вынесли из локальной функции в общий модуль и добавили новый вариант входных данных.
val total: Long = Int.MaxValue.toLong + 10
val clipped = total.toInt
println(total -> clipped)

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

Вопрос 8 из 20

Какое решение по теме «Базовые типы» опирается на проверяемую гарантию?

val total: Long = Int.MaxValue.toLong + 10
val clipped = total.toInt
println(total -> clipped)
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.

Держите возвращаемое выражение заметным и не смешивайте вычисление результата с завершающим журналированием без явного `val`. На ревью разделяйте запрет переприсвоения и неизменяемость данных; для состояния предпочитайте неизменяемые типы и явное создание нового значения. Расширить спорный тип до `Any`, а точные проверки перенести во все места использования, чтобы не менять текущую реализацию. Сужайте числа только в точке, где проверены диапазон и смысл; для денежных и идентификационных значений используйте предметные типы. Перенести локальное состояние в общий `object`, чтобы все экземпляры наблюдали одно и то же значение без передачи зависимости.

Вопрос 9 из 20

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

В проектном решении сохранить утверждение «Scala не выполняет неявное сужение из `Long` в `Int`: разработчик должен явно выбрать преобразование и принять ответственность за диапазон» и риск «если локальный вызов успешен, распределённые повторы и частичные отказы не меняют вывод». В проектном решении сохранить утверждение «Scala не выполняет неявное сужение из `Long` в `Int`: разработчик должен явно выбрать преобразование и принять ответственность за диапазон» и риск «считать `val` глубокой неизменяемостью опасно: коллекция или объект под неизменяемой ссылкой всё ещё может менять внутреннее состояние». В проектном решении сохранить утверждение «`val` запрещает повторное присваивание имени, а `var` допускает его; изменяемость самого объекта определяется его типом и методами» и риск «если ветви выражения возвращают несвязанные типы, результат может стать слишком общим, и ошибка проявится далеко от места выбора». В проектном решении сохранить утверждение «Scala не выполняет неявное сужение из `Long` в `Int`: разработчик должен явно выбрать преобразование и принять ответственность за диапазон» и риск «автоматическое сужение могло бы молча потерять старшие биты, поэтому ожидание «компилятор сам разберётся» приводит к ошибке сборки или неверному преобразованию». В проектном решении сохранить утверждение «вывод типа учитывает правую часть и ожидаемый тип выражения; преждевременное расширение до общего супертипа лишает код более точных операций» и риск «автоматическое сужение могло бы молча потерять старшие биты, поэтому ожидание «компилятор сам разберётся» приводит к ошибке сборки или неверному преобразованию».

Вопрос 10 из 20

При проверке темы «Базовые типы» как сформулировать защиту от регрессии без расплывчатого «работает как раньше»?

В теме «Базовые типы» исправить один показанный вызов по рекомендации «Держите возвращаемое выражение заметным и не смешивайте вычисление результата с завершающим журналированием без явного `val`». Общий контракт и прежнюю границу отдельно не воспроизводить. Scala не выполняет неявное сужение из `Long` в `Int`: разработчик должен явно выбрать преобразование и принять ответственность за диапазон. Проверить только маленький объём данных и не измерять рост затрат. Сужайте числа только в точке, где проверены диапазон и смысл; для денежных и идентификационных значений используйте предметные типы. В проверке воспроизвести ситуацию: считать `val` глубокой неизменяемостью опасно: коллекция или объект под неизменяемой ссылкой всё ещё может менять внутреннее состояние. На ревью разделяйте запрет переприсвоения и неизменяемость данных; для состояния предпочитайте неизменяемые типы и явное создание нового значения. В проверке воспроизвести ситуацию: автоматическое сужение могло бы молча потерять старшие биты, поэтому ожидание «компилятор сам разберётся» приводит к ошибке сборки или неверному преобразованию. Сужайте числа только в точке, где проверены диапазон и смысл; для денежных и идентификационных значений используйте предметные типы. В проверке воспроизвести ситуацию: автоматическое сужение могло бы молча потерять старшие биты, поэтому ожидание «компилятор сам разберётся» приводит к ошибке сборки или неверному преобразованию.

Вопрос 11 из 20

Какой вывод о теме «Вывод типов» можно сделать без дополнительных допущений?

val value = if System.currentTimeMillis() % 2 == 0 then 42 else "42"
println(value.getClass.getSimpleName)

Scala не выполняет неявное сужение из `Long` в `Int`: разработчик должен явно выбрать преобразование и принять ответственность за диапазон. Вывод типа учитывает правую часть и ожидаемый тип выражения; преждевременное расширение до общего супертипа лишает код более точных операций. `val` запрещает повторное присваивание имени, а `var` допускает его; изменяемость самого объекта определяется его типом и методами. Неявное числовое преобразование всегда выбирает ближайший тип без потери диапазона, поэтому явная проверка границ не требуется. Компилятор откладывает выбор типа до первого использования значения, поэтому объявленная форма выражения здесь ничего не ограничивает.

Вопрос 12 из 20

Для темы «Вывод типов» какое последствие нельзя исключить одним успешным запуском?

Если ветви выражения возвращают несвязанные типы, результат может стать слишком общим, и ошибка проявится далеко от места выбора. Побочный эффект в последней строке может случайно сделать результатом `Unit`, хотя вызывающий код ожидает вычисленное значение. Считать `val` глубокой неизменяемостью опасно: коллекция или объект под неизменяемой ссылкой всё ещё может менять внутреннее состояние. Компилятор всегда выводит узкий общий тип, в котором доступны методы каждой ветви выражения. Выведенный общий тип ветвей обязательно сохраняет полный набор операций каждой исходной ветви.

Вопрос 13 из 20

При исправлении темы «Вывод типов» какая правка сохраняет полезную семантику и не расширяет обещания API?

val value = if System.currentTimeMillis() % 2 == 0 then 42 else "42"
println(value.getClass.getSimpleName)
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.

Оставить публичный тип результата выведенным из тела: это позволит API автоматически подстраиваться под будущие правки. Когда тип выражает контракт API, укажите его явно; локальные очевидные значения оставляйте выведенными компилятором. Добавить `asInstanceOf` к ожидаемому узкому типу, оставив ветви выражения без изменений. На ревью разделяйте запрет переприсвоения и неизменяемость данных; для состояния предпочитайте неизменяемые типы и явное создание нового значения. Держите возвращаемое выражение заметным и не смешивайте вычисление результата с завершающим журналированием без явного `val`.

Вопрос 14 из 20

В контракте темы «Вывод типов» локальный пример стал частью более крупной системы. Какая трактовка контракта остаётся полной?

Scala не выполняет неявное сужение из `Long` в `Int`: разработчик должен явно выбрать преобразование и принять ответственность за диапазон. Отдельная граница — если ветви выражения возвращают несвязанные типы, результат может стать слишком общим, и ошибка проявится далеко от места выбора. Вывод типа учитывает правую часть и ожидаемый тип выражения; преждевременное расширение до общего супертипа лишает код более точных операций. Отдельная граница — одного примера достаточно, чтобы подтвердить законы абстракции и отсутствие побочных эффектов. Вывод типа учитывает правую часть и ожидаемый тип выражения; преждевременное расширение до общего супертипа лишает код более точных операций. Отдельная граница — побочный эффект в последней строке может случайно сделать результатом `Unit`, хотя вызывающий код ожидает вычисленное значение. Вывод типа учитывает правую часть и ожидаемый тип выражения; преждевременное расширение до общего супертипа лишает код более точных операций. Отдельная граница — если ветви выражения возвращают несвязанные типы, результат может стать слишком общим, и ошибка проявится далеко от места выбора. `val` запрещает повторное присваивание имени, а `var` допускает его; изменяемость самого объекта определяется его типом и методами. Отдельная граница — считать `val` глубокой неизменяемостью опасно: коллекция или объект под неизменяемой ссылкой всё ещё может менять внутреннее состояние.

Вопрос 15 из 20

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

На ревью разделяйте запрет переприсвоения и неизменяемость данных; для состояния предпочитайте неизменяемые типы и явное создание нового значения. В проверке воспроизвести ситуацию: если ветви выражения возвращают несвязанные типы, результат может стать слишком общим, и ошибка проявится далеко от места выбора. Когда тип выражает контракт API, укажите его явно; локальные очевидные значения оставляйте выведенными компилятором. В проверке воспроизвести ситуацию: если ветви выражения возвращают несвязанные типы, результат может стать слишком общим, и ошибка проявится далеко от места выбора. Вывод типа учитывает правую часть и ожидаемый тип выражения; преждевременное расширение до общего супертипа лишает код более точных операций. Оставить тест без старой версии данных и неизвестных полей. Когда тип выражает контракт API, укажите его явно; локальные очевидные значения оставляйте выведенными компилятором. В проверке воспроизвести ситуацию: побочный эффект в последней строке может случайно сделать результатом `Unit`, хотя вызывающий код ожидает вычисленное значение. В теме «Вывод типов» исправить один показанный вызов по рекомендации «Держите возвращаемое выражение заметным и не смешивайте вычисление результата с завершающим журналированием без явного `val`». Общий контракт и прежнюю границу отдельно не воспроизводить.

Вопрос 16 из 20

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

val answer =
  val base = 40
  println("counted")
  base + 2
println(answer)

`val` запрещает повторное присваивание имени, а `var` допускает его; изменяемость самого объекта определяется его типом и методами. В Scala блок, `if` и многие управляющие конструкции являются выражениями: результатом блока становится значение последней строки. Scala не выполняет неявное сужение из `Long` в `Int`: разработчик должен явно выбрать преобразование и принять ответственность за диапазон. Выражение с побочным эффектом не может влиять на выведенный тип блока: компилятор всегда берёт первую содержательную строку. Неявное числовое преобразование всегда выбирает ближайший тип без потери диапазона, поэтому явная проверка границ не требуется.

Вопрос 17 из 20

Для темы «Выражения» какой пограничный случай относится к контракту, а не только к стилю записи?

Пограничное значение будет автоматически отклонено до выполнения, даже если код явно делает сужающее преобразование или приведение. Единственное последствие ошибки здесь — менее понятное сообщение компилятора; поведение собранной программы не меняется. Если ветви выражения возвращают несвязанные типы, результат может стать слишком общим, и ошибка проявится далеко от места выбора. Побочный эффект в последней строке может случайно сделать результатом `Unit`, хотя вызывающий код ожидает вычисленное значение. Считать `val` глубокой неизменяемостью опасно: коллекция или объект под неизменяемой ссылкой всё ещё может менять внутреннее состояние.

Вопрос 18 из 20

При исправлении темы «Выражения» что здесь лучше исправить до объединения изменений?

val answer =
  val base = 40
  println("counted")
  base + 2
println(answer)
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.

Перенести локальное состояние в общий `object`, чтобы все экземпляры наблюдали одно и то же значение без передачи зависимости. Сужайте числа только в точке, где проверены диапазон и смысл; для денежных и идентификационных значений используйте предметные типы. Когда тип выражает контракт API, укажите его явно; локальные очевидные значения оставляйте выведенными компилятором. Оставить публичный тип результата выведенным из тела: это позволит API автоматически подстраиваться под будущие правки. Держите возвращаемое выражение заметным и не смешивайте вычисление результата с завершающим журналированием без явного `val`.

Вопрос 19 из 20

В контракте темы «Выражения» условия эксплуатации изменились, но синтаксис остался прежним. Что теперь важно удержать вместе?

`val` запрещает повторное присваивание имени, а `var` допускает его; изменяемость самого объекта определяется его типом и методами. Отдельная граница — побочный эффект в последней строке может случайно сделать результатом `Unit`, хотя вызывающий код ожидает вычисленное значение. В Scala блок, `if` и многие управляющие конструкции являются выражениями: результатом блока становится значение последней строки. Отдельная граница — побочный эффект в последней строке может случайно сделать результатом `Unit`, хотя вызывающий код ожидает вычисленное значение. В Scala блок, `if` и многие управляющие конструкции являются выражениями: результатом блока становится значение последней строки. Отдельная граница — если ветви выражения возвращают несвязанные типы, результат может стать слишком общим, и ошибка проявится далеко от места выбора. Scala не выполняет неявное сужение из `Long` в `Int`: разработчик должен явно выбрать преобразование и принять ответственность за диапазон. Отдельная граница — считать `val` глубокой неизменяемостью опасно: коллекция или объект под неизменяемой ссылкой всё ещё может менять внутреннее состояние. В Scala блок, `if` и многие управляющие конструкции являются выражениями: результатом блока становится значение последней строки. Отдельная граница — успешная сборка гарантирует бинарную и исходную совместимость опубликованного API.

Вопрос 20 из 20

При проверке темы «Выражения» что поможет соседнему модулю не повторить ту же ошибку?

Сужайте числа только в точке, где проверены диапазон и смысл; для денежных и идентификационных значений используйте предметные типы. В проверке воспроизвести ситуацию: побочный эффект в последней строке может случайно сделать результатом `Unit`, хотя вызывающий код ожидает вычисленное значение. В теме «Выражения» исправить один показанный вызов по рекомендации «Когда тип выражает контракт API, укажите его явно; локальные очевидные значения оставляйте выведенными компилятором». Общий контракт и прежнюю границу отдельно не воспроизводить. В Scala блок, `if` и многие управляющие конструкции являются выражениями: результатом блока становится значение последней строки. Проверить локальный успех, не моделируя частичный отказ внешнего сервиса. Держите возвращаемое выражение заметным и не смешивайте вычисление результата с завершающим журналированием без явного `val`. В проверке воспроизвести ситуацию: побочный эффект в последней строке может случайно сделать результатом `Unit`, хотя вызывающий код ожидает вычисленное значение. Держите возвращаемое выражение заметным и не смешивайте вычисление результата с завершающим журналированием без явного `val`. В проверке воспроизвести ситуацию: если ветви выражения возвращают несвязанные типы, результат может стать слишком общим, и ошибка проявится далеко от места выбора.