Почему неправильно использовать числа в именах методов Java?

Question

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

Согласно Sun (и теперь Oracle) общее соглашение об именах для имен методов:

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

Условные обозначения Java

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

Рассмотрим ситуацию (которая есть у моего коллеги), когда вы хотите выполнить некоторую логику на основе конкретного года, например, новую политику, которая вступит в силу в 2011 году, и поэтому ваше приложение должно действовать на основе информации и обрабатывать ее на основе это год. Здравый смысл может сказать вам, что вы можете вызвать метод:

boolean isSessionPost2011(int id) {}

Допустимо ли использовать числа в именах методов (несмотря на формулировку стандарта)? Если нет, то почему?

Редактировать:"Это прямо не говорит о том, что числа не могут быть использованы, хотя по пропуску вы можете увидеть, что это не рекомендуется". Возможно, я сформулировал это неправильно. Стандарт гласит: «Методы должны быть глаголами». Я прочитал это, чтобы сказать, что если число не глагол, то имена методов не должны использовать числа.

Answer 1

Единственная проблема, которую я вижу при использовании чисел в именах методов, заключается в том, что это может указывать на то, что что-то в вашем дизайне может быть улучшено. (Я не решаюсь сказать «неправильно».) Например, в своем примере вы заявили, что у вас есть особая политика, которая вступает в силу после 2011 года. Однако наличие метода, специально предназначенного для проверки на этот год, кажется чрезмерно специфичным и волшебным. номер-у. Вместо этого я бы предложил создать обобщенную функцию, чтобы проверить, произошло ли событие после указанной даты, как предложил Анон.

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

Answer 2

ничего страшного

String int2string(int i)

User findUser4Id(long id)

void startHibern8();

вау!этот сайт не любит эти имена методов!Я получил капчу!

Answer 3

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

Если я понимаю ваш вариант использования, вам нужно внести некоторые устаревшие данные в новую версию вашего приложения. Если это так, то обязательно добавьте этот метод, отметьте его @deprecated и удалите его после обновления всех ваших клиентов.

С другой стороны Ральф здесь имеет действительную точку. Не позволяйте этому проекту проскользнуть в 2012:)

Answer 4

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

Answer 5

Пока у вас есть причина для использования чисел, тогда я думаю, что это нормально.

Для вашего примера, может быть 2 метода isSessionPost, так как бы вы назвали их?isSessionPost и isSessionPost2?Не очень ясно, если честно.

Просто помните, что все имена должны быть значимыми, и вы не ошибетесь.

Answer 6

Я не верю, что есть сама по себе причина избегать чисел в идентификаторах, хотя в случае, который вы описываете, я не знаю, использовал бы я это.Скорее, я бы назвал метод примерно как boolean isPolicyXyzApplicable(int id).

Если это политика, которая, как ожидается, будет со временем меняться, рассмотрите возможность разделения политик на разные классы, чтобы вы не росли долго.лоза if(isPolicyX) ... else if(isPolicyY) ... else if(isPolicyZ) ... в твоих методах.Как только это будет учтено, используйте абстрактный или интерфейсный метод Policy.isApplicableTo(transaction) и коллекцию Policy объектов, чтобы определить, что делать.

Answer 7

Мы используем их все время, как в примере, который вы показали. Также для версий интерфейса, таких как IConnection2 и IConnection3.

Затмение также не жалуется, что это нетрадиционное имя. :)

Но приемлемо? Это зависит от вас.