¿Qué forma de nombrar una función en Go, CamelCase o Semi-CamelCase?

Quiero escribir una función en Go para insertar un documento en una colección en una base de datos MongoDB. Qué forma de nombrar la función es mejor,

• writeToMongoDB o
• WriteToMongoD?

El segundo es CamelCase, mientras que vi a alguien usando el estilo del primero, así que no estoy seguro de cuál es el más apropiado. Gracias.

Sintaxis

En Go esto no es una cuestión de estilo, es una cuestión de sintaxis.

Los nombres exportados (es decir, los identificadores que se pueden usar desde un paquete diferente al que están definidos) comienzan con una letra mayúscula. Por lo tanto, si su método es parte de su API pública, debe escribirse:

WriteToDB

pero si es un método auxiliar interno, debería escribirse:

writeToDB

La ventaja de hacerlo de esta manera sobre el uso de palabras clave para definir exportedness ( extern, public, etc.) es que lo que es una parte de los que asegura nombre en cualquier lugar de un identificador se utiliza se puede decir si se exporta o no sin tener que encontrar donde se definió (para ver si la definición contiene una palabra clave).

Consulte también: Identificadores exportados de la especificación.

i18n

Debido a que Go está codificado en UTF-8 y admite cualquier carácter Unicode con la propiedad de letras o números en los nombres de los identificadores, algunas personas en configuraciones regionales que no tienen un concepto de caso pueden tener problemas para crear métodos exportados (el valor predeterminado es no exportado). En este caso (juego de palabras) es común anteponer identificadores con un Xpara indicar exportedness. Por ejemplo:X日本語

Consulte también: ¿Qué pasa con los identificadores Unicode? de las preguntas frecuentes.

Estilo

En cuanto al estilo general, es utilizar siempre camel-case (excepto la primera letra, como se mencionó anteriormente). Esto incluye constantes, funciones y otros identificadores. Entonces, por ejemplo, una lista de constantes (exportadas) podría verse así:

const (
    StateConnected = iota
    StateError
    StateDone

    internalStateMask = 0x2 
)

Además, las abreviaturas siempre se escriben con el mismo caso, por lo que debería escribir una de las siguientes:

dbWrite
writeDB

en lugar de writeDbo DbWrite.

En Go, es una convención utilizar cap mixtos. De los documentos: https://golang.org/doc/effective_go.html#mixed-caps

Finalmente, la convención en Go es usar MixedCaps o mixedCaps en lugar de guiones bajos para escribir nombres de varias palabras.

Tenga en cuenta que los nombres de nivel de archivo que comienzan con Mayúscula se exportan a nivel de paquete: https://golang.org/doc/effective_go.html#Getters

Además, es una convención escribir siglas en mayúsculas. Así que a continuación está bien:

writeToMongoDB // unexported, only visible within the package

o

WriteToMongoDB // exported

Y no:

writeToMongoDb

Nombres

Los nombres son tan importantes en Go como en cualquier otro idioma. Incluso tienen efecto semántico: la visibilidad de un nombre fuera de un paquete está determinada por si su primer carácter está en mayúsculas . Por lo tanto, vale la pena dedicar un poco de tiempo a hablar sobre las convenciones de nomenclatura en los programas Go.

Nombres de paquetes

Cuando se importa un paquete, el nombre del paquete se convierte en un acceso al contenido. Después

import "bytes" el paquete de importación puede hablar de bytes.Buffer. Es útil si todos los que usan el paquete pueden usar el mismo nombre para referirse a su contenido, lo que implica que el nombre del paquete debe ser bueno: corto, conciso, evocador. Por convención, los paquetes reciben nombres de una sola palabra en minúsculas; no debería haber necesidad de guiones bajos o mayúsculas mixtas. Erra por el lado de la brevedad, ya que todos los que usen su paquete escribirán ese nombre. Y no te preocupes por las colisiones a priori. El nombre del paquete es solo el nombre predeterminado para las importaciones; no es necesario que sea único en todo el código fuente y, en el raro caso de una colisión, el paquete de importación puede elegir un nombre diferente para usarlo localmente. En cualquier caso, la confusión es poco común porque el nombre del archivo en la importación determina qué paquete se está utilizando.

Otra convención es que el nombre del paquete es el nombre base de su directorio fuente; el paquete en src / encoding / base64 se importa como "encoding / base64" pero tiene el nombre base64, no encoding_base64 y no encodingBase64.

El importador de un paquete usará el nombre para referirse a su contenido, por lo que los nombres exportados en el paquete pueden usar ese hecho para evitar tartamudeos. (No use la notación import., Que puede simplificar las pruebas que deben ejecutarse fuera del paquete que están probando, pero que de lo contrario deberían evitarse). Por ejemplo, el tipo de lector almacenado en búfer en el paquete bufio se llama Reader, no BufReader, porque los usuarios lo ven como bufio.Reader, que es un nombre claro y conciso. Además, debido a que las entidades importadas siempre se direccionan con su nombre de paquete, bufio.Reader no entra en conflicto con io.Reader. De manera similar, la función para crear nuevas instancias de ring.Ring, que es la definición de un constructor en Go, normalmente se llamaría NewRing, pero dado que Ring es el único tipo exportado por el paquete, y dado que el paquete se llama ring, ' s llamado simplemente New, que los clientes del paquete ven como ring.New. Utilice la estructura del paquete como ayuda para elegir buenos nombres.

Otro breve ejemplo es once.Do; once.Do (configuración) se lee bien y no se mejoraría escribiendo once.DoOrWaitUntilDone (configuración). Los nombres largos no hacen que las cosas sean más legibles automáticamente. Un comentario de documento útil a menudo puede ser más valioso que un nombre extralargo .

Getters

Go no proporciona soporte automático para getters y setters. No hay nada de malo en proporcionar getters y setters usted mismo, y a menudo es apropiado hacerlo, pero no es idiomático ni necesario poner Get en el nombre del getter. Si tiene un campo llamado propietario (minúsculas , no exportado), el método getter debe llamarse Propietario (mayúsculas, exportado), no GetOwner . El uso de nombres en mayúsculas para la exportación proporciona el gancho para discriminar el campo del método. Una función de establecimiento, si es necesaria, probablemente se llamará SetOwner . Ambos nombres se leen bien en la práctica:

owner := obj.Owner()
if owner != user {
    obj.SetOwner(user)
}

Nombres de interfaz

Por convención, las interfaces de un método son nombrados por el nombre del método más un sufijo -er o modificación similar a la construcción de un agente sustantivo: Lector, escritor, formateador, CloseNotifier etc .

Hay varios nombres de este tipo y es productivo honrarlos y los nombres de funciones que capturan. Leer, Escribir, Cerrar, Flush, String, etc. tienen firmas y significados canónicos. Para evitar confusiones, no le dé a su método uno de esos nombres a menos que tenga la misma firma y significado. Por el contrario, si su tipo implementa un método con el mismo significado que un método en un tipo conocido, asígnele el mismo nombre y firma; llame a su método de conversión de cadenas String no ToString .

MixedCaps

Finalmente, la convención en Go es usar MixedCaps o mixedCaps en lugar de guiones bajos para escribir nombres de varias palabras .

ref: Go eficaz

En Golang, cualquier variable (o función) con un identificador que comience con una letra mayúscula (ejemplo, CamelCase) se hace pública (accesible) para todos los demás paquetes de su programa, mientras que aquellos que comienzan con una letra minúscula (ejemplo , camelCase) no es accesible para ningún paquete excepto en el que se declara.

Debe usar CamelCase en caso de que tenga la intención de usar la variable (o función) en otro paquete, o puede seguir con camelCase.