Split the code, Luke !

Hace tiempo que vengo desarrollando un proyecto de una magnitud considerable en mi lenguaje favorito ( para los que ayer no vinieron a clase, léase en C ).... Naturalmente, y , como buen informático, ampliamente influenciado por los más prestigiosos manuales sobre Ingeniería del Software, todo mi código fuente estaba en un único fichero .c y un único fichero cabecera .h. Es sobradamente sabido de que esas mariconadas de que el código conviene distribuirlo sensatamente entre múltiples ficheros fuente no es más que una invención de los autores de esos libros, que sostienen con argumentos que aparentan muy sensatos y que dicen que están comprobados pero que en realidad constituyen una forma de tener algo que decir en sus manuales para poder poner algo entre tapa y tapa y tener algo que vender, y por lo que ingresar un dinero para poder alimentar a sus retoños..... En particular, el argumento de que así, cuando buscas algo en tu código fuente, lo encuentras más rápido y fácilmente, dado que vas directamente al fichero donde lo que buscas tiene que estar, me parecía el más endeble..... Leñe..... ¡ Si encontrar lo que busco en mi editor favorito teniendo un único fichero lo único que requiere es recordar de una maldita vez y para siempre si en él Buscar es Control-B o Control-F !

De todas formas, ayer, no sé por qué, me dio por ser ingenuo y creerme esas paparruchas ( probablemente fue un ataque de pánico al ver que el tamaño de mi fichero estaba alcanzando unas dimensiones tan desmesuradas que entraba dentro de lo posible que me devorase y mis pobres parientes ni siquiera encontraran en este cuarto unos restos de los que disponer del modo que estimasen más oportuno).

Así que empleé un tiempo razonable en hacer un diseño inteligente ( no confundir con la teoría de los antidarwinistas ) sobre cómo distribuir mi código en unidades de compilación homogéneas y coherentes... Una vez planificado el patrón de corte y confección en un DIN-A4 para saber por dónde tenía que meter las tijeras divisorias, me puse a ello. Me sorprendió lo fácil que logré hacer las adaptaciones que me parecieron oportunas ( separar el código entre los ficheros obtenidos en mi diseño de las escisiones - splitters, puagh ! - , crear un fichero cabecera para cada unidad de compilación, incluir cláusulas de salvaguarda para evitar definiciones dobles por inclusión múltiple de los .h.... esas cosas ).

Hasta ahí parecía fácil..... Lo siguiente era donde el sudor frío amenazaba con paralizarme. Tuve que escribir una larga línea comenzando por gcc, incluyendo las opciones convenientes para la compilación y el enlazado, y la lista de ficheros fuente a compilar y enlazar. El resultado fue una orden cuyo aspecto abstruso hacía palidecer las frases más enrevesadas que pueda contener una mezcla de serbo-croata, olov y arameo; y la gran cuestión: ¿ cuántos errores de compilación voy a obtener ? El resultado me dejó estupefacto. Pulsé ENTER y el sistema no hizo nada,..... sólo volver al prompt mansamente.... Ni un sólo error de compilación, ni una triste queja del linker, ni un mísero warning..... Nada.... Era una cámara oculta, sin duda. Ahora hago un DIR y veo que no ha generado ningún .exe y se me va a quedar una cara de gilipollas que lo flipas. Coño, pues no.... Pues hay un .exe. Vale.... los autores de la broma, que a estas alturas no tiene ni puta gracia, han sido muy elaborados.... Han dispuesto que el compilador con truco crease un .exe. ¡ Qué cabrones ! Lo dejan todo p'al final, pa cuando ejecute el .exe que no será más que una cáscara de nuez y no hará nada. Hmmm.... Vamos a ejecutarlo, que la cara de tonto va a marcar un antes y un después. ¡ El complejo programa funciona, exactamente igual que el que obtenía de compilar mi fichero único !

¡ He visto la luz ! Los autores de manuales de Ingeniería del Software son unos tíos honestos. A partir de ahora todos mis proyectos software los planificaré desde el inicio para que su código esté distribuido de modo adecuado en múltiples ficheros....

Fíjate, querido lector, que hasta estoy empezando a considerar la idea de que eso de la Programación Orientada a Objetos no sea una tomadura de pelo. ¡ Cualquier día pruebo !