Konwencje nazewnictwa i styl

Go ma silne i niepodlegające negocjacjom konwencje nazewnictwa i stylu: oficjalny program formatujący gofmt (i jego nadzbiór goimports) decyduje o wcięciach, odstępach i kolejności importu. Dyskusja na temat stylu jest uważana za nie na temat: uruchamiasz gofmt -w i idziesz dalej. To uwalnia energię na ciekawsze problemy.

Widoczność: wielkie lub małe litery

Brak słów kluczowych public/private. pierwsza litera imienia określa widoczność:

• Duże litery → wyeksportowane poza pakiet (User, Login, MaxRetries).
• Małe litery → prywatne do pakietu (user, parseLine, defaultTimeout).

Dotyczy to: typów, funkcji, metod, zmiennych, stałych, pól strukturalnych.

type User struct {
    Name  string  // exported
    email string  // private to the package
}

„Prywatne” pole strukturalne nie jest serializowane przez encoding/json (patrz Moduł 8) i nie jest dostępne z testów w pkg_test.

CamelCase, nigdy Snake_case

Brak podkreśleń w nazwach składających się z wielu słów:

• ✅ KODEF0, KODEF1, KODEF2
• ❌ KODEF3, KODEF4, KODEF5

Akronimy pisane są wyłącznie wielkimi literami (lub małymi literami, jeśli należą do zakresu prywatnego):

• ✅ URL, ID, HTML, JSON, parseURL, userID
• ❌ KODEF6, KODEF7, KODEF8, KODEF9, KODEF10, KODEF11

type APIResponse struct {
    UserID  int
    HTMLURL string
}

Krótkie nazwy krótkich zakresów

Styl Go faworyzuje zwięzłość i równą przejrzystość w wąskich zakresach:

// idiomatic
for i, v := range items { ... }
for k, v := range m { ... }

if err := f(); err != nil { ... }

func (s *Server) Serve(w http.ResponseWriter, r *http.Request) { ... }

Ustalone konwencje:

• i, j, k dla indeksów pętli.
• v dla wartości, k dla kluczy.
• r dla *Request/io.Reader, w dla Writer/ResponseWriter.
• err dla błędów.
• v0 dla v1.
• Odbiorniki metod: 1–2 spójne litery w całym typie (v2, v3). Nigdy nie używaj v4 ani v5.

Im szerszy zakres, tym bardziej opisowa musi być nazwa: lokalna wartość count jest w porządku, ale wyeksportowana zmienna Count powinna powiedzieć, co się liczy.

Brak przedrostka „I” na interfejsach, brak przyrostka „Impl”.

// idiomatic
type Reader interface { ... }
type fileReader struct { ... } // concrete implementation

// not idiomatic
type IReader interface { ... }
type ReaderImpl struct { ... }

Małe interfejsy często przyjmują przyrostek -er: Reader, Writer, Stringer, Closer. Powtarza fakt, że opisują zachowanie (najlepiej jedną metodę).

Nazwy pakietów

Pakiet ma pojedynczą nazwę, krótką, wszystkie małe litery, bez podkreśleń:

• ✅ KODEF0, KODEF1, KODEF2, KODEF3
• ❌ KODEF4, KODEF5, KODEF6

Nazwa pakietu to przedrostek użycia jego symboli: bytes.Buffer, http.Client. Zatem user.User jest zbędny: lepiej zmienić nazwę typu (user.Account) lub pakietu.

gofmt nie podlega dyskusji

gofmt wymusza:

• Wcięcie z tabulatorami (nie spacjami).
• Nawias klamrowy { w tej samej linii co podpis.
• Importy w grupach oddzielonych pustą linią; goimports dodaje również brakujące importy.
• Przestrzenie wokół operatorów.

Zawsze uruchamiaj przed zatwierdzeniem:

go fmt ./...
goimports -w .
go vet ./...

Linters (staticcheck, golangci-lint) dodają dodatkowe reguły (nieużywane zmienne, cieniowanie, bezużyteczne porównania, ...).

Ćwiczenia

type ??? struct {}