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

Типы, переменные и константы Go

Проверяет типы, нулевые значения, короткие объявления, константы и явные преобразования без вопросов на механическое запоминание терминов. В тесте 20 вопросов, из них 12 требуют чтения кода, команд или диагностических фрагментов. Задания опираются на устойчивые правила современного Go; если поведение зависит от версии, это оговорено в самом вопросе.

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

⏱ --:--

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

Вопрос 1 из 20

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

// Фрагмент для трассировки.
package main
import "fmt"
func main() {
    var n int
    var ok bool
    var s string
    fmt.Printf("%d %t %q", n, ok, s)
}

Для `n == 2` код печатает только `small`, потому что после совпавшего `case` выполнение выходит из `switch`. Цикл напечатает `0 1 2`, после чего `break` завершит только самую внутреннюю конструкцию `for`. Код печатает `есть: 2`; переменная `n` существует только внутри `if` и `else`. Код печатает `0 false ""`, потому что переменные объявлены, но им ничего не присвоено. Код печатает `3 2 1`, потому что три `defer` снимаются как стек после выхода из функции.

Вопрос 2 из 20

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "fmt"
func main() {
    var n int
    var ok bool
    var s string
    fmt.Printf("%d %t %q", n, ok, s)
}

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

Вопрос 3 из 20

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

// Определите правило Go, которое объясняет результат.
package main
import "fmt"
func main() {
    var n int
    var ok bool
    var s string
    fmt.Printf("%d %t %q", n, ok, s)
}

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

Вопрос 4 из 20

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

Только один операнд `%w` обычно соответствует одной оборачиваемой ошибке; форматирование `%v` не создаёт цепочку. После восстановления нельзя автоматически считать частично изменённые данные согласованными. Паника в фоновой горутине без восстановления завершает весь процесс, а не только эту горутину. Нельзя использовать многозначный вызов как один аргумент рядом с другими аргументами, если сигнатура не допускает точного разворачивания. Размер `int` зависит от разрядности целевой платформы, поэтому его нельзя молча считать всегда 64-битным.

Вопрос 5 из 20

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

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

Вопрос 6 из 20

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

// Фрагмент для трассировки.
package main
func read() (int, error) { return 3, nil }
func main() {
    var err error
    n, err := read()
    _, _ = n, err
}

`fmt.Errorf("read config: %w", err)` позволяет позже распознать исходную ошибку через `errors.Is`. Код печатает `3 2 1`, потому что три `defer` снимаются как стек после выхода из функции. Для ошибки, обёрнутой через `%w`, `errors.Is(err, ErrMissing)` возвращает `true`. Код печатает `есть: 2`; переменная `n` существует только внутри `if` и `else`. Вторая строка компилируется: `err` уже существует, но `n` объявляется впервые в этом блоке.

Вопрос 7 из 20

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
func read() (int, error) { return 3, nil }
func main() {
    var err error
    n, err := read()
    _, _ = n, err
}

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

Вопрос 8 из 20

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

// Определите правило Go, которое объясняет результат.
package main
func read() (int, error) { return 3, nil }
func main() {
    var err error
    n, err := read()
    _, _ = n, err
}

Именованные результаты являются локальными переменными и участвуют в `return` без выражений, но могут быть изменены отложенной функцией. Вариативный параметр внутри функции имеет тип среза; существующий срез передают с `...`. `recover` останавливает текущую панику только при вызове внутри отложенной функции той же горутины. `panic` прекращает обычное выполнение текущей горутины и запускает раскрутку стека с выполнением `defer`. Оператор `:=` допустим внутри функций и требует хотя бы одну новую переменную в текущем блоке.

Вопрос 9 из 20

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

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

Вопрос 10 из 20

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

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

Вопрос 11 из 20

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

// Фрагмент для трассировки.
package main
const x = 1 << 40
var a int64 = x
// var b int32 = x
func main() { _ = a }

Функция возвращает `7, nil`; запись `n, err := parse()` корректно получает оба результата. `break outer` завершает оба цикла при первой паре `i == 1 && j == 1`. Присваивание `const x = 1 << 40` переменной `int64` корректно; присваивание `int32` не скомпилируется. Перед завершением программы отложенный `fmt.Println("cleanup")` выполнится, а затем будет напечатана трассировка паники. Код печатает `есть: 2`; переменная `n` существует только внутри `if` и `else`.

Вопрос 12 из 20

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
const x = 1 << 40
var a int64 = x
// var b int32 = x
func main() { _ = a }

Использовать явный `return value`, если изменение результата через `defer` не является намеренной и хорошо объяснённой частью контракта. Не менять вариативный срез без явного контракта: при передаче `xs...` он может разделять массив с данными вызывающего кода. Назначать константе явный тип, когда контракт API должен фиксировать диапазон или представление. Использовать инициализацию в `if`, когда промежуточное значение не нужно после проверки. Ставить защиту внутри точки запуска каждой независимой задачи, если процесс должен переживать её панику.

Вопрос 13 из 20

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

// Определите правило Go, которое объясняет результат.
package main
const x = 1 << 40
var a int64 = x
// var b int32 = x
func main() { _ = a }

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

Вопрос 14 из 20

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

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

Вопрос 15 из 20

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

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

Вопрос 16 из 20

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

// Фрагмент для трассировки.
package main
type Meters int
func main() {
    var d Meters = 5
    var extra int = 2
    // _ = d + extra
    _ = d + Meters(extra)
}

Отложенная функция увеличивает именованный результат, поэтому `answer()` возвращает `2`, а не `1`. Функция возвращает ненулевую ошибку при отрицательном входе, а вызывающий код может обработать её без паники. Отложенная функция получает значение `"boom"`, и программа продолжает выполнение после завершения функции `run`. Перед завершением программы отложенный `fmt.Println("cleanup")` выполнится, а затем будет напечатана трассировка паники. Сложение `Meters` и `int` не компилируется, пока один операнд не будет явно преобразован.

Вопрос 17 из 20

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
type Meters int
func main() {
    var d Meters = 5
    var extra int = 2
    // _ = d + extra
    _ = d + Meters(extra)
}

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

Вопрос 18 из 20

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

// Определите правило Go, которое объясняет результат.
package main
type Meters int
func main() {
    var d Meters = 5
    var extra int = 2
    // _ = d + extra
    _ = d + Meters(extra)
}

Go не выполняет неявное числовое преобразование между именованными типами; преобразование пишется явно. Именованные результаты являются локальными переменными и участвуют в `return` без выражений, но могут быть изменены отложенной функцией. Отложенные вызовы выполняются в обратном порядке регистрации; аргументы обычного отложенного вызова вычисляются сразу. `panic` прекращает обычное выполнение текущей горутины и запускает раскрутку стека с выполнением `defer`. В Go `switch` не проваливается в следующую ветвь автоматически; `fallthrough` нужно писать явно.

Вопрос 19 из 20

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

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

Вопрос 20 из 20

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

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

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

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

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

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