En una de enlaces, hacía referencia a How to C in 2016, una lectura breve, y muy recomendable, si eres un programador clásico de C.
Como sabemos, desde los inicios del lenguaje C con K&R, las variables locales, deben declararse al principio de la función. Muchos programadores se quejan de que ello dificulta el seguimiento del código. En mi caso, quizás por haberme acostumbrado a ello, me da una sensación de orden y de planificación a la hora de escribir código. Por otro lado, ordenarlas colocando primero aquellas que se usan con más frecuencia, para facilitar el uso de registros de la CPU por parte del compilador, me parecía una buena práctica.
Si necesito saber el tipo de una variable mi nomenclatura me permite saberlo de un vistazo, y si quiero saber más detalles, se que la encontraré declarada al principio de la función.
Con la aparición de C++, las variables pueden definirse en cualquier punto de la función, siempre y cuando ocurra antes de su primer uso, lógicamente. Sin embargo, remontándonos a los tiempos de Borland C++ 3, resultaba que cada vez que se encontraba una nueva variable definida dentro de la función, se generaba código especial para reservarle su correspondiente espacio en la pila. Es decir, código más grande, y de menos rendimiento. O sea, código menos eficiente.
En aquella época era discutible hasta que punto ello importaba. A mi modo de ver, lo hacía, sobre todo si tomábamos esta práctica como norma, con variables limitadas al ámbito de bucles, que debían crearse y destruirse en cada iteración.
Con C99, la capacidad de declarar variables de ámbito local en cualquier punto de la función, así como en bucles for, se extendió a C99, que a la práctica quiere decir, que la mayoría de compiladores de C actuales lo aceptan.
Tras las advertencias de CppCheck en el código de FileOptimizer, pensé que valdría la pena volver a considerar el impacto de reducir ámbito de variables, si pretendía facilitar la colaboración de otros desarrolladores.
Me sorprendió como Visual C++ 2015, incluso con las optimizaciones desactivadas, era ls suficientemente listo como para declarar esas variables al principio de la función. Es decir, independientemente de dónde escribiéramos su declaración, si al principio, o dentro de la función, él las declararía todas al principio. Como era de esperar, este comportamiento ocurría solamente con tipos de datos simples (enteros, flotantes, carácteres), pero no para los compuestos (estructuras, uniones, o arrays), que requerían espacio adicional en la pila, y donde en la mayoría de casos, el generador de código no era capaz de anticiparse.
Hay que tener en cuenta, que si la variable además de declararse, se inicializa, esa inicialización si que se ejecutará cada vez que se pase por ahí, por ejemplo en el interior de un bucle, lo cual es normal, pero hay que tenerlo en cuenta.
Tras ello, en el repositorio SVN, me dediqué a reducir el scope de esas variables locales, como una adaptación más a los tiempos modernos.
buen artículo, gracias.
Gracias a ti por la lectura Manuel.