Исправление орфографической ошибки в имени метода

73

Один из методов, которые я обычно использую в нашей кодовой базе, написан с ошибками (и это предшествовало мне).

Это действительно раздражает меня не просто потому, что оно введено неправильно, но, что более важно, оно заставляет меня ВСЕГДА неправильно вводить имя при первом наборе (а затем я должен помнить: «О, верно, это должно быть введено неправильно…»)

Я делаю несколько изменений вокруг оригинального метода. Должен ли я воспользоваться возможностью, чтобы просто переименовать чертов метод?

refactoring

— Раз два три
источник

12

Вы можете переименовать его? Если он используется кодом, который вы не контролируете, вы должны оправдать разрыв с обратной совместимостью.

16

* опечатка. И вам придется менять его везде, где вызывается метод.

— JohnP

2

* опечатка ... или, возможно, другое написание?

— ХорусКол

2

@JohnP Их было три, теперь один исправлен, а два все еще неверны. По совпадению подходит имя OP довольно хорошо. :)

— Разочарован

3

Мы не должны допустить, чтобы ничто не было неправильно заброшено!

— Волхв

136

Должен ли я воспользоваться возможностью, чтобы просто переименовать чертов метод?

Абсолютно.

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

— Telastyn
источник

33

Идея «перейти к правильно названному методу» проста и гениальна. Интересная ссылка на теорию разбитых окон.

— dev_feed

2

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

— Во

10

@ воу - а? Какой язык сделает добавление нового метода (и изменение его реализации таким же точным поведением) несовместимым?

— Теластин

3

@Telastyn иногда бывает сложно добавить методы, чтобы сказать веб-сервисы. Например, некоторые клиенты отказываются от изменения WSDL, неожиданно отказываясь общаться с сервером. Это проблема реализации в клиенте, но если клиент является важным, который вы не хотите расстраивать, он вполне может помешать вам изменить свой интерфейс.

— Проходя

17

