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

Question

Si asumes el control de un proyecto de alguien para hacer actualizaciones simples ¿sigues su convención de nombres? 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 hemos tenido mucha gente haciendo reportes personalizados a lo largo de los años y hacían lo que les daba la gana.

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

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

Answer 1

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

Answer 2

A menudo, hacer un cambio al por mayor a 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, o bien se debe:

1. actualizar el código que está trabajando para cumplir con la directriz a medida que trabaja en ella.

2. Utilice las convenciones en el código para ayudar en los esfuerzos futuros de mantenimiento.

Recomendaría 2., pero la notación húngara hace sangrar mis ojos: p.

Answer 3

En general, sí, prefiero la convención y la legibilidad a los estándares en este escenario. A nadie le gusta esa respuesta, pero es lo correcto para mantener el código a largo plazo.

Cuando es un buen código de lectura del programador, debería ser capaz de analizar los nombres de las variables y realizar un seguimiento de varios en su cabeza, siempre que sean coherentes, al menos dentro del archivo de origen. Pero si rompe esa consistencia, probablemente forzará al programador que lee el código a sufrir alguna disonancia cognitiva, lo que haría que sea un poco más difícil hacer un seguimiento. No es un asesino: los buenos programadores lo superarán, pero maldecirán tu nombre y probablemente te publiquen en TheDailyWTF.

Answer 4

Si mantiene el código que otros escribieron y que otras personas van a conservar después de usted, le debe a todos los involucrados no realizar cambios gratuitos. Cuando entren al sistema de control de código fuente para ver qué cambiaste, deberían ver lo que era necesario para solucionar el problema en el que estabas trabajando, y no un millón de diffs porque hiciste un montón de búsquedas globales y reemplazaste o reformateaste el código para adaptarse a su convención de coincidencia de corcho favorito.

Por supuesto, si el código original es una mierda, todas las apuestas están desactivadas.

Answer 5

Ciertamente seguiría usando la misma convención de nomenclatura, ya que mantendrá el código constante (incluso si es siempre feo) y más legible que la mezcla de convenciones de nomenclatura variable. Los cerebros humanos parecen ser bastante buenos en el reconocimiento de patrones y realmente no se quiere lanzar al cerebro una bola curva rompiendo dicho patrón.

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

Answer 6

Personalmente siempre que asumo un proyecto que tiene un esquema de nomenclatura de variable diferente, tiendo a mantener el mismo esquema que estaba usando 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 entrar en el historial de fuentes y comparar versiones. Pero cuando se trata de heredar códigos o comentarios que simplemente no se pueden leer, generalmente los repaso y los limpio lo mejor que puedo sin volver a escribir todo (se ha llegado a eso). ¡La organización es clave para tener un código extensible!

Answer 7

si puedo leer el código, (TRY) a tomar las mismas convenciones si no es legible de todos modos tengo que refactorizar y por lo tanto cambiándolo (dependiendo de lo que su gusto) una considerable

Answer 8

Depende. Si estoy construyendo una nueva aplicación y robando el código de una aplicación heredada con nomenclatura de mierda de nombres, voy a refactorizar una vez que lo tenga en mi aplicación.

Answer 9

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

Este tipo de cosas se vuelven aún más complicadas cuando se importan bibliotecas de terceros: no desea volver a escribirlas, pero su estilo de código podría no coincidir con el suyo. Entonces, al final, terminará con varias convenciones de nombres diferentes, y es mejor trazar líneas claras entre "nuestro código" y "su código".

Answer 10

Si el archivo o proyecto ya está escrito usando 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 cierto nivel de limpieza para comprenderlo, 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 de unidad) mientras ejecuta la posibilidad de introducir cambios inesperados de ruptura.

Answer 11

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 subsiguientes que han modificado el código desde entonces) no siguió ninguna convención de nomenclatura consistente.

Answer 12

Sí .. Hay algo más frustrante que entrar en una aplicación que tiene dos estilos drásticamente diferentes. Un proyecto en el que he trabajado recientemente tenía dos formas diferentes de manipular archivos, dos formas diferentes de implementar pantallas, dos estructuras fundiales diferentes. El segundo codificador llegó incluso a hacer que las nuevas funciones formen parte de un dll que recibe llamadas desde el código principal. Maintence era una pesadilla y tuve que aprender ambos paradigmas y la esperanza cuando estaba en una sección que estaba trabajando con la correcta.

Answer 13

Cuando esté en Roma haga lo mismo que los romanos.

(A excepción de nombres variables de índice, por ejemplo "iArrayIndex ++". Dejar de tolerar que la idiotez.)

Answer 14

pienso en hacer una corrección de errores como un procedimiento quirúrgico. Métete, distiéndete lo menos posible, arréglelo, salga, deje tan poca huella de su presencia como sea posible.

Answer 15

Estoy de acuerdo que dejando el código como el autor lo escribió está bien , siempre que el código sea internamente consistente. Si el código es difícil de seguir debido a la incoherencia, usted tiene la responsabilidad del futuro mantenedor (probablemente usted) para hacerlo más claro.

Si pasas 40 horas para averiguar lo que hace una función, ya que utiliza las variables mal llamada, etc., se debe refactor/cambiar el nombre de la claridad/añadir el comentario/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 utilizó es diferente del estándar de la compañía o de lo que está acostumbrado, creo que está perdiendo el tiempo para cambiarle el nombre a 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.

Answer 16

Sí, pero desafortunadamente, hubo varios desarrolladores antes que yo que no cumplieron con esta regla, así que tengo varias convenciones de nombres para elegir.

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

Answer 17

Si el código ya tiene un estilo consistente, incluido el nombre, trato de seguirlo. Si los programadores anteriores no fueron consistentes, entonces me siento libre de aplicar el estándar de la compañía o mis estándares personales si no existe un estándar de la compañía.

En cualquiera de los casos, trato de marcar los cambios que he hecho al enmarcarlos con comentarios. Sé que con los sistemas de CVS de hoy a menudo esto no se hace, pero aún así prefiero hacerlo.

Answer 18

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

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

Answer 19

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

El código existente sustituye 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 camaleón su código para que coincida con el código existente en los mismos archivos, por dos razones:

1. para evitar tener varios estilos distintos/patrones dentro de un solo módulo/archivo (que contradicen el propósito de estándares y mantenimiento del obstáculo).
2. El esfuerzo de refactorizar el código existente es propenso a ser innecesariamente más costoso (lleva mucho tiempo y conduce a la introducción de nuevos errores).

Answer 20

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 el 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 capitalización, etc. del código existente si hay un estilo coherente.

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