Именование переменных в Go: 6 практических советов

Помню, когда устраивался на первую работу джуниор-разработчиком, меня очень сильно критиковали за название переменных. Тогда я не понимал: «Какая разница, назову переменную u или user? Код же работает! Мне казалось, что тимлид придирается к мелочам.

Теперь, спустя годы опыта, понимаю: он был прав.

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

Когда вы возвращаетесь к своему коду через полгода или когда другой разработчик пытается разобраться в вашей логике — правильное именование экономит часы, а иногда и дни.

Поэтому в этой статье решил собрать 6 проверенных советов по именованию переменных в Go. Каждый совет сопровождается наглядными примерами: как правильно и как не стоит делать. Изучив это, ваши будущие коллеги (и вы сами) скажут вам спасибо.

Совет 1. Короткие имена для короткой жизни

Если переменная живёт всего 2-3 строки кода, короткое имя из одной-двух букв — это нормально и даже правильно. Go не требует многословия там, где оно не нужно.

❌Плохо:

func sum(numbers []int) int {
    totalSum := 0
    for arrayIndex := 0; arrayIndex < len(numbers); arrayIndex++ {
        totalSum += numbers[arrayIndex]
    }
    return totalSum
}

✅Хорошо:

func sum(nums []int) int {
    total := 0
    for i := 0; i < len(nums); i++ {
        total += nums[i]
    }
    return total
}

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

Совет 2. Будьте последовательны

Если одна и та же сущность появляется в разных функциях, называйте её одинаково. Это снижает когнитивную нагрузку на читателя.

❌Плохо:

func getUser(identifier int) *User { ... }
// то же самое, но другое имя
func fetchUser(userIdentifier int) *User { ... } 
// третье имя
func deleteUser(uid int) error { ... }

✅Хорошо:

func getUser(id int) *User { ... }
func fetchUser(id int) *User { ... }
func deleteUser(id int) error { ... }

Ещё пример из реального проекта:

// ❌Плохо - разнобой в именах
func processOrder(orderID string) { ... }
// oid вместо orderID
func shipOrder(oid string) { ... }
// identifier вместо orderID
func cancelOrder(identifier string) { ... }

// ✅Хорошо - единообразие
func processOrder(orderID string) { ... }
func shipOrder(orderID string) { ... }
func cancelOrder(orderID string) { ... }

Этот совет особенно важен в командной работе. Договоритесь о стандартах внутри проекта и следуйте им — скорее всего, в команде принято вести документацию, и эти договоренности уже там описаны.

Совет 3. Описательные имена без лишних сокращений

В большинстве случаев используйте полные, понятные имена. Сокращения оправданы только тогда, когда они общеприняты и очевидны всем.

❌Плохо (избыточные сокращения):

usr := getUser()
addr := getAddress()
qty := getQuantity()
fl := getFile()

✅Хорошо (ясные имена):

user := getUser()
address := getAddress()
quantity := getQuantity()
file := getFile()

Когда сокращения действительно уместно:

Пример хороших имён: row, column, book, address, order, customer, product, price, count.

Совет 4. camelCase для неэкспортируемых сущностей

В Go принято использовать camelCase для неэкспортируемых (приватных) переменных, функций, типов и — внимание — даже констант.

Многие приходят из других языков, где константы принято писать в UPPER_CASE. В Go это не так.

❌Плохо (чужие привычки):

const MAX_RETRIES = 3
const DEFAULT_PORT = 8080

var user_name string  // подчеркивание не в стиле Go

✅Хорошо (Go-стиль):

const maxRetries = 3 // camelCase для приватной константы
const defaultPort = 8080

var userName string // camelCase без подчеркивания

Для экспортируемых (публичных) сущностей — PascalCase (начинаются с большой буквы):

const MaxRetries = 3 // экспортируемая константа
type UserService struct {} // экспортируемый тип
func NewUserService() {} // экспортируемая функция

Для пакетов — только строчные буквы, одно слово:

package user // хорошо
package userService  // плохо (два слова в camelCase)
package user_service // плохо (подчеркивание)
package userservice // допустимо, но лучше user

Совет 5. Не описывайте тип в имени

В Go статическая типизация. Компилятор и ваша IDE знают тип переменной. Не нужно дублировать эту информацию в имени — это называется венгерской нотацией, и она здесь не в почёте.

❌Плохо (венгерская нотация):

var iCount int // i - integer
var sName string // s - string
var pUser *User // p - pointer
var usersMap map[string]User // Map
var usersSlice []User // Slice
var bIsActive bool // b - boolean

✅Хорошо (Go-стиль):

var count int
var name string
var user *User
var users map[string]User
var usersList []User // если нужно подчеркнуть, что это список
var isActive bool

Единственное разумное исключение — когда тип не очевиден из контекста:

var userIDs []int // понятно, что это список ID, а не объекты User
var userByID map[int]User // понятно, что это map с ключом ID
var nameBytes []byte // понятно, что это байтовое представление строки

Запомните: не нужно гадать, перед вами указатель или значение. IDE покажет это при наведении.

Совет 6. Имена не начинаются с цифры

Это не просто совет, а правило синтаксиса Go. Имена переменных, функций, типов и констант не могут начинаться с цифры.

❌Неправильно (не скомпилируется):

var 1stUser string // ошибка компиляции
var 2ndAttempt int // ошибка компиляции
func 3rdParty() {} // ошибка компиляции

✅Правильно:

var firstUser string // буква в начале
var secondAttempt int
func thirdParty() {}

var user1 string // цифры в конце можно
var attempt2 int
var data2026 []byte

Правило простое: первым символом всегда должна быть буква (или подчёркивание, но подчёркивание не в стиле Go, не используйте его без причины). Цифры допустимы в середине или в конце имени.

Бонус: что говорят официальные источники Go

Помимо шести основных советов, вот несколько правил из официального Google Style Guide:

1. Акронимы пишутся единообразно — все заглавные:

type HTMLParser struct {} // HTML, не Html
type JSONEncoder struct {} // JSON, не Json
func ToURL() string {} // URL, не Url
var userID string // ID, не Id

2. Геттеры не требуют префикса Get (забудьте про Java-style):

// ❌Плохо (привет из Java)
func (u *User) GetName() string { return u.name }
func (u *User) GetAge() int { return u.age }

// ✅Хорошо (Go-стиль)
func (u *User) Name() string { return u.name }
func (u *User) Age() int { return u.age }

3. Избегайте пустых имён пакетов:

package util // плохо - ничего не говорит о назначении
package common // плохо
package helper // плохо

package stringutil // хорошо - понятно, что работа со строками
package jsonutil // хорошо - понятно, что работа с JSON
package user // хорошо - понятно, что работа с пользователями

Сводная таблица: можно и нельзя

Как выбрать правильное имя: чек-лист

Задайте себе три вопроса перед тем, как назвать переменную:

1. Как долго она живёт?

• 2-3 строки → короткое имя (i, n, c)
• Вся функция или глобально → описательное имя (userCount, maxRetries)

2. Что она представляет?

• Используйте термины из предметной области: row, column, book, address, order.
• Избегайте общих слов: data, info, temp.

3. Пойму ли я это имя через полгода?

• Если сомневаетесь — сделайте имя длиннее на пару символов.
• Лучше customerAddress чем ca.

Ключевой вывод

Именование переменных в Go — это не магия, а набор простых и логичных правил:

• Короткие имена для маленькой области видимости
• Длинные имена для большой области видимости
• Единообразие внутри проекта
• camelCase для всего неэкспортируемого
• Никакой венгерской нотации
• Цифры только не в начале

Следуя этим советам, вы сделаете свой код понятным не только компилятору, но и другим разработчикам. И себе через полгода — тоже.

Какой совет вы применяете чаще всего? Или, может быть, у вас есть свой любимый совет по именованию, не вошедший в список? Делитесь в комментариях!