Правила и идиомы Go

Идиома — это решение, которое приняли за вас до того, как вы открыли редактор. В других языках споры об именовании и обработке ошибок длятся десятилетиями, потому что «правильно» каждый понимает по-своему. В Go позиция другая: большинство таких решений зафиксировано в документе Effective Go — «tips for writing clear, idiomatic Go code», сборнике советов, который лежит рядом со спецификацией языка. Именно поэтому код двух незнакомых Go-программистов так похож: они читали один и тот же документ, а компилятор и gofmt отсекают остальное.

Что важно понимать про статус этого документа. Во-первых, он не спецификация: нарушить идиому нельзя — компилятор примет и underscore_names, и GetOwner, и гигантские интерфейсы. Нарушение идиомы — социальное событие: ваш код станут читать медленнее, а на ревью попросят переделать. Во-вторых, документ честно стареет: он написан до дженериков (тринадцатый урок), до появления контекста как стандарта и до многих современных линтеров, и его до сих пор не переписали — базовые привычки там верны, а вот к рекомендациям «только каналы, никаких мьютексов» стоит относиться с оговорками, о которых поговорим ниже. В-третьих, Effective Go — не единственный источник: есть Go Code Review Comments, доклады Роба Пайка с Go Proverbs и исходники стандартной библиотеки — лучший образец идиоматичного кода.

Дорожная карта урока: именование (MixedCaps, геттеры без Get, короткие имена в узкой области, групповая форма и iota), ошибки как значения и честный if err != nil, малые интерфейсы, слоган «don't communicate by sharing memory», пустая структура struct{} и финал — простота против cleverness и gofmt. Каждая идиома — короткий блок с отсылкой к уроку курса, где она родилась: здесь ничего нового не изобретается, всё уже было, но по одному фрагменту за раз. Запрос «идиомы go» на самом деле ищет именно это: не новые возможности языка, а умение писать старыми так, чтобы ваш код выглядел как стандартная библиотека.

Первая идиома Effective Go — про имена: «the convention in Go is to use MixedCaps or mixedCaps rather than underscores to write multiword names». Многословные имена пишутся горбиком: rateLimit, ParseDuration, upperLimit — но не rate_limit и не Rate_Limit. Подчёркивания в Go живут ровно в двух местах: в начале имени (неэкспортированные хелперы вида _test, пустой идентификатор _) и в именах файлов. В идентификаторах им места нет — и это не эстетика, а способ убрать целую войну стилей: camelCase, snake_case и PascalCase не сосуществуют, победил один горбик.

Регистр первой буквы в Go несёт СМЫСЛОВУЮ нагрузку, которой нет почти нигде: имя с заглавной — экспортированное (видно из других пакетов), со строчной — приватное для пакета. Четырнадцатый урок разбирал устройство пакетов — здесь важно следствие: когда вы пишете StatusOK вместо STATUS_OK, вы одновременно выбираете стиль и решаете, экспортировать ли константу. Пакеты именуются ещё строже — lower case, single-word: «there should be no need for underscores or mixedCaps» — strconv, strings, http. Аббревиатуры держат собственный регистр целиком: ParseURL, а не ParseUrl; тип URL в net/url, пакет utf8, метод ServeHTTP — посмотрите на любую страницу стандартной библиотеки, и паттерн увидите сами.

Вторая половина идиомы — о длине. Правило сообщества формулируется так: чем больше расстояние между объявлением имени и его использованием, тем длиннее должно быть имя. Пакетная константа живёт в сотнях файлов — ей нужно полное имя (StatusTooManyRequests, maxIdleConnsPerHost). Локальный счётчик живёт три строки — ему достаточно i, n, r: короткое имя в узкой области читается мгновенно, потому что всё, что о нём нужно знать, видно на экране. Ошибка новичка — наоборот: i := 0 в двухстрочном цикле никто не обидит, а вот промежуточная переменная данных пользователя с именем d в функции на сто строк заставит читателя листать назад. Имя — это документация с самым коротким сроком устаревания: оно либо честно описывает содержимое, либо врёт в каждой строке, где употреблено.

