Este documento presenta varias reglas y heurísticas para escribir código limpio y de alta calidad. Recomienda seguir estándares de diseño establecidos, sustituir números mágicos por constantes con nombre descriptivo, usar precision al declarar variables y tipos, aplicar estructuras sobre convenciones como herencia, encapsular lógica condicional en funciones, evitar condicionales negativas, diseñar funciones que realicen una sola tarea, ocultar conexiones temporales entre argumentos y no heredar constantes.

1. CAPITULO 17
SINTOMASY HEURISTICA
LIBRO CODIGO LIMPIO
ROBERT C. MARTIN
EDISON SALAZAR MEJIA

2. Seguir las convenciones estándar
• Seguir un estándar de diseño basado en normas comunes de la industria
(protocolos)
• Deber tener muy claro en el estándar:
Donde declarar variables de instancia
 Como asignar nombres a clases
Métodos
 Variables
Donde añadir llaves
• -Todos los miembros del grupo de trabajo deben seguir estas convenciones
(Codigo refactorizado)

3. Sustituir números mágicos por constantes
con nombre
• Esta es la regla mas antigua del desarrollo de software (1960 -
Manuales de COBOL,FORTRAN y PL/1)
• Se debe ocultar constantes y números con nombres correctos, el cual
sea fácil de reconocer.
El número 86400 debe ocultarse SECONDS_PER_DAY
Si se va a imprimir 55 líneas, la constante 55 debe ocultarse por
LINES_PER_PAGE
• Se debe tener en cuenta que el termino número mágico no solo se
aplica para números, sino también para símbolos que tengan un valor
no descriptivo

4. Sustituir números mágicos por constantes
con nombre

5. PRECISION
• Declara una variable como ArrayList, cuando solo se necesita una List, es un
exceso e restricciones.
• Falta de restricciones es crear todas las variables como protected
• Al adoptar una decisión dentro del código debe de hacerlo en forma
precisa, saber por que la adopta y regular las excepciones
• Si se invoca una función que devuelva NULL, se debe de comprobar ese
NUll.
• Comprobar la cantidad de registros de la base de datos para estar seguros
• si tiene que trabajar con divisas use enteros y aplique redondeo correcto
• La ambigüedad y las imprecisiones son el resultado de desacuerdos o de
indolencia

6. ESTRUCTURA SOBRE CONVENCIÓN
• Aplique las decisiones de diseño con las estructuras y no
convenciones
• Los casos Switch con enumeración de nombres correctos son
inferiores a clases base con métodos abstractos. (herencia)
• "Hacer una función que por dentro contenga los casos necesarios, con
el fin de aplicar solo la función en el Switch"
• no siempre se debe utilizar el Switch/case de la misma manera
• Las clases base hacen que las clases concretas implementen métodos
abstractos

7. ENCAPSULAR CONDICIONALES
• Lógica Booleana.... Se debe extraer funciones que expliquen la lógica
de la condicional

8. EVITAR CONDICIONALES NEGATIVAS
• Las condicionales negativas son mas difíciles de entender que las
positivas, por tanto se deben expresar como condiciones positivas
mientras se pueda

9. LAS FUNCIONES SOLO DEBEN HACER UNA
COSA
• Es tentador tener funciones que realicen varias operaciones.
• Este tipo de funciones que hacen mas de una cosa deben convertirse
en funciones de menos tamaño, cada una para cada cosa.

10. LAS FUNCIONES SOLO DEBEN HACER UNA
COSA

11. CONEXIONES TEMPORALES OCULTAS
• Estructure los argumentos de sus funciones de modo que el orden de
invocación sea evidente
• Tener en cuenta que el orden de las funciones es importante.
• Cada función genera un resultado que la siguiente necesita,
aumentando la complejidad de las funciones, pero ese incremento de
sintáctica muestra la verdadera complejidad de la situación,
aumentando el rendimiento y el entendimiento.

12. EVITAR LA ARBITRARIEDAD
• Si la estructura parece coherente en la totalidad del sistema, otros la
usarán y conservaran la convención.
• Se debe asegurar que la estructura del código comunique cada
argumento.
• las clases publicas no son utilidades de otra clase, no deben incluirse
en el ámbito de otra clase.

13. EVITAR EXTENSAS LISTAS DE IMPORTACIÓN
MEDIANTE EL USO DE COMODINES
• Si usa dos o mas clases de un paquete, importe el paquete completo
con
Import package.*;
• Las listas de importación intimidan al lector.
• Debe ser una instrucción concisa con los que colaboramos.
• Las importaciones especificas son dependencias rígidas, mientras
que las importaciones de comodín no.
• Lo cual permite aligerar las consultas en nuestros módulos,
agregando el paquete a la lista de búsqueda al localizar los nombres.

14. NO HEREDAR CONSTANTES
• Añadir constantes a una interface y después acceder a las mismas
heredando dicha interfaz es horrible

15. NO HEREDAR CONSTANTES

16. NO HEREDAR CONSTANTES
• No use la herencia para burlas las reglas del ámbito del lenguaje. Use
una importación estática.

17. GRACIAS..!!!!