Introducción: Por qué el código limpio no es un lujo, sino una necesidad
\nCada desarrollador Java se ha enfrentado a la situación de abrir un proyecto antiguo y pasar horas tratando de entender lo que él mismo escribió hace un par de meses. ¿Y qué decir del código ajeno? El código sucio ralentiza el desarrollo, aumenta la cantidad de errores y desmotiva al equipo. El libro de Robert Martin "Clean Code" se ha convertido en una biblia para los programadores, pero sus principios a menudo siguen siendo abstractos. En este artículo, analizaremos los conceptos clave de Clean Code en Java con ejemplos reales que se pueden aplicar hoy mismo.
\nEl código limpio no se trata de una sintaxis perfecta o de seguir una moda. Se trata de respeto hacia los colegas, hacia uno mismo en el futuro y, en última instancia, hacia el negocio. El código legible es más fácil de mantener, probar y refactorizar. Veamos cómo transformar el código Java de "funcional" a "limpio".
\n\n1. Nombres significativos: hable el lenguaje del dominio
\nRegla: el nombre debe responder a las preguntas "¿por qué?", "¿qué?", "¿cómo?"
\nLa mala elección de nombres es el principal enemigo del código limpio. Variables como int a, String d o List<Integer> list1 no aportan información. Un buen nombre debe revelar la intención del programador.
// Mal\nint d; // elapsed time in days\nList<Integer> lst;\n\n// Bien\nint daysSinceCreation;\nList<Integer> customerIds;\n\nEvite la desinformación
\nNo use accountList si no es una List, sino, por ejemplo, un Set o un Map. No abrevie lo obvio: usrNm en lugar de userName.
Nombres de clases y métodos
\n- \n
- Clases: sustantivos (
Customer,OrderProcessor). \n - Métodos: verbos (
calculateTotal(),saveToDatabase()). \n - Variables booleanas: predicados (
isActive,hasPermission). \n
// Mal\npublic class Data {\n public void proc() { ... }\n}\n\n// Bien\npublic class InvoiceCalculator {\n public BigDecimal calculateTotalAmount() { ... }\n}\n\n2. Funciones: cortas, atómicas y sin efectos secundarios
\nPrimer principio: una función debe hacer solo una cosa
\nLa función ideal en Java tiene entre 4 y 20 líneas. Si una función hace más de una acción, debe dividirse. Una señal clásica: si puede extraer de la función otra función con un nombre significativo, hágalo.
\n\n// Mal: la función hace tres cosas\npublic void processOrder(Order order) {\n if (order == null) throw new IllegalArgumentException();\n // 1. Validación\n if (order.getItems().isEmpty()) {\n logger.warn("Empty order");\n return;\n }\n // 2. Cálculo del total\n BigDecimal total = BigDecimal.ZERO;\n for (Item item : order.getItems()) {\n total = total.add(item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())));\n }\n // 3. Envío de email\n emailService.sendConfirmation(order.getCustomerEmail(), total);\n}\n\n// Bien: cada función hace una cosa\npublic void processOrder(Order order) {\n validateOrder(order);\n BigDecimal total = calculateTotal(order);\n sendConfirmationEmail(order, total);\n}\n\nprivate void validateOrder(Order order) {\n if (order == null || order.getItems().isEmpty()) {\n throw new IllegalArgumentException("Invalid order");\n }\n}\n\nprivate BigDecimal calculateTotal(Order order) {\n return order.getItems().stream()\n .map(item -> item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())))\n .reduce(BigDecimal.ZERO, BigDecimal::add);\n}\n\nLa regla del scout: deja el campamento más limpio de lo que lo encontraste
\nCada vez que edite un archivo, mejórelo: renombre una variable deficiente, divida una función larga. Esto evita la entropía del código.
\n\n<