В чем прикол для создания _names _fields _like _these в Java?

Question

Время от времени я вижу что-то вроде этого:

class Clazz {

   private int _goodName;

   private int _anotherGoodName;

   ...
}

Я не понимаю. Трудно и необычно читать такой код. Какие плюсы?

Answer 1

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

Лично я не фанат, так как думаю, что вы можете отказаться от подчеркивания и добиться того же результата, но каждому свой. Я думаю, что это может иметь свои корни в дни до IDE, когда вы, возможно, просматриваете метод, и видимость / принадлежность определенных переменных не всегда ясна.

Answer 2

Примеры элементов и методов с префиксом подчеркивания, которые я видел, используют соглашение, чтобы указать, что вы не должны касаться этого элемента или метода, когда вы не можете сделать его закрытым. Я прочитал это как «здесь драконы», у меня никогда не было причин использовать это сам.

Примером является метод _jspService () в разработке сервлетов. Проверьте связанные JavaDocs.

Answer 3

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

Answer 4

Я использовал эти условные обозначения в своем коде:

• Неокончательные статические поля начинаются с подчеркивания.

  private static SomethingOrOther _goodName;
  

• Параметры заканчиваются подчеркиванием.

  public void doSomething(Object goodParam_, String stringToo_) {
  }
  

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

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

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

Я отошел от этого с помощью Java-кода, предпочитая вместо этого, чтобы моя IDE всегда полностью соответствовала this для полей экземпляра и имени класса для статических полей и всегда использовала final для каждой переменной, которая не ' изменить даже параметры метода. Интересная вещь в этом маршруте заключается в том, что он поощряет хорошую практику именования, по крайней мере для меня, потому что мне нравится, когда мои переменные хорошо читаются, когда в префиксе указано this или имя класса.

Answer 5

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

private string _myVariable;
public MyClass(string myVariable)
{
    //do stuff.
    _myVariable = myVariable;
}

public string MyVariable
{
    get
    {
         return _myVariable;
    }
}

Answer 6

Соглашения об именах - все о том, что удобно для человека, пишущего код, для чтения / копирования (хотя они должны быть о том, что легко для всех, чтобы прочитать)

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

private int m_myVariable;

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