¿Sigue la convención de nomenclatura del programador original?

https://stackoverflow.com/questions/284113

08-07-2019
|

Pregunta

Si toma el control de un proyecto de alguien para hacer actualizaciones simples, ¿sigue su convención de nomenclatura? Acabo de recibir un proyecto donde el programador anterior usó la notación húngara en todas partes. Nuestro producto principal tiene un estándar de nomenclatura, pero a lo largo de los años hemos hecho que muchas personas hagan informes personalizados y hagan lo que quieran.

No tengo tiempo para cambiar todos los nombres de variables que ya están en el código.

Me inclino por la legibilidad solo para continuar con su convención de nomenclatura.

Solución

Sí, lo hago. Hace que sea más fácil de seguir por las personas que lo heredan después de usted. Intento limpiar el código un poco para que sea más legible si es realmente difícil de entender.

Otros consejos

Acepto sugerir que dejar el código tal como lo escribió el autor está bien siempre y cuando el código sea internamente consistente. Si el código es difícil de seguir debido a la inconsistencia, usted tiene la responsabilidad de futuro mantenedor (probablemente usted) para hacerlo más claro.

Si pasa 40 horas averiguando qué hace una función porque usa variables mal nombradas, etc., debería refactorizar / renombrar para mayor claridad / agregar comentarios / hacer lo que sea apropiado para la situación.

Dicho esto, si el único problema es que el estilo más consistente que el autor usó es diferente del estándar de la compañía o de lo que estás acostumbrado, creo que estás perdiendo el tiempo cambiando el nombre de todo. Además, puede perder una fuente de experiencia si el autor original todavía está disponible para preguntas porque ya no reconocerá el código.

Si no está cambiando todo el código existente a su estándar, entonces diría que siga las convenciones originales siempre que cambie esos archivos. Mezclar dos estilos de código en el mismo archivo está destruyendo cualquier beneficio que tendría un estilo de código consistente, y el siguiente individuo tendría que preguntarse constantemente quién escribió esta función, cómo se llamará: FooBar () o fooBar ()? "

Este tipo de cosas se vuelve aún más complicado cuando importa bibliotecas de terceros: no desea volver a escribirlas, pero su estilo de código puede no coincidir con el suyo. Entonces, al final, terminarás con varias convenciones de nomenclatura diferentes, y es mejor dibujar líneas claras entre "nuestro código". y " su código " ;.

A menudo, hacer un cambio general en una base de código solo para cumplir con la guía de estilo es solo una forma de introducir nuevos errores con poco valor agregado.

Esto significa que debes:

Actualice el código en el que está trabajando para cumplir con la directriz mientras trabaja en ella.
Use las convenciones del código para ayudar en futuros esfuerzos de mantenimiento.

Recomiendo 2., pero la notación húngara me hace sangrar los ojos: p.

Si mantiene el código que otros escribieron y que otras personas mantendrán después de usted, le debe a todos los involucrados que no realicen cambios gratuitos. Cuando ingresan al sistema de control del código fuente para ver qué ha cambiado, deberían ver lo que fue necesario para solucionar el problema en el que estaba trabajando, y no un millón de diferencias porque realizó un montón de búsquedas globales y reemplazó o volvió a formatear el código para se ajusta a su convención de combinación de llaves favorita.

Por supuesto, si el código original realmente apesta, todas las apuestas están canceladas.

Generalmente, sí, iría por convenciones y legibilidad sobre los estándares en este escenario. A nadie le gusta esa respuesta, pero es lo correcto para mantener el código mantenible a largo plazo.

Cuando el código de lectura de un buen programador, debería poder analizar los nombres de las variables y hacer un seguimiento de varias en su cabeza, siempre que sean coherentes, al menos dentro del archivo fuente. Pero si rompe esa consistencia, es probable que obligue al programador que lee el código a sufrir cierta disonancia cognitiva, lo que dificultaría un poco su seguimiento. No es un asesino: los buenos programadores lo superarán, pero maldecirán su nombre y probablemente lo publicarán en TheDailyWTF .

Ciertamente seguiría utilizando la misma convención de nomenclatura, ya que mantendrá el código consistente (incluso si es feo) y más legible que mezclar convenciones de nomenclatura variable. Los cerebros humanos parecen ser bastante buenos para el reconocimiento de patrones y realmente no quieres lanzarle una bola curva al cerebro rompiendo gratuitamente dicho patrón.

Dicho esto, soy cualquier cosa menos notación húngara, pero si eso es con lo que tienes que trabajar ...

Si el archivo o proyecto ya está escrito con un estilo consistente, entonces debe intentar seguir ese estilo, incluso si entra en conflicto / contradice su estilo existente. Uno de los objetivos principales de un estilo de código es la coherencia, por lo que si introduce un estilo diferente en el código que ya es coherente (dentro de sí mismo) pierde esa coherencia.

