Evolución en los estándares de codificación, ¿cómo lidiar con ellos?

12

¿Cómo aborda la evolución en la guía de estilo / estándares de codificación en un proyecto para la base de código existente? Digamos que alguien en su equipo descubrió una mejor manera de crear instancias de objetos en el lenguaje de programación. No es que la forma antigua sea mala o esté llena de errores, sino 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 todos los códigos existentes?

Digamos que su código base es de aproximadamente 500.000 líneas de código. ¿Todavía quieres cambiar todo el código existente? ¿O solo permitirías que el nuevo código se adhiera a la nueva norma? ¿Básicamente pierdes consistencia?

¿Cómo aborda la evolución de los estándares de codificación en su proyecto?

    
pregunta Ward Bekker 17.01.2011 - 10:10

5 respuestas

13

Existen estándares de codificación 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 meta-trabajo parece peor en los equipos donde todos están comprometidos, apasionados y obsesionados con hacer lo correcto.

Como consultor que pasa de un proyecto a otro, he descubierto que una excelente disciplina 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 pequeña molestia para los desarrolladores sorprendentes. Son productivos con o sin consistencia. Por supuesto, si encuentran un código inconsistente, preguntarán sobre el estándar actual y se apegarán a él. Sin embargo, no insistirán en actualizar cada línea de código del proyecto al estándar actual. No insisten porque han visto ir y venir las mejores prácticas. La manera correcta de hacer algo hoy no es lo mismo que la manera correcta de hacer algo mañana. Si lo fuera, sus estándares de codificación no evolucionarán. Por lo tanto, si la forma correcta de hacer algo cambia con el tiempo, tal vez nuestra definición de "correcto" no sea correcta.

Eso no quiere decir que las normas no importan. Solo tenga en cuenta que el objetivo de los estándares es la productividad. Si no puede garantizar que la reescritura a un nuevo estándar se pagará por sí misma a largo plazo, no pierda tiempo en ello. 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.

    
respondido por el Corbin March 17.01.2011 - 18:30
5

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

  • el nuevo código está escrito
  • el código es refactorizado
  • los errores están arreglados
  • las nuevas porciones se agregan a una clase existente

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

respondido por el rsp 17.01.2011 - 10:39
3

En primer lugar, no incluiría tales "mejores prácticas" en la (parte obligatoria de las directrices de codificación). Pueden mencionarse, por ejemplo, en un apéndice, como ejemplo de cómo podría hacer algo, pero no que debería hacerse de esa manera .

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

  1. Los cambios que no afectan la legibilidad, incluso si el código antiguo y el nuevo se mezclan sin actualizar el código antiguo.
    Estos cambios se pueden agregar al estándar de codificación inmediatamente y se deben considerar vigentes para todos los códigos nuevos y modificados. El código antiguo debe adaptarse de manera gradual según lo permita el tiempo y conforme 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 principio de cada archivo.
  2. Cambios que deterioran la legibilidad si se mezclan el código antiguo y el nuevo.
    Estos cambios deben aplicarse a la base de código completa 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 la colocación de llaves.
respondido por el Bart van Ingen Schenau 17.01.2011 - 11:40
2

Esto realmente tiene que depender del tipo de producto que está creando:

  • Para una aplicación comercial que está escrita en forma interna y que está implementando para los clientes, su principal objetivo debe ser los ingresos. Siempre que el código antiguo 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. De todos modos, 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 en el que varias compañías (tal vez incluso sus clientes) vean y trabajen en la fuente, la legibilidad del código se vuelve mucho más importante y, en este caso, , se debe tomar una decisión sensata según la cantidad exacta de código que deba cambiarse y los beneficios que se obtendrán a largo plazo. Aunque a todos nos gusta el código bonito, la realidad es que para una empresa comercial que trabaja con código cerrado, la adaptación constante de nuevos estándares significará que perderá ingresos a largo plazo.
respondido por el mrwooster 17.01.2011 - 10:21
0

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

    
respondido por el Barun 17.01.2011 - 10:22

Lea otras preguntas en las etiquetas