Как бороться с ошибочно названной функцией в производственном коде?

Я недавно натолкнулся на библиотеку Python на GitHub. Библиотека отличная, но содержит одно явное опечатка в имени функции. Давайте назовем это, dummy_fuction()пока это должно быть dummy_function(). Эта функция определенно «в дикой природе» и, скорее всего, используется во встроенных системах.

Первое, что приходит на ум, - это добавить вторую версию функции с правильным именем и добавить предупреждение об устаревании в первую версию для следующего выпуска.

Три вопроса:

Может ли описанный выше подход иметь какие-либо непредвиденные последствия?
Существует ли стандартный подход к такого рода проблемам?
Как долго следует оставлять предупреждение об устаревании?

— Джейми Булл
источник

Это ситуация (хотя и не очень частая), в которой статический язык гораздо надежнее динамического: компилятор может проверить, существует ли уже переименованная функция.

— Джорджио

см. также HTTP referer [sic]

— AakashM

Я бы также указал на mod_speling в Apache , но это могло быть преднамеренно.

— Восстановить Монику iamnotmaynard

@AakashM: Мне нравится, что в статье в Википедии теперь используется как неправильное, так и правильное написание по всей этой странице (даже при ссылке на объект, а не на термин), причем версия с орфографической ошибкой является более распространенной!

— Мартейн Питерс

Еще одна хорошая новость о том, что http_referer«Это похоже на то, когда я делал поле реферера. У меня не было ничего, кроме горя за мой выбор орфографии. Сейчас я пытаюсь исправить орфографию в OED, поскольку мое правописание используется несколько миллиардов раз в минуту больше». чем их. " - Филипп Хэллам-Бейкер

— Джейми Булл,

В первую очередь, политика зависит от сопровождающего.

Я думаю, что ваш вопрос интересен, но в основном основан на мнении.

По моему личному мнению, ваш подход обоснован - переименуйте функцию и оставьте ошибочную версию устаревшим, перенаправив ее на правильный.

Может ли описанный выше подход иметь какие-либо непредвиденные последствия?

Это может нарушить код, например. если кто-то тоже не мог вынести опечатки и реализовал переименованную версию самостоятельно. Теперь произойдет столкновение имен после обновления библиотеки.

Существует ли стандартный подход к такого рода проблемам?

Не допускайте орфографических ошибок при написании библиотеки;)

Как долго следует оставлять предупреждение об устаревании?

Я считаю, что амортизацию следует оставить на месте до следующего основного выпуска (когда увеличится первая цифра в номере версии).

Это когда допускается некоторое - оправданное - нарушение обратной совместимости, и пользователи библиотеки должны убедиться, что их код по-прежнему работает нормально.

Просто не забудьте указать это в журнале изменений: ребята, если вы использовали dummy_fuction, замените его dummy_functionвезде, и все готово.

Если библиотека не версионирована, как это может быть - это хороший повод начать ее версионирование.

— Конрад Моравский
источник

Рад слышать. Библиотека версионирована, поэтому подход к управлению версиями звучит хорошо. На самом деле у него есть собственная IDE, поэтому неправильно написанную версию можно скрыть из инструмента завершения кода, который должен остановить использование ее новыми пользователями. Если бы я мог дать вам еще один +1 за ответ на вопрос 2, я бы!

— Джейми Булл,

Это подход, который я видел в других программах. Я использую сторонний API для части программного обеспечения, которую я разрабатываю, и их API содержит метод получения, который содержит опечатку. Проблема была исправлена путем переименования метода и создания фиктивного метода со старым (неправильным) написанием, который просто вызывает правильную версию. Пустой метод не содержит никакой документации, кроме упоминания о том, что он устарел, и ссылки на правильную версию. Этот метод существует уже много лет , чтобы избежать нарушения обратной совместимости.

— Карл Николл