Conventions de nommage et style

Go a des conventions de dénomination et de style fortes et non négociables : le formateur officiel gofmt (et son sur-ensemble goimports) décide de l'indentation, de l'espacement et de l'ordre d'importation. Discuter du style est considéré comme hors sujet : vous exécutez gofmt -w et passez à autre chose. Cela libère de l'énergie pour des problèmes plus intéressants.

Visibilité : majuscules ou minuscules

Il n’existe aucun mot-clé public/private. La première lettre du nom détermine la visibilité :

• Majuscule → exporté hors package (User, Login, MaxRetries).
• Minuscule → privé au package (user, parseLine, defaultTimeout).

Cela s'applique aux : types, fonctions, méthodes, variables, constantes, champs de structure.

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

Un champ de structure "privé" n'est pas sérialisé par encoding/json (voir Module 8), et il n'est pas accessible à partir des tests dans pkg_test.

CamelCase, jamais Snake_case

Pas de trait de soulignement dans les noms comportant plusieurs mots :

• ✅HTTPClient, userName, parseRequest
• ❌Http_Client, user_name, parse_request

Les acronymes sont entièrement en majuscules (ou en minuscules, s'ils sont à portée privée) :

• ✅URL, ID, HTML, JSON, parseURL, userID
• ❌Url, Id, Html, Json, ID0, ID1

type APIResponse struct {
    UserID  int
    HTMLURL string
}

Noms courts pour les portées courtes

Le style Go privilégie la brièveté pour une clarté égale dans des portées étroites :

// 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) { ... }

Conventions établies :

• i, j, k pour les indices de boucle.
• v pour les valeurs, k pour les clés.
• r pour *Request/io.Reader, w pour Writer/ResponseWriter.
• err pour les erreurs.
• v0 pour v1.
• Récepteurs de méthode : 1 à 2 lettres cohérentes sur l'ensemble du type (v2, v3). Jamais v4 ou v5.

Plus la portée est large, plus le nom doit devenir descriptif : un count local convient, mais une variable Count exportée devrait vous dire ce qu'elle compte.

Pas de préfixe "I" sur les interfaces, pas de suffixe "Impl"

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

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

Les petites interfaces prennent souvent le suffixe -er : Reader, Writer, Stringer, Closer. Cela fait écho au fait qu'ils décrivent un comportement (une seule méthode, idéalement).

Noms des packages

Un package a un seul nom, court, tout en minuscules, pas de trait de soulignement :

• ✅bytes, http, os, userauth
• ❌userAuth, user_auth, UserAuth

Le nom du package est le préfixe d'utilisation de ses symboles : bytes.Buffer, http.Client. Donc user.User est redondant : mieux vaut renommer le type (user.Account) ou le package.

gofmt n'est pas sujet à débat

gofmt applique :

• Indentation avec tabulations (pas d'espaces).
• Accolade { sur la même ligne que la signature.
• Importations par groupes séparés par une ligne vierge ; goimports ajoute également les importations manquantes.
• Espaces autour des opérateurs.

Exécutez toujours avant de vous engager :

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

Les Linters (staticcheck, golangci-lint) ajoutent des règles supplémentaires (variables inutilisées, shadowing, comparaisons inutiles, ...).

Exercices

type ??? struct {}