Comment gérer une fonction mal nommée dans le code de production?

J'ai récemment rencontré une bibliothèque Python sur GitHub. La bibliothèque est géniale, mais contient une faute de frappe flagrante dans un nom de fonction. Appelons cela dummy_fuction()alors qu'il devrait l'être dummy_function(). Cette fonction est définitivement "à l'état sauvage" et très probablement utilisée dans les systèmes embarqués.

La première chose qui me vient à l'esprit est d'ajouter une deuxième version de la fonction avec le nom correct et d'ajouter un avertissement de dépréciation à la première version pour la prochaine version.

Trois questions:

L'approche ci-dessus pourrait-elle avoir des conséquences imprévues?
Existe-t-il une approche standard pour ce type de problème?
Pendant combien de temps un avertissement de dépréciation doit-il être laissé en place?

— Jamie Bull
source

Il s'agit d'une situation (même si elle n'est pas très fréquente) dans laquelle un langage statique est beaucoup plus robuste qu'un langage dynamique: un compilateur pourrait vérifier si votre fonction renommée existe déjà.

— Giorgio

voir aussi HTTP referer [sic]

— AakashM

Je voudrais également souligner le mod_speling d'Apache , mais cela aurait pu être intentionnel.

— Rétablir Monica iamnotmaynard

@AakashM: J'adore la façon dont l'article Wikipédia utilise désormais à la fois l'orthographe incorrecte et correcte tout au long de cette page (même en faisant référence à l'objet, pas au terme), la version mal orthographiée étant plus répandue!

— Martijn Pieters

Une autre bonne chose à propos du http_referer- "C'est comme quand j'ai fait le champ référent. Je n'ai eu que du chagrin pour mon choix d'orthographe. J'essaie maintenant de corriger l'orthographe dans l'OED car mon orthographe est utilisée plusieurs milliards de fois par minute de plus que la leur. " - Phillip Hallam-Baker

— Jamie Bull

Tout d'abord, la politique dépend du mainteneur.

Je pense que votre question est intéressante, mais surtout basée sur l'opinion.

À mon avis, votre approche est bonne - renommez la fonction et laissez la version mal orthographiée comme un artefact obsolète, redirigeant vers la bonne.

L'approche ci-dessus pourrait-elle avoir des conséquences imprévues?

Cela pourrait casser le code par exemple. si quelqu'un ne pouvait pas supporter la faute d'orthographe non plus et implémentait une version renommée de la leur. Maintenant, il y aura un conflit de noms une fois qu'ils auront mis à jour la bibliothèque.

Existe-t-il une approche standard pour ce type de problème?

Ne faites pas de fautes d'orthographe lors de l'écriture d'une bibliothèque;)

Pendant combien de temps un avertissement de dépréciation doit-il être laissé en place?

Je pense que la dépréciation devrait être laissée en place jusqu'à la prochaine version majeure (lorsque le premier chiffre du numéro de version est augmenté).

C'est à ce moment-là qu'une rupture de compatibilité descendante - justifiée - est tolérable, et il appartient aux utilisateurs de la bibliothèque de s'assurer que leur code fonctionne toujours correctement.

Assurez-vous simplement de le signaler dans le journal des modifications: les gars, si vous l'avez utilisé dummy_fuction, remplacez-le par dummy_functionpartout et vous êtes prêt à partir.

Si la bibliothèque n'est pas versionnée, comme cela pourrait l'être - il est judicieux de commencer à la versionner.

— Konrad Morawski
source

Bon à entendre. La bibliothèque est versionnée, donc l'approche du contrôle de version sonne bien. Il a en fait son propre IDE, de sorte que la version mal orthographiée peut être masquée par l'outil de complétion de code, ce qui devrait empêcher les nouveaux utilisateurs de l'utiliser. Si je pouvais vous donner un autre +1 pour la réponse à Q2, je le ferais!

— Jamie Bull

C'est l'approche que j'ai également vue dans d'autres logiciels. J'utilise une API tierce pour un logiciel que je développe et leur API contient une méthode getter qui contient une faute de frappe. Le problème a été résolu en renommant la méthode et en créant une méthode factice avec l'ancienne orthographe (incorrecte) qui appelle simplement la version correcte. La méthode factice ne contient aucune documentation autre que de mentionner qu'elle est obsolète et un lien vers la version correcte. Cette méthode existe depuis des années maintenant, pour éviter de briser toute compatibilité descendante.

— Karl Nicoll