Effective Go говорит про геттеры дословно следующее: «it's neither idiomatic nor necessary to put Get into the getter's name. If you have a field called owner (lower case, unexported), the getter method should be called Owner (upper case, exported), not GetOwner». Логика проста: имя метода в Go читается как ответ на вопрос «что это или что с этим делать», и префикс Get — шум. Поле email — метод Email(); счётчик p.count — метод p.Count(). Сеттер — единственное исключение, где глагол нужен, чтобы отличить запись от чтения: u.SetEmail("oleg@example.com"). И то же правило продолжается в конвертерах: строковый метод типа называется String, а не ToString — «call your string-converter method String not ToString» — именно поэтому fmt.Stringer выглядит так лаконично, и именно с ним мы соберём малый интерфейс ниже.

Вторая привычка этого блока — групповая форма объявлений. Ключевые слова const и var в Go умеют объявлять СПИСКИ: константы статуса собираются в один const-блок, пакетные переменные — в один var-блок, и это не байка про компактность, а способ показать родство: то, что объявлено группой, читается как одна мысль. Импорты тоже группируются — стандартная библиотека первой группой, внешние пакеты второй (это уже правило gofmt-инструментов вроде goimports). Внутри const-группы живёт и iota — «enumerated constants are created using the iota enumerator», перечислитель, который в каждой следующей строке группы на единицу больше: Low = iota, за ним Mid и High получают 1 и 2 бесплатно. Iota — идиоматичная замена рукописным 0, 1, 2: новое перечисление вставляется в середину группы, и нумерация перестраивается сама.

Практический минимум блока: поле храните неэкспортированным, наружу выпускайте метод с именем поля; группу констант начинайте с имени с iota, если это перечисление; локальные имена — короткие, пакетные — длинные. Всё это проверяется в раннере ниже — он исполняется обоими движками, потому что в коде нет ничего экзотического: только fmt, strings и групповые объявления.

Центральная идиома языка и главного его не-фичи: в Go нет исключений в привычном смысле — ошибки это ЗНАЧЕНИЯ. Функция, которая может не справиться, возвращает последний (или единственный) результат типа error — интерфейс с одним методом Error() string. Пятнадцатый урок разобрал всю механику: fmt.Errorf с глаголом %w для заворачивания, errors.Is и errors.As для проверки цепочки, ошибки-сентинеллы вида var ErrNotFound = errors.New(...). Здесь важна идиома верхнего уровня — КАК выглядит работа с этим значением: err := f(); if err != nil { return err }. Не try/catch вокруг блока, а проверка сразу после каждого вызова, где ошибка имеет смысл.

Effective Go объясняет, почему это красиво: «the code reads well if the successful flow of control runs down the page, eliminating error cases as they arise» — успешный путь идёт вниз по странице, а ошибки отсекаются guard-ветвями по ходу. Отсюда три честных правила. Первое: err != nil — это не формальность, а решение; печатать ошибку и продолжать с nil-результатом хуже, чем честно вернуть её наверх. Второе: игнорировать ошибку молча нельзя; единственная идиоматичная форма сознательного игнорирования — пустой идентификатор, _ = err или _, err := f(), — и он читается как «я знаю, что здесь может быть ошибка, и осознанно её выбрасываю». Компилятор не заставит вас проверять err — это идиома, а не синтаксис, поэтому сообщество написало линтеры (errcheck и компания), а код-ревью ловит пропуски. Третье: panic — не замена ошибке; паника для программиста, сломавшего контракт (нулевая ссылка, невозможное состояние), ошибка — для данных, которые не совпали (файл не найден, ответ не распарсился). Каскад guard-ветвей ниже показывает стиль целиком.

Пара (значение, error) — самый частый контракт в языке: os.Open, http.Get, json.Unmarshal, time.Parse — все возвращают результат и ошибку рядом. У идиомы есть честная цена: boilerplate. Она признана языковым комитетом — дженерики её не убрали, специальные синтаксисы (try, ?) отвергали по разу, потому что явность проверки — та самая «честность»: в месте вызова видно, ошибка обрабатывается, заворачивается или выбрасывается.

Идиома о размерах: интерфейс в Go тем сильнее, чем меньше у него методов. Формула Роба Пайка из Go Proverbs: «The bigger the interface, the weaker the abstraction» — а её обратная сторона вам уже знакома по десятому и одиннадцатому урокам: чем меньше методов требует контракт, тем больше типов его удовлетворяют без единой строчки приспосабливания. Экстремум — сам error: интерфейс из ОДНОГО метода Error() string, и любая структура с этим методом становится ошибкой. Дальше fmt.Stringer (String() string), io.Reader и io.Writer (по одному методу), sort.Interface (три) — стандартная библиотека набита контрактами на один-два метода, и это не экономия, а дизайн.

