Go-caballeros: Code Style y convenciones para el trabajo en equipo

¿Por qué incluso un código genial puede arruinar un proyecto?

Imagina: escribes en Go. El código funciona rápido, las pruebas pasan y la producción es estable. Pero el lunes llega un nuevo desarrollador, abre tu módulo y... se queda atónito. Las variables se llaman x1, data2, tmp. Las funciones — func1, process. Los imports están desordenados. El código compila, pero entenderlo es una tarea complicada.

¿Te suena esta situación? Si trabajas en equipo, el code style y las convenciones para Go no son un capricho del linter, sino tu lenguaje común. Sin él, incluso el desarrollador más talentoso se convierte en un "jugador solitario" que frena a todo el equipo. En este artículo, veremos cómo escribir en Go para que tu código sea leído, entendido y amado por tus colegas. Y también, cómo no caer en la trampa de "rápido pero sucio".

Go se trata de simplicidad. Pero la simplicidad hay que acordarla

El lenguaje Go fue creado pensando en el trabajo en equipo. No en vano, Rob Pike y Ken Thompson incorporaron la idea de "legibilidad ante todo". Sin embargo, incluso en Go se puede escribir código que funcione, pero que dé ganas de reescribirlo desde cero.

Analicemos los bloques clave que transforman el caos en un sistema ordenado.

1. gofmt — tu primer amigo y aliado

Go tiene una herramienta de formateo incorporada: gofmt. No es solo "estética". Es un estándar. Si no usas gofmt, estás violando la convención. Punto.

Ejemplo: imagina que un desarrollador usa tabulaciones para las sangrías y otro, espacios. En Go, este problema está resuelto de una vez por todas. gofmt unifica el código. Ejecútalo antes de cada commit. Mejor aún, configura un pre-commit hook.

// Mal (sin gofmt)\nfunc add(a int,b int) int {\nreturn a+b\n}\n\n// Bien (después de gofmt)\nfunc add(a, b int) int {\n    return a + b\n}\n

Consejo: En los IDE modernos (VS Code, GoLand), gofmt se ejecuta automáticamente al guardar. Revisa la configuración: te ahorrará horas de code review.

2. Nomenclatura: habla el lenguaje del dominio

Go fomenta nombres cortos. Pero corto no significa sin sentido. La regla es simple: cuanto mayor sea el ámbito de visibilidad, más largo debe ser el nombre.

\n
• Variables locales (dentro de una función) — 1-2 caracteres: i, j, s, err.
\n
• Parámetros de función — con significado, pero breves: ctx, req, db.
\n
• Funciones y tipos exportados — nombres completos: CreateUser, UserService.
\n

Ejemplo malo:

func p(u string, pwd string) bool {\n    return u == "admin" && pwd == "12345"\n}\n

Ejemplo bueno:

func IsValidCredentials(username, password string) bool {\n    return username == "admin" && password == "12345"\n}\n

Observa: IsValidCredentials no es solo un nombre, es documentación. Otro desarrollador entenderá de inmediato qué hace la función, sin necesidad de mirar su cuerpo.

3. Imports: el orden es la clave de la tranquilidad

En Go, los imports se dividen en tres grupos:

\n
1. Librería estándar (fmt, net/http, os).
\n
2. Paquetes externos (github.com/xxx).
\n
3. Paquetes internos (tu proyecto).
\n

Entre grupos, una línea en blanco. Esta es una regla tácita pero estricta. gofmt no la verifica, pero el code review sí.

import (\n    "fmt"\n    "os"\n\n    "github.com/gorilla/mux"\n    "github.com/lib/pq"\n\n    "yourproject/internal/config"\n    "yourproject/internal/handler"\n)\n

¿Por qué es importante? Cuando los imports están desordenados, pierdes tiempo buscando un paquete. Un orden uniforme acelera la lectura del código.

4. Comentarios: no escr