Полезно ли использовать суффикс подчеркивания для членов?

Question

class C {
 private:
  int member_; // here is the underscore I refer to.
}

Это подчеркивание рекомендуется Руководством по стилю Google и Руководством по стилю Geosoft для C ++ .

Я понимаю, что существуют разные мнения и вкусы.

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

Вот мой ответ:

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

В этом свете я считаю этот стиль вредным.

Answer 1

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

например:

class MyClass
{
   int someMember_;

public:
   int someMember() const { return someMember_; }
   void someMember( int newValue ) { someMember_ = newValue; }
};

не то чтобы я использовал этот стиль.

Answer 2

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

Мне все еще нравится это, потому что это часто упрощает именование параметров функции-члена:

class person
{
public:
  person(const std::string& first_name, const std::string& last_name)
    : first_name_(first_name), last_name_(last_name) {}

  // .......

private:
  std::string first_name_;
  std::string last_name_;
};

Answer 3

Я использую «m_» в качестве префикса для обычных переменных-членов и «s_» для статических переменных-членов. Таким образом, область видна непосредственно.

Answer 4

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

Answer 5

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

class Foo
{
  int mMember;
  int member_;
  int _member;
  int m_Member;
};

Все стили дают вам необходимую информацию. Пока вы остаетесь в одном и том же стиле все время, никаких проблем. Иногда другие люди должны работать с вашим кодом (например, когда вы создаете библиотеку или вы работаете с сообществом). Тогда было бы неплохо придерживаться наиболее используемого стиля в сообществе C ++.

Извините - я не могу ответить, что это за стиль.

Answer 6

Это обсуждалось у нас там, где я работал, но с программированием на Java. Но я думаю, что это относится и к C ++. Мой ответ заключается в том, что в среде IDE есть удобная функция окрашивания переменных-членов класса. В Eclipse они становятся синими. Подчеркивание лишнее. Как сказал другой постер: «EW, венгерские бородавки !!». 1980 позвонил и хочет вернуть венгерскую запись.

Answer 7

Это в основном религиозный аргумент, поэтому вы никогда не достигнете консенсуса по этому стилю. FWIW, я использую этот стиль для своих переменных-членов по причинам, уже указанным другими, например ::100100

class Foo
{
public:
  Foo(std::string name, int age) :
    name_(name),
    age_(age)
  {
  }

  std::string name() const { return name_; }
  void name(const std::string& name) { name_ = name; }

  int age() const { return age_; }
  void age(int age) { age_ = age; }
private:
  std::string name_;
  int age_;
};

Просто прими то, что тебе нравится, и придерживайся этого.

Answer 8

Я придумал этот стиль независимо в начале моих дней программирования на C ++ (конец 80-х, начало 90-х), потому что я столкнулся с несколькими запутанными ситуациями, в которых мне приходилось возвращаться к заголовку класса, чтобы выяснить, какая переменная действительно является членом переменная.

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

Это не часто полезно, но довольно безобидно, а когда полезно, очень полезно.

Вот почему я действительно ненавижу стиль m_. Это не безобидно, и я думаю, что дополнительное уродство не стоит пользы.

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

Answer 9

Мы придерживаемся стандарта кодирования C ++ вероятности.com , в котором говорится, что нужно префиксировать переменные-члены с помощью «m», но я также проделал некоторую работу под руководством по стилю Google.

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

• Упрощенное именование параметров , как и в ответе sbi, является одним из преимуществ.
• A согласованный стиль кодирования важен независимо от того, какой стиль вы выберете. В идеале, все в команде должны использовать один и тот же стиль кодирования, так что вы не можете сразу определить, кто написал данный раздел кода. Это помогает при привлечении новых разработчиков в команду и с гибкими практиками, такими как отсутствие владения кодом, и еще более важно в проектах с открытым исходным кодом, которые могут привлекать различные вклады.
• Самое главное, удобочитаемость может принести большую пользу, если весь код будет следовать довольно строгому стилю, который проясняет типы идентификаторов, подобных этому. Разница между способностью с первого взгляда сказать , что переменная является членом, и способностью определять по объявлениям локальных переменных может быть небольшой, но следование хорошему стандарту кодирования приведет к многочисленным небольшим различиям, таким как это повсюду в теле кода, и это может иметь огромное значение в том, как легко следовать коду и как легко начать работу в незнакомом разделе кода.

(Вы упомянули, что вы попробовали этот стиль, но если он был только для части кода и только для кода, с которым вы уже были знакомы, то труднее увидеть преимущество читабельности, которое следует за таким стилем кодирования, как этот за всю кодовую базу можно привести.)

Все это по моему опыту, ваш пробег может отличаться и т. Д.

Answer 10

Я согласен с Тобиасом в том, что есть какое-то преимущество - какое бы оно ни было - выделение переменных класса. С другой стороны, я всегда нахожу, что такие соглашения делают код «поток» менее хорошо. Просто проще прочитать «totalPrice = productPrice + salesTax», затем «m_totalPrice = l_productPrice + l_salesTax» или что-то еще.

В конце концов, я предпочитаю просто оставить все имена полей без декораций и иметь достаточно мало переменных класса, чтобы их отслеживание не было проблемой. В конструкторах и установщиках я добавляю к параметру префикс или суффикс, или в Java я обычно различаю переменную класса с помощью «this», например:

public Foo(int bar)
{
  this.bar=bar;
}

(Можете ли вы сделать это в C ++? Это было так долго, я не помню.)