Come gestire una funzione errata nel codice di produzione?

Di recente mi sono imbattuto in una libreria Python su GitHub. La libreria è fantastica, ma contiene un errore di battitura evidente in un nome di funzione. Chiamiamolo dummy_fuction()mentre dovrebbe essere dummy_function(). Questa funzione è sicuramente "allo stato brado" e molto probabilmente utilizzata nei sistemi embedded.

La prima cosa che mi viene in mente è aggiungere una seconda versione della funzione con il nome corretto e aggiungere un avviso di deprecazione alla prima versione per la prossima versione.

Tre domande:

L'approccio sopra potrebbe avere conseguenze non intenzionali?
Esiste un approccio standard a questo tipo di problema?
Per quanto tempo dovrebbe essere lasciato in atto qualsiasi avviso di deprecazione?

— Jamie Bull
fonte

Questa è una situazione (anche se non molto frequente) in cui un linguaggio statico è molto più robusto di un linguaggio dinamico: un compilatore potrebbe verificare se la tua funzione rinominata esiste già.

— Giorgio,

vedi anche referer HTTP [sic]

— AakashM,

Vorrei anche sottolineare il mod_speling di Apache , ma potrebbe essere stato intenzionale.

— Ripristina Monica iamnotmaynard

@AakashM: Adoro il modo in cui l'articolo di Wikipedia ora utilizza sia l'ortografia errata che corretta in quella pagina (anche quando si fa riferimento all'oggetto, non al termine), con la versione errata più prevalente!

— Martijn Pieters,

Un altro aspetto positivo del http_referer- "È come quando ho fatto il campo referer. Non ho avuto altro che dolore per la mia scelta dell'ortografia. Ora sto provando a correggere l'ortografia nell'OED poiché la mia ortografia viene utilizzata diverse miliardi di volte al minuto in più del loro ". - Phillip Hallam-Baker

— Jamie Bull,

Innanzitutto, la politica dipende dal manutentore.

Penso che la tua domanda sia interessante, ma principalmente basata sull'opinione pubblica.

Secondo la mia opinione personale il tuo approccio è valido: rinominare la funzione e lasciare la versione errata come artefatto deprecato, reindirizzando a quella corretta.

L'approccio sopra potrebbe avere conseguenze non intenzionali?

Potrebbe rompere il codice ad es. se qualcuno non sopportava l'ortografia e implementava una versione rinominata. Ora ci sarà uno scontro di nomi una volta che aggiorneranno la libreria.

Esiste un approccio standard a questo tipo di problema?

Non commettere errori di ortografia durante la scrittura di una libreria;)

Per quanto tempo dovrebbe essere lasciato in atto qualsiasi avviso di deprecazione?

Credo che la deprecazione debba essere lasciata al suo posto fino alla prossima versione principale (quando la prima cifra nel numero di versione viene aumentata).

Questo è quando alcune (giustificate) interruzioni della compatibilità con le versioni precedenti sono tollerabili e spetta agli utenti della libreria assicurarsi che il loro codice continui a essere compilato correttamente.

Assicurati di segnalarlo nel log delle modifiche: ragazzi, se lo avete usato dummy_fuction, sostituitelo con dummy_functionovunque e siete pronti per partire.

Se la libreria non è dotata di versione, per quanto sia possibile, è consigliabile iniziare la versione.

— Konrad Morawski
fonte

Buono a sapersi. La libreria ha una versione in modo che l'approccio al controllo della versione suona bene. In realtà ha un proprio IDE, quindi la versione errata può essere nascosta dallo strumento di completamento del codice che dovrebbe impedire ai nuovi utenti di usarla. Se potessi darti un altro +1 per la risposta a Q2 lo farei!

— Jamie Bull,

Questo è l'approccio che ho visto anche in altri software. Uso un'API di terze parti per un software che sviluppo e la loro API contiene un metodo getter che contiene un refuso. Il problema è stato risolto rinominando il metodo e creando un metodo fittizio con l'ortografia vecchia (errata) che chiama semplicemente la versione corretta. Il metodo fittizio non contiene altra documentazione se non quella di menzionare che è obsoleto e un collegamento alla versione corretta. Tale metodo esiste da anni ormai, per evitare di rompere qualsiasi compatibilità con le versioni precedenti.

— Karl Nicoll,