Отсюда две практические привычки. Первая — «принимай интерфейсы, возвращай конкретные типы»: функция printPrice(p Pricer) работает с любым носителем цены, а конструктор NewTicket возвращает конкретный Ticket, потому что вызывающему удобнее получить максимум возможностей, а не минимум обещаний. Интерфейс при этом объявляют ПОТРЕБИТЕЛЬ, а не поставщик: интерфейс живёт в пакете, который его использует, — так контракт точно описывает то, что нужно, а не то, что реализовано. Вторая — строковая идиома: тип, которому предстоят печати и логи, получает метод String() string и автоматически печатается по-человечески в fmt.Println — запомните форму «String, не ToString» из предыдущего блока.

Малый интерфейс — ещё и страховка от переусложнения: если контракт из одного метода вдруг захотел расти, это сигнал, что он смешивает две обязанности. В раннере ниже — Pricer из одного метода и Ticket с методами Price и String: оба движка исполняют пример одинаково, потому что интерфейсная диспетчеризация в песочнице честная. Связка с десятым уроком прямая: там интерфейсы как механизм, здесь — как стиль выбора размера.

Слоган из Effective Go стоит выучить дословно: «Do not communicate by sharing memory; instead, share memory by communicating» — не общайтесь, разделяя память; делитесь памятью, общаясь. За ним стоит модель, о которой документ пишет честно: «Only one goroutine has access to the value at any given time. Data races cannot occur, by design» — в каждый момент времени значение доступно одной горутине, гонок нет по построению. Практическая форма этой идиомы — владелец канала: данные проходят через канал (четвертый и пятый уроки), а не через общую переменную под замком (восьмой урок). Горутина-владелец единственная пишет в канал, потребители читают; кто создаёт канал, тот и закрывает — close в Go вообще имеет смысл только у отправителя, и range по каналу в настоящем коде завершается именно на этом close.

У идиомы есть канонические проявления, которые вы уже видели: воркер-тикер из двадцать третьего урока владел своим каналом и уходил по ctx.Done() из девятого; таймауты в select из шестого — это тоже коммуникация вместо общего флага. И у неё есть честная оговорка из самого Effective Go: «This approach can be taken too far. Reference counts may be best done by putting a mutex around an integer variable» — зашаренную переменную-счётчик честнее защитить мьютексом из восьмого урока, чем городить вокруг неё канал. Идиома — высокоуровневый подход, а не религиозный запрет: выбирайте владение каналом, когда значение переходит из руки в руку, и мьютекс — когда много читателей щиплет одно поле.

Ниже — задание на порядок: владелец-замыкание шлёт два значения, main читает ровно обещанное. Обратите внимание на чтение фиксированного числа значений вместо range: в резервном движке песочницы range по каналу зависает (close он не знает), поэтому оба раннера урока построены на подсчёте — это и есть пример идиомы, адаптированной под честные ограничения инструмента.

struct{} — структура без полей, и в этом её сила: она занимает НОЛЬ байт (девятнадцатый урок мерял размеры через unsafe.Sizeof — можно проверить: sizeof(struct{}) == 0), поэтому все её значения буквально совпадают в памяти. Идиоматичных применений три. Первое — множество: map[string]struct{} — это set, где ключ — данные, а значение — пустышка; проверка принадлежности через _, ok := set["go"] читается идеально, и по сравнению с map[string]bool вы экономите не память (нулевой bool и так дешёв), а намерение: map на struct{} ЧИТАЕТСЯ как множество, а не как «словарь флагов». Второе — сигнальный канал: chan struct{} — канал, у которого важно только событие, а не содержимое; done := make(chan struct{}), close(done) — и все читатели получают нулевое значение немедленно. Третье — пустые типы-маркеры: у структуры без полей нечего копировать, поэтому передача Empty{} — бесплатна.

