Quelles sont les conventions relatives aux noms de fichiers dans Go?

114

J'ai pu trouver les conventions pour nommer les paquets dans Go: pas de trait de soulignement entre les mots, tout en minuscules.

Cette convention s'applique-t-elle également aux noms de fichiers?

Mettez-vous également une structure dans un fichier comme si vous le faisiez pour une classe java et nommez-vous le fichier après la structure?

Actuellement, si j'ai un struct WebServer, je le mets dans un fichier web_server.go.

go naming-conventions

— David
source

3

AFAIK il n'y a pas de convention mais les suffixes _ peuvent avoir une sémantique spéciale à l'avenir, je recommande donc de les éviter.

— fuz

127

Il y a quelques directives à suivre.

Noms de fichiers commençant par "." ou "_" sont ignorés par l'outil aller
Les fichiers avec le suffixe _test.gosont uniquement compilés et exécutés par l' go testoutil.
Les fichiers avec des suffixes spécifiques à l'OS et à l'architecture suivent automatiquement ces mêmes contraintes, par exemple name_linux.gone seront construits que sur Linux, name_amd64.gone seront construits que sur amd64. C'est la même chose que d'avoir une //+build amd64ligne en haut du fichier

Consultez la documentation de l' go buildoutil pour plus de détails: https://golang.org/pkg/go/build/

— JimB
source

3

Où est-ce documenté? Merci!

— Abhijeet Rastogi

2

@AbhijeetRastogi: golang.org/pkg/go/build et golang.org/cmd/go

— JimB

3

Que dois-je faire si je veux construire pour unixet others. Par exemple, je peux créer deux fichiers file_windows.goet file_others.go. Ça fonctionne bien. Mais pour file_unix.goet file_others.goça ne marche pas. Je ne veux pas créer huit fichiers darwin freebsg linux openbsd netbsd dragonfly solaris android.

— Ivan Black

3

@Fire: les noms de fichiers sont généralement tous en minuscules en cas de casse, à la fois pour la cohérence et pour les systèmes avec des systèmes de fichiers insensibles à la casse.

— JimB

1

Pour toute personne ayant la même question que @IvanBlack, cela peut être accompli en utilisant des balises de construction. Voir ici pour un bon aperçu de la façon de faire cela: dave.cheney.net/2013/10/12/…

— Ian Gustafson

30

En plus de la réponse fournie par JimB , les noms de fichiers normaux sont en minuscules, courts et sans aucune sorte de trait de soulignement ou d'espace. En général, les noms de fichiers suivent la même convention que les noms de packages. Consultez la section Noms des packages de Effective Go .

Voir le package strconv pour un bon exemple.

— Zamicol
source

3

qu'avez-vous donné un nom aux fichiers longs? mycommandsub1command.goou my_command_sub1command.go, et qu'en est-ilmycommandVO

— user2727195

9

Je suggérerais des traits de soulignement pour les noms longs. J'ai vu cela dans quelques bons projets.

— Avi

17

Go est assez libéral en ce qui concerne la façon dont vous organisez votre code dans un package, généralement c'est ce qui améliore la lisibilité et la compréhension de votre code. La meilleure façon d'apprendre comment cela est fait est d'étudier les maîtres, c'est-à-dire de parcourir la bibliothèque standard:

http://golang.org/src/pkg/

Il y a 2 règles auxquelles je peux penser cependant. Lorsque vous spécifiez du code à compiler pour différentes plates-formes, vous utilisez le nom de la plate-forme comme suffixe:

mypkg_linux.go         // only builds on linux systems
mypkg_windows_amd64.go // only builds on windows 64bit platforms

De plus, si vous avez un fichier appelé server.go, les tests pour ce fichier seraient au format server_test.go.

— Matt Harrison
source

3

Dans le lien que vous avez fourni, j'ai trouvé des cas d'utilisation avec le trait de soulignement: golang.org/src/pkg/compress/bzip2/move_to_front.go , golang.org/src/pkg/compress/flate/huffman_bit_writer.go , golang.org/ src / pkg / compress / flate / reverse_bits.go .

— david

1

Je suppose qu'ils n'utiliseront pas _front, _writerou _bitscomme suffixes significatifs dans le futur alors!

— Matt Harrison

J'adore Go, mais l' gooutil est très restrictif sur la structure des packages (c'est l'une de mes choses préférées à propos du langage). Il favorise certaines conventions très spécifiques (un package par dossier [avec au moins une exception], le package du dossier partage le même nom que le dossier [avec au moins une exception], le chemin d'importation complet du package correspond au chemin relatif de $GOPATH, certains fichiers sont traités différemment selon le format de leur nom, etc.)

— weberc2

1

@ weberc2 Les restrictions sont analogues à Latex. Tout d'abord, je voulais contrôler ma mise en page et d'autres détails non pertinents, jusqu'à ce que je réalise que tout ce qui doit être écrit est un bon contenu. De même, Go nous permet d'écrire du bon code et gère d'autres détails pour nous.

— david

@david Je suis d'accord. Rétrospectivement, je n'étais pas clair: je répondais à la déclaration du répondant Go is quite liberal in terms of how you organise your code within a package. Go n'est pas libéral, c'est assez restrictif. Mais c'est une bonne chose.

— weberc2

8

Habituellement, les traits de soulignement dans les noms de fichiers sont utilisés pour attribuer du code de plate-forme / arch uniquement, par exemple:

➜ cd $GOROOT/src/pkg/math/
➜ ls sqrt*s
sqrt_386.s  sqrt_amd64p32.s  sqrt_amd64.s  sqrt_arm.s

sqrt_386.sne sera lu par le compilateur que sur les processeurs 32 bits, sqrt_amd64.ssur amd64, etc.

Il peut s'agir de l'une des valeurs valides de GOOSet / ou GOARCH( réf .

file_windows_amd64.go ne sera compilé que sur win64.

— OneOfOne
source