💡 Инструкция: Выберите один ответ из пяти. Время — 55 минут. У каждого задания ровно один правильный вариант. Фрагменты рассчитаны на Ruby 4.0.6; задания Rails — на Rails 8.1.3. После завершения откроются общий процент, 4 тематических результатов и разбор всех ответов.
Вопрос 1 из 20
Проследите выполнение фрагмента. Какой результат верен для темы «Интерполяция»? Верный вариант не содержит частично правильной подмены причины или следствия.
Ruby Ruby — Интерполяция Копировать
# Проследите выполнение и выберите точный результат.
calculated = "total=#{2 * 3}"
literal = 'total=#{2 * 3}'
p [calculated, literal]
Первая строка содержит вычисленное число 6, вторая — символы `#{2 * 3}` без вычисления. Это объясняется тем, что у String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов.
Для уже заглавной строки `upcase!` возвращает nil, хотя сама строка остаётся `RUBY`. Это объясняется тем, что интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными.
Первая строка содержит вычисленное число 6, вторая — символы `#{2 * 3}` без вычисления. Это объясняется тем, что интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными.
Первая строка содержит вычисленное число 6, вторая — символы `#{2 * 3}` без вычисления. Это объясняется тем, что методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались.
Два литерала `:ready` имеют одинаковый object_id и подходят как стабильные ключи Hash. Это объясняется тем, что интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными.
Вопрос 3 из 20
Какое описание результата точно соответствует показанному коду «Кодировка»? Выберите связку, в которой верны и основной вывод, и его обоснование.
Ruby Ruby — Кодировка Копировать
# Проследите выполнение и выберите точный результат.
text = "é"
p text.encoding
p [text.length, text.bytesize, text.bytes]
p text.valid_encoding?
Первая строка содержит вычисленное число 6, вторая — символы `#{2 * 3}` без вычисления. Такой итог следует из правила: у String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов.
Строка `é` в UTF-8 занимает два байта, но содержит один символ; `bytesize` и `length` возвращают разные числа. Такой итог следует из правила: у String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов.
Строка `é` в UTF-8 занимает два байта, но содержит один символ; `bytesize` и `length` возвращают разные числа. Такой итог следует из правила: методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались.
Строка `é` в UTF-8 занимает два байта, но содержит один символ; `bytesize` и `length` возвращают разные числа. Такой итог следует из правила: интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными.
Два литерала `:ready` имеют одинаковый object_id и подходят как стабильные ключи Hash. Такой итог следует из правила: у String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов.
Вопрос 4 из 20
Как следует прочитать результат показанного примера «Изменение строк»? Одного совпавшего вывода недостаточно — проверьте также вторую часть ответа.
Ruby Ruby — Изменение строк Копировать
# Проследите выполнение и выберите точный результат.
text = +'RUBY'
changed = text.upcase!
p [text, changed]
text << '!'
p text
Для уже заглавной строки `upcase!` возвращает nil, хотя сама строка остаётся `RUBY`. Механизм результата таков: у String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов.
Для уже заглавной строки `upcase!` возвращает nil, хотя сама строка остаётся `RUBY`. Механизм результата таков: интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными.
Для уже заглавной строки `upcase!` возвращает nil, хотя сама строка остаётся `RUBY`. Механизм результата таков: методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались.
Два литерала `:ready` имеют одинаковый object_id и подходят как стабильные ключи Hash. Механизм результата таков: методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались.
Первая строка содержит вычисленное число 6, вторая — символы `#{2 * 3}` без вычисления. Механизм результата таков: методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались.
Вопрос 5 из 20
Почему успешный пример ещё не доказывает надёжность решения «Интерполяция»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.
Ruby Ruby — Интерполяция Копировать
# Обычный запуск проходит. Найдите скрытый риск.
calculated = "total=#{2 * 3}"
literal = 'total=#{2 * 3}'
p [calculated, literal]
Проверка `if text.upcase!` смешивает факт изменения с фактом успеха и даёт ложную ветку для уже нормализованной строки. Причина — интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными.
Неверный выбор кавычек способен тихо отправить пользователю шаблон вместо значения, не вызывая исключения. Причина — у String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов.
Неверный выбор кавычек способен тихо отправить пользователю шаблон вместо значения, не вызывая исключения. Причина — интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными.
Ограничение поля или обрезка по байтам может разрезать многобайтовый символ и породить недопустимую последовательность. Причина — интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными.
Неверный выбор кавычек способен тихо отправить пользователю шаблон вместо значения, не вызывая исключения. Причина — методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались.
Вопрос 6 из 20
Какой дефект может проявиться на границе показанного сценария «Символы Symbol»? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Ruby Ruby — Символы Symbol Копировать
# Обычный запуск проходит. Найдите скрытый риск.
a = :ready
b = 'ready'.to_sym
p [a == b, a.object_id == b.object_id]
state = { ready: true }
p state[a]
Проверка `if text.upcase!` смешивает факт изменения с фактом успеха и даёт ложную ветку для уже нормализованной строки. Этот риск связан с тем, что symbol — неизменяемый идентификатор с содержимым имени; сравнение одинаковых символов даёт тот же объект, но преобразование пользовательских строк в символы не заменяет валидацию.
Массовое символизирование внешних значений создаёт множество объектов Symbol и давит на память до их сборки, а главное — маскирует отсутствие перечня допустимых состояний. Этот риск связан с тем, что symbol — неизменяемый идентификатор с содержимым имени; сравнение одинаковых символов даёт тот же объект, но преобразование пользовательских строк в символы не заменяет валидацию.
Массовое символизирование внешних значений создаёт множество объектов Symbol и давит на память до их сборки, а главное — маскирует отсутствие перечня допустимых состояний. Этот риск связан с тем, что интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными.
Ограничение поля или обрезка по байтам может разрезать многобайтовый символ и породить недопустимую последовательность. Этот риск связан с тем, что symbol — неизменяемый идентификатор с содержимым имени; сравнение одинаковых символов даёт тот же объект, но преобразование пользовательских строк в символы не заменяет валидацию.
Массовое символизирование внешних значений создаёт множество объектов Symbol и давит на память до их сборки, а главное — маскирует отсутствие перечня допустимых состояний. Этот риск связан с тем, что методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались.
Вопрос 7 из 20
Где в показанном решении «Кодировка» скрыт дефект, который проявится не на каждом входе? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Ruby Ruby — Кодировка Копировать
# Обычный запуск проходит. Найдите скрытый риск.
text = "é"
p text.encoding
p [text.length, text.bytesize, text.bytes]
p text.valid_encoding?
Ограничение поля или обрезка по байтам может разрезать многобайтовый символ и породить недопустимую последовательность. Уязвимое место возникает потому, что интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными.
Проверка `if text.upcase!` смешивает факт изменения с фактом успеха и даёт ложную ветку для уже нормализованной строки. Уязвимое место возникает потому, что у String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов.
Ограничение поля или обрезка по байтам может разрезать многобайтовый символ и породить недопустимую последовательность. Уязвимое место возникает потому, что у String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов.
Ограничение поля или обрезка по байтам может разрезать многобайтовый символ и породить недопустимую последовательность. Уязвимое место возникает потому, что методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались.
Неверный выбор кавычек способен тихо отправить пользователю шаблон вместо значения, не вызывая исключения. Уязвимое место возникает потому, что у String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов.
Вопрос 8 из 20
Какое допущение делает этот код по теме «Изменение строк» ненадёжным? Нужен вариант без логического разрыва между первой и второй частью.
Ruby Ruby — Изменение строк Копировать
# Обычный запуск проходит. Найдите скрытый риск.
text = +'RUBY'
changed = text.upcase!
p [text, changed]
text << '!'
p text
Проверка `if text.upcase!` смешивает факт изменения с фактом успеха и даёт ложную ветку для уже нормализованной строки. К такому сбою приводит правило: у String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов.
Проверка `if text.upcase!` смешивает факт изменения с фактом успеха и даёт ложную ветку для уже нормализованной строки. К такому сбою приводит правило: методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались.
Проверка `if text.upcase!` смешивает факт изменения с фактом успеха и даёт ложную ветку для уже нормализованной строки. К такому сбою приводит правило: интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными.
Неверный выбор кавычек способен тихо отправить пользователю шаблон вместо значения, не вызывая исключения. К такому сбою приводит правило: методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались.
Ограничение поля или обрезка по байтам может разрезать многобайтовый символ и породить недопустимую последовательность. К такому сбою приводит правило: методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались.
Вопрос 9 из 20
Какой контракт нужно помнить при ревью кода по теме «Интерполяция»? Правильным считается только полностью согласованное утверждение.
Интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными. Поэтому первая строка содержит вычисленное число 6, вторая — символы `#{2 * 3}` без вычисления.
Интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными. Поэтому два литерала `:ready` имеют одинаковый object_id и подходят как стабильные ключи Hash.
У String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов. Поэтому первая строка содержит вычисленное число 6, вторая — символы `#{2 * 3}` без вычисления.
Методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались. Поэтому первая строка содержит вычисленное число 6, вторая — символы `#{2 * 3}` без вычисления.
Интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными. Поэтому для уже заглавной строки `upcase!` возвращает nil, хотя сама строка остаётся `RUBY`.
Вопрос 10 из 20
Какой принцип темы «Символы Symbol» переносится на другие примеры того же типа? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Symbol — неизменяемый идентификатор с содержимым имени; сравнение одинаковых символов даёт тот же объект, но преобразование пользовательских строк в символы не заменяет валидацию. Из этого следует, что два литерала `:ready` имеют одинаковый object_id и подходят как стабильные ключи Hash.
Интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными. Из этого следует, что два литерала `:ready` имеют одинаковый object_id и подходят как стабильные ключи Hash.
Symbol — неизменяемый идентификатор с содержимым имени; сравнение одинаковых символов даёт тот же объект, но преобразование пользовательских строк в символы не заменяет валидацию. Из этого следует, что первая строка содержит вычисленное число 6, вторая — символы `#{2 * 3}` без вычисления.
Методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались. Из этого следует, что два литерала `:ready` имеют одинаковый object_id и подходят как стабильные ключи Hash.
Symbol — неизменяемый идентификатор с содержимым имени; сравнение одинаковых символов даёт тот же объект, но преобразование пользовательских строк в символы не заменяет валидацию. Из этого следует, что для уже заглавной строки `upcase!` возвращает nil, хотя сама строка остаётся `RUBY`.
Вопрос 11 из 20
Какой принцип темы «Кодировка» переносится на другие примеры того же типа? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными. Наблюдаемое следствие: строка `é` в UTF-8 занимает два байта, но содержит один символ; `bytesize` и `length` возвращают разные числа.
Методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались. Наблюдаемое следствие: строка `é` в UTF-8 занимает два байта, но содержит один символ; `bytesize` и `length` возвращают разные числа.
У String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов. Наблюдаемое следствие: строка `é` в UTF-8 занимает два байта, но содержит один символ; `bytesize` и `length` возвращают разные числа.
У String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов. Наблюдаемое следствие: два литерала `:ready` имеют одинаковый object_id и подходят как стабильные ключи Hash.
У String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов. Наблюдаемое следствие: первая строка содержит вычисленное число 6, вторая — символы `#{2 * 3}` без вычисления.
Вопрос 12 из 20
Какое правило остаётся верным, даже если вход и порядок вызовов изменятся, в теме «Изменение строк»? Не выбирайте ответ по одному точному фрагменту: вся формулировка должна выдерживать проверку.
Методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались. Именно поэтому для уже заглавной строки `upcase!` возвращает nil, хотя сама строка остаётся `RUBY`.
Методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались. Именно поэтому первая строка содержит вычисленное число 6, вторая — символы `#{2 * 3}` без вычисления.
У String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов. Именно поэтому для уже заглавной строки `upcase!` возвращает nil, хотя сама строка остаётся `RUBY`.
Методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались. Именно поэтому два литерала `:ready` имеют одинаковый object_id и подходят как стабильные ключи Hash.
Интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными. Именно поэтому для уже заглавной строки `upcase!` возвращает nil, хотя сама строка остаётся `RUBY`.
Вопрос 13 из 20
Какой вариант решения «Интерполяция» останется понятным при сопровождении? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Ruby Ruby — Интерполяция Копировать
# Выберите изменение, которое исправляет причину.
calculated = "total=#{2 * 3}"
literal = 'total=#{2 * 3}'
p [calculated, literal]
Не использовать возвращаемое значение bang-метода как признак валидности; сравнивать до/после или вызывать небанг-версию. Так закрывается риск: неверный выбор кавычек способен тихо отправить пользователю шаблон вместо значения, не вызывая исключения.
Сопоставлять внешнюю строку с заранее известным набором символов, а неизвестные значения отвергать до бизнес-логики. Так закрывается риск: неверный выбор кавычек способен тихо отправить пользователю шаблон вместо значения, не вызывая исключения.
Выбирать тип кавычек по намерению и проверять итоговый текст, а не только отсутствие ошибки при его построении. Так закрывается риск: неверный выбор кавычек способен тихо отправить пользователю шаблон вместо значения, не вызывая исключения.
Выбирать тип кавычек по намерению и проверять итоговый текст, а не только отсутствие ошибки при его построении. Так закрывается риск: ограничение поля или обрезка по байтам может разрезать многобайтовый символ и породить недопустимую последовательность.
Выбирать тип кавычек по намерению и проверять итоговый текст, а не только отсутствие ошибки при его построении. Так закрывается риск: проверка `if text.upcase!` смешивает факт изменения с фактом успеха и даёт ложную ветку для уже нормализованной строки.
Вопрос 14 из 20
Какое исправление уменьшает риск, не скрывая исходное поведение «Символы Symbol»? Одного совпавшего вывода недостаточно — проверьте также вторую часть ответа.
Ruby Ruby — Символы Symbol Копировать
# Выберите изменение, которое исправляет причину.
a = :ready
b = 'ready'.to_sym
p [a == b, a.object_id == b.object_id]
state = { ready: true }
p state[a]
Не использовать возвращаемое значение bang-метода как признак валидности; сравнивать до/после или вызывать небанг-версию. Это изменение устраняет проблему: массовое символизирование внешних значений создаёт множество объектов Symbol и давит на память до их сборки, а главное — маскирует отсутствие перечня допустимых состояний.
Выбирать тип кавычек по намерению и проверять итоговый текст, а не только отсутствие ошибки при его построении. Это изменение устраняет проблему: массовое символизирование внешних значений создаёт множество объектов Symbol и давит на память до их сборки, а главное — маскирует отсутствие перечня допустимых состояний.
Сопоставлять внешнюю строку с заранее известным набором символов, а неизвестные значения отвергать до бизнес-логики. Это изменение устраняет проблему: ограничение поля или обрезка по байтам может разрезать многобайтовый символ и породить недопустимую последовательность.
Сопоставлять внешнюю строку с заранее известным набором символов, а неизвестные значения отвергать до бизнес-логики. Это изменение устраняет проблему: массовое символизирование внешних значений создаёт множество объектов Symbol и давит на память до их сборки, а главное — маскирует отсутствие перечня допустимых состояний.
Сопоставлять внешнюю строку с заранее известным набором символов, а неизвестные значения отвергать до бизнес-логики. Это изменение устраняет проблему: проверка `if text.upcase!` смешивает факт изменения с фактом успеха и даёт ложную ветку для уже нормализованной строки.