имена переменных Java

Question

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

Мои аргументы на данный момент:

• вы можете напрямую знать, о чем говорите:

  для (Студент студент: студенты) {...}

довольно легко понять (против Студент с или Студент любой )

• это помогает комментировать код
• наш ide обеспечивает прямую поддержку того, что
• вы можете непосредственно видеть, используете ли вы яблоки вместо груш (или медведей);-))

Меньше путаницы, когда тонкие различия имеют значение:

criteriaBuilder.equal(nameExpression, name);

Единственный аргумент, который я могу видеть против этого, состоит в том, что он делает код длиннее (что, я думаю, не 't проблема с современными IDE).

Существует ли публичное предоставление такой рекомендации?Кто-нибудь использует то же правило?Любая альтернатива?

Answer 1

Для меня это звучит как Венгерская нотация .

В принципе, это звучит как хорошая идея, но я, честно говоря, не уверен, что для этого есть веские причины:

• Самокомментирующий / документирующий код - это должно быть возможно без указания типовв именах переменных;
• Среда IDE также должна обеспечивать поддержку для определения типа переменной, не помещая ее в имя переменной (например, Eclipse может сделать это)
• Я не знаю, чтоэто действительно преимущество.

Одна из проблем с венгерской нотацией, о которой вы не упомянули, заключается в том, что если вы реорганизуете код, вам также придется изменить все имена переменных.В The Daily WTF есть множество примеров, где переменные называются «strSOMETHING» или «intSOMETHING», даже если типы определены как что-то другое.

В общем, IMO в случае использования венгерской нотации довольно хрупкаяи вообще я бы не рекомендовал делать это политикой.

(Если это не совсем то, о чем вы говорите, прошу прощения!)

Answer 2

Ваша библия по этому вопросу - книга Стива Макконнела, Code Complete , которая является наиболее полной книгой о такой практике создания программного обеспечения.У него есть целая глава по именованию переменных и тому, почему это важно.

Ключ в том, чтобы сделать имя полным описанием того, что делает переменная, чтобы ее было легко понять человеку, читающему ее.Если это достигается, то это хорошая практика.

Учащийся ученик выглядит простой для понимания политикой, но у нее есть непосредственный недостаток - она ​​не содержит дополнительной информации о переменной.Вы уже знаете, его студент.Если вы знаете что-то еще об объекте, добавьте его к имени переменной - studentUnderReview, GravatingStudent и т. Д. «Student» следует использовать только в том случае, если вы абсолютно ничего не знаете, например, переменная используется для перебора всех студентов.Теперь в длинном методе полезно узнать тип, просто взглянув на имя, но если переменная имеет короткую область видимости, то она является маргинальной, полезной она или нет.Есть некоторые исследования (см. McConnel), которые показывают, что для переменных с очень короткой областью действия, таких как индексы цикла, короткие имена лучше.

Как только у вас есть две переменные, эта система выходит из строя.Если по умолчанию вызывается одна переменная «student», то возникает искушение вызвать две переменные «student1» и «student2», что действительно является плохой практикой (подробности см. В McConnel).Вам нужно сделать имена, которые описывают объект - goodStudent и badStudent;studentBeingSaved и studentBeingRead.

Answer 3

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

Что касается остальных:

• помогает комментировать код самостоятельно - нет, он дублирует информацию из объявления переменной
• наш идеал обеспечивает прямую поддержку этому - это будет аргумент, только если альтернативы не дают никаких преимуществ
• вы можете непосредственно видеть, используете ли вы яблоки вместо груш (или медведей ;-)) - это работа системы типов

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

for (Student student: students) { ... }

Если вы перебираете всех учеников, это нормально. Но если у вас есть неуниверсальный экземпляр Student, имя переменной должно описывать, какую конкретную роль играет студент в этой части программы (например, candidate или graduate).

Answer 4

Как правило, имена ваших переменных должны помочь разработчику быстро увидеть, что они на самом деле представляют.Student student было бы хорошо, если бы отношение, которое определяет, выражало отношение что-либо к ученику, такое как Student[] students (или, лучше, некоторая коллекция учеников), было бы хорошо для класса Professor или подобного.

String string вообще плохая идея, так как она ничего не говорит об использовании этой переменной.Лучше имена будут String name, String description или аналогичные.В некоторых случаях, когда все, что имеет значение, это то, что вы имеете дело с одной строкой - как обычные строковые утилиты - вы можете вызвать переменную string, но если у вас есть две или более, вы должны использовать лучшие имена (например, source иtarget и т. Д. В зависимости от класса / метода).

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