SW Swift · 20 вопросов · ~55 мин · ⏱ Таймер 55:00 · Лёгкий ·

Типы, переменные и optional

Проверяет основу темы «Типы, переменные и optional» через чтение кода, предсказание результата и выбор корректной конструкции. Вопросы требуют не только узнать конструкцию, но и проследить выполнение, найти причину дефекта, выбрать исправление и оценить пограничный сценарий. Языковые примеры рассчитаны на Swift 6; задания с Apple SDK рассматриваются в контексте современных платформенных контрактов.

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. В тесте 20 вопросов, на работу отведено 55 минут. В каждом задании верен только один вариант. Часть фрагментов намеренно содержит ошибку: определяйте её по коду, а не по внешнему виду ответа. После завершения откроются общий результат, 4 тематические шкалы и подробные объяснения.

Вопрос 1 из 20

Какой из пяти выводов подтверждается построчной трассировкой? Важно учесть: различие между неизменяемой привязкой и изменяемым состоянием.

var attempts = 1
let limit = 3
attempts += 1
print(attempts, limit)

Код печатает «2 3»: изменяется значение переменной attempts, а константа limit не остаётся прежней. Код печатает «2 4»: изменяется значение переменной attempts, а константа limit остаётся прежней. Код печатает «3 3»: изменяется значение переменной attempts, а константа limit остаётся прежней. Код печатает «2 3»: изменяется значение переменной attempts, а константа limit остаётся прежней. Для этого примера достаточно учесть, что условное связывание меняет исходный Optional на обычное значение.

Вопрос 2 из 20

Определите не предполагаемое, а фактическое поведение примера «Типы значений». Здесь оценивается арифметика значений, вывод типа и цена неявных предположений.

let total = 7
let parts = 2
let ratio = Double(total) / Double(parts)
print(ratio)

Фрагмент не требует отдельного условия: Optional автоматически подставляет значение по умолчанию при чтении. После явного преобразования обоих операндов результат равен 3.5, а не 3. После явного преобразования обоих операндов результат равен 3.5, а не 4. После явного преобразования обоих операндов результат равен 4.5, а не 3. Последняя строка ведёт себя именно так, потому что force unwrap безопасен после проверки другого Optional того же типа.

Вопрос 3 из 20

В этом примере важна одна точная деталь механизма «Необязательные значения Optional». Что действительно произойдёт? Проверяется различие между отсутствием значения, пустым значением и неудачным преобразованием.

let raw: String? = "42"
let number = raw.flatMap(Int.init)
print(number as Any)

number имеет тип Int? и содержит 43; flatMap не создаёт вложенный Optional. Для этого примера достаточно учесть, что Optional автоматически подставляет значение по умолчанию при чтении. number имеет тип Int? и содержит 42; flatMap не создаёт вложенный Result. number имеет тип Int? и содержит 42; flatMap не создаёт вложенный Optional. number имеет тип Int? и содержит 42; map не создаёт вложенный Optional.

Вопрос 4 из 20

Что увидит разработчик после выполнения этого примера по теме «Безопасное извлечение»? Не упускайте из виду следующее: выбор между optional binding, guard, значением по умолчанию и принудительным извлечением.

let name: String? = "Ada"
if let name {
    print(name.count)
} else {
    print(0)
}

Optional binding создаёт внутри ветви значение без оболочки Optional, поэтому печатается 3. Для этого примера достаточно учесть, что значимый тип разделяет изменения между всеми копиями. Optional binding не создаёт внутри ветви значение без оболочки Optional, поэтому печатается 3. Result binding создаёт внутри ветви значение без оболочки Optional, поэтому печатается 3. Optional binding создаёт внутри ветви значение без оболочки Optional, поэтому печатается 4.

Вопрос 5 из 20

На проверку кода принесли этот фрагмент. Какой диагноз точнее всего объясняет проблему в части «let и var»? Проверяется различие между неизменяемой привязкой и изменяемым состоянием.

let queue = ["A", "B"]
queue.append("C")
print(queue.count)

