Comme le titre l'indique, nous avons résumé les règles de dénomination dont les débutants d'autres langues devraient au moins se soucier.
Il est destiné à ceux qui comprennent la syntaxe de base de Go.
Explique les règles et conventions de dénomination des noms de fichiers Go, des noms de variables, etc.
Il existe plusieurs façons d'écrire Go dont vous devez être conscient, en dehors de la dénomination.
Cependant, ils ne sont pas traités dans cet article.
Il est programmeur depuis près de huit ans et possède de l'expérience dans les langues suivantes en plus de Go.
J'ai écrit Go il y a quelque temps, et je ne l'ai pas écrit pendant un moment, mais récemment je l'ai réécrit.
Au total, Go a environ un an et demi d'expérience.
Effective Go recommande un nom concis et clair.
Il est souhaitable de n'utiliser que des lettres minuscules et de se composer d'un seul mot (forme unique).
--Bon exemple
Cependant, il y a une exception.
C'est un modèle avec un suffixe _test.
Go n'autorise pas plusieurs noms de paquet dans le même répertoire, mais vous pouvez le faire avec _test.
Puisqu'il s'agira d'un package différent, vous ne pourrez pas faire référence à des méthodes privées, etc.
Cependant, il y a des avantages tels que d'éviter le problème de la référence circulaire en l'utilisant.
Il s'agit d'une technique également utilisée dans les packages standard.
//(Exemple) Test de paquet de tas, donc tas_Devenez un test
package heap_test
En outre, il est prudent de ne pas utiliser les noms suivants.
Ces noms sont des «noms concis», mais pas des «noms explicites».
Si vous vous demandez comment le nommer, c'est une bonne idée de faire référence au nom du package standard de Go.
Je n'ai pas trouvé la déclaration «Que dois-je faire avec le nom de fichier» dans les informations officielles de Go (veuillez me le faire savoir dans les commentaires s'il y en a un).
La dénomination des cas Snake est utilisée dans les packages OSS et standard bien connus tels que kubernetes et terraform. Il semble donc prudent de le suivre.
(Exemple)
addressed_types_test.goaddressed_types.goComme pour le nom du fichier, je n'ai pas trouvé de description de "quoi faire avec les informations officielles de Go" (veuillez me le faire savoir dans les commentaires s'il y en a une).
Pour cela, il est préférable de lui donner un nom en un mot qui soit aussi concis et clair que le nom du package.
Il semble donc correct de n'utiliser que des lettres minuscules.
Boîtiers Kebab (utilisez - pour séparer les mots" dans des OSS célèbres tels que kubernetes et terraform J'ai trouvé un modèle qui utilise).
Si vous voulez vraiment des sauts de mots, il peut être intéressant d'utiliser un étui à kebab.
(Exemple)
Je n'utilise pas d'étui kebab, mais j'essaie d'utiliser toutes les lettres minuscules.
En passant, peu importe si le nom du package et le nom du répertoire sont différents, mais il est plus sûr de les faire correspondre.
Nommez-le avec un étui de chameau.
Pour les fonctions et les structures exposées à l'extérieur, il existe une spécification de langage selon laquelle le début est en majuscule, de sorte que la casse supérieure du chameau (en commençant par la première majuscule) ou la casse inférieure du chameau (en commençant par la première minuscule) est déterminée en conséquence.
//Lors de la publication en dehors du package
func Contents(filename string) (string, error) {}
//Lors de l'utilisation uniquement dans l'emballage
func contents(filename string) (string, error) {}
Nom le plus court possible avec une ou deux lettres anglaises.
Si le type est «Client», alors «c», «cl», etc.
Le nom du récepteur doit être le même (il est NG si c ou cl est utilisé selon l'emplacement)
Il est également important de ne pas utiliser de modificateurs.
Par exemple, pour «httpClient», le nom du destinataire sera «c», et pour «DBCreator», ce sera «c».
Nous recommandons également des noms de variables courts.
Pour l'argument, vous pouvez utiliser un caractère comme le nom du récepteur.
Idéalement, le nom de la variable doit être aussi court que possible, mais soyez prudent avec la portée.
Si vous utilisez une fonction avec une grande portée et une variable courte, la lisibilité sera considérablement réduite.
Faites également attention aux abréviations.
Il n'y a aucun problème à utiliser les abréviations courantes parmi les programmeurs comme indiqué ci-dessous, mais si vous les abrégez de force et que les noms de variables n'ont pas de sens, la lisibilité diminuera.
Config → confString → strÀ mon avis, si vous ne pouvez pas trouver une bonne abréviation, il est prudent d'utiliser un nom de variable qui utilise normalement des mots anglais.
Ce n'est pas parce qu'un nom de variable court est recommandé que vous pouvez négliger la convention de dénomination, alors soyez prudent à ce sujet.
Si vous déclarez «error» comme variable, déclarez-la avec le préfixe «Err».
Ce n'est pas explicitement indiqué, mais sur le blog officiel de Go Working with Errors in Go 1.13 Vous pouvez voir un exemple d'utilisation des noms de variables.
En outre, Effective Go a également la description suivante.
// Error codes returned by failures to parse an expression.
var (
ErrInternal = errors.New("regexp: internal error")
ErrUnmatchedLpar = errors.New("regexp: unmatched '('")
ErrUnmatchedRpar = errors.New("regexp: unmatched ')'")
...
)
Au fait, la gestion des erreurs de Go vérifie «err» pour voir si l'erreur est «nulle» pour voir s'il y a des erreurs.
Par conséquent, beaucoup de code comme celui-ci sort.
data, err := ioutil.ReadFile(src)
if err != nil {
return nil, err
}
À ce stade, il est habituel de le recevoir avec le nom de variable «err».
Le préfixe «Err» n'est qu'une règle pour déclarer «erreur» en tant que variable, il n'est donc pas utilisé pour la gestion des erreurs comme décrit ci-dessus.
Comme mentionné dans l'article suivant, si vous limitez la portée de err dans la syntaxe if ou utilisez la méthode d'écriture en utilisant: =, vous pouvez faire la plupart des cas avec juste err. Je vais.
(Référence) [Explication de «Go les débutants doivent être prudents» Trop de variantes de noms de variables err (dans la plupart des cas, seul «err» est requis)](https://zenn.dev/nobonobo/articles/e0af4e8afc6c38b42ae1# % E3% 82% A8% E3% 83% A9% E3% 83% BC% E3% 83% 8F% E3% 83% B3% E3% 83% 89% E3% 83% AA% E3% 83% B3% E3 % 82% B0% E5% 91% A8% E3% 82% 8A)
Si vous constatez que vous ne pouvez pas simplement utiliser «err», vous pouvez utiliser le préfixe «Err».
À propos, des OSS célèbres tels que kubernetes et terraform adoptent la méthode utilisant le préfixe «Err». Je ne l'ai pas fait.
Il ne semble pas y avoir de règle claire sur ce qu'il faut faire dans ce domaine, il semble donc qu'il soit bon de l'ajuster pour chaque projet.
Il semble habituel d'utiliser le nom de variable «ok» lors de la vérification de l'existence d'une clé particulière, comme indiqué ci-dessous.
id, ok := users[userID]
Cela n'est spécifié nulle part, mais ce modèle est souvent utilisé dans les packages standard.
C'est le contenu décrit ci-dessous.
https://github.com/golang/go/wiki/CodeReviewComments#initialisms
La dénomination de Go est essentiellement un cas de chameau, mais les mots qui sont à l'origine omniprésents en tant qu'abréviations utilisent des majuscules et des minuscules cohérentes.
Utilisez URL au lieu de url, ou utilisez HTTP au lieu de http.
À mon avis, il était difficile au début de comprendre cette règle.
Par exemple, je ne savais pas si des mots tels que «GitHub» et «Twitter» ne devraient pas être utilisés avec «github» et «twitter».
Il y a une partie qui vérifie cette notation avec un outil appelé golangci-lint, mais les mots couverts sont les suivants.
(Partie applicable, extrait ci-dessous). https://github.com/morix1500/lint/blob/master/lint.go#L743
var commonInitialisms = map[string]bool{
"ACL": true,
"API": true,
"ASCII": true,
"CPU": true,
"CSS": true,
"DNS": true,
"EOF": true,
"GUID": true,
"HTML": true,
"HTTP": true,
"HTTPS": true,
"ID": true,
"IP": true,
"JSON": true,
"LHS": true,
"QPS": true,
"RAM": true,
"RHS": true,
"RPC": true,
"SLA": true,
"SMTP": true,
"SQL": true,
"SSH": true,
"TCP": true,
"TLS": true,
"TTL": true,
"UDP": true,
"UI": true,
"UID": true,
"UUID": true,
"URI": true,
"URL": true,
"UTF8": true,
"VM": true,
"XML": true,
"XMPP": true,
"XSRF": true,
"XSS": true,
}
Je voudrais vérifier mécaniquement ces règles avec golangci-lint, mais vérifiez les mots tels que «gRPC» et «GraphQL» qui apparaissent souvent récemment. Cela ne semble pas être fait.
En outre, certains outils qui génèrent automatiquement du code Go peuvent également générer du code qui ignore cette règle.
J'ai désactivé cette règle dans golangci-lint et je l'ai unifiée pour qu'elle soit nommée dans le cas normal du chameau.
J'ai fait référence aux informations suivantes lors de la rédaction de cet article.
J'ai résumé la convention de dénomination de Go.
Vous pouvez vérifier certaines des règles listées ici à golangci-lint.
Il est encore en construction, mais dans le futur j'écrirai sur les paramètres de golangci-lint.
Merci d'avoir lu jusqu'au bout.