Числовой суффикс к методам: это правильный стиль? (например, myMethod2 ()) - PullRequest
Новая
       28

Числовой суффикс к методам: это правильный стиль? (например, myMethod2 ())

1 голос
/ 04 апреля 2019

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

Я видел в некоторых местах, когда новая версиядобавлен метод, он будет иметь то же имя, но с некоторым числовым префиксом, например, 

void doTheThing2(...) {...};

На первый взгляд это довольно уродливо и, очевидно, ничего не делает для того, чтобы сообщить реальную разницу в методе.С другой стороны, я обнаружил, что зачастую даже уродливее, а иногда просто невозможно уловить семантическое изменение в «версии 2» метода в названии.Например, 

boolean doTheThingButReturnResultCode(...) {...};

И не дай бог, если у вас есть версия 3 метода, то что?

Очевидно, я пишу код на Java, но этот вопрос не относится к Java.И я понимаю, что здесь нет объективного ответа, но я надеюсь получить некоторые мнения с рациональными.

1 Ответ

1 голос
/ 21 апреля 2019

Я бы сказал, что это не рекомендуется, но не недействительно.Я думаю, у вас очень правильная идея поддерживать обратную совместимость методов в течение значительных периодов времени в общедоступном API с четко объявленными периодами устаревания.

Одна проблема с суффиксами заключается в том, что новый метод в конечном итоге скажет, скажем,после 1-2 основных версий API, стать основным методом для использования.Тем не менее, это подрывает поток работающего программиста - вы получаете устаревший суффикс, все еще прикрепленный к методу.Даже до этого значение между method() и method2() обычно не является четким соглашением.

Поскольку английский является языком, богатым синонимами, я видел, что они предпочтительнее суффиксов версий на уровне метода.Это обычно меньше жертвы ясности и простоты.Например, addItem() (deprecated) может стать storeItem().Это особенно хорошо работает, когда новое соглашение об именах может соблюдаться в нескольких местах в API.Затем addWidget() и addWudget() становятся storeWidget() и storeWudget().

Этот синонимный подход можно увидеть в самих API Java и Python - они редко используют числовые суффиксы.Возможно, метод String.subSequence() можно считать версией 2 String.substring().

Другая проблема с числовыми суффиксами заключается в том, что неясно, какой номер является версией.Это версия метода?API?Год?Java-версия?Основная версия API, вероятно, имеет больше смысла, но трудно дать этот контекст последовательно, не добавляя более длинный суффикс, такой как addItemJava2() или addItemV2().Это также становится не интуитивно понятным с использованием потерянного числового суффикса после изменения основной версии API.Должен ли я использовать addItemv3() сейчас это версия API 5?

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

Что касается стиля, то часть этого может быть субъективной, но этоРассмотрим некоторые конструктивные нагрузки.

...