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

Условия, циклы и switch

Разбирает ветвления, единственную форму цикла `for`, разные виды `switch` и управление выполнением на небольших, но неочевидных фрагментах. В тесте 20 вопросов, из них 12 требуют чтения кода, команд или диагностических фрагментов. Задания опираются на устойчивые правила современного Go; если поведение зависит от версии, это оговорено в самом вопросе.

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

⏱ --:--

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

Вопрос 1 из 20

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

// Фрагмент для трассировки.
package main
import "fmt"
func main() {
    if n := len("go"); n > 0 {
        fmt.Println("есть:", n)
    } else {
        fmt.Println("пусто")
    }
}

Код печатает `3 2 1`, потому что три `defer` снимаются как стек после выхода из функции. Внешний `defer` в `main` не восстановит панику, запущенную внутри отдельной горутины. Код печатает `есть: 2`; переменная `n` существует только внутри `if` и `else`. Вторая строка компилируется: `err` уже существует, но `n` объявляется впервые в этом блоке. Код печатает `0 false ""`, потому что переменные объявлены, но им ничего не присвоено.

Вопрос 2 из 20

Фрагмент относится к теме «Условие if». Какую правку стоит предложить на ревью, сохранив назначение кода?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "fmt"
func main() {
    if n := len("go"); n > 0 {
        fmt.Println("есть:", n)
    } else {
        fmt.Println("пусто")
    }
}

Использовать пакетную sentinel-ошибку только когда вызывающему коду действительно нужно программно различать этот случай. Возвращать ошибку для ожидаемых отказов; панику оставлять для нарушенного внутреннего инварианта или невозможной инициализации. Назначать константе явный тип, когда контракт API должен фиксировать диапазон или представление. Использовать инициализацию в `if`, когда промежуточное значение не нужно после проверки. Возвращать значение и ошибку, когда отсутствие результата вызвано сбоем, а не кодировать ошибку магическим числом.

Вопрос 3 из 20

На ревью разбирают тему «Условие if». На какой контракт языка или стандартной библиотеки здесь нужно опереться?

// Определите правило Go, которое объясняет результат.
package main
import "fmt"
func main() {
    if n := len("go"); n > 0 {
        fmt.Println("есть:", n)
    } else {
        fmt.Println("пусто")
    }
}

Оператор `:=` допустим внутри функций и требует хотя бы одну новую переменную в текущем блоке. Именованные результаты являются локальными переменными и участвуют в `return` без выражений, но могут быть изменены отложенной функцией. Инициализирующая часть `if` создаёт переменные, доступные в условии и обеих ветвях, но не после конструкции. Несколько результатов — обычная часть сигнатуры; вызывающий код обязан принять их все либо явно отбросить через `_`. Неинициализированная переменная получает нулевое значение своего типа; это не означает, что такое значение подходит предметной области.

Вопрос 4 из 20

В разделе «Условие if» показан конкретный случай. Какое ограничение опаснее всего пропустить?

Сравнение текстов ошибок ненадёжно: сообщение может измениться, быть локализовано или содержать контекст. Переменная из инициализатора может затенить одноимённую внешнюю переменную. В цикле отложенные вызовы выполнятся только при выходе из окружающей функции, что может слишком долго удерживать ресурсы. Вызов `recover()` вне выполняемого `defer` возвращает `nil` и ничего не перехватывает. Преобразование целого к меньшему типу отбрасывает старшие биты и не сообщает о переполнении.

Вопрос 5 из 20

Команда проверяет решение по теме «Условие if». Какой вывод о сопровождении решения наиболее взвешенный?

Короткая область видимости уменьшает случайные зависимости, но слишком плотная строка ухудшает чтение сложного условия. Именованные результаты полезны для документации и коротких функций, но скрытая мутация результата повышает цену ревью. Sentinel упрощает ветвление, но публичный набор категорий становится частью совместимости пакета. `defer` упрощает освобождение, но в большом цикле отдельная вспомогательная функция часто задаёт более короткое время жизни. Явные преобразования делают риск видимым, но сами по себе не доказывают безопасность диапазона.

Вопрос 6 из 20

Фрагмент относится к теме «Цикл for». Как завершится показанный фрагмент при указанных входных данных?

// Фрагмент для трассировки.
package main
import "fmt"
func main() {
    for i := 0; ; i++ {
        if i == 3 { break }
        fmt.Print(i, " ")
    }
}

Перед завершением программы отложенный `fmt.Println("cleanup")` выполнится, а затем будет напечатана трассировка паники. Код печатает `0 false ""`, потому что переменные объявлены, но им ничего не присвоено. Цикл напечатает `0 1 2`, после чего `break` завершит только самую внутреннюю конструкцию `for`. Отложенная функция получает значение `"boom"`, и программа продолжает выполнение после завершения функции `run`. Код печатает `3 2 1`, потому что три `defer` снимаются как стек после выхода из функции.

Вопрос 7 из 20

На ревью разбирают тему «Цикл for». Что здесь следует изменить прежде всего?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "fmt"
func main() {
    for i := 0; ; i++ {
        if i == 3 { break }
        fmt.Print(i, " ")
    }
}

