Использование символов подчеркивания в переменных Java и именах методов

Даже в наши дни я часто вижу подчеркивания в переменных и методах Java, примером являются переменные-члены (например, "m_count" или "_count" ). Насколько я помню, использование подчеркиваний в этих случаях называется "плохой стиль" Солнцем.

Единственное место, где они должны использоваться, - это константы (например, в "public final static int IS_OKAY = 1;" ), потому что константы должны быть все в верхнем регистре, а не в случае с верблюдом. Здесь подчеркивание должно сделать код более удобочитаемым.

Считаете ли вы, что использование подчеркивания на Java - это плохой стиль? Если да (или нет), почему?

Ответ 1

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

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

Ответ 2

sunDoesNotRecommendUnderscoresBecauseJavaVariableAndFunctionNamesTendToBeLongEnoughAsItIs();

as_others_have_said_consistency_is_the_important_thing_here_so_chose_whatever_you_think_is_more_readable();

Ответ 3

Правила:

Выполняйте то, что редактирует код.
Если # 1 не применяется, используйте camelCase, не подчеркивайте

Ответ 4

Я не думаю, что использование _ или m_ для обозначения переменных-членов является плохим на Java или на любом другом языке. По моему мнению, это улучшает читаемость вашего кода, потому что позволяет вам просмотреть фрагмент и быстро определить все переменные-члены из локальных сетей.

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

Мой собственный стиль - использовать m_ вместо _. Причина в том, что существуют также глобальные и статические переменные. Преимущество m_/_ заключается в том, что он различает область переменных. Поэтому вы не можете повторно использовать _ для глобального или статического, и вместо этого я выбираю g_ и s_ соответственно.

Ответ 5

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

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

(я почти никогда не использую "this", хотя, чтобы предотвратить столкновение имен.)

Ответ 6

используя "m_" или "_" перед переменной, упрощает определение переменных-членов в методах по всему объекту.

В качестве побочного преимущества наберите 'm_' или '_', чтобы intellsense всплывал в первую очередь;)

Ответ 7

Мне кажется, что мне нравятся ведущие символы подчеркивания для (частных) переменных экземпляра, кажется, легче читать и различать. Конечно, эта вещь может вызвать у вас проблемы с краевыми случаями (например, переменные открытого экземпляра (не общие, я знаю)) - либо как вы их называете, вы, возможно, нарушаете свое соглашение об именах:
private int _my_int; public int myInt;? _my_int? )

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

-автоматическое генерирование кода (например, eclipse generate getters, seters) вряд ли поймут это, поэтому вам придется исправить это вручную или muck с затмением, чтобы распознать его.

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

Ответ 8

Приятно иметь что-то, чтобы отличать частные или общедоступные переменные, но мне не нравится "_" в общем кодировании. Если я смогу помочь в новом коде, я избегу их использования.

Ответ 9

Это сочетание стилей кодирования. Одна школа мысли состоит в том, чтобы предисловие к частным членам подчеркивать, чтобы отличать их.

setBar( int bar)
{
   _bar = bar;
}

вместо

setBar( int bar)
{
   this.bar = bar;
}

Другие будут использовать символы подчеркивания, чтобы указать временную переменную temp, которая выйдет за пределы области действия в конце вызова метода. (Я нахожу это довольно бесполезным - хороший метод не должен быть таким длинным, и декларация ПРАВИЛЬНО!), Поэтому я знаю, что это выходит за рамки). Редактировать: не дай бог программист из этой школы, а программист из школы memberData сотрудничает! Это был бы ад.

Иногда сгенерированный код предирует переменные с помощью _ или __. Идея заключалась в том, что никто из людей никогда не сделает этого, так что это безопасно.

Ответ 10

Здесь ссылка для рекомендаций Sun для Java. Не то, чтобы вы использовали их или даже что их библиотечный код следует за всеми из них, но это хороший старт, если вы собираетесь с нуля. Инструмент, такой как Eclipse, имеет встроенные средства форматирования и очистки, которые могут помочь вам в соответствии с этими соглашениями (или другими, которые вы определяете).

Для меня "_" слишком сложно напечатать:)

Ответ 11

Существует причина, почему использование подчеркивания считалось плохим стилем в старые времена. Когда компилятор времени исполнения был чем-то недоступным, а мониторы приходили с поразительным разрешением 320x240 пикселей, часто бывает непросто различать _name и __name.

Ответ 12

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

Без сомнения, код, который вы видели, был написан кем-то, кто работал на языке, где подчеркивание было приемлемым.

Некоторые люди просто не могут адаптироваться к новым стилям кодирования...

Ответ 13

Причина, по которой люди делают это (по моему опыту), - это различать переменные-члены и функциональные параметры. В Java вы можете иметь такой класс:

public class TestClass {
  int var1;

  public void func1(int var1) {
     System.out.println("Which one is it?: " + var1);
  }
}

Если вы внесли переменную-член _var1 или m_var1, у вас не было бы двусмысленности в функции.

Итак, это стиль, и я бы не назвал это плохо.

Ответ 14

Лично я считаю, что язык не должен устанавливать правила стиля кодирования. Это вопрос предпочтений, использования, удобства, концепции читаемости.
Теперь проект должен установить правила кодирования для согласованности между списками. Вы можете не согласиться с этими правилами, но вы должны придерживаться их, если хотите внести свой вклад (или работать в команде).

По крайней мере, IDE, такие как Eclispe, являются агностиками, позволяющими устанавливать правила, такие как префиксы переменных или суффиксы, различные стили размещения фигур и управление пространством и т.д. Поэтому вы можете использовать его для переформатирования кода в соответствии с вашими рекомендациями.

Примечание. Я среди тех, кто сохраняет свои старые привычки с C/С++, кодируя Java с префиксами m_ для переменных-членов (и s_ для статических), префикс booleans с начальным b, используя начальную букву верхнего регистра для имен функций и выравнивающие фигурные скобки... Ужас для фундаменталистов Java!;-)
Смешно, что конвенции, используемые там, где я работаю... возможно потому, что основной первоначальный разработчик приходит из мира MFC!:-D

Ответ 15

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