Jak radzić sobie z błędnie nazwaną funkcją w kodzie produkcyjnym?

Ostatnio natrafiłem na bibliotekę Python na GitHub. Biblioteka jest świetna, ale zawiera jedną rażącą literówkę w nazwie funkcji. Nazwijmy to dummy_fuction()tak, jak powinno być dummy_function(). Ta funkcja jest zdecydowanie „na wolności” i najprawdopodobniej używana w systemach wbudowanych.

Pierwszą rzeczą, jaka przychodzi mi do głowy, jest dodanie drugiej wersji funkcji o poprawnej nazwie i dodanie ostrzeżenia o wycofaniu do pierwszej wersji dla następnej wersji.

Trzy pytania:

Czy powyższe podejście może mieć niezamierzone konsekwencje?
Czy istnieje standardowe podejście do tego rodzaju problemu?
Jak długo należy pozostawić ostrzeżenie o rezygnacji?

— Jamie Bull
źródło

Jest to sytuacja (choć niezbyt częsta), w której język statyczny jest znacznie bardziej odporny niż język dynamiczny: kompilator może sprawdzić, czy funkcja o zmienionej nazwie już istnieje.

— Giorgio

patrz także odsyłacz HTTP [sic]

— AakashM

Chciałbym również zwrócić uwagę na mod_speling Apache , ale mogło to być celowe.

— Przywróć Monikę iamnotmaynard

@AakashM: Uwielbiam to, jak artykuł Wikipedii używa teraz zarówno niepoprawnej, jak i poprawnej pisowni na tej stronie (nawet jeśli odnosi się do obiektu, a nie terminu), a błędna wersja jest bardziej rozpowszechniona!

— Martijn Pieters

Kolejna dobra informacja na temat http_referer- „To tak, jak wtedy, gdy robiłem pole referer. Mam tylko żal z powodu wyboru pisowni. Teraz próbuję poprawić pisownię w OED, ponieważ moja pisownia jest używana kilka miliardów razy na minutę więcej niż ich. ” - Phillip Hallam-Baker

— Jamie Bull

Przede wszystkim polityka zależy od opiekuna.

Myślę, że twoje pytanie jest interesujące, ale w większości oparte na opiniach.

Moim osobistym zdaniem twoje podejście jest zdrowe - zmień nazwę funkcji i pozostaw błędną wersję jako przestarzały artefakt, przekierowując na właściwy.

Czy powyższe podejście może mieć niezamierzone konsekwencje?

Może to uszkodzić kod np. jeśli ktoś nie mógł znieść błędu pisowni i zaimplementował własną wersję o zmienionej nazwie. Po aktualizacji biblioteki nastąpi konflikt nazw.

Czy istnieje standardowe podejście do tego rodzaju problemu?

Nie popełniaj błędów ortograficznych podczas pisania biblioteki;)

Jak długo należy pozostawić ostrzeżenie o rezygnacji?

Uważam, że wycofanie powinno pozostać na miejscu aż do następnej ważnej wersji (kiedy pierwsza cyfra w numerze wersji zostanie zwiększona).

Dzieje się tak, gdy pewne - uzasadnione - łamanie wstecznej kompatybilności jest dopuszczalne i od użytkowników biblioteki zależy, czy ich kod nadal będzie działał poprawnie.

Po prostu zaznacz to w dzienniku zmian: chłopaki, jeśli używałeś dummy_fuction, zamień go na dummy_functionwszędzie i możesz już iść.

Jeśli biblioteka nie jest wersjonowana, tak jak być może - warto rozpocząć wersjonowanie.

— Konrad Morawski
źródło

Dobrze słyszeć. Biblioteka jest wersjonowana, więc podejście do kontroli wersji brzmi dobrze. W rzeczywistości ma własne IDE, więc błędnie napisaną wersję można ukryć przed narzędziem do uzupełniania kodu, co powinno powstrzymać nowych użytkowników. Gdybym mógł dać ci kolejne +1 za odpowiedź na Q2, zrobiłbym to!

— Jamie Bull

Takie podejście widziałem również w innym oprogramowaniu. Używam interfejsu API innej firmy do tworzenia oprogramowania, a ich interfejs API zawiera metodę gettera, która zawiera literówkę. Problem został rozwiązany przez zmianę nazwy metody i utworzenie metody zastępczej ze starą (niepoprawną) pisownią, która po prostu wywołuje poprawną wersję. Metoda fikcyjna nie zawiera żadnej dokumentacji poza tym, że jest przestarzała, oraz łącza do właściwej wersji. Ta metoda istnieje od lat , aby uniknąć naruszenia wstecznej kompatybilności.

— Karl Nicoll