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

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

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

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

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

Правила:

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

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

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, у вас не было бы двусмысленности в функции.

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

sunDoesNotRecommendUnderscoresBecauseJavaVariableAndFunctionNamesTendToBeLongEnoughAsItIs();

as_others_have_said_consistency_is_the_important_thing_here_so_chose_whatever_you_think_is_more_readable();

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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