Please enable JavaScript.
Coggle requires JavaScript to display documents.
Código Limpio (Funciones (Primera linea de organización de cualquier…
Código Limpio
Funciones
Primera linea de organización de cualquier programa.
¿Cómo podemos hacer que una función comunique su intención? ¿Qué atributos podemos dar a nuestras funciones que permitirán a un lector casual intuir el tipo de programa en el que vive?
Pequeño
La primera regla de las funciones es que deben ser cortas.
Las líneas no deben tener 150 caracteres de longitud.
Las funciones no deben tener 100 líneas de largo.
Las funciones casi nunca deben tener 20 líneas de largo.
Hacer una sola cosa
Las funciones deben hacer una sola cosa y hacerla bien.
Los bloques dentro de las declaraciones(if,else,while,etc...) deberán tener solo una linea, probablemente una llamada a función.
Si se puede extraer otra función con un nombre que no sea una re formulación de su implementan esta cumple mas de una acción.
Si una funciona tiene secciones en ella claramente no cumple una sola cosa.
Las funciones deben poseer solo un nivel de abstracción.
Poder leer el programa como si fuera un conjunto de párrafos.
Usar nombres descriptivos
Escoger nombres que describan correctamente lo que realiza una función.
Es mejor un nombre largo descriptivo que uno enigmático corto
Ser consistente
Argumentos de funcion
El numero ideal de argumentos por función es 0. Evitar el uso de 3 o mas. Entre mas argumentos, es mas difícil entender una función
Monadic(un argumento)
Triadic(tres argumentos)
Dyadic(dos argumentos)
Cuando una función parece necesitar más de dos o tres argumentos, es probable que algunos de
esos argumentos deben ser envueltos en una clase propia.
Si varios argumentos se tratan igual es equivalente a usar un único de tipo lista.
La funcion y el argumento deben formar un par verbo/sustantivo
Evitar el uso de booleanos como argumento
SI se puede es mejor evitar los argumento de salida.
Efectos ocultos
Una función no debe cumplir solo con lo que promete, no debe realizar nada oculto.
Separación de consulta de comando
Una función debe hacer algo o responder algo, no ambas.
Realizar ambas tiende a la confusión.
Retorno de códigos de error
Devolver códigos de error de las funciones de comando es una violación sutil de la separación de consultas de comando.
Conduce a estructuras profundamente anidadas.
Se debe tratar el problema inmediatamente
Extraer bloques Try / Catch
Confunden la estructura del código y mezclan el procesamiento de errores con el procesamiento normal.
Es mejor extraer los cuerpos del intento y atrapar bloques en funciones propias.
El manejo de errores es una acción
Una función debe realizar solo una acción.
Una función que maneje un error no debe realizar nada mas.
No te repitas a ti mismo
Evitar repetir código.
Crear una función.
Comentarios
Utilizados para compensar nuestra falta de expresión.
¿Cómo crear buenos comentarios?
Los comentarios no compensan el mal código
Es preferible un código con pocos comentarios que uno desordenado con muchos comentarios.
Explícate en código
Toma el tiempo necesario al nombrar tu código y este se explicara solo.
Disminuye la cantidad de comentarios necesarios.
Buenos comentarios
Comentarios importantes a utilizar.
Comentarios legales
Comentarios con fines comerciales.
Copyright y autor.
Comentarios informativos
Brindar información básica: como el valor de retorno de un método abstracto.
Explicación de intención
Proporciona la intención en una decisión del programador.
Aclaracion
Traducir el significado de algún argumento.
Advertencia de consecuencias
Advertir de ciertas consecuencias.
Tareas pendientes
Comentar planes futuros.
Amplificación
Amplificar la importancia de una parte del codigo.
Javadocs en API publicas
Utilizados cuando se escribe un API publico.
Malos comentarios
La mayoría entran aquí como escusa para un código pobre.
Masculleo
Escribir un comentario por creer que debe.
Porque el proceso lo requiere.
Redundantes
Comentario redundante que dura mas en leerse que el código.
Comentarios engañosos
Comentarios ligeramente engañosos
Posible explicación errónea.
Comentarios obligatorios
No es necesario comentarlo todo.
Comentarios necesarios solo abarrotan el código.
Comentario diario
Comentario escrito después de cada cambio al código.
Se pueden acumular.
Comentario de ruido
Reafirmar lo obvio.
No proporciona información nueva.
Ruido aterrador
Ruido de los java docs.
Marcadores de posición
Marcar la posición en particular de un archivo fuente.
Usar con moderación.
Comentarios de llave de cierre
Comentar el final de una función.
Tiene sentido cuando una función es grande.
Usarlo con funciones pequeñas puede saturar el código.
Atribuciones y Bylines
Contaminar el código con pequeños bylines.
Mejor usar los sistemas de control de código fuente.
Código comentado
Nunca lo hagas.
Tiende a crear confusión y otras personas no tienen el coraje para borrarlo pensando que puede ser importante
Comentarios HTML
Hacen que el código sea difícil de leer.
Responsabilidad de otras herramientas no del programador.
Información no local
Comentar código cercano. No ofrecer información de todo el sistema.
Demasiada información
No sobrecargue el código con información innecesaria.
Conexión no obvia
Las conexiones de los comentarios y sus códigos deben ser obvias.
Encabezados de funciones
Evitar encabezados en funciones pequeñas.
Lo mejor es escoger buenos nombres.
Javadocs en código no público
Innecesario.
Nunca uses un comentario cuando puedes usar una variable o función.