Correction d'une faute d'orthographe dans un nom de méthode

73

Une des méthodes que j'utilise couramment dans notre base de code est mal orthographiée (et elle m'a précédée).

Cela m'irrite vraiment pas simplement parce qu'il est mal orthographié, mais plus important encore, je me trompe TOUJOURS le premier fois que je tape le nom (et ensuite je dois me rappeler "Oh, oui, il devrait être mal orthographié ...")

Je fais quelques changements autour de la méthode originale. Devrais-je en profiter pour renommer la méthode freaking?

refactoring

— Un deux trois
source

12

Pouvez-vous le renommer? S'il est utilisé par un code que vous ne contrôlez pas, vous devez justifier la rupture de compatibilité ascendante.

16

* mal orthographié. Et vous devrez le changer partout où cette méthode est appelée.

— JohnP

2

* mal épelé ... ou peut-être une orthographe différente?

— HorusKol

2

@JohnP Il y en avait trois, maintenant un est corrigé et deux sont toujours incorrects. Par coïncidence convient très bien au nom de OP. :)

— Désillusionné le

3

Il ne faut rien permettre d'être mal pillé!

— Magus

136

Devrais-je en profiter pour renommer la méthode freaking?

Absolument.

Cela dit, si votre code a été publié en tant qu'API, vous devez également généralement laisser la méthode mal orthographiée et la transmettre à la méthode correctement nommée (la marquant comme obsolète si votre langue prend en charge de telles choses).

— Telastyn
source

33

L'idée de "transmettre à la méthode correctement nommée" est simple et brillante. Lien intéressant sur la théorie des fenêtres brisées.

— dev_feed

2

Notez que si cela fait partie d'une API publique, il se peut que cette modification ne soit pas compatible avec les versions antérieures (selon la langue). Ce n'est pas aussi improbable que cela puisse paraître. Si je devais hériter d'une API existante avec un nom mal orthographié, je corrigerais certainement cela.

— Voo

10

@voo - hein? Quel langage rendrait l'ajout d'une nouvelle méthode (et la modification de son implémentation afin qu'elle reproduise le même comportement) ne soit pas compatible avec les versions antérieures?

— Telastyn

3

@Telastyn, il peut parfois être difficile d'ajouter des méthodes pour dire des services Web. Par exemple, certains clients hésitent à changer de WSDL et refusent soudainement de parler au serveur. C'est un problème d'implémentation chez le client, mais si le client est un client important, vous ne voulez pas le contrarier, il peut très bien vous empêcher de modifier votre interface.

— Jwenting

17

@Telastyn Si le nom de la méthode mal orthographié se trouve sur une interface (comme dans le type d'interface utilisé dans Delphi / Java / C #), l'ajout d'une version du nom correctement orthographié briserait probablement toutes les implémentations existantes de cette interface.

— Désillusionné

52

Il y a des cas où vous devriez éviter de faire de tels refactorings:

Si la méthode est utilisée dans une interface publique. Un exemple canonique est l’orthographe erronée de refererrer dans le référent HTTP , l’orthographe erronée étant conservée, car changer l’orthographe aurait maintenant trop de répercussions.
Si la base de code n'est couverte par aucun test. Toute refactorisation doit être effectuée sur du code testé afin de pouvoir effectuer des tests de régression. Refactoriser la base de code non testée est particulièrement risqué. Si vous avez beaucoup de temps, commencez par ajouter des tests; si vous travaillez sous la pression du temps, prendre le risque d'introduire des bugs subtils n'est pas la meilleure chose à faire si vous souhaitez expédier à temps.
Si la méthode peut être utilisée de manière inhabituelle , cela rend son utilisation pratiquement impossible à trouver (via Ctrl + F ou à l'aide d'un outil de refactoring automatisé). Par exemple, en C #, une méthode peut être appelée via Reflection, ce qui rend la boîte de dialogue Renommer de Visual Studio inefficace. En JavaScript, la fonction appelée inside eval()est également difficile à trouver. En PHP, les variables variables peuvent causer des problèmes.
Si la taille du projet est énorme et que la méthode peut être utilisée par d'autres équipes. Ceci est similaire au premier point, c.-à-d. Que l'interface que vous fournissez aux autres équipes peut être considérée comme une interface publique.
Si vous traitez avec un projet critique de la vie. Les erreurs d’orthographe ne sont pas très importantes pour justifier quelques mois de paperasse afin de changer le nom de la méthode et d’assurer qu’un patient ne reçoive pas dix fois plus de radiations autorisées, ni aucune navette ne calculera mal sa vitesse.

Dans toute autre situation, n'hésitez pas à renommer la méthode.

— Arseni Mourzenko
source

1

+1 pour le commentaire mentionnant Reflection, ça m'a mordu plus d'une fois.

— DaveShaw

33

Si votre projet essentiel à la vie est suffisamment fragile pour que la moindre refonte soit susceptible de tuer quelqu'un, il est suffisamment fragile pour que personne ne puisse lui faire confiance. Comment pouvez-vous être sûr que votre nouvelle fonctionnalité ou votre interface utilisateur simplifiée n'a pas introduit de bugs mettant votre vie en danger si vous ne pouvez même pas renommer une méthode?

— user2357112

2

De même, si un nom de méthode modifié entraîne plusieurs mois de paperasse supplémentaire (plutôt que, par exemple, la paperasserie s'occupe de toutes les autres choses qui changent en même temps), alors la balance entre la programmation et la paperasse est faussée par plusieurs ordres de grandeur, et il est impossible d'obtenir une amélioration majeure sans changer le système.

— user2357112

8

@ user2357112: Je n'ai jamais dit que le moindre refactoring risquait de tuer quelqu'un. Il ne s'agit pas de tuer quelqu'un, mais de faire tout son possible pour atténuer le risque restant de 0,001% d'avoir un bogue. Cela nécessite un prof formel. Cela nécessite plusieurs couches de test. Cela nécessite du formalisme. Cela interdit "Je veux renommer rapidement cette méthode, j'espère que cela fonctionnerait!" comportement. Les projets critiques utilisent des techniques qui seraient considérées comme une perte de temps et d’argent pour toute application professionnelle. C'est pourquoi ils sont si fiables (et chers).

— Arseni Mourzenko

5

@ user2357112: comme l'a souligné MainMa, il ne s'agit pas d'applications professionnelles occasionnelles. Il s'agit d'un type de logiciel spécial qui est testé / vérifié de manière approfondie. Et si la méthode s'appelle par réflexion quelque part? Que se passe-t-il si un outil de pré / post-compilation fait quelque chose avec? Qu'en est-il de la documentation? Qu'en est-il des autres équipes qui l'utilisent? Utilisent-ils la réflexion? Et si ... La vie réelle peut parfois être assez complexe. Et parfois, il est préférable de laisser un nom de méthode intact, plutôt que de vérifier s'il y a des conséquences à l'épreuve des balles.

— dagnelies

30

Je l'ai fait il y a quelques mois (pour différentes raisons). Les étapes que j'ai prises (la langue était Perl):

Renommez la méthode. Alias l'ancien nom avec le nouveau nom (cela ne devrait pas briser le code, car la méthode peut être appelée par l'un ou l'autre nom).
Informez les autres développeurs du changement de nom et de la raison, en leur disant d'utiliser le nouveau nom à partir de maintenant.
Grep la base de code pour l'ancien nom, corrige toutes les occurrences.
Consignez toutes les utilisations de l'ancien nom (utiliser l'ancien devrait toujours fonctionner à ce moment-là). Corrigez ces cas.
Attendez (en faisant 4.), jusqu'à ce que plus aucune entrée n'apparaisse dans le journal.
Casser l'alias. Créez une méthode en utilisant l'ancien nom qui lève une exception fatale avec un message sur le changement de nom.
Après un certain temps, supprimez la méthode avec l'ancien nom.

Bien sûr, votre kilométrage variera.

— Abigail
source

Une amélioration - ne comptez pas sur grep pour rechercher les utilisateurs de l'ancien nom, connectez-vous également à l'intérieur du redirecteur.

— Ben Voigt

@ BenVoigt N'est-ce pas ce que fait le n ° 4?

— Bob

6

Un bon moyen de ne casser aucun code existant serait de chaîner le nouveau nom de la méthode à l'ancien, par exemple

private void MyNewMethodName()
{
    TheOldMethodName();
}

puis marquez l'ancienne méthode comme obsolète (si votre langue le supporte). De cette façon, tout code existant fonctionnera toujours et vous pourrez éliminer progressivement l’ancienne erreur d’orthographe de votre base de code. Finalement, vous pourriez même copier / coller le corps de la méthode dans la nouvelle méthode et supprimer l’ancien.

/ Edit Comme le disait ivo dans le commentaire: Une meilleure chose à faire serait de déplacer le code de TheOldMethodNamedans le MyNewMethodNameet d'appeler la nouvelle méthode à partir de l'ancienne. Celui-ci aurait également l'avantage d'aider le développeur à se faire une idée de l'endroit où le code appartient.

— Rémi
source

2

Je suis d'accord avec votre méthode. Je voudrais faire la même chose. C'est la méthode de refactoring la plus saine, la plus claire et la plus sûre. Ce qui pourrait aussi être un bon moyen est de déplacer le code de l'ancienne méthode dans la nouvelle méthode et de faire en sorte que l'ancienne utilise la nouvelle méthode. Lorsque la base de code se trouve à quelques itérations de la timeline, il vous suffit de supprimer l'ancienne méthode obsolète.

— Ivo Limmen

1

@IvoLimmen C'est une très bonne suggestion. De cette façon, les gens ont encore plus de mal à utiliser la nouvelle méthode, ce qui supprime un avertissement de l'appel obsolète à l'ancienne méthode de la nouvelle. Je vais ajouter ceci à ma réponse.

— Rémi

1

Renommer la méthode:

Faites-le en refacturant de peur que vous n'ayez plus de travail à faire que vous ne le souhaitez
Si votre IDE supporte l'auto-complétion, utilisez-la pour référencer cette méthode

Ce sont deux options que vous pourriez choisir. Je préférerais l'auto-complétion (ex. Eclipse IDE) et n'ai pas besoin de taper le nom de la méthode. Aller pour le renommer; Assurez-vous simplement de savoir ce qui appelle cette méthode et modifiez les références directes à chaque endroit. Le refactoring sera votre ami pour cela, mais soyez très prudent lorsque vous le faites.

— Détrempé
source

0

Je recommanderais généralement oui, le renommer.

D'autres réponses ici ont énuméré les bonnes raisons pour lesquelles vous pourriez ne pas vouloir le renommer, alors si vous vous trouvez dans une telle situation, vous pouvez créer une nouvelle méthode avec le nom et l'implémentation appropriés et modifier l'ancienne méthode pour appeler la nouvelle méthode. . Ensuite, marquez l’ancien comme obsolète si votre langue le supporte.

— Brian
source