Correzione di un errore di ortografia nel nome di un metodo

73

Uno dei metodi che uso comunemente nella nostra base di codice è scritto erroneamente (e mi ha preceduto).

Questo mi irrita davvero non solo perché è scritto in modo errato, ma soprattutto mi fa SEMPRE sbagliare il nome la prima volta che lo scrivo (e poi devo ricordare "Oh, giusto, dovrebbe essere errato a questo ...")

Sto apportando alcune modifiche al metodo originale. Dovrei cogliere l'occasione per rinominare semplicemente il metodo impazzito?

refactoring

— Uno due tre
fonte

12

Puoi rinominarlo? Se viene utilizzato da un codice che non controlli, devi giustificare l'interruzione della compatibilità con le versioni precedenti.

16

* errata. E dovrai cambiarlo ovunque venga chiamato quel metodo.

— JohnP,

2

* errore di ortografia ... o forse un'ortografia diversa?

— HorusKol,

2

@JohnP Ce n'erano tre, ora uno è stato corretto e due sono ancora errati. Per coincidenza si adatta abbastanza bene al nome di OP. :)

— Disilluso il

3

Non dobbiamo permettere che nulla venga impilato in modo errato!

— Magus,

136

Dovrei cogliere l'occasione per rinominare semplicemente il metodo impazzito?

Assolutamente.

Detto questo, se il tuo codice è stato rilasciato come API, generalmente dovresti anche lasciare il metodo errato e inoltrarlo al metodo corretto (contrassegnandolo Obsoleto se la tua lingua supporta tali cose).

— Telastyn
fonte

33

L'idea di "passare al metodo corretto" è semplice e geniale. Interessante collegamento anche sulla teoria delle finestre rotte.

— dev_feed,

2

Se fa parte di un'API pubblica, potrebbe non essere una modifica compatibile con le versioni precedenti (a seconda della lingua). Questo non è così improbabile come potrebbe sembrare ... se dovessi ereditare da un'API esistente con un nome errato lo risolverei sicuramente.

— Voo,

10

@voo - eh? Quale lingua renderebbe l'aggiunta di un nuovo metodo (e la modifica dell'implementazione di uno per fare lo stesso comportamento esatto) non essere retrocompatibile?

— Telastyn,

3

@Telastyn a volte può essere complicato aggiungere metodi per dire servizi web. Alcuni client si rifiutano di cambiare WSDL per esempio, all'improvviso si rifiutano di parlare con il server. Questo è un problema di implementazione nel client, ma se il client è importante non si desidera sconvolgerlo, può benissimo impedirti di cambiare l'interfaccia.

— jwenting

17

@Telastyn Se il nome del metodo misspelt si trova su un'interfaccia (come nel tipo di interfaccia utilizzato in Delphi / Java / C #), l'aggiunta di una versione corretta del nome probabilmente interromperà tutte le implementazioni esistenti di detta interfaccia.

— Disilluso il

52

Ci sono casi in cui dovresti evitare di fare questi refactoring:

Se il metodo viene utilizzato in un'interfaccia pubblica. Un esempio canonico è l'ortografia errata del referrer nel referer HTTP , l'ortografia errata viene mantenuta, perché la modifica dell'ortografia ora avrebbe troppe ripercussioni.
Se la base di codice non è coperta da alcun test. Qualsiasi refactoring deve essere eseguito su codice testato per poter eseguire test di regressione. Il refactoring della base di codice che non è sotto test è particolarmente rischioso. Se hai molto tempo, inizia aggiungendo dei test; se lavori sotto pressione del tempo, correre il rischio di introdurre bug impercettibili non è la cosa migliore da fare se desideri spedire in tempo.
Se il metodo potesse essere utilizzato in un modo insolito , il che rende praticamente impossibile trovare i suoi usi (tramite Ctrl + F o uno strumento di refactoring automatizzato). Ad esempio, in C #, è possibile richiamare un metodo tramite Reflection, rendendo inefficace la finestra di dialogo Rinomina di Visual Studio. In JavaScript, anche la funzione chiamata inside eval()è difficile da trovare. In PHP, le variabili variabili potrebbero causare problemi.
Se la dimensione del progetto è enorme e il metodo potrebbe essere utilizzato da altri team. Questo è simile al primo punto, ovvero l'interfaccia che fornisci ad altri team può essere considerata un'interfaccia pubblica.
Se hai a che fare con un progetto critico per la vita. È probabile che l'ortografia non sia troppo importante per giustificare alcuni mesi di scartoffie al fine di cambiare il nome del metodo e garantire che non causi a nessun paziente di ricevere dieci volte la radiazione autorizzata o qualsiasi navetta per calcolare erroneamente la sua velocità.

In qualsiasi altra situazione, sentiti libero di rinominare il metodo.

— Arseni Mourzenko
fonte

1

+1 per il commento che menziona Reflection, mi ha morso più di una volta.

— DaveShaw l'

33

Se il tuo progetto critico per la vita è abbastanza fragile da far sì che il minimo refactoring possa uccidere qualcuno, è abbastanza fragile che nessuno dovrebbe fidarsi della propria vita. Come avrai mai la certezza che la tua nuova funzionalità o l'interfaccia utente ottimizzata non abbia introdotto bug potenzialmente letali se non riesci nemmeno a rinominare un metodo?

— user2357112

2

Allo stesso modo, se un nome di metodo modificato causa diversi mesi extra di scartoffie (piuttosto che, diciamo, per lo più prendersi cura delle scartoffie per tutte le altre cose che cambiano allo stesso tempo), allora il bilancio da programmazione a scartoffie è distorto di diversi ordini di grandezza ed è impossibile ottenere importanti miglioramenti senza cambiare il sistema.

— user2357112

8

@ user2357112: Non ho mai detto che il minimo refactoring possa uccidere qualcuno. Non si tratta di uccidere qualcuno, ma di rendere tutto il possibile per mitigare il rimanente rischio dello 0,001% di avere un bug. Ciò richiede un proff formale. Ciò richiede diversi livelli di test. Ciò richiede formalismo. Ciò proibisce "Voglio rinominare rapidamente questo metodo, speriamo che funzioni!" comportamento. I progetti critici per la vita utilizzano tecniche che sarebbero considerate una completa perdita di tempo e denaro per qualsiasi app aziendale. Ecco perché sono così affidabili (e costosi).

— Arseni Mourzenko,

5

@ user2357112: come sottolineato da MainMa, non si tratta di app aziendali occasionali. Si tratta di un tipo speciale di software ampiamente testato / verificato. Che cosa succede se il metodo viene chiamato dalla riflessione da qualche parte? Cosa succede se uno strumento di compilazione pre / post fa qualcosa con esso? E la documentazione? E gli altri team che lo usano? Usano la riflessione? E se ... La vita reale a volte può essere piuttosto complessa. E a volte è meglio lasciare intatto il nome di un metodo piuttosto che verificare se ci sono conseguenze in modo a prova di proiettile.

— Dagnelies,

30

L'ho fatto alcuni mesi fa (per diversi motivi). I passi che ho fatto (la lingua era Perl):

Rinomina il metodo. Alias il vecchio nome con il nuovo nome (ciò non dovrebbe interrompere alcun codice, poiché il metodo può essere chiamato con uno dei due nomi).
Informa il resto degli sviluppatori sulla modifica del nome e sul perché, dicendo loro di utilizzare il nuovo nome da ora in poi.
Grep la base di codice per il vecchio nome, correggere eventuali occorrenze.
Registra eventuali usi del vecchio nome (l'utilizzo del vecchio nome dovrebbe ancora funzionare in questo momento). Risolvi quei casi.
Attendere (mentre si esegue 4.), fino a quando non vengono più visualizzate voci nel registro.
Rompere l'alias. Crea un metodo utilizzando il vecchio nome che genera un'eccezione irreversibile con un messaggio sulla modifica del nome.
Dopo qualche tempo, rimuovere il metodo con il vecchio nome.

Naturalmente, il tuo chilometraggio varierà.

— Abigail
fonte

Un miglioramento: non fare affidamento su grep per trovare utenti con il vecchio nome, ma accedi anche allo spedizioniere.

— Ben Voigt,

@BenVoigt Non è quello che fa # 4?

— Bob,

6

Un buon modo per non violare alcun codice esistente sarebbe quello di concatenare il nome del nuovo metodo al vecchio in un esempio

private void MyNewMethodName()
{
    TheOldMethodName();
}

e quindi segna il vecchio metodo come obsoleto (se la tua lingua lo supporta). In questo modo qualsiasi codice esistente funzionerà ancora e potrai gradualmente eliminare tutti i vecchi errori di ortografia dalla tua base di codice. Alla fine potresti persino copiare / incollare il corpo del metodo nel nuovo metodo ed eliminare quello vecchio.

/ Modifica Come ha detto ivo nel commento: Una cosa ancora migliore da fare sarebbe spostare il codice da TheOldMethodNamein MyNewMethodNamee chiamare il nuovo metodo da quello vecchio. Questo avrebbe anche il vantaggio di aiutare lo sviluppatore a capire dove appartiene il codice.

— Rémi
fonte

2

Sono d'accordo con il tuo metodo; Io farei lo stesso. È il metodo di refactoring più sano, chiaro e sicuro. Quello che potrebbe anche essere un bel modo è di spostare il codice dal vecchio metodo nel nuovo metodo e fare in modo che quello vecchio usi il nuovo metodo. Quando la base di codice contiene alcune iterazioni lungo la linea temporale, è sufficiente rimuovere il vecchio metodo obsoleto.

— Ivo Limmen,

1

@IvoLimmen È davvero un buon suggerimento. In questo modo le persone ottengono ancora di più la testa usando il nuovo metodo e questo eliminerebbe un avvertimento dalla chiamata obsoleta al vecchio metodo dall'interno di quello nuovo. Aggiungerò questo alla mia risposta.

— Rémi,

1

Rinominare il metodo:

Fallo attraverso il refactoring per non avere più lavoro da fare di quello che desideri
Se il tuo IDE supporta il completamento automatico, utilizzalo quando fai riferimento a quel metodo

Queste sono due opzioni che potresti scegliere. Preferirei il completamento automatico (es. Eclipse IDE) e non è necessario digitare il nome del metodo. Andare per la ridenominazione; assicurati solo di scoprire ciò che chiama quel metodo e di cambiare i riferimenti diretti in ogni luogo. Il refactoring sarà tuo amico per questo, ma fai molta attenzione quando lo fai.

— pastoso
fonte

0

Consiglierei generalmente di sì, rinominalo.

Altre risposte qui hanno elencato buoni motivi per cui potresti non voler rinominarlo, quindi se ti trovi in una situazione del genere, puoi creare un nuovo metodo con il nome e l'implementazione appropriati e modificare il vecchio metodo per chiamare il nuovo metodo . Quindi contrassegnare quello vecchio come deprecato se la tua lingua lo supporta.

— Brian
fonte