¿Cómo lidiar con una función mal nombrada en el código de producción?

Recientemente me encontré con una biblioteca de Python en GitHub. La biblioteca es excelente, pero contiene un error tipográfico deslumbrante en el nombre de una función. Llamémoslo dummy_fuction()mientras debería ser dummy_function(). Esta función es definitivamente "en la naturaleza" y probablemente se usa en sistemas embebidos.

Lo primero que me viene a la mente es agregar una segunda versión de la función con el nombre correcto y agregar una advertencia de desaprobación a la primera versión para la próxima versión.

Tres preguntas:

¿Podría el enfoque anterior tener consecuencias no deseadas?
¿Existe un enfoque estándar para este tipo de problema?
¿Cuánto tiempo se debe dejar en su lugar una advertencia de desaprobación?

— Jamie Bull
fuente

Esta es una situación (aunque no muy frecuente) en la que un lenguaje estático es mucho más robusto que uno dinámico: un compilador podría verificar si su función renombrada ya existe.

— Giorgio

ver también HTTP referer [sic]

— AakashM

También señalaría mod_speling de Apache , pero eso podría haber sido intencional.

— Reinstale a Monica iamnotmaynard

@AakashM: Me encanta cómo el artículo de Wikipedia ahora usa la ortografía incorrecta y correcta en toda esa página (incluso cuando se refiere al objeto, no al término), ¡con la versión mal escrita más frecuente!

— Martijn Pieters,

Otro buen detalle sobre http_referer: "Es como cuando hice el campo de referencia. No tengo nada más que pena por mi elección de ortografía. Ahora estoy tratando de corregir la ortografía en el DEO ya que mi ortografía se usa varios miles de millones de veces más por minuto". que la de ellos ". - Phillip Hallam-Baker

— Jamie Bull

En primer lugar, la política depende del responsable.

Creo que su pregunta es interesante, pero sobre todo basada en opiniones.

En mi opinión personal, su enfoque es sólido: cambie el nombre de la función y deje la versión mal escrita como un artefacto obsoleto, redirigiendo a la correcta.

¿Podría el enfoque anterior tener consecuencias no deseadas?

Podría romper el código, por ejemplo. si alguien tampoco podía soportar la falta de ortografía e implementaba una versión renombrada propia. Ahora habrá un choque de nombres una vez que actualicen la biblioteca.

¿Existe un enfoque estándar para este tipo de problema?

No cometas errores ortográficos al escribir una biblioteca;)

¿Cuánto tiempo se debe dejar en su lugar una advertencia de desaprobación?

Creo que la desaprobación debe dejarse en su lugar hasta la próxima versión principal (cuando se aumenta el primer dígito en el número de versión).

Esto es cuando es tolerable alguna ruptura de compatibilidad hacia atrás, justificada, y corresponde a los usuarios de la biblioteca asegurarse de que su código siga funcionando correctamente.

Solo asegúrate de señalarlo en el registro de cambios: chicos, si lo usaste dummy_fuction, reemplázalo por dummy_functiontodas partes y listo.

Si la biblioteca no está versionada, como podría estarlo, es un buen caso para comenzar a versionarla.

— Konrad Morawski
fuente

Es bueno escucharlo. La biblioteca está versionada, por lo que el enfoque del control de versiones suena bien. En realidad, tiene su propio IDE, por lo que la versión mal escrita puede ocultarse de la herramienta de finalización de código, lo que debería evitar que los nuevos usuarios la utilicen. ¡Si pudiera darte otro +1 por la respuesta a la Q2, lo haría!

— Jamie Bull

Este es el enfoque que he visto en otro software también. Utilizo una API de terceros para una pieza de software que desarrollo, y su API contiene un método getter que contiene un error tipográfico. El problema se solucionó cambiando el nombre del método y creando un método ficticio con la ortografía antigua (incorrecta) que simplemente llama a la versión correcta. El método ficticio no contiene documentación más que mencionar que está en desuso y un enlace a la versión correcta. Ese método ha estado allí durante años para evitar romper cualquier compatibilidad con versiones anteriores.

— Karl Nicoll