Використання підкреслення в змінних Java та іменах методів [закрито]

Навіть сьогодні я часто бачу підкреслення у змінних та методах Java, прикладом є змінні-члени (наприклад, "m_count" або "_count"). Наскільки я пам’ятаю, використовувати підкреслення в цих випадках Sun називає поганим стилем.

Єдине місце, де їх слід використовувати, - це константи (наприклад, у "public final static int IS_OKAY = 1;"), оскільки константи мають бути з великої літери, а не з верблюда. Тут підкреслення повинно зробити код більш читабельним.

Чи вважаєте ви, що використання підкреслень у Java є поганим стилем? Якщо так (чи ні), чому?

Якщо у вас зараз немає коду, я пропоную продовжити це. Якщо ваша кодова база використовує його, продовжуйте це.

Найбільше у стилі кодування - це послідовність . Якщо у вас немає з чим узгоджуватись, тоді рекомендації постачальника мов, швидше за все, є гарним місцем для початку.

sunDoesNotRecommendUnderscoresBecauseJavaVariableAndFunctionNamesTendToBeLongEnoughAsItIs ();

as_others_have_said_consistentcy_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) і, ймовірно, матимете від цього певні неприємності. І як згадували попередні плакати, послідовність кодової бази переважає всі вищезазначені проблеми.

Є причина, чому в підсумки використання підкреслень вважалося поганим стилем. Коли під час виконання компілятор що - то по кишені і монітори прийшли з дивним дозволом 320х240 пікселів , це часто вже не так легко розрізняти _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

це просто ваш власний стиль, нічого поганого і нічого хорошого, просто відмінніть наш код від інших.