Al escribir un paquete único destinado a ser utilizado como un comando, que es idiomático: nombre todos los identificadores como privados o nombre todos los identificadores como públicos.

Question

En Ir, los nombres públicos comienzan con una letra mayúscula y los nombres privados comienzan con una letra minúscula.

Estoy escribiendo un programa que no es una biblioteca y es un paquete único. ¿Hay algún modismo Go que estipule si mis identificadores deben ser públicos o privados? No planeo usar este paquete como biblioteca o como algo que deba importarse desde otro programa Go.

No puedo pensar en ninguna razón por la que quisiera una mezcla. Se "siente" como ir completamente privado es la elección correcta.

---

no creo que me dieron ninguna respuesta concreta, pero Nate estaba más cerca de mí diciendo que pensar en "exportar vs no exportadoras" en lugar de "pública y privada".

Esto me lleva a pensar que no exportar nada es el mejor enfoque. En el peor de los casos, si termino importando código de mi aplicación en otro paquete, tendré que replantear lo que debería exportarse y lo que no debería ser. Lo cual es algo bueno IMO.

Answer 1

Si está intentando ajustar su modo de pensar a ser más idiomático, debe dejar de pensar en variables, funciones y métodos como públicos o privados. El término más preciso se exporta o no se exporta. Definitivamente tiene una sensación más parecida a C.

Como otros han declarado, la exportación realmente no es necesaria para el código del programa de aplicación. Si por razones de organización decide dividir su programa en paquetes, podría usar subpaquetes. En el trabajo, hemos decidido hacer justamente esto. Tenemos:

projectgopath/src/projectname 
        projectname/subcomponent1 
        projectname/subcomponent2 

Hasta ahora realmente me ha gustado esta estructura. Ayuda a separar las preocupaciones, pero no llega al extremo de hacer un paquete fuera del proyecto principal. La intención es clara. El uso previsto del subpaquete es solo para este programa ...

Los nuevos comandos go build y go install parecen funcionar muy bien. Agrupamos componentes en paquetes y exponemos solo los bits necesarios a través de exportaciones.

Answer 2

En la situación descrita, ambos enfoques son igualmente válidos, por lo que se trata más o menos de preferencias personales. En mi caso estoy usando los identificadores camelCase para el paquete principal, principalmente por costumbre.

Answer 3

Muchos de mis archivos go comenzaron su vida en comandos aislados y se movieron a paquetes, ya que podían reutilizarse con unos pocos comandos sobre el mismo tema.

Creo que deberías hacer privado todo lo que no se puede llamar desde otro lugar (suponiendo que algún día lo conviertas en un paquete importable) y hacer públicas las grandes funciones que se pueden entender desde otro lugar (si las hay) y estructurar campos cuando son ortogonales (quiero decir cuando un cambio del valor de un campo no rompe la consistencia del valor de la estructura).