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

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

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

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

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

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

sunDoesNotRecommendUnderscoresBecauseJavaVariableAndFunctionNamesTendToBeLongEnoughAsItIs ();

as_others_have_said_consistency_is_the_important_thing_here_so_chose_whatever_you_think_is_more_readable ();

Правила:

1. Делайте то, что делает код, который вы редактируете
2. Если №1 не подходит, используйте camelCase, без подчеркивания

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

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

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

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

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

(Я почти никогда не использую «это», кроме как для предотвращения конфликта имен.)

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

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

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

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

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

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

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

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

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

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

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

setBar( int bar)
{
   _bar = bar;
}

вместо

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

Другие будут использовать подчеркивание, чтобы указать временную локальную переменную, которая выйдет за пределы области видимости в конце вызова метода. (Я считаю это довольно бесполезным - хороший метод не должен быть таким длинным, и объявление находится ПРЯМО ЗДЕСЬ! Так что я знаю, что он выходит за рамки) Редактировать: не дай Бог сотрудничать программисту из этой школы и программисту из школы memberData ! Это было бы адом.

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

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

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

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

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

public class TestClass {
  int var1;

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

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

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

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

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

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

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