Si el código está mal escrito y requiere algún nivel de limpieza para comprenderlo, entonces limpiar el estilo se convierte en una opción más relevante, pero solo debe hacerlo si es absolutamente necesario (especialmente si no hay pruebas unitarias) como tiene la posibilidad de introducir cambios de ruptura inesperados.

Absolutamente sí. El único caso en el que no creo que sea preferible seguir la convención de nomenclatura del programador original es cuando el programador original (o los desarrolladores posteriores que han modificado el código desde entonces) no pudo seguir ninguna convención de nomenclatura coherente.

Sí De hecho, escribí esto en un documento de normas. Creé en mi empresa actual:

El código existente reemplaza a todos los demás estándares y prácticas (ya sean estándares de la industria o los que se encuentran en este documento). En la mayoría de los casos, debe camaleonar su código para que coincida con el código existente en los mismos archivos, por dos razones:

Para evitar tener múltiples estilos / patrones distintos dentro de un solo módulo / archivo (que contradicen el propósito de los estándares y dificultan la mantenibilidad).
El esfuerzo de refactorizar el código existente tiende a ser innecesariamente más costoso (lleva mucho tiempo y conduce a la introducción de nuevos errores).

Personalmente, cada vez que me hago cargo de un proyecto que tiene un esquema de nomenclatura variable diferente, tiendo a mantener el mismo esquema que estaba utilizando el programador anterior. Lo único que hago diferente es que para cualquier variable nueva que agregue, pongo un guión bajo antes del nombre de la variable. De esta manera puedo ver rápidamente mis variables y mi código sin tener que ir al historial de origen y comparar versiones. Pero cuando se trata de heredar un código o comentarios simplemente ilegibles, generalmente los revisaré y los limpiaré lo mejor que pueda sin volver a escribir todo (ha llegado a eso). ¡La organización es clave para tener código extensible!

si puedo leer el código, (intento) tomar las mismas convenciones si no es legible de todos modos, necesito refactorizarlo y así cambiarlo (dependiendo de cómo sea) considerable

Depende. Si estoy creando una nueva aplicación y robando el código de una aplicación heredada con nombres variables de basura, volveré a factorizar una vez que la tenga en mi aplicación.

Sí ... Hay algo más frustrante que entrar en una aplicación que tiene dos estilos drásticamente diferentes. Un proyecto en el que trabajé recientemente tenía dos formas diferentes de manipular archivos, dos formas diferentes de implementar pantallas, dos estructuras de fondos diferentes. El segundo codificador incluso llegó a hacer que las nuevas características formen parte de un dll que se llama desde el código principal. Maintence era una pesadilla y tuve que aprender los dos paradigmas y la esperanza cuando estaba en una sección y trabajaba con la correcta.

Cuando estés en Roma, haz lo que hacen los romanos.

(Excepto los nombres de las variables de índice, por ejemplo, "iArrayIndex ++". Deje de tolerar esa idiotez).

Pienso hacer una corrección de errores como un procedimiento quirúrgico. Entre, moleste lo menos posible, arréglelo, salga, deje el menor rastro posible de su presencia allí.

Sí, pero desafortunadamente, hubo varios desarrolladores antes que yo que no cumplían con esta regla, por lo que tengo varias convenciones de nombres para elegir.

Pero a veces tenemos tiempo para arreglar las cosas, así que al final, será agradable y limpio.

Si el código ya tiene un estilo consistente, incluidos los nombres, trato de seguirlo. Si los programadores anteriores no fueron consistentes, me siento libre de aplicar el estándar de la compañía o mis estándares personales si no hay ningún estándar de la compañía.

En cualquier caso, trato de marcar los cambios que he realizado enmarcandolos con comentarios. Sé que con los sistemas CVS actuales esto a menudo no se hace, pero aún así prefiero hacerlo.

Desafortunadamente, la mayoría de las veces la respuesta es sí. La mayoría de las veces, el código no sigue buenas convenciones, por lo que es difícil seguir el precedente. Pero para facilitar la lectura, a veces es necesario seguir la corriente.

Sin embargo , si se trata de una aplicación lo suficientemente pequeña, puedo refactorizar gran parte del código existente para "oler". mejor, entonces lo haré. O, si esto es parte de una reescritura más grande, también comenzaré a codificar con los estándares de codificación actuales. Pero este no suele ser el caso.

Si hay un estándar en la aplicación existente, creo que es mejor seguirlo. Si no hay un estándar (pestañas y espacios mezclados, llaves en todas partes ... oh, horror), entonces hago lo que creo que es mejor y generalmente ejecuto el código existente a través de una herramienta de formateo (como Vim). Siempre mantendré el estilo de mayúsculas, etc. del código existente si hay un estilo coherente.

Mi única excepción a esta regla es que no usaré la notación húngara a menos que alguien tenga un arma en mi cabeza. No me tomaré el tiempo de cambiar el nombre de las cosas existentes, pero cualquier cosa que agregue nueva no tendrá verrugas húngaras.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow