Prácticas recomendadas de Go Fundamentals
Hábitos centrales que todo desarrollador de Go debería internalizar primero.
//
Busca en todas las páginas de la documentación
Hábitos centrales que todo desarrollador de Go debería internalizar primero.
Estas reglas refuerzan los fundamentos de la sección: nombres claros, manejo explícito de errores en los límites y colecciones usadas con su semántica real.
gofmt, go vet y golangci-lint para detectar violaciones automáticamente.i y err están bien en bucles; las API exportadas merecen nombres descriptivos.:= dentro de las funciones cuando el tipo sea obvio. Reserve var para declaraciones a nivel de paquete y valores cero intencionales.iota. Evite números mágicos dispersos en la lógica; nombre los estados y las banderas explícitamente.make o literales antes de escribir. Nunca asigne a un mapa nil.len(string) como longitud de bytes, no como recuento de caracteres. Use range o utf8.RuneCountInString para texto visible por el usuario.make([]T, 0, n) reduce las asignaciones en bucles intensivos.append. s = append(s, x) porque append puede devolver una cabecera nueva.main delgado; ponga la lógica en paquetes importables. Un módulo puede alojar puntos de entrada cmd/ y código de biblioteca uno al lado del otro.internal/ para código que no debe filtrarse entre módulos. Deje que el compilador imponga los límites en lugar de solo comentarios.go fmt ./... antes de cada commit. El formato consistente elimina los debates de estilo en la revisión.go test ./... y go vet ./... en CI. Los errores fundamentales deben fallar rápidamente en la automatización.go.mod y confirme go.sum. Las compilaciones reproducibles comienzan con un grafo de módulos limpio.No, las structs pequeñas son más baratas por valor.
Use punteros para mutación, campos opcionales o costo de copia probado.
Las constantes y las variables de solo lectura están bien.
El estado mutable del paquete necesita sincronización y perjudica la capacidad de prueba; evítelo a menos que esté envolviendo primitivas de sync por diseño.
Raramente: tamaños de cable fijos, bloques criptográficos o restricciones incrustadas.
Predetermine slices para el código de la aplicación.
Incorpore cuando el tipo externo exponga genuinamente el comportamiento incrustado (Server registra a través de Logger incrustado).
Use campos nombrados cuando la relación sea "tiene-un", no "se-comporta-como".
append puede reasignar y devolver una cabecera de slice diferente.
Ignorar el resultado lo deja apuntando a capacidad o datos obsoletos.
Los retornos nombrados ayudan a la documentación en funciones pequeñas; evítelos cuando oscurezcan la claridad.
El código de fundamentos debe favorecer return x, err explícito.
Pase las variables del bucle como parámetros de función.
En Go 1.22+, las variables por iteración reducen el riesgo, pero los parámetros explícitos siguen siendo los más claros.
cmd/<app>/main.go contiene los ejecutables; el código de la biblioteca vive en paquetes importables en la raíz del módulo o en pkg/ según la convención del equipo.
Los slices nil a menudo se codifican como null; los slices vacíos como [].
Elija intencionalmente para los contratos de API y documente la elección.
Siempre que el código no deba ser importado por otros módulos: ayudantes vinculados a un producto, no a un SDK público.
Solo cuando se requieran validación o invariantes.
Prefiera valores cero útiles para structs de configuración simples.
Habilite linters como govet, staticcheck y errcheck para aplicar muchos de estos hábitos automáticamente en CI.
makeVersiones de la pila: Esta página fue escrita para Go 1.26.x (predeterminado de GC Green Tea, go fix modernizers - verifique el parche en la compilación), chi (última versión - verifique en la compilación), gin (última versión - verifique en la compilación), echo (última versión - verifique en la compilación), google.golang.org/grpc (última versión - verifique en la compilación), sigs.k8s.io/controller-runtime (última versión - verifique en la compilación), kubebuilder (última versión - verifique en la compilación), tinygo (última versión - verifique los objetivos de la placa en la compilación), wazero (última versión - verifique en la compilación) y golangci-lint (última versión - verifique el conjunto de linters en la compilación).
Revisado por Chris St. John·Última actualización: 19 jul 2026