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

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

пример:

class MyClass
{
   int someMember_;

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

не что я использую этот стиль.

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

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

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

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

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

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

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_;
};

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

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

есть еще один «стиль», который предлагает объявлять члены класса, как показано ниже:

class Foo{
    int m_value;
public:
     //...
};

Я нашел его пригодным для использования. но это всего лишь моя точка зрения.

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

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

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

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

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

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

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_;
};

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

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

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

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

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

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

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

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

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

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