De quelle manière nommer une fonction dans Go, CamelCase ou Semi-CamelCase?
Je veux écrire une fonction dans Go pour insérer un document dans une collection dans une base de données MongoDB. Quelle manière de nommer la fonction est la meilleure,
writeToMongoDBouWriteToMongoD?
Le second est CamelCase, alors que je voyais quelqu'un utiliser le style du premier, je ne suis donc pas sûr de celui qui convient le mieux. Merci.
Syntaxe
Dans Go, ce n’est pas une question de style, c’est une question de syntaxe.
Les noms exportés (c'est-à-dire les identificateurs pouvant être utilisés à partir d'un package autre que celui où ils sont définis) commencent par une lettre majuscule. Ainsi, si votre méthode fait partie de votre API publique, vous devez écrire:
WriteToDB
mais si c'est une méthode d'assistance interne, il faut écrire:
writeToDB
L’avantage de le faire de cette manière par rapport à l’utilisation de mots-clés pour définir le caractère exporté (extern, public, etc.) est que, si vous en indiquez une partie dans le nom, vous pouvez savoir s'il est exporté ou non sans avoir à trouver où il a été défini (pour voir si la définition contient un mot clé).
Voir aussi: Identifiants exportés de la spéc.
i18n
Comme Go est codé en UTF-8 et prend en charge tous les caractères Unicode avec la propriété lettres ou chiffres dans les noms d’identificateur, certaines personnes dans les paramètres régionaux qui n’ont pas de concept de casse peuvent rencontrer des difficultés pour créer des méthodes exportées (la valeur par défaut est non exportée). Dans ce cas (jeu de mots voulu), il est courant de préfixer les identifiants avec un X pour indiquer leur exportation. Par exemple: X日本語
Voir aussi: Qu'est-ce qui se passe avec les identifiants Unicode? ) de la FAQ.
Style
En ce qui concerne le style général, il est toujours recommandé d'utiliser la casse du chameau (à l'exception de la première lettre, comme mentionné précédemment). Cela inclut les constantes, les fonctions et d’autres identificateurs. Ainsi, par exemple, une liste de constantes (exportées) pourrait ressembler à ceci:
const (
StateConnected = iota
StateError
StateDone
internalStateMask = 0x2
)
De plus, les abréviations sont toujours écrites avec le même cas, vous pouvez donc écrire l'un des éléments suivants:
dbWrite
writeDB
au lieu de writeDb ou DbWrite.
En Go, il est de convention d'utiliser des capsules mixtes. De la documentation: https://golang.org/doc/effective_go.html#mixed-caps
Enfin, la convention dans Go consiste à utiliser MixedCaps ou mixedCaps plutôt que des traits de soulignement pour écrire des noms de plusieurs mots.
Notez que les noms de fichiers commençant par une majuscule sont exportés au niveau du package: https://golang.org/doc/effective_go.html#Getters
En outre, il est habituel d'écrire des acronymes en majuscules. Donc ci-dessous c'est bien:
writeToMongoDB // unexported, only visible within the package
ou
WriteToMongoDB // exported
Et pas:
writeToMongoDb
Des noms
Les noms sont aussi importants dans Go que dans toute autre langue. Ils ont même un effet sémantique: la visibilité d'un nom en dehors d'un package est déterminée par le caractère majuscule ou non de son premier caractère . Il est donc utile de passer un peu de temps à parler de conventions de nommage dans les programmes Go.
Noms de paquets
Lorsqu'un package est importé, le nom du package devient un accesseur pour le contenu. Après
import "octets", le package d'importation peut parler d'octets.Buffer. Il est utile que toutes les personnes utilisant le paquet puissent utiliser le même nom pour faire référence à son contenu, ce qui implique que le nom du paquet doit être bon: bref, concis, évocateur. Par convention, les paquets ont un nom en minuscule, un seul mot; il ne devrait pas y avoir besoin de traits de soulignement ou de mixedCaps . Err du côté de la brièveté, puisque tout le monde utilisant votre paquet va taper ce nom. Et ne vous inquiétez pas des collisions a priori. Le nom du package est uniquement le nom par défaut pour les importations; il n'a pas besoin d'être unique dans tout le code source et, dans les rares cas de collision, le package d'importation peut choisir un nom différent à utiliser localement. Dans tous les cas, la confusion est rare car le nom du fichier dans l'importation détermine uniquement le package utilisé.
Une autre convention est que le nom du paquet est le nom de base de son répertoire source; le paquetage dans src/encoding/base64 est importé sous le nom "encoding/base64" mais porte le nom base64, pas encoding_base64 ni encodingBase64.
L'importateur d'un package utilisera le nom pour faire référence à son contenu, de sorte que les noms exportés dans le package peuvent utiliser ce fait pour éviter le bégaiement. (N'utilisez pas la notation import., Qui peut simplifier les tests devant s'exécuter en dehors du package qu'ils testent, mais qu'il faudrait sinon éviter.) Par exemple, le type de lecteur mis en mémoire tampon dans le package bufio s'appelle Reader, pas BufReader, car les utilisateurs le voient comme bufio.Reader, qui est un nom clair et concis. De plus, étant donné que les entités importées sont toujours adressées avec leur nom de package, bufio.Reader n'entre pas en conflit avec io.Reader. De même, la fonction permettant de créer de nouvelles occurrences de ring.Ring - qui correspond à la définition d’un constructeur dans Go - s’appellera normalement NewRing. Toutefois, Ring étant le seul type exporté par le package, il s’appelle ring. appelé juste Nouveau, quels clients du paquet voient comme ring.New. Utilisez la structure de package pour vous aider à choisir les bons noms.
Un autre exemple court est une fois.Do; once.Do (installation) lit bien et ne serait pas amélioré en écrivant une fois.DoOrWaitUntilDone (installation). Les noms longs ne rendent pas automatiquement les choses plus lisibles. Un commentaire doc utile peut souvent être plus précieux qu'un nom extra long .
Getters
Go ne fournit pas de support automatique pour les getters et les setters. Il n'y a rien de mal à fournir soi-même des accesseurs et des setters, et il est souvent approprié de le faire, mais il n'est ni idiomatique ni nécessaire de mettre Get dans le nom de getter. Si vous avez un champ appelé propriétaire (minuscule, non exporté), , la méthode de lecture doit s'appeler Propriétaire (majuscule, exportée), et non pas GetOwner . L'utilisation de noms en majuscules pour l'exportation fournit le raccord permettant de distinguer le champ de la méthode. Une fonction de définition, si nécessaire, sera probablement appelée SetOwner . Les deux noms se lisent bien dans la pratique:
owner := obj.Owner()
if owner != user {
obj.SetOwner(user)
}
Noms d'interface
Par convention, les interfaces à une méthode sont nommées par le nom de la méthode plus un suffixe -er ou une modification similaire pour construire un nom d'agent: Lecteur, Écrivain, Formateur, CloseNotifier, etc. .
Il existe un certain nombre de noms de ce type et il est productif de les honorer et de nommer les noms de fonction qu'ils capturent. Les signatures et significations canoniques sont lues, écrites, fermées, vidées, sur des chaînes, etc. Pour éviter toute confusion, ne donnez à votre méthode l’un de ces noms que si elle a la même signature et la même signification. Inversement, si votre type implémente une méthode ayant la même signification que la méthode d’un puits. -connu, donnez-lui le même nom et la même signature; appelez votre méthode de conversion de chaîne String not ToString .
MixedCaps
Enfin, la convention dans Go consiste à utiliser MixedCaps ou mixedCaps plutôt que des traits de soulignement pour écrire des noms de plusieurs mots .
ref: Effective Go
Dans Golang, toute variable (ou fonction) avec un identifiant commençant par une lettre majuscule (exemple, CamelCase) est rendue publique (accessible) à tous les autres packages de votre programme, tandis que celles commençant par une lettre minuscule (exemple). , camelCase) n’est accessible à aucun paquet, à l’exception de celui pour lequel il est déclaré.
Vous devez utiliser CamelCase si vous souhaitez utiliser la variable (ou la fonction) dans un autre package, ou si vous pouvez vous en tenir à CamelCase en toute sécurité.