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

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

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

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

Кодовые обозначения Java

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

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

boolean isSessionPost2011(int id) {}

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

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

Ответ 1

Стандартная библиотека классов Java полна классов и методов с числами в ней, например Graphics2D.

Ответ 2

Метод кажется... слишком специфичным.

Не могли бы вы использовать:

boolean isSessionAfter(int id, Date date)

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

Ответ 3

Конечно, допустимо использовать числа в именах методов. Но в соответствии с вашим примером, почему он вообще нахмурился. Скажем, что в 2012 году наметилась новая политика. Теперь есть новая политика на 2014 год. И, возможно, 2020 год! Итак, у вас есть четыре метода, которые примерно эквивалентны.

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

Ответ 4

Спецификация языка Java кажется довольно конкретным по этой теме:

3.8 Идентификаторы

Идентификатор - это неограниченная последовательность букв Java и цифр Java, первая из которых должна быть буквой Java.

...

Буквы Java включают в себя прописные и строчные буквы ASCII латиницы A-Z (\u0041-\u005a) и A-Z (\u0061-\u007a), а по историческим причинам подчеркивание ASCII (_ или \u005f) и знак доллара ($, или \u0024). Символ $ следует использовать только в механически генерируемом исходном коде или, реже, для доступа к существующим именам в устаревших системах.

"Знаки Java" включают в себя цифры ASCII 0-9 (\u0030-\u0039).

Ответ 5

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

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

Думаю, единственное предостережение в том, что JSG рекомендует использовать значащие имена. И следствие состоит в том, что вы должны использовать числа только в идентификаторах, когда они семантически значимы. Хорошими примерами являются

"3D",
"i18n" (== интернационализация),
"2020" (год),
"X509" (стандарт) и т.д.

Даже "int2Real" имеет смысл в народном стиле.

ОБНОВЛЕНИЕ

@biziclomp поднял случай LayoutManager2 и утверждает, что 2 не имеет никакого значения.

Здесь, что javadoc говорит о цели этого интерфейса:

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

Из этого я бы сказал, что 2 в названии имеет смысл. В основном, это говорит о том, что вы можете рассматривать это как преемника LayoutManager. Я думаю, это можно было бы сказать словами, но см. Примеры выше о том, как числа, где числа используются как короткие.

@BlueRaja пишет:

2 ничего не объясняет - как LayoutManager2 отличается от LayoutManager?

Совет Руководства по стилю НЕ означает, что имена должны объяснять вещи. Скорее, он советует им иметь смысл. (Для пояснения см. Javadoc.) Очевидно, значимость относительна, но существует практический предел количества информации, которую вы можете поместить в идентификатор, прежде чем становится трудно читать и трудно печатать.

Мой прием заключается в том, что идентификатор должен напомнить читателю, что имя объекта (класс, поле, метод и т.д.) называется.

Это компромисс.

Ответ 6

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

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

Идея состоит в том, что полный вызов метода может быть прочитан как полное предложение, причем объектом является объект перед точкой, глагол - имя метода, а дополнительные объекты - аргументы метода:

if (buffer.isEmpty()) 
    buffer.append(word);

(Большинство таких предложений будут либо допросами, либо императивными).

Ваше имя метода имеет (с точки зрения соглашения об именовании) единственную проблему, в которой объект предложения (сеанс) не является объектом this вашего метода, а параметром, но этого нельзя избежать с помощью Java, я думаю (пожалуйста, кто-то докажет мне, что я ошибаюсь).

Для многопараметрических методов метод smalltalk будет работать лучше:

"Hello" replace: "e" with: "x"

(где replace:with: - один из методов строкового класса.)

Ответ 7

Да, в некоторых случаях. Например, возможно, вы хотите обрабатывать сертификаты X.509. Я думаю, было бы вполне приемлемо написать метод под названием handleX509Certificate.

Ответ 8

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

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

Ответ 9

Я бы назвал ваш метод другим. Ничто против чисел точно, но что произойдет, если проект ускользнет от даты выпуска? У вас будет метод, называемый post2011 - теперь его следует называть post2012. Подумайте, можно ли вместо этого вызвать postProjNameImplentation?

Ответ 10

Использование числа не плохо, но обычно они не очень распространены.

в конкретном случае, я не думаю, что isSessionPost2011(int id) {} - хорошее имя. но лучше isSessionPostYear(int id, int year) {} более расширяемый для будущих целей.

Ответ 11

Тот факт, что это соглашение о кодировании, и использование глагола "должно" предложить вам, что цифры разрешены, но рекомендуется в именах методов. Однако в вашем примере, почему бы не обобщать тот же код, что и?

session.isPostYear(int year);

Ответ 12

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

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

Но приемлемо? Такого рода до вас.

Ответ 13

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

Ответ 14

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

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

Ответ 15

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

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

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

Ответ 16

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

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

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

Ответ 17

ничего плохого

String int2string(int i)

User findUser4Id(long id)

void startHibern8();

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