Evolución en los estándares de codificación, ¿cómo los maneja?

¿Cómo manejas la evolución en los estándares de codificación / guía de estilo en un proyecto para la base de código existente? Digamos que alguien en su equipo descubrió una mejor forma de instanciación de objetos en el lenguaje de programación. No es que la forma anterior sea mala o con errores, es solo que la nueva forma es menos detallada y se siente mucho más elegante. Y a todos los miembros del equipo realmente les gusta. ¿Cambiarías todo el código existente?

Digamos que su base de código tiene más de 500,000 líneas de código. ¿Todavía quieres cambiar todo el código existente? ¿O solo permitiría que el nuevo código se adhiera al nuevo estándar? Básicamente perder consistencia?

¿Cómo manejas una evolución en los estándares de codificación de tu proyecto?

Los estándares de codificación existen para que los equipos sean más productivos. En teoría, hacen que el código sea más fácil de entender, alterar y probar. En la práctica, pueden crear una cantidad peligrosa de meta-trabajo; los equipos reescriben el código existente una y otra vez en busca de la solución más correcta y elegante. Desafortunadamente, el problema del metatrabajo parece peor en los equipos donde todos están comprometidos, apasionados y obsesionados con hacer lo correcto.

Como consultor que se traslada de un proyecto a otro, descubrí que una disciplina excelente con un estándar de codificación rígido contribuye mucho menos al éxito de un proyecto que los excelentes desarrolladores interesados ​​en los resultados. Los estilos de codificación inconsistentes son una molestia menor para los desarrolladores increíbles. Son productivos con o sin consistencia. De acuerdo, si encuentran un código inconsistente, preguntarán sobre el actualestándar y seguir con ello. Sin embargo, no insistirán en actualizar cada línea de código del proyecto al estándar actual. No insisten porque han visto las mejores prácticas ir y venir. La forma correcta de hacer algo hoy no es lo mismo que la forma correcta de hacer algo mañana. Si lo fuera, sus estándares de codificación no evolucionarían. Entonces, si la forma correcta de hacer algo cambia con el tiempo, tal vez nuestra definición de "correcto" se rompa.

Eso no quiere decir que los estándares no importen. Solo tenga en cuenta que el objetivo de los estándares es la productividad. Si no puede garantizar que la reescritura de un nuevo estándar se amortice a largo plazo, no pierda el tiempo. Es mucho más fácil justificar un nuevo estándar en código nuevo o refactorizado. La elegancia es genial, pero no es lo mismo que los resultados.

Lo que hacemos es evolución (no revolución) para la base de código también, usaríamos el estándar actualizado cuando;

• nuevo código está escrito
• el código se refactoriza
• los errores son corregidos
• nuevas porciones se agregan a una clase existente

Es importante que su base de código sea coherente, por lo que si el cambio abre una posibilidad de confusión entre el código de estilo "antiguo" y el "nuevo", podría ser mejor reservar la actualización de su estándar de codificación para el próximo proyecto.

En primer lugar, no incluiría tales "mejores prácticas" en la (parte obligatoria de) las directrices de codificación. Se pueden mencionar, por ejemplo, en un apéndice, como un ejemplo de cómo se puede hacer algo, pero no se debe hacer de esa manera.

Dicho esto, hay dos casos a considerar para los cambios en un estándar de codificación:

1. Cambios que no afectan la legibilidad, incluso si el código antiguo y el nuevo se mezclan sin actualizar el código anterior.
   Estos cambios pueden agregarse al estándar de codificación inmediatamente y deben considerarse vigentes para todos los códigos nuevos y modificados. El código antiguo debe adaptarse gradualmente a medida que el tiempo lo permita y a medida que se realicen cambios en esa área.
   Un ejemplo de este tipo de cambio, que realmente encontré, es un cambio en la declaración de derechos de autor al comienzo de cada archivo.
2. Cambios que deterioran la legibilidad si se mezclan el código antiguo y el nuevo.
   Estos cambios deben aplicarse a toda la base de código de una sola vez, o deben reconsiderarse si realmente son necesarios.
   Un ejemplo de este tipo de cambio es un cambio en la sangría o colocación de llaves.

Esto realmente depende del tipo de producto que esté creando:

• Para una aplicación comercial que está escrita internamente y que está implementando para los clientes, su objetivo principal deben ser los ingresos. Siempre que el código anterior no tenga errores, no importa que los nuevos estándares de codificación hayan evolucionado, debe concentrarse en agregar nuevas características a su producto y generar ingresos. Por supuesto, adapte los nuevos estándares de codificación para el nuevo código, pero cambiar todo el código existente sería una pérdida de tiempo.
• Si está desarrollando un producto de código abierto, o un producto donde varias compañías (tal vez incluso sus clientes) verán y trabajarán en la fuente, entonces la legibilidad del código se vuelve mucho más importante y en este caso, se debe tomar una decisión sensata dependiendo de exactamente cuánto código debe cambiarse y cuáles serán los beneficios a largo plazo. Aunque a todos nos gusta el código bonito, la realidad es que para una empresa comercial que se ocupa del código cerrado, adaptar constantemente los nuevos estándares significará que perderá ingresos a largo plazo.

Personalmente, optaría por mantener los códigos antiguos tal como están, y seguir los nuevos estándares de lo que haga nuevo. Más específicamente, no usaré dobles raseros en old.c. Pero si voy a crear new.c, puede usar las sintaxis más nuevas y refinadas :)