ProBiotekКак вообще решаете этот вопрос ? Как решаете когда что нужно ? Хочу понять некую базовую логику, чтобы больше никогда вообще не задаваться этим вопросов вообще, а действовать на основании некое четкого алгоритма.
Лично я лет десять как пришёл к следующей системе:

По умолчанию пишется и используется метод getSomething(). Он возвращает something, которое существует и единственно. Если вдруг не существует - возбуждается исключение.


Когда в каком-то месте кода по бизнес-логике имеет смысл ситуация "something не существует", добавляется метод findSomething(). Его отличие в том, что он может вернуть null, и его результат обязательно проверяется в вызывающем коде.

ДиезНо если при переименовании метода должно меняться его поведение - это как-то странно. :)
Давайте рассмотрим переименование метода giveMoney() в takeMoney()

Диезsoftwarerпропущено...
Давайте рассмотрим переименование метода giveMoney() в takeMoney()
Давайте еще рассмотрим переименование giveMoneyToRecipient() в takeMoneyFromPayer() ?
Согласен, пример ровно из той же серии.

ДиезПереименование идентификаторов - обычный процесс рефакторинга.
Безусловно.

ДиезМожно вообще называть методы m1() m2() итд, в качестве естественного обсфуцирования кода ))
Можно. Собственно, Ваше предложение и сводится к тому, чтобы переменную "количество" можно было называть sum, переменную "цена" - name, а переменную "код завершения" - i.

Лично я полагаю, что идентификатор таки должен соответствовать содержимому. И "переименование идентификаторов при рефакторинге" как раз и является следствием либо перестройки содержимого, либо исправления неудачных названий.

ДиезРовно наоборот.
Оба эти идентификатора обозначают один и тот же процесс,
Да ну правда что ли? Один обозначает "взять у плательщика и положить в кошелёк", другой обозначает "взять из кошелька и отдать получателю". У этих процессов нет почти ничего общего.

Диезпоэтому имеем полное право переименовать метод, не меняя его поведения.
Я бы сказал, мы никогда не имеем права переименовывать хорошо названный метод, не меняя его поведения. Просто потому, что "переименовать плохо названный в хорошо названный" - единственное разумное обоснование для этой операции.

ДиезТо, что идентификатор должен соответствовать содержимому - общепринятое правило самодокументированного кода. Но это лишь для удобства программиста
Именно так. И в рамках этого же "для удобства" изложенный мной подход вполне гармоничен. При подходе "называем методы M1, M2, M3" он, разумеется, неуместен.

Диез привязать формальный контракт метода к структуре наименования идентификатора не позволяет ни один известный мне ЯП
Ну и хорошо, ибо этого не нужно делать.

ДиезПривязка к сигнатуре метода жестче с формальной точки зрения.
Сравните:



Первое - дикий геморрой, которого избегают все кроме упёртых теоретиков-пищущих-книжки-и-не-опускающихся-до-практики. Второе - вполне возможный подход. На мой вкус, тяжеловатый, но со своими достоинствами.

ДиезА в моем понимании - это всё метод transferMoneyFromPayerToRecipient()
Вот теперь Вы его хорошо назвали :) Именно сюда я и вёл. А теперь попробуйте его существенно переименовать, не меняя его поведения :)

ДиезРазные разработчики могут понять смысл одного названия совершенно по-разному.
Не должно такого быть в хорошем коде. После того, как разработчик входит в курс дела - то есть воспринимает принятую в проекте терминологию, схему именования объектов итп - подобное расхождение будет.. удивительно.

ДиезИначе не нужна была бы документация с примерами :)
Документация с примерами нужна для описания более глубоких особенностей, не охватываемых названием.

Диез"Хорошо" или"плохо" назван идентификатор - это глубоко субъективное мнение.
Не соглашусь. Хорошесть измеряется тем, насколько легко члены команды, столкнувшись, понимают смысл этого идентификатора и насколько легко потом его вспоминают (то есть могут применить без поиска). Конечно, бывают экстравагантные схемы (скажем, я на всю жизнь запомнил из одного проекта функции naref() и daref() - они расшифровывались как "на резиденцию файла" и ... да, правильно, "дай резиденцию файла") - но и это куда лучше, чем когда метод giveMoneyToRecipient() может оказаться названным takeMoneyFromPayer().

ДиезМы, надеюсь, обсуждаем не ваши личные предпочтения, а тему топика:
Эти два примера методов формально описывают два разных поведения, если не найден объект по идентификатору:
Формальное описание не является темой топика :) А к такому подходу мне сразу хочется спросить: а как поступать, если у объекта нужны оба этих метода?