Lista de Verificación de Reglas de Go Efectivo
Veinticinco reglas destiladas de Effective Go y la práctica comunitaria.
//
Busca en todas las páginas de la documentación
Veinticinco reglas destiladas de Effective Go y la práctica comunitaria.
Recorre esta lista al incorporarte, auditar un paquete o convertir comentarios de revisión repetidos en política de equipo.
gofmt en cada commit: El código sin formato nunca se merge; gofmt -w es la única herramienta de estilo.
test -z "$(gofmt -l .)" en CIgoimports para higiene de importaciones: Las importaciones faltantes y no utilizadas fallan la revisión igual que los bugs de lógica.
Verificar cada retorno de error: No usar _ silenciosamente en errores, excepto en casos deliberados y documentados.
if err != nil en cada llamada falibleEnvolver con contexto usando %w: Los llamadores necesitan errors.Is/errors.As a través de la pila.
fmt.Errorf("failed") sin envolver al inspeccionar centinelasManejar errores una sola vez: Registrar o devolver o traducir a estado HTTP/gRPC - no los tres.
Usar nombres cortos en ámbitos pequeños: i, err, ctx están bien en bucles; los nombres exportados se mantienen descriptivos.
Preferir := dentro de funciones: Usar var para valores cero a nivel de paquete y claridad de tipo intencional.
Ejecutar go vet en cada PR: vet apunta a posibles errores, no a preferencias.
go vet ./... en verde en CIExportar solo superficies estables: Los identificadores en mayúsculas son promesas de compatibilidad bajo semver.
Godoc para cada símbolo exportado: Los comentarios comienzan con el nombre del símbolo y describen el comportamiento.
go doc / pkg.go.dev renderiza la documentación completa del paqueteAceptar interfaces, devolver structs: Los parámetros se mantienen flexibles; los retornos se mantienen concretos a menos que el envoltorio sea explícito.
func Load(r io.Reader) (*Config, error)Definir interfaces en los consumidores: Los productores devuelven tipos concretos; los llamadores declaran interfaces mínimas.
type Reader interface { Read... } en el paquete productor "para extensibilidad"Preferir composición sobre incrustación para el comportamiento: Incrustar para reenvío; no simular jerarquías de herencia.
Hacer que los valores cero sean útiles cuando sea posible: Los llamadores no siempre necesitan constructores para tipos simples.
Usar receptores de puntero al mutar: Receptores de valor para tipos inmutables pequeños; mantenerse consistente por tipo.
Pruebas basadas en tablas con subpruebas: Codificar casos como datos; nombrar filas con t.Run.
Ejemplos en example_test.go para bibliotecas: La documentación ejecutable aparece en pkg.go.dev.
cmd/ internoInicializar mapas antes de escribir: make(map[K]V) o literales; nunca asignar a mapas nil.
panic: assignment to entry in nil mapAsignar resultados de append: s = append(s, x) porque la capacidad puede reasignarse.
make([]T, 0, n) cuando se conoce el tamañoCopiar variables de bucle al lanzar goroutines: Capturar variables de bucle explícitamente en cierres cuando sea necesario (patrones antiguos) o confiar en la semántica de Go 1.22+ y aún así probar con -race.
go test -racePasar context como primer parámetro: Nombrarlo ctx; propagar a IO y RPC.
context.Context en structsNo usar panic para flujo de control: Los panic son para errores de programador y fallos de init, no para errores esperados.
Mantener los paquetes main delgados: main conecta dependencias; la lógica vive en bibliotecas.
cmd/ + paquetes reutilizablesUsar internal/ para paquetes no públicos: Los límites impuestos por el compilador superan a los comentarios solos.
internal/Etiquetar módulos con semver intencional: Los cambios de API que rompen el código incrementan la versión mayor en v1+ a través de una nueva ruta de módulo o un directorio de versión mayor.
go mod tidy limpio en CISuficiente cobertura para la incorporación sin duplicar hojas de trucos especializadas de seguridad y rendimiento.
Promover fallos repetidos en ADRs de equipo.
Formato, algunas comprobaciones de errores (errcheck), estilo de receptor (revive) y comentarios de exportación.
El diseño de interfaces y los límites de los paquetes siguen siendo de revisión humana.
La mayoría de las reglas de Nivel 1-2 se aplican.
La concurrencia y los subconjuntos de stdlib difieren; delimitar listas de verificación por etiqueta de compilación.
Cada elemento se mapea a una sección de Effective Go más los valores predeterminados operativos de la comunidad.
Lee primero la página explicativa para obtener contexto de capas.
Documentar la excepción con benchmarks en el PR.
Las reglas asumen claridad primero; las rutas críticas pueden justificar la desviación.
Automatizar el Nivel 1.
Usar los Niveles 2-3 como tarjetas de repaso durante el primer mes.
Al incorporar, auditorías trimestrales y después de actualizaciones menores de Go que agreguen verificaciones de vet.
Sí, agrégala a tu conjunto de ADRs.
Mantén esta página alineada con los modismos portátiles de Go, no con las elecciones exclusivas de la organización.
Usar solo para registro de efectos secundarios (controladores database/sql, formatos image).
Documentar el porqué en un comentario; evitar importaciones en blanco por conveniencia.
No directamente.
Dividir cuando las pruebas no puedan cubrir las ramas o los revisores no puedan seguir el flujo de control.
Preferir parámetros de tipo restringidos sobre interface{} cuando la capacidad se conoce.
Las interfaces pequeñas siguen siendo válidas en los límites de integración.
Ejecuta los ejemplos de Conceptos Básicos de Calidad de Código localmente, luego habilita los mismos objetivos en CI.
Versiones de Stack: Esta página fue escrita para Go 1.26.x (predeterminado de GC Green Tea,
go fixmodernizadores - verificar parche en la compilación), chi (última versión - verificar en la compilación), gin (última versión - verificar en la compilación), echo (última versión - verificar en la compilación), google.golang.org/grpc (última versión - verificar en la compilación), sigs.k8s.io/controller-runtime (última versión - verificar en la compilación), kubebuilder (última versión - verificar en la compilación), tinygo (última versión - verificar objetivos de placa en la compilación), wazero (última versión - verificar en la compilación) y golangci-lint (última versión - verificar conjunto de linters en la compilación).
Revisado por Chris St. John·Última actualización: 16 jul 2026