Puntos clave
1. El código limpio es legible, simple y expresivo
El código limpio siempre parece haber sido escrito por alguien que se preocupa.
La claridad es clave. El código limpio se caracteriza por su legibilidad y simplicidad. Debe ser fácil de entender, modificar y mantener para otros programadores. Esto implica utilizar nombres claros y significativos, mantener las funciones y clases pequeñas y enfocadas, y organizar el código de manera lógica.
El código expresivo comunica la intención. El código limpio debe expresar claramente la intención del programador sin necesidad de comentarios extensos. Esto se logra a través de nombres bien elegidos, funciones pequeñas que hacen una cosa bien y una estructura general clara. El código en sí mismo debe contar una historia, facilitando a los lectores seguir la lógica y el propósito de cada componente.
La mejora continua es esencial. Escribir código limpio es un proceso continuo que requiere atención constante y refactorización. Los programadores deben seguir la Regla del Boy Scout: "Deja el campamento más limpio de lo que lo encontraste." Esto significa siempre buscar oportunidades para mejorar la claridad y la estructura del código, incluso en pequeñas formas, con cada modificación o adición.
2. Nombres significativos mejoran la claridad y mantenibilidad del código
El nombre de una variable, función o clase debe responder a todas las grandes preguntas. Debe decirte por qué existe, qué hace y cómo se utiliza.
Elige nombres descriptivos. Los nombres deben ser autoexplicativos y revelar la intención detrás de las variables, funciones y clases. Evita nombres de una sola letra, abreviaturas o códigos crípticos que requieran un mapeo mental para entender su propósito.
Usa convenciones de nomenclatura de manera consistente. Adopta y mantén convenciones de nomenclatura estándar para tu lenguaje de programación y equipo. Esto incluye:
- CamelCase para nombres de clases (por ejemplo, PedidoCliente)
- camelCase para nombres de variables y funciones (por ejemplo, montoTotal)
- ALL_CAPS para constantes (por ejemplo, TAMAÑO_MAXIMO)
Evita la desinformación y el ruido. No uses nombres que puedan ser engañosos o confusos. Por ejemplo, evita usar 'lista' en un nombre de variable si en realidad no es una Lista. Además, evita palabras redundantes o sin significado en los nombres, como 'datos' o 'info' cuando no añaden valor.
3. Las funciones deben ser pequeñas, hacer una sola cosa y operar a un solo nivel de abstracción
Las funciones deben hacer una cosa. Deben hacerlo bien. Deben hacerlo solamente.
Mantén las funciones pequeñas. Las funciones ideales no deben tener más de 20 líneas. Esto las hace más fáciles de leer, entender y mantener. Las funciones más pequeñas también son más fáciles de nombrar con precisión, probar y reutilizar.
Principio de responsabilidad única. Cada función debe tener un propósito claramente definido. Si una función está haciendo múltiples cosas, debe dividirse en funciones más pequeñas y enfocadas. Esto mejora la legibilidad y hace que el código sea más modular y fácil de modificar.
Nivel de abstracción consistente. Dentro de una función, todas las operaciones deben estar al mismo nivel de abstracción. Mezclar lógica de alto nivel con detalles de bajo nivel hace que las funciones sean más difíciles de entender y mantener. Utiliza la técnica de refactorización "Extraer Método" para separar diferentes niveles de abstracción en funciones distintas.
4. Los comentarios deben ser mínimos y verdaderamente necesarios
El uso adecuado de los comentarios es compensar nuestra incapacidad para expresarnos en código.
El código debe ser autoexplicativo. Un código bien escrito con nombres y estructura claros a menudo elimina la necesidad de comentarios. Antes de agregar un comentario, considera si puedes refactorizar el código para que su intención sea más clara.
Usa comentarios con juicio. Los buenos comentarios explican por qué se hace algo, no cómo se hace. Deben proporcionar contexto o aclaraciones que no se pueden expresar solo en código. Tipos de comentarios útiles incluyen:
- Comentarios legales (derechos de autor, licencias)
- Explicación de la intención o algoritmos
- Advertencias sobre consecuencias
- Comentarios TODO (usados con moderación)
Evita comentarios redundantes o engañosos. No escribas comentarios que simplemente repitan lo que el código dice claramente. Los comentarios desactualizados o incorrectos son peores que no tener comentarios en absoluto, ya que pueden confundir a los lectores. Revisa y actualiza regularmente los comentarios junto con el código que describen.
5. Un formato adecuado mejora la legibilidad del código
El formato del código se trata de comunicación, y la comunicación es la primera prioridad del desarrollador profesional.
El estilo consistente importa. Establece y sigue un estilo de formato consistente en tu base de código. Esto incluye:
- Sangrías
- Saltos de línea
- Colocación de llaves
- Espaciado alrededor de operadores y palabras clave
Formato vertical. Organiza el código verticalmente para mejorar la legibilidad:
- Mantén conceptos relacionados juntos
- Separa conceptos no relacionados
- Declara variables cerca de su uso
- Coloca funciones dependientes cerca unas de otras
Formato horizontal. Mantén las líneas razonablemente cortas (generalmente de 80 a 120 caracteres) para evitar la necesidad de desplazamiento horizontal. Divide declaraciones largas en múltiples líneas de manera lógica. Usa espacios en blanco para separar bloques lógicos dentro de una línea.
6. Los objetos y las estructuras de datos sirven a diferentes propósitos
Los objetos ocultan sus datos detrás de abstracciones y exponen funciones que operan sobre esos datos. Las estructuras de datos exponen sus datos y no tienen funciones significativas.
Objetos vs. estructuras de datos. Los objetos encapsulan datos y exponen comportamiento a través de métodos. Son buenos para agregar nuevos tipos (clases) sin cambiar el comportamiento existente. Las estructuras de datos, por otro lado, exponen datos y no tienen un comportamiento significativo. Son buenas para agregar nuevos comportamientos sin cambiar los tipos de datos existentes.
Elige el enfoque correcto. Usa objetos cuando quieras agregar nuevos tipos con frecuencia pero mantener los comportamientos estables. Usa estructuras de datos cuando quieras agregar nuevos comportamientos con frecuencia pero mantener los tipos estables. Comprender esta distinción ayuda a diseñar sistemas más flexibles y mantenibles.
Ley de Demeter. Para los objetos, sigue la Ley de Demeter: un método solo debe llamar a métodos en:
- El objeto mismo
- Sus parámetros
- Cualquier objeto que cree
- Sus objetos componentes directos
Este principio ayuda a reducir el acoplamiento entre diferentes partes de un sistema.
7. El manejo de errores debe ser limpio e informativo
El manejo de errores es importante, pero si oscurece la lógica, está mal.
Usa excepciones en lugar de códigos de error. Las excepciones proporcionan una forma más limpia de manejar errores en comparación con los códigos de error tradicionales. Separan la lógica de manejo de errores del código principal, haciendo que ambos sean más fáciles de entender y mantener.
Crea mensajes de error informativos. Los mensajes de error deben proporcionar suficiente contexto para entender qué salió mal y dónde. Incluye detalles relevantes como:
- Qué operación se estaba intentando
- Qué error específico ocurrió
- Cualquier valor o información de estado relevante
Escribe primero las declaraciones try-catch-finally. Al escribir código que podría lanzar excepciones, comienza escribiendo los bloques try-catch-finally. Esto ayuda a garantizar que el código sea resistente a errores desde el principio y que los casos de error se consideren adecuadamente.
8. Las pruebas unitarias son cruciales para mantener un código limpio
El código de prueba es tan importante como el código de producción.
Escribe pruebas primero. Sigue la práctica del Desarrollo Guiado por Pruebas (TDD):
- Escribe una prueba que falle
- Escribe el código mínimo para pasar la prueba
- Refactoriza el código mientras mantienes la prueba aprobada
Este enfoque asegura que tu código sea testeable desde el principio y ayuda a impulsar un buen diseño.
Mantén las pruebas limpias. Aplica los mismos estándares de limpieza a tu código de prueba que a tu código de producción. Las pruebas limpias son:
- Legibles
- Mantenibles
- Confiables
Sigue los principios F.I.R.S.T para las pruebas:
- Rápidas: Las pruebas deben ejecutarse rápidamente
- Independientes: Las pruebas no deben depender unas de otras
- Repetibles: Las pruebas deben ser repetibles en cualquier entorno
- Auto-validantes: Las pruebas deben tener una salida booleana (aprobada/fallida)
- Oportunas: Las pruebas deben escribirse justo antes del código de producción
9. Las clases deben ser pequeñas, enfocadas y seguir el Principio de Responsabilidad Única
La primera regla de las clases es que deben ser pequeñas. La segunda regla de las clases es que deben ser más pequeñas que eso.
Mantén las clases enfocadas. Una clase debe tener una única responsabilidad bien definida. Si no puedes describir el propósito de una clase en unas 25 palabras sin usar "y" o "o", probablemente esté haciendo demasiado.
Apunta a una alta cohesión. Los métodos y variables dentro de una clase deben estar estrechamente relacionados y trabajar juntos para cumplir con la responsabilidad de la clase. La baja cohesión a menudo indica que una clase está tratando de hacer demasiado y debería dividirse.
Principio Abierto-Cerrado. Diseña clases para que estén abiertas a la extensión pero cerradas a la modificación. Esto a menudo implica usar abstracciones e interfaces para permitir que se agregue nueva funcionalidad sin cambiar el código existente.
10. La concurrencia requiere un diseño e implementación cuidadosos
Escribir programas concurrentes limpios es difícil—muy difícil.
Comprende los desafíos de la concurrencia. La programación concurrente introduce complejidades como:
- Condiciones de carrera
- Interbloqueos
- Problemas de vivacidad
- Impactos en el rendimiento
Mantén el código relacionado con la concurrencia separado. Aísla el código que trata con la concurrencia. Esto facilita el razonamiento, la prueba y el mantenimiento tanto de las partes concurrentes como de las no concurrentes de tu sistema.
Usa bibliotecas y marcos existentes. Aprovecha bibliotecas y marcos de concurrencia bien probados (por ejemplo, java.util.concurrent en Java) en lugar de intentar implementar el control de concurrencia de bajo nivel tú mismo. Estas herramientas han sido optimizadas y probadas exhaustivamente para patrones de concurrencia comunes.
Escribe pruebas exhaustivas. Probar código concurrente es un desafío, pero crucial. Escribe pruebas que:
- Creen múltiples hilos
- Varíen el tiempo y la programación
- Se ejecuten muchas veces para aumentar la posibilidad de exponer problemas intermitentes
- Usen herramientas como sanitizadores de hilos y analizadores estáticos para ayudar a identificar posibles errores de concurrencia.
Última actualización:
FAQ
What's Clean Code: A Handbook of Agile Software Craftsmanship about?
- Focus on Software Craftsmanship: The book emphasizes the importance of writing clean, maintainable code as a hallmark of professionalism in software development.
- Principles and Practices: It outlines various principles, patterns, and practices that help programmers write code that is not only functional but also easy to read and understand.
- Real-World Examples: Numerous examples of both good and bad code are included, demonstrating how to transform messy code into clean code through refactoring and disciplined practices.
Why should I read Clean Code by Robert C. Martin?
- Improve Coding Skills: Reading the book can significantly enhance your programming skills by teaching you how to write code that is easier to maintain and understand.
- Professional Development: It is a valuable resource for anyone looking to advance their career in software development, instilling a mindset of craftsmanship and quality.
- Practical Advice: The book provides practical advice that can be applied immediately in your coding practices, making it a useful guide for both novice and experienced programmers.
What are the key takeaways of Clean Code?
- Meaningful Names: The book stresses the importance of using intention-revealing names for variables, functions, and classes to enhance code readability and maintainability.
- Small Functions: Functions should be small and focused on a single task, adhering to the principle of "Do One Thing" to improve clarity and reduce complexity.
- Error Handling: Martin advocates for using exceptions rather than return codes for error handling, which helps keep the main logic of the code clean and unobscured.
What are the best quotes from Clean Code and what do they mean?
- "Clean code is a matter of discipline.": This quote emphasizes that writing clean code requires consistent effort and adherence to best practices, rather than relying on luck or talent alone.
- "Comments do not make up for bad code.": This highlights the idea that if code is poorly written, no amount of commenting can compensate for its lack of clarity and structure.
- "Leave the campground cleaner than you found it.": This metaphor encourages developers to improve the codebase with every change, ensuring that the code remains clean and maintainable over time.
How does Clean Code define clean code?
- Readable and Understandable: Clean code is defined as code that is easy to read and understand, allowing other developers to quickly grasp its purpose and functionality.
- Minimal Complexity: It should have minimal complexity, with each function and class focused on a single responsibility, making it easier to test and maintain.
- Well-Structured: Clean code is well-structured, following consistent formatting and naming conventions that enhance its clarity and reduce the cognitive load on the reader.
What is the Boy Scout Rule in Clean Code?
- Continuous Improvement: The Boy Scout Rule states that developers should "leave the campground cleaner than you found it," meaning that every time you work on code, you should strive to improve it.
- Small Changes Matter: This can be as simple as renaming a variable for clarity or refactoring a small function, which contributes to the overall cleanliness of the codebase.
- Professional Responsibility: Adhering to this rule reflects a professional attitude towards code quality and maintenance, fostering a culture of continuous improvement within a team.
What is the Single Responsibility Principle (SRP) in Clean Code?
- Definition of SRP: The SRP states that "a class should have one, and only one, reason to change." This means that each class should focus on a single responsibility or functionality.
- Benefits of SRP: Adhering to SRP leads to better organization of code, making it easier to understand, test, and maintain. It reduces the risk of changes in one area affecting unrelated parts of the code.
- Implementation Guidance: Martin provides practical advice on how to identify responsibilities and refactor classes to adhere to SRP, ensuring that code remains clean and manageable.
How does Clean Code address error handling?
- Use Exceptions: The book advocates for using exceptions rather than return codes for error handling, which helps keep the main logic of the code clean and unobscured.
- Separation of Concerns: Error handling should be separated from the main logic of the code, allowing developers to focus on the primary functionality without being bogged down by error-checking clutter.
- Provide Context: Exceptions should provide enough context to understand the source and nature of the error, making it easier to diagnose and fix issues when they arise.
What role does testing play in Clean Code?
- Foundation of Clean Code: Testing is considered a fundamental discipline in writing clean code. It ensures that the code behaves as expected and helps catch issues early in the development process.
- Fast and Reliable Tests: The book emphasizes that tests should be fast and reliable to encourage frequent execution. This helps maintain a clean codebase and reduces the risk of introducing bugs.
- Self-Validating Tests: Tests should be designed to be self-validating, meaning they should clearly indicate whether the code is functioning correctly. This reduces ambiguity and increases confidence in the code.
How does Clean Code suggest handling dependencies?
- Dependency Inversion Principle (DIP): The book explains that "high-level modules should not depend on low-level modules. Both should depend on abstractions." This principle encourages the use of interfaces and abstract classes to reduce coupling.
- Use of Dependency Injection: Martin recommends using dependency injection to manage dependencies, allowing for more flexible and testable code. This approach decouples the creation of dependencies from their usage.
- Benefits of Managing Dependencies: By managing dependencies effectively, developers can create systems that are easier to maintain and extend, leading to cleaner and more robust code.
What are some common code smells identified in Clean Code?
- Duplicated Code: This is a major code smell that indicates a lack of abstraction. The book advises eliminating duplication to improve maintainability and reduce errors.
- Long Methods: Methods that are too long can be difficult to understand and maintain. The book suggests breaking them down into smaller, more manageable functions.
- Excessive Comments: While comments can be helpful, excessive or redundant comments often indicate that the code itself is not clear. The goal should be to write self-explanatory code that requires minimal comments.
How can I apply the principles from Clean Code in my own projects?
- Start with Small Changes: Begin by applying the principles of clean code to small sections of your codebase. Refactor one class or function at a time to improve readability and maintainability.
- Write Tests First: Adopt Test-Driven Development (TDD) practices by writing tests before implementing new features. This ensures that your code is always covered by tests and helps maintain quality.
- Regularly Refactor: Make refactoring a regular part of your development process. Continuously look for opportunities to improve code structure and eliminate duplication, keeping your codebase clean and efficient.
Reseñas
Código Limpio es ampliamente considerado como una lectura esencial para los desarrolladores de software, ofreciendo valiosas perspectivas sobre cómo escribir código legible y mantenible. Aunque se elogia por sus consejos prácticos sobre convenciones de nomenclatura, diseño de funciones y pruebas, algunos lectores lo encontraron excesivamente centrado en Java y, en ocasiones, extremo en sus recomendaciones. Los estudios de caso del libro recibieron reacciones mixtas, con algunos considerándolos útiles y otros menos impresionados. A pesar de sus defectos, muchos desarrolladores lo consideran una lectura obligada que ha mejorado significativamente sus prácticas de codificación y su comprensión de la artesanía del software.
Similar Books
