Código limpio en Java: reglas que salvarán tu proyecto

Por qué el código limpio no es un lujo, sino una necesidad

Imagina que entras en un proyecto ajeno. Las clases se llaman Class1, Manager, UltraProcessor. Los métodos lo hacen todo a la vez: consulta a la base de datos, renderizado de HTML y envío de email. Y las variables — x, y, temp. ¿Te suena? Si es así, sabes lo rápido que ese código convierte la vida del desarrollador en un infierno.

El código limpio en Java no se trata de pedantería. Se trata de respeto hacia los colegas, hacia tu futuro yo y hacia el negocio. El código sucio ralentiza el desarrollo entre 2 y 3 veces, hace que los errores sean difíciles de detectar y la refactorización, imposible. En este artículo analizaremos reglas concretas que te ayudarán a escribir código que sea agradable de leer y mantener.

Regla n.º 1: La nomenclatura es el 50 % del éxito

Robert Martin (tío Bob) en el libro «Código limpio» afirma: un buen nombre reemplaza un comentario. Los desarrolladores Java a menudo pecan con nombres abstractos. Corrijamos esto.

Variables: di lo que almacenas

Mal:

int d; // elapsed time in days

Bien:

int elapsedTimeInDays;

Mal:

List<String> list = new ArrayList<>();

Bien:

List<String> customerNames = new ArrayList<>();

Métodos: verbo + contexto

El método debe responder a la pregunta «¿qué hace?». Evita palabras genéricas como process, handle, doStuff.

Mal:

public void process(int id) {\n    // 50 líneas de código: validación, cálculo, envío de email\n}

Bien:

public void sendEmailConfirmation(int orderId) {\n    // solo la lógica de envío de email\n}

Clases: sustantivos sin sufijos parásitos

Evita Manager, Processor, Util a menos que esté justificado. La clase debe reflejar la entidad.

Mal: DataProcessor, UserManager

Bien: UserRepository, InvoiceCalculator, EmailSender

Regla n.º 2: Métodos cortos y de una sola tarea

La regla de oro: un método, una responsabilidad. Si un método tiene más de 15-20 líneas, probablemente deba dividirse. Esto mejora la legibilidad del código Java y simplifica las pruebas.

Ejemplo de refactorización

Antes:

public boolean isValidOrder(Order order) {\n    if (order == null) return false;\n    if (order.getItems().isEmpty()) return false;\n    double total = 0;\n    for (Item item : order.getItems()) {\n        total += item.getPrice() * item.getQuantity();\n    }\n    if (total > 10000) {\n        // verificación del límite de crédito\n        User user = userRepository.findById(order.getUserId());\n        return user.getCreditLimit() >= total;\n    }\n    return true;\n}

Después:

public boolean isValidOrder(Order order) {\n    if (isOrderNullOrEmpty(order)) return false;\n    double total = calculateTotal(order);\n    if (isHighValueOrder(total)) {\n        return hasSufficientCredit(order.getUserId(), total);\n    }\n    return true;\n}\n\nprivate boolean isOrderNullOrEmpty(Order order) {\n    return order == null || order.getItems().isEmpty();\n}\n\nprivate double calculateTotal(Order order) {\n    return order.getItems().stream()\n            .mapToDouble(item -> item.getPrice() * item.getQuantity())\n            .sum();\n}\n\nprivate boolean isHighValueOrder(double total) {\n    return total > 10000;\n}\n\nprivate boolean hasSufficientCredit(int userId, double total) {\n    User user = userRepository.findById(userId);\n    return user.getCreditLimit() >= total;\n}

Regla n.º 3: Comentarios solo cuando no haya otra opción

Un comentario a menudo es una excusa para el mal código. En lugar de escribir «// obtiene