Muchos no saben quizás que el programador siempre busca que su código se "vea bien".
El programador experimentado puede conocerse por su código: los nombres de variables son significativos, utiliza sangrías (tabulación), comenta su código de forma ordenada, entre otras buenas costumbres:
En cambio el novato deja mucho que desear...
Por algún lado tenemos que empezar, ¿no?.
Uno de los problemas principales en la actualidad a la hora de programar, es la falta de modularidad en el código. Muchos (pero muchos) programadores creen que sus clases tienen que hacer de todo. Estas clases todo (o super clases) son en realidad, El Santo Grial del programador... es decir... la búsqueda inalcanzable de:
la ultima clase objeto super abstracta genérica y su jerarquía.
"Imagen tomada del comic: c0ders"Y claro, en esa búsqueda se termina en una bola de código (basura) gigante.
Un ejemplo visual perfecto para esto, es un juego que se asemeja mucho al problema que menciono, este juego es Katamari Damacy, que consiste en rodar una bola pegajosa llamada katamari, a lo largo y ancho de distintas pantallas, recolectando todo tipo de objetos hasta que la bola se convierte en una gigantesca esfera de basura... casi lo que sucede con el código de muchos de nosotros:
La analogía es ideal: el código comienza pequeño (como la bola de katamari) y termina acumulando miles de lineas de código inútiles... una clase en donde falla la abstracción y la modularidad. La probabilidad de que un proyecto de software falle esta directamente relacionada con el tamaño del mismo. Y la relación entre lineas de código y bugs (errores) es completamente linear. Menos código significa menos errores. Si el código es mas corto, se evita el síndrome de
ML; NL, es decir: "Muy Largo; No leí"
(y en ingles TL;DR : "Too Long; Ditn't Read").
Si hay menos código para leer y es más entendible, son mas altas las probabilidades de que alguien realmente lo lea.
Hasta la próxima!