Вы уже держали сигнальный канал в руках, не зная об идиоме: ctx.Done() из девятого урока возвращает именно <-chan struct{} — контекст сообщает «время вышло», и данные тут ни при чём. Точно так же выглядят done-каналы горутин, семафоры на буферизованных каналах и ping-каналы сторожей. Сравните с не-идиоматичными заменами: chan bool приглашает спросить «true — это успех или сигнал?», а map[string]bool не отличает множество от словаря. Пустая структура — идиома намерения: она говорит «содержимое не имеет значения» синтаксически.

Пара (set и канал) собирается в predict ниже: дубликат ключа не увеличил len, а печатается структура без полей честными пустыми фигурными скобками. Оба движка дают одинаковый ответ, потому что map, len и печать структур — базовые вещи; прогнано трижды, как и всё в уроке.

Осталось самое трудное — идиома без синтаксиса. «Clear is better than clever» — ещё одна пословица Роба Пайка, и Go проводит её во всём: в явной проверке ошибок вместо магии исключений, в отсутствии перегрузки операторов, в запрете циклических импортов, в дженериках, спроектированных так, чтобы не породить метапрограммирование ради метапрограммирования. Простота — тоже идиома, и измеряется она не объёмом кода, а скоростью чтения. Практическая форма: код читают на порядок чаще, чем пишут; остроумный однострочник — это налог на каждого следующего читателя, а простой явный цикл — подарок. Идиоматичный Go скучен нарочно: он собирается из названных вещей — малых интерфейсов, ошибок-значений, владения каналом — так, что читатель опознаёт формы, а не расшифровывает новые.

Здесь же — gofmt, идиома, доведённая до машины: «The gofmt program reads a Go program and emits the source in a standard style of indentation and vertical alignment, retaining and if necessary reformatting comments». Форматирование в Go не обсуждается — его делает инструмент (gofmt или go fmt на уровне пакета), и это выносит из ревью целую категорию споров: отступы, пробелы вокруг операторов, порядок перестановки полей. Effective Go добавляет метаправило: «if the answer doesn't seem right, rearrange your program — don't work around gofmt» — если вывод gofmt кажется плохим, проблема в том, что код написан в неудачной форме. Простой язык + простой формат + честные ошибки = код, который стареет медленно: он читается и через десять лет, потому что ничего умного в нём не спрятано.

Финальный штрих — идиомы проверяются линтерами: go vet входит в дистрибутив и ловит механические ошибки (Printf-глаголы, неиспользуемые результаты), gofmt и goimports держат форму, community-линтеры (errcheck, staticcheck) добирают то, что идиома отдала на честное слово. Проверка идиоматичности — часть обычного цикла, а не подвиг: напишите по-простому, прогоните инструменты, поправьте — и код станет понятен незнакомцу.

Соберём урок в один абзац. Именование: MixedCaps вместо подчёркиваний, видимость через регистр, геттеры без Get, String вместо ToString, короткие имена в узких областях, групповые объявления и iota. Ошибки: значение error, проверяемое честным if err != nil, guard-ветви и успех вниз по странице, контекст через fmt.Errorf, цепочки через errors.Is — механика в пятнадцатом уроке, стиль здесь. Интерфейсы: один метод — уже контракт, потребитель объявляет, конкретный тип возвращается. Конкуренция: don't communicate by sharing memory — владелец канала, а честный мьютекс для общего поля. Ноль байт: struct{} для множеств и сигналов. И всё это держит gofmt с простотой против cleverness.

Двадцать пятый урок — финал курса: проект-воркер, где идиомы работают на канатах настоящего приложения — владелец канала будет качать задачи, тикер из двадцать третьего урока задаст такт, ошибки-значения из пятнадцатого сложатся в цепочки, defer из второго закроет ресурсы, контекст из девятого урежет всё по дедлайну. Это не экзамен по списку выше, а его применение: вы увидите, как идиомы перестают быть правилами и становятся способом думать.

Если захочется перечитать первоисточники — Effective Go лежит на go.dev/doc/effective_go, а лучшие живые примеры — исходники стандартной библиотеки. Внутри курса вернитесь к уроку про time: время как значения — тоже идиома, Duration вместо магических чисел; к уроку про обработку ошибок: там вся механика %w и errors.Is, на которую опирается стиль этого урока; и к уроку про интерфейсы: малые интерфейсы выросли из его механизмов. До встречи на странице курса — остался один шаг.