Фрагмент не компилируется: сама коллекция объявлена через let, поэтому изменяющий метод append недоступен. Фрагмент компилируется: сама коллекция объявлена через let, поэтому изменяющий метод append недоступен. Фрагмент не компилируется: сама коллекция объявлена через let, поэтому изменяющий метод append доступен. Причина сбоя в том, что force unwrap безопасен после проверки другого Optional того же типа. Проблема возникает из-за правила: Optional автоматически подставляет значение по умолчанию при чтении.

Вопрос 6 из 20

Какой диагноз согласуется и с исходным кодом, и с правилами Swift? Проверяется арифметика значений, вывод типа и цена неявных предположений.

let price = 199
let discount = 15
let final = price * (1 - discount / 100)
print(final)

Из-за целочисленного деления discount / 100 получается 0, поэтому скидка фактически не применяется. Из-за целочисленного деления discount / 100 получается 0, поэтому скидка фактически применяется. Из-за целочисленного деления discount / 101 получается 0, поэтому скидка фактически не применяется. Проблема возникает из-за правила: значимый тип разделяет изменения между всеми копиями. Из-за целочисленного деления discount / 100 получается 1, поэтому скидка фактически не применяется.

Вопрос 7 из 20

Почему этот код не выполняет заявленный контракт? Не упускайте из виду следующее: различие между отсутствием значения, пустым значением и неудачным преобразованием.

let token: String? = nil
if token == "" {
    print("empty")
} else {
    print("missing or nonempty")
}

Проблема возникает из-за правила: force unwrap безопасен после проверки другого Optional того же типа. Причина сбоя в том, что значимый тип разделяет изменения между всеми копиями. Условие ложно для nil: отсутствие значения равно пустой строке, поэтому выполняется ветвь else. Условие ложно для nil: отсутствие значения не равно пустой строке, поэтому не выполняется ветвь else. Условие ложно для nil: отсутствие значения не равно пустой строке, поэтому выполняется ветвь else.

Вопрос 8 из 20

Какую причину стоит указать в отчёте об ошибке, прежде чем предлагать исправление? Здесь оценивается выбор между optional binding, guard, значением по умолчанию и принудительным извлечением.

import Foundation

func normalized(_ value: String?) -> String {
    guard let value else { return "unknown" }
    return value.trimmingCharacters(in: .whitespaces)
}

Причина сбоя в том, что `let` делает ссылочный объект полностью неизменяемым. Наблюдаемый симптом объясняется тем, что force unwrap безопасен после проверки другого Optional того же типа. Первой нарушенной гарантией здесь является предположение, что Optional автоматически подставляет значение по умолчанию при чтении. guard некорректно завершает ранний путь для nil и оставляет извлечённое значение доступным до конца функции. guard корректно завершает ранний путь для nil и оставляет извлечённое значение доступным до конца функции.

Вопрос 9 из 20

Какой вариант ремонта вы бы приняли после содержательной проверки кода? Не упускайте из виду следующее: различие между неизменяемой привязкой и изменяемым состоянием.

let queue = ["A", "B"]
queue.append("C")
print(queue.count)

Оставить let для неизменяемого состояния, а var вводить только там, где переназначение или мутация входят в контракт. Нужно адаптировать только вызов `queue`, поскольку условное связывание меняет исходный Optional на обычное значение. Правка сводится к локальному обходу: force unwrap безопасен после проверки другого Optional того же типа. Достаточно изменить работу с `queue`, исходя из того, что Optional автоматически подставляет значение по умолчанию при чтении. Исправление — оставить контракт прежним и учитывать, что `let` делает ссылочный объект полностью неизменяемым.

Вопрос 10 из 20

Какой вариант ремонта вы бы приняли после содержательной проверки кода? Проверяется арифметика значений, вывод типа и цена неявных предположений.

let price = 199
let discount = 15
let final = price * (1 - discount / 100)
print(final)

Сигнатуру можно не менять, если считать, что значимый тип разделяет изменения между всеми копиями. Нужно адаптировать только вызов `price`, поскольку условное связывание меняет исходный Optional на обычное значение. Достаточно изменить работу с `price`, исходя из того, что Optional автоматически подставляет значение по умолчанию при чтении. Перевести вычисление процентов в Double либо перестроить целочисленную формулу так, чтобы деление выполнялось после умножения. Правка сводится к локальному обходу: force unwrap безопасен после проверки другого Optional того же типа.

Вопрос 11 из 20

Выберите правку, после которой дефект исчезает не только в удачном примере. Здесь оценивается различие между отсутствием значения, пустым значением и неудачным преобразованием.

let token: String? = nil
if token == "" {
    print("empty")
} else {
    print("missing or nonempty")
}

Правка сводится к локальному обходу: значимый тип разделяет изменения между всеми копиями. Исправление — оставить контракт прежним и учитывать, что Optional автоматически подставляет значение по умолчанию при чтении. Хранить отсутствие как nil, а пустую строку использовать только как отдельное осмысленное состояние; смешивать их в одном условии. Хранить отсутствие как nil, а пустую строку использовать только как отдельное осмысленное состояние; не смешивать их в одном условии. Достаточно изменить работу с `token`, исходя из того, что force unwrap безопасен после проверки другого Optional того же типа.

Вопрос 12 из 20

Выберите правку, после которой дефект исчезает не только в удачном примере. Важно учесть: выбор между optional binding, guard, значением по умолчанию и принудительным извлечением.

import Foundation

func normalized(_ value: String?) -> String {
    guard let value else { return "unknown" }
    return value.trimmingCharacters(in: .whitespaces)
}

Исправление — оставить контракт прежним и учитывать, что условное связывание меняет исходный Optional на обычное значение. Для обязательного предусловия использовать guard let с ранним выходом; принудительное извлечение оставлять лишь там, где инвариант доказан структурой программы. Достаточно изменить работу с `normalized`, исходя из того, что `let` делает ссылочный объект полностью неизменяемым. Для обязательного предусловия использовать guard let с значением по умолчанию; принудительное извлечение оставлять лишь там, где инвариант доказан структурой программы. Нужно адаптировать только вызов `normalized`, поскольку значимый тип разделяет изменения между всеми копиями.

Вопрос 13 из 20

Какую предпосылку стоит явно записать в документации и тестах? Здесь оценивается различие между неизменяемой привязкой и изменяемым состоянием.

Ограничение определяется предположением, что значимый тип разделяет изменения между всеми копиями. let запрещает изменение связанного значения; для ссылочного объекта это не означает автоматической неизменяемости всего объекта. Правило меняется только в ситуации, где force unwrap безопасен после проверки другого Optional того же типа. Пограничный случай связан с тем, что Optional автоматически подставляет значение по умолчанию при чтении. let запрещает изменение связанного значения; для ссылочного объекта это означает автоматической неизменяемости всего объекта.

Вопрос 14 из 20

На какой границе входов, владения или времени жизни результат может стать другим? Проверяется арифметика значений, вывод типа и цена неявных предположений.

Вывод типа из литерала зависит от контекста: один и тот же числовой литерал не может стать Int, Double или другим совместимым типом. Вывод типа из литерала не зависит от контекста: один и тот же числовой литерал может стать Int, Double или другим совместимым типом. Граница применимости проходит там, где force unwrap безопасен после проверки другого Optional того же типа. Вывод типа из литерала зависит от контекста: один и тот же числовой литерал может стать Int, Double или другим совместимым типом. Контрпример появляется, когда Optional автоматически подставляет значение по умолчанию при чтении.

Вопрос 15 из 20

Какое уточнение защищает решение от слишком широкого толкования? Здесь оценивается различие между отсутствием значения, пустым значением и неудачным преобразованием.

Optional — это перечисление с состояниями any и none; наличие контейнера не гарантирует, что внутри есть полезное значение. Optional — это перечисление с состояниями some и none; наличие контейнера не гарантирует, что внутри есть полезное значение. Result — это перечисление с состояниями some и none; наличие контейнера не гарантирует, что внутри есть полезное значение. Optional — это перечисление с состояниями some и none; наличие контейнера гарантирует, что внутри есть полезное значение. Ограничение определяется предположением, что значимый тип разделяет изменения между всеми копиями.

Вопрос 16 из 20

Какую предпосылку стоит явно записать в документации и тестах? Не упускайте из виду следующее: выбор между optional binding, guard, значением по умолчанию и принудительным извлечением.

Несколько условий в if let вычисляются слева направо, и последующее условие может использовать ранее извлечённое значение. Несколько условий в if let вычисляются слева направо, и последующее условие не может использовать ранее извлечённое значение. Граница применимости проходит там, где условное связывание меняет исходный Optional на обычное значение. Контрпример появляется, когда значимый тип разделяет изменения между всеми копиями. Пограничный случай связан с тем, что `let` делает ссылочный объект полностью неизменяемым.

Вопрос 17 из 20

Какой инженерный принцип лучше всего подходит для долгосрочного сопровождения части «let и var»? Сосредоточьтесь на следующем: различие между неизменяемой привязкой и изменяемым состоянием.

При ревью полезно отличать реальную изменяемость модели от привычки объявлять всё через var: узкая область мутации упрощает доказательство некорректности. Архитектуру стоит строить из предположения, что force unwrap безопасен после проверки другого Optional того же типа. При ревью полезно отличать реальную изменяемость модели от привычки объявлять всё через var: узкая область мутации упрощает доказательство корректности. Для устойчивого решения достаточно принять, что значимый тип разделяет изменения между всеми копиями. В API и тестах следует исходить из правила: условное связывание меняет исходный Optional на обычное значение.

Вопрос 18 из 20

Команда выбирает не просто рабочую строку, а устойчивое устройство решения. Какой подход сильнее? Сосредоточьтесь на следующем: арифметика значений, вывод типа и цена неявных предположений.

При расширении системы нужно опираться на то, что условное связывание меняет исходный Optional на обычное значение. Явное указание типа оправдано на границах API и денежных расчётах, но избыточные аннотации вне простого выражения ухудшают читаемость. Главным проектным принципом здесь является утверждение, что значимый тип разделяет изменения между всеми копиями. Явное указание типа оправдано на границах API и денежных расчётах, но избыточные аннотации внутри простого выражения ухудшают читаемость. В API и тестах следует исходить из правила: force unwrap безопасен после проверки другого Optional того же типа.

Вопрос 19 из 20

Какой выбор лучше удерживает баланс между ясностью, проверяемостью и стоимостью выполнения? Сосредоточьтесь на следующем: различие между отсутствием значения, пустым значением и неудачным преобразованием.

Если nil несёт бизнес-смысл, его следует отражать в типе и тестах, а не маскировать пустой строкой или условным числом. При расширении системы нужно опираться на то, что force unwrap безопасен после проверки другого Optional того же типа. Главным проектным принципом здесь является утверждение, что Optional автоматически подставляет значение по умолчанию при чтении. Если nil несёт бизнес-смысл, его не следует отражать в типе и тестах, а не маскировать пустой строкой или условным числом. В API и тестах следует исходить из правила: `let` делает ссылочный объект полностью неизменяемым.

Вопрос 20 из 20

Какое замечание на проверке кода поможет предотвратить повторение такого дефекта? Важно учесть: выбор между optional binding, guard, значением по умолчанию и принудительным извлечением.

Архитектуру стоит строить из предположения, что условное связывание меняет исходный Optional на обычное значение. Безопасное извлечение должно сокращать область неопределённости: длинная пирамида вложенных if let обычно хуже ранних выходов. Для устойчивого решения достаточно принять, что `let` делает ссылочный объект полностью неизменяемым. При расширении системы нужно опираться на то, что значимый тип разделяет изменения между всеми копиями. Безопасное извлечение не должно сокращать область неопределённости: длинная пирамида вложенных if let обычно хуже ранних выходов.

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу