Go-Gentlemen: Code Style and Conventions for Teamwork

Why even brilliant code can fail a project?

Imagine: you are writing in Go. The code runs fast, tests pass, and production is stable. But on Monday, a new developer arrives, opens your module and... freezes. Variables are named x1, data2, tmp. Functions — func1, process. Imports are scattered chaotically. The code will compile, but understanding it is a challenge with a twist.

Sound familiar? If you work in a team, code style and conventions for Go are not a linter's whim, but your common language. Without it, even the most talented developer turns into a "solo player" who slows down the entire team. In this article, we'll break down how to write Go so that your code is read, understood, and loved by colleagues. And also — how to avoid the trap of "fast, but dirty."

Go is about simplicity. But simplicity needs to be agreed upon

The Go language was created with teamwork in mind. It's no coincidence that Rob Pike and Ken Thompson embedded the idea of "readability above all else." However, even in Go, you can write code that works but makes you want to rewrite it from scratch.

Let's break down the key blocks that turn chaos into a coherent system.

1. gofmt — your first friend and ally

Go has a built-in formatting tool — gofmt. This is not just "prettiness." It's the standard. If you don't use gofmt — you are violating the convention. Period.

Example: imagine one developer uses tabs for indentation, another uses spaces. In Go, this problem is solved once and for all. gofmt brings the code to a uniform look. Run it before every commit. Better yet, set up a pre-commit hook.

// Bad (without gofmt)\nfunc add(a int,b int) int {\nreturn a+b\n}\n\n// Good (after gofmt)\nfunc add(a, b int) int {\n    return a + b\n}\n

Tip: In modern IDEs (VS Code, GoLand), gofmt runs automatically on save. Check your settings — it will save hours of code review.

2. Naming: speak the language of the domain

Go encourages short names. But short doesn't mean meaningless. The rule is simple: the larger the scope, the longer the name.

\n
• Local variables (inside a function) — 1-2 characters: i, j, s, err.
\n
• Function parameters — meaningful but concise: ctx, req, db.
\n
• Exported functions and types — full names: CreateUser, UserService.
\n

Bad example:

func p(u string, pwd string) bool {\n    return u == "admin" && pwd == "12345"\n}\n

Good example:

func IsValidCredentials(username, password string) bool {\n    return username == "admin" && password == "12345"\n}\n

Notice: IsValidCredentials is not just a name, it's documentation. Another developer will immediately understand what the function does without looking at the body.

3. Imports: order is the key to peace of mind

In Go, imports are divided into three groups:

\n
1. Standard library (fmt, net/http, os).
\n
2. External packages (github.com/xxx).
\n
3. Internal packages (your project).
\n

Between groups — a blank line. This is an unspoken but strict rule. gofmt doesn't check it, but code review does.

import (\n    "fmt"\n    "os"\n\n    "github.com/gorilla/mux"\n    "github.com/lib/pq"\n\n    "yourproject/internal/config"\n    "yourproject/internal/handler"\n)\n

Why is this important? When imports are scattered, you waste time searching for a package. A consistent order speeds up code reading.

4. Comments: don't writ