@Telastyn Если имя метода опечатки находится на интерфейсе (как в типе интерфейса, используемом в Delphi / Java / C #), то добавление правильно написанной версии имени, вероятно, нарушит все существующие реализации указанного интерфейса.

— Разочарован

52

Есть случаи, когда вам следует избегать таких рефакторингов:

Если метод используется в общедоступном интерфейсе. Каноническим примером является неправильное написание реферера в HTTP реферере , неправильное написание сохраняется, потому что изменение орфографии теперь будет иметь слишком много последствий.
Если кодовая база не покрыта какими-либо тестами. Любой рефакторинг должен быть выполнен для тестируемого кода, чтобы иметь возможность проводить регрессионное тестирование. Рефакторинг кодовой базы, которая не тестируется, особенно рискован. Если у вас много времени, начните с добавления тестов; если вы работаете в условиях нехватки времени, риск, связанный с внесением незначительных ошибок, не самый лучший вариант, если вы хотите доставить вовремя.
Если метод может быть использован необычным способом , что делает его использование практически невозможно найти (через Ctrl + F или с помощью автоматического инструмента рефакторинга). Например, в C # метод может быть вызван через Reflection, что делает диалог Rename в Visual Studio неэффективным. В JavaScript также eval()трудно найти вызываемую внутри функцию . В PHP переменные переменные могут вызвать проблемы.
Если размер проекта огромен и метод может быть использован другими командами. Это похоже на первый пункт, то есть интерфейс, который вы предоставляете другим командам, может рассматриваться как общедоступный интерфейс.
Если вы имеете дело с жизненно важным проектом. Скорее всего, опечатка не слишком важна, чтобы оправдать несколько месяцев оформления документов, чтобы изменить название метода и гарантировать, что ни один пациент не получит в десять раз больше разрешенного излучения или какого-либо челнока, чтобы просчитать его скорость.

В любой другой ситуации, не стесняйтесь переименовать метод.

— Арсений Мурзенко
источник

1

+1 за комментарий с упоминанием Reflection, он меня укусил не раз.

— DaveShaw

33

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

— user2357112

2

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

— user2357112

8

@ user2357112: Я никогда не говорил, что малейший рефакторинг может кого-то убить. Речь идет не о том, чтобы кого-то убить, а о том, чтобы сделать все возможное, чтобы уменьшить оставшийся 0,001% риск ошибки. Это требует формального проф. Это требует нескольких уровней тестирования. Это требует формализма. Это запрещает: «Я хочу быстро переименовать этот метод, надеюсь, он сработает!» поведение. Жизненно важные проекты используют методы, которые будут считаться пустой тратой времени и денег для любого бизнес-приложения. Вот почему они такие надежные (и дорогие).

— Арсений Мурзенко

5

@ user2357112: как указала MainMa, речь идет не о случайных бизнес-приложениях. Речь идет о специальном программном обеспечении, которое тщательно протестировано / проверено. Что если метод вызывается отражением где-нибудь? Что, если какой-то инструмент до / после компиляции что-то с этим сделает? Как насчет документации? Как насчет других команд, использующих это? Они используют отражение? Что если ... Реальная жизнь иногда бывает довольно сложной. И иногда лучше оставить имя метода нетронутым, а не проверять, есть ли какие-либо последствия в пуленепробиваемой манере.

— dagnelies

30

Я сделал это несколько месяцев назад (по разным причинам). Шаги, которые я предпринял (язык был Perl):

Переименуйте метод. Псевдоним старого имени новому имени (это не должно нарушать код, так как метод может быть вызван любым именем).
Сообщите остальным разработчикам об изменении имени и почему, указав им использовать новое имя отныне.
Grep код базы для старого имени, исправить все вхождения.
Записывайте все случаи использования старого имени (использование старого имени должно все еще работать в это время). Исправьте эти случаи.
Подождите (пока делаете 4.), пока в журнале не появится больше записей.
Сломай псевдоним. Создайте метод, используя старое имя, которое выдает фатальное исключение с сообщением об изменении имени.
Через некоторое время удалите метод со старым именем.

Конечно, ваш пробег будет меняться.

— камеристка
источник

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

— Бен Фойгт

@BenVoigt Разве это не то, что делает # 4?

— Боб

6

Хороший способ не нарушать существующий код - связать имя нового метода со старым в таком виде, как

private void MyNewMethodName()
{
    TheOldMethodName();
}

а затем пометьте старый метод как устаревший (если ваш язык поддерживает это). Таким образом, любой существующий код все еще будет работать, и вы можете постепенно убрать все старые орфографические ошибки из вашей кодовой базы. В конце концов вы можете даже скопировать / вставить тело метода в новый метод и удалить старый.

/ Edit Как сказал ivo в комментарии: еще лучше сделать так, чтобы код переместился TheOldMethodNameв MyNewMethodNameи вызвал новый метод из старого. У этого также было бы преимущество, чтобы помочь разработчику разобраться в том, к чему принадлежит код.

— Рэй
источник

2

Я согласен с вашим методом; Я бы сделал то же самое. Это самый разумный, понятный и безопасный метод рефакторинга. Что также может быть хорошим способом - это переместить код из старого метода в новый метод и заставить старый использовать новый метод. Когда кодовая база проходит несколько итераций по временной шкале, вам нужно только удалить старый устаревший метод.

— Иво Лиммен

1

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

— Реми

1

Переименование метода:

Сделайте это с помощью рефакторинга, чтобы у вас не было больше работы, чем вы хотите
Если ваша IDE поддерживает автозаполнение, используйте его при ссылке на этот метод

Это два варианта, на которые вы могли бы пойти. Я бы предпочел автозаполнение (например, Eclipse IDE) и не нужно вводить имя метода. Собираюсь переименовать; просто убедитесь, что вы узнали, что вызывает этот метод, и измените прямые ссылки в каждом месте. Рефакторинг будет вашим другом для этого, но будьте очень осторожны при этом.

— слащавый
источник

0

Я бы вообще рекомендовал да, переименовать его.

В других ответах здесь перечислены веские причины, по которым вы, возможно, не захотите переименовывать его, поэтому, если вы окажетесь в одной из таких ситуаций, вы можете создать новый метод с правильным именем и реализацией и изменить старый метод для вызова нового метода. , Затем пометьте старый как устаревший, если ваш язык поддерживает его.

— Брайан
источник