Comment écrire du code propre en Go : 7 règles pour les pros

Introduction : pourquoi le code propre en Go n'est pas un luxe, mais une nécessité

Go (ou Golang) est un langage qui, à première vue, semble simple et même ennuyeux. Pas de génériques (avant la version 1.18), pas de classes, pas de machine virtuelle. Mais c'est justement ce minimalisme qui en fait un terrain de jeu idéal pour le code propre. Si vous écrivez en Go et que votre projet commence à ressembler à un plat de spaghettis composé de goroutine et de switch illisibles, vous perdez le principal avantage du langage : la rapidité de développement et la simplicité de maintenance.

Dans cet article, nous allons analyser 7 règles pratiques qui vous aideront à écrire du code Go idiomatique, compréhensible non seulement par le compilateur, mais aussi par vos collègues (et par vous-même dans un mois). C'est parti !

1. Noms de variables appropriés : court et clair

En Go, on utilise des noms courts mais significatifs. Contrairement à Java, où ListOfUserOrders est la norme, en Go vous verrez orders ou même os. Pourquoi ? Parce que Go est un langage conçu pour la lecture du code, pas seulement pour son écriture.

Règles de base pour le nommage en Go

\n
• Variables locales : 1 à 2 lettres pour les choses évidentes (i pour un compteur, s pour une chaîne).
\n
• Paquets : un seul mot, en minuscules, sans tirets bas (http, fmt).
\n
• Identifiants exportés : commencent par une majuscule (GetUser).
\n
• Acronymes : s'écrivent dans la même casse (HTTP, URL, et non Http ou Url).
\n

// Mauvais\nfunc GetUserDataFromDatabaseByID(userID string) (UserData, error) {\n    var userDataFromDb UserData\n    // ...\n    return userDataFromDb, nil\n}\n\n// Bon\nfunc GetUser(id string) (User, error) {\n    var u User\n    // ...\n    return u, nil\n}

Conseil : si le nom d'une variable contient plus de 2 mots, vous compliquez probablement les choses.

2. Formatage : faites confiance à gofmt

En Go, il n'y a pas de « guerres de style ». La commande gofmt décide tout pour vous. Ce n'est pas une recommandation, c'est une norme. Si vous n'utilisez pas gofmt, vous n'écrivez pas en Go, mais dans un « dialecte de Go ».

Que fait gofmt ?

\n
• Gère l'indentation (tabulations, pas d'espaces).
\n
• Supprime les sauts de ligne inutiles.
\n
• Aligne les commentaires.
\n
• Supprime les imports inutilisés (avec le flag -s).
\n

// Avant gofmt\nfunc  add (a int,b int) int{\nreturn a+b\n}\n\n// Après gofmt\nfunc add(a, b int) int {\n    return a + b\n}

Dans tout éditeur moderne (VS Code, GoLand), gofmt s'exécute automatiquement lors de la sauvegarde. Si ce n'est pas le cas, configurez-le. Cela vous fera gagner des heures de revue de code.

3. Gestion des erreurs : ne les ignorez pas, ne paniquez pas

En Go, il n'y a pas d'exceptions (try-catch). Les erreurs sont simplement des valeurs qu'il faut vérifier. C'est l'un des points forts du langage, à condition de l'utiliser correctement.

Règles pour un travail propre avec les erreurs

\n
• Vérifiez toujours error. Pas de _ pour les ignorer.
\n
• N'utilisez pas panic dans le code de bibliothèque. Uniquement si le programme ne peut pas continuer (par exemple, si le fichier de configuration ne s'ouvre pas).
\n
• Enveloppez les erreurs avec fmt.Errorf("context : %w", err) (Go 1.13+).
\n

// Mauvais\nfunc ReadConfig(path string) *Config {\n    data, _ := ioutil.ReadFile(path) // on ignore l'erreur\n    var cfg Config\n    json.Unmarshal(data, &cfg)\n    return &cfg\n}\n\n// Bon\nfunc ReadConfig(path string) (*Config, error) {\n    data, err := ioutil.ReadFile(path)\n    if err != nil {\n        return nil, fmt.Errorf("read config: %w", err)\n    }\n    var cfg Config\n    if err := json.Unma