Clean Code en Go: principios para escribir código legible

Clean Code en Go: principios para escribir código legible y mantenible

El código limpio no es un lujo, sino una necesidad para cualquier proyecto serio. En el lenguaje Go, que se destaca por su simplicidad y concisión, los principios de Clean Code son especialmente importantes. El código mal escrito en Go rápidamente se vuelve ilegible y difícil de mantener, a pesar de todas las ventajas del lenguaje. En este artículo analizaremos los principios fundamentales para escribir código limpio en Go con ejemplos concretos.

1. Nomenclatura correcta: la base de la legibilidad

En Go se aplica la regla: cuanto menor sea el ámbito de visibilidad, más corto debe ser el nombre. Sin embargo, esto no significa que debamos usar variables de una sola letra en todas partes. Veamos ejemplos.

Malo (código ilegible):

func f(x int, y int) int {    z := x + y    return z}

Bueno (código limpio):

func Sum(a int, b int) int {    result := a + b    return result}

Reglas importantes de nomenclatura en Go:

• Variables: use camelCase (por ejemplo, userName, totalCount)
• Funciones y tipos exportados (públicos): con mayúscula inicial — func CalculateTax()
• No exportados (privados): con minúscula inicial — func parseInput()
• Abreviaturas: escríbalas en mayúsculas (por ejemplo, HTTPHandler, no HttpHandler)
• Evite la notación húngara: no escriba strName o intCount — el tipo ya es evidente

2. Manejo de errores: explícito y conciso

Go no utiliza excepciones — los errores se devuelven como valores. El código limpio requiere un manejo explícito de cada error. ¡No los ignore!

Malo (ignorar el error):

file, _ := os.Open("data.txt")// ¡Error perdido!

Bueno (manejo explícito):

file, err := os.Open("data.txt")if err != nil {    log.Fatalf("No se pudo abrir el archivo: %v", err)}defer file.Close()

Consejos adicionales:

• Siempre verifique err != nil inmediatamente después de llamar a una función
• Use defer para cerrar recursos
• Cree sus propios tipos de error con fmt.Errorf("contexto: %w", err)
• No use pánico (panic) para errores comunes — es una situación excepcional

3. Funciones: cortas y con una sola responsabilidad

El Principio de Responsabilidad Única (Single Responsibility Principle) también se aplica a las funciones. Cada función debe hacer solo una cosa.

Malo (la función hace demasiado):

func ProcessUserData(userID int) (string, error) {    // 1. Conexión a la BD    db, _ := sql.Open("postgres", "...")    // 2. Consulta de datos    row := db.QueryRow("SELECT name, email FROM users WHERE id = ?", userID)    // 3. Formateo    var name, email string    row.Scan(&name, &email)    result := fmt.Sprintf("Nombre: %s, Email: %s", name, email)    // 4. Envío de email (¡efecto secundario!)    sendEmail(email, "Saludo")    return result, nil}

Bueno (división en funciones pequeñas):

func GetUserName(db *sql.DB, userID int) (string, error) {    var name string    err := db.QueryRow("SELECT name FROM users WHERE id = ?", userID).Scan(&name)    return name, err}

func FormatUserInfo(name, email string) string {    return fmt.Sprintf("Nombre: %s, Email: %s", name, email)}

func ProcessUserData(db *sql.DB, userID int) (string, error) {    name, err := GetUserName(db, userID)    if err != nil {        return "", fmt.Errorf("error al obtener usuario: %w", err)    }    email, _ := getUserEmail(db, userID) /