Возвращать ошибку для ожидаемых отказов; панику оставлять для нарушенного внутреннего инварианта или невозможной инициализации. Для фоновой работы связывать цикл с `context` или каналом завершения, а не оставлять его без пути остановки. Не менять вариативный срез без явного контракта: при передаче `xs...` он может разделять массив с данными вызывающего кода. Использовать `=` при повторном присваивании всех имён; `:=` оставлять для появления хотя бы одного нового имени. Оставить нулевое значение только там, где оно имеет ясный смысл; иначе создавать значение через конструктор с проверкой.

Вопрос 8 из 20

В разделе «Цикл for» показан конкретный случай. Какое правило отделяет верный разбор от правдоподобной догадки?

// Определите правило Go, которое объясняет результат.
package main
import "fmt"
func main() {
    for i := 0; ; i++ {
        if i == 3 { break }
        fmt.Print(i, " ")
    }
}

`fmt.Errorf` с `%w` сохраняет исходную ошибку в цепочке и добавляет контекст. Go не выполняет неявное числовое преобразование между именованными типами; преобразование пишется явно. Нетипизированная константа сохраняет точное значение до контекста, где требуется конкретный тип, если значение представимо. `for` без условия является бесконечным циклом; завершение должно быть выражено `break`, `return` или внешней отменой. Ошибка — значение, обычно возвращаемое отдельным результатом; `errors.New` подходит для постоянного сообщения без форматирования.

Вопрос 9 из 20

Команда проверяет решение по теме «Цикл for». Какой крайний случай обязан попасть в тесты?

Короткое объявление во вложенном блоке может затенить внешнюю переменную и оставить её значение неизменным. Голый `return` в длинной функции усложняет понимание, какое значение фактически возвращается. Сравнение текстов ошибок ненадёжно: сообщение может измениться, быть локализовано или содержать контекст. После восстановления нельзя автоматически считать частично изменённые данные согласованными. Изменение длины среза внутри `range` не заставляет цикл заново вычислять число итераций.

Вопрос 10 из 20

Перед публикацией кода по теме «Цикл for» нужно уточнить контракт. Какой выбор лучше отражает баланс простоты и контроля?

`defer` упрощает освобождение, но в большом цикле отдельная вспомогательная функция часто задаёт более короткое время жизни. Явные преобразования делают риск видимым, но сами по себе не доказывают безопасность диапазона. Нетипизированные константы удобны в выражениях, но явный тип полезен на границе пакета и при сериализации. Обычный `for` даёт полный контроль, а `range` короче и безопаснее для обхода, но скрывает часть деталей индексации. Паника быстро выявляет невозможное состояние, но как обычный протокол ошибок она лишает вызывающий код явного выбора.

Вопрос 11 из 20

На ревью разбирают тему «Ветвление switch». Как изменится состояние программы после этого фрагмента?

// Фрагмент для трассировки.
package main
import "fmt"
func main() {
    n := 2
    switch n {
    case 1, 2:
        fmt.Println("small")
    case 3:
        fmt.Println("three")
    }
}

Перед завершением программы отложенный `fmt.Println("cleanup")` выполнится, а затем будет напечатана трассировка паники. Код печатает `0 false ""`, потому что переменные объявлены, но им ничего не присвоено. Код печатает `3 2 1`, потому что три `defer` снимаются как стек после выхода из функции. Для `n == 2` код печатает только `small`, потому что после совпавшего `case` выполнение выходит из `switch`. Отложенная функция получает значение `"boom"`, и программа продолжает выполнение после завершения функции `run`.

Вопрос 12 из 20

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "fmt"
func main() {
    n := 2
    switch n {
    case 1, 2:
        fmt.Println("small")
    case 3:
        fmt.Println("three")
    }
}

Объединять несколько значений в одном `case`, если им соответствует одно действие, вместо цепочки пустых ветвей. Возвращать значение и ошибку, когда отсутствие результата вызвано сбоем, а не кодировать ошибку магическим числом. Использовать `=` при повторном присваивании всех имён; `:=` оставлять для появления хотя бы одного нового имени. Оставить нулевое значение только там, где оно имеет ясный смысл; иначе создавать значение через конструктор с проверкой. Использовать пакетную sentinel-ошибку только когда вызывающему коду действительно нужно программно различать этот случай.

Вопрос 13 из 20

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

// Определите правило Go, которое объясняет результат.
package main
import "fmt"
func main() {
    n := 2
    switch n {
    case 1, 2:
        fmt.Println("small")
    case 3:
        fmt.Println("three")
    }
}

`recover` останавливает текущую панику только при вызове внутри отложенной функции той же горутины. В Go `switch` не проваливается в следующую ветвь автоматически; `fallthrough` нужно писать явно. Несколько результатов — обычная часть сигнатуры; вызывающий код обязан принять их все либо явно отбросить через `_`. Go не выполняет неявное числовое преобразование между именованными типами; преобразование пишется явно. Нетипизированная константа сохраняет точное значение до контекста, где требуется конкретный тип, если значение представимо.

Вопрос 14 из 20

Перед публикацией кода по теме «Ветвление switch» нужно уточнить контракт. Где корректный фрагмент легко становится ошибочным?

Вызов `recover()` вне выполняемого `defer` возвращает `nil` и ничего не перехватывает. Паника в фоновой горутине без восстановления завершает весь процесс, а не только эту горутину. `errors.Is` не предназначен для поиска совпадающего текста сообщения. Короткое объявление во вложенном блоке может затенить внешнюю переменную и оставить её значение неизменным. `fallthrough` переходит в следующую ветвь без проверки её выражения.

Вопрос 15 из 20

В рабочем примере по теме «Ветвление switch» важно отделить гарантию от догадки. Что учитывать при выборе этого приёма для публичного API?

Паника быстро выявляет невозможное состояние, но как обычный протокол ошибок она лишает вызывающий код явного выбора. Явные преобразования делают риск видимым, но сами по себе не доказывают безопасность диапазона. `switch` хорошо показывает взаимоисключающие случаи, но чрезмерный `fallthrough` делает поток управления труднее проверки. Граница восстановления защищает сервер от дефекта одного запроса, но не должна скрывать повреждённое общее состояние. Контекст ускоряет диагностику, но бессмысленное многократное повторение делает сообщение громоздким.

Вопрос 16 из 20

В разделе «Управление выполнением» показан конкретный случай. Какой результат даст этот код на поддерживаемой реализации Go?

// Фрагмент для трассировки.
package main
func main() {
outer:
    for i := 0; i < 3; i++ {
        for j := 0; j < 3; j++ {
            if i == 1 && j == 1 { break outer }
        }
    }
}

Перед завершением программы отложенный `fmt.Println("cleanup")` выполнится, а затем будет напечатана трассировка паники. `break outer` завершает оба цикла при первой паре `i == 1 && j == 1`. Отложенная функция получает значение `"boom"`, и программа продолжает выполнение после завершения функции `run`. Функция возвращает `7, nil`; запись `n, err := parse()` корректно получает оба результата. Код печатает `3 2 1`, потому что три `defer` снимаются как стек после выхода из функции.

Вопрос 17 из 20

Команда проверяет решение по теме «Управление выполнением». Что нужно поменять, чтобы граничный случай не превратился в сбой?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
func main() {
outer:
    for i := 0; i < 3; i++ {
        for j := 0; j < 3; j++ {
            if i == 1 && j == 1 { break outer }
        }
    }
}

Использовать явный `return value`, если изменение результата через `defer` не является намеренной и хорошо объяснённой частью контракта. Использовать метку, когда она делает цель выхода очевидной; при сложной логике лучше вынести поиск в отдельную функцию и вернуть результат. Использовать пакетную sentinel-ошибку только когда вызывающему коду действительно нужно программно различать этот случай. Использовать `defer` рядом с успешным захватом ресурса и не прятать в нём критически важную бизнес-логику. Возвращать значение и ошибку, когда отсутствие результата вызвано сбоем, а не кодировать ошибку магическим числом.

Вопрос 18 из 20

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

// Определите правило Go, которое объясняет результат.
package main
func main() {
outer:
    for i := 0; i < 3; i++ {
        for j := 0; j < 3; j++ {
            if i == 1 && j == 1 { break outer }
        }
    }
}

Метка у `break` или `continue` позволяет явно воздействовать на внешнюю конструкцию, а не только на ближайший цикл. `recover` действует только в той горутине, где возникла паника; родительская горутина не перехватит панику дочерней. Нетипизированная константа сохраняет точное значение до контекста, где требуется конкретный тип, если значение представимо. Несколько результатов — обычная часть сигнатуры; вызывающий код обязан принять их все либо явно отбросить через `_`. `recover` останавливает текущую панику только при вызове внутри отложенной функции той же горутины.

Вопрос 19 из 20

В рабочем примере по теме «Управление выполнением» важно отделить гарантию от догадки. Что стоит проверить до переноса решения в общий компонент?

После восстановления нельзя автоматически считать частично изменённые данные согласованными. Паника в фоновой горутине без восстановления завершает весь процесс, а не только эту горутину. `defer` не выполняется при `os.Exit`, поэтому такой выход нельзя считать обычным завершением функции. После обычных аргументов вариативный параметр должен быть последним в сигнатуре. Голый `return` в длинной функции усложняет понимание, какое значение фактически возвращается.

Вопрос 20 из 20

Фрагмент относится к теме «Управление выполнением». Как точнее всего описать пользу и цену этого решения?

Граница восстановления защищает сервер от дефекта одного запроса, но не должна скрывать повреждённое общее состояние. Паника быстро выявляет невозможное состояние, но как обычный протокол ошибок она лишает вызывающий код явного выбора. Variadic удобен для небольшого необязательного набора, но срез яснее, когда коллекция является самостоятельным объектом данных. Метки иногда проще флагов состояния, но большое число переходов быстро разрушает локальную понятность кода. Локальное восстановление повышает живучесть, но требует чёткой изоляции состояния и наблюдаемого сигнала о дефекте.

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

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

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

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