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

Question

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

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

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

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

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

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

boolean isSessionPost2011(int id) {}

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

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

Answer 1

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

Answer 2

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

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

boolean isSessionAfter(int id, Date date)

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

Answer 3

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

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

Answer 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).

Answer 5

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

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

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

• "3D",
• "i18n" (== интернационализация),
• "2020" (год), * ​​1016 *
• «X509» (стандарт) и так далее.

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

---

ОБНОВЛЕНИЕ

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

Вот что говорит Javadoc о назначении этого интерфейса:

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

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

@ BlueRaja пишет:

2 неОбъясните что-нибудь - чем LayoutManager2 отличается от LayoutManager?

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

Я полагаю, что идентификатор должен напоминать читателю, что означает предмет (класс, поле, метод и т. Д.), Который назван.

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

Answer 6

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

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

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

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

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

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

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

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

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

Answer 7

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

Answer 8

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

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

Answer 9

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

session.isPostYear(int year);

Answer 10

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