Go se plaint "undefined" pour une fonction d'un autre fichier ? Décryptage

Fonction « Undefined » en Go : comment faire collaborer les fichiers sans perdre la tête

Imaginez : vous écrivez un programme en Go, vous divisez le code en fichiers logiques (par exemple, main.go et helper.go), vous lancez go run main.go — et le compilateur vous sort un glacial : « undefined: MyFunction ». Cela vous dit quelque chose ? Cette question est l'une des plus populaires sur Stack Overflow (des milliers de vues !), et aujourd'hui nous allons l'analyser une fois pour toutes.

Pourquoi Go, pourtant réputé pour sa simplicité, ne voit-il soudainement plus une fonction d'un fichier voisin ? Ce n'est pas de la magie, mais des règles strictes d'organisation du code. Passons en revue tous les scénarios — de l'erreur classique du débutant au bon fonctionnement avec les modules.

Scénario 1 : Le classique — oubli de spécifier tous les fichiers au lancement

Le cas le plus fréquent. Vous écrivez :

// main.go\npackage main\n\nfunc main() {\n    printHello() // Erreur : undefined: printHello\n}\n

// helper.go\npackage main\n\nimport "fmt"\n\nfunc printHello() {\n    fmt.Println("Hello!")\n}\n

Et vous lancez seulement go run main.go. Go ne voit pas helper.go, car vous ne l'avez pas explicitement spécifié. La bonne solution :

go run main.go helper.go\n// ou plus simplement :\ngo run .\n

Pourquoi ? Go ne scanne pas automatiquement le répertoire — vous devez lister tous les fichiers du package. La commande go run . exécute tout le dossier courant comme un seul package.

Scénario 2 : Packages différents — invisibilité par défaut

Un autre piège courant : tenter d'appeler une fonction d'un autre package sans import ni export.

// main.go\npackage main\n\nfunc main() {\n    helper.DoSomething() // Erreur : undefined: helper\n}\n

// helper/helper.go\npackage helper\n\nfunc DoSomething() {\n    // ...\n}\n

Ici, deux problèmes :

\n
• Les fichiers sont dans des packages différents (main et helper).
\n
• La fonction DoSomething n'est pas exportée (commence par une minuscule).
\n

Version corrigée :

// main.go\npackage main\n\nimport "yourmodule/helper"\n\nfunc main() {\n    helper.DoSomething() // Ça marche !\n}\n

// helper/helper.go\npackage helper\n\nfunc DoSomething() { // Majuscule !\n    // ...\n}\n

Retenez : En Go, seules les entités commençant par une majuscule sont exportées. Une minuscule signifie privé au package.

Scénario 3 : Problèmes avec les modules et GOPATH

Si vous utilisez l'ancien style (GOPATH) ou si vous avez mal initialisé votre module, Go peut ne pas trouver vos fichiers, même dans un même dossier.

Vérifiez :

\n
1. Y a-t-il un fichier go.mod à la racine du projet ? Sinon, créez-le : go mod init nom_du_module.
\n
2. Ne stockez-vous pas votre projet dans $GOPATH/src sans module ? C'est un mode legacy qui peut prêter à confusion.
\n
3. Assurez-vous que tous les fichiers du dossier ont le même package (sauf les fichiers de test avec le suffixe _test).
\n

Exemple de structure correcte :

myproject/\n├── go.mod          # module myproject\n├── main.go         # package main\n└── helper.go       # package main\n

Scénario 4 : Noms de fichiers avec underscores et fichiers de test

Go ignore les fichiers commençant par _ ou . (par exemple, _hidden.go). Les fichiers avec le suffixe _test.go ne sont compilés que lors de l'exécution des tests (go test). Si vous avez accidentellement nommé un fichier de travail helper_test.go, ses fonctions ne seront pas visibles dans le code principal.

Scénario 5 : Dépendances cycliques

Parfois, l'erreur « undefined » peut être la conséquence d'un import cyclique. Par exemple, le package A importe B, et B importe A. Go interdit ces cycles et m