Чистый код: как правильно называть члены структур

[ViTech]

Код

C++ (Qt)
struct Example
{
    int param1;
    int param2;
 
    Example(int param1, int param2)
        : param1{param1},
          param2{param2}
    {}
};
 

[YvenTitan]

Спасибо за мнение

[_Bers]

Здравстуйте,
Есть мнение, что члены классов должны начинаться с m_
Как считаете, к членам структур это правило должно относиться?

Уже написали в принципе - префикс добавляется к мемберам, чтобы избежать коллизии с геттером:
a.value(); // геттер
a.setValue(); // сеттер
a.m_value; // мембер

Я лично предпочитаю писать не m_value (как в венгерской нотации), а _value. Еще есть вариант с постфиксом value_, но мне он кажется безобразным (value_->foo()) - _value->foo()->bar() встречается гораздо чаще, чем a->_foo->_bar (тоже ужасно, но внутрь привата лезешь редко).

Еще есть вариант с d-pointer'ом: T value() const { return d->value; }

подчеркивание в начале имени - дурной тон.
можно нарваться на UB.
грамотные любители подчеркиваний ставят черточки в конце имени.

[deMax]

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

[Авварон]

подчеркивание в начале имени - дурной тон.
можно нарваться на UB.
грамотные любители подчеркиваний ставят черточки в конце имени.

Пруфы? Черточки в конце имени отвратительны, код вида bar_.foo(); абсолютно нечитаем.
_ и __ зарезервированы для имен стандартных библиотек, но чтобы UB - первый раз слышу.

[Racheengel]

подчеркивание в начале имени - дурной тон.

Согласен. Лушче m_

можно нарваться на UB.

Скорее на УГ.

Пруфы? Черточки в конце имени отвратительны, код вида bar_.foo(); абсолютно нечитаем.

Согласен. Такое чувство, что человек хотел что-то разумное после bar_ добавить, но... умер, наверное...

[Igors]

Черточки в конце имени отвратительны, код вида ...

Рассуждаете как чистый гуманитарий Все на чувствах, эмоциях, объективности никакой. Да, я бы не стал использовать подчеркивания ни в начале, ни в конце, но если другой так делает - нет оснований его осуждать. Любой разумный стиль неплох. И, кстати, всегда есть исключения. Напр m_  дело хорошее, но иногда (пусть редко) лучше без него, напр здесь

Код

C++ (Qt)
struct Point {
  int x, y;
}; 

[deMax]

struct Point

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

[Пантер]

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

[deMax]

Способов много, стандарта тут нет. m_ немного мешает чтению, но зато сразу видно что это закрытый член класса ( а не аргумент или переменная на стеке ).
Выделение цветом, не так наглядно как имя. Ну и автодополнение непонятно как настроить чтобы фильтровать члены класса и переменые.

[_Bers]

подчеркивание в начале имени - дурной тон.
можно нарваться на UB.
грамотные любители подчеркиваний ставят черточки в конце имени.

Пруфы? Черточки в конце имени отвратительны, код вида bar_.foo(); абсолютно нечитаем.
_ и __ зарезервированы для имен стандартных библиотек, но чтобы UB - первый раз слышу.

зарезервированы для нужд языка.
_ или __ для глобальных идентификаторов
_UpperCase  для любых возможных кейсов использования.

с обычными глобальными переменными можно попутаться в шаблонах:
http://rextester.com/VTE47007

Код:

#include <iostream>
#include <string>

std::string _reserved = "global";

struct base
{
    std::string _reserved = "member";    
};

template<class t> struct sample: t
{
    void set(const std::string& v) { _reserved = v; }
};

int main()
{
    sample<base> s;
    s.set("UB");
    
    std::cout << s._reserved << '\n';
}

кроме того, дефайны препроцессора так же являются глобальными идентификаторами.
а им вапще плевать на области видимости.

итого: подчеркивание в начале имени открывает потенциальную вероятность коллизий.

конретную ссылку на стандарт искать лень.

[Racheengel]

struct Point

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

А вот если это protected-поле, не моветонъ ли в наследнике его читать-писать без геттеросеттера?

[ssoft]

А вот если это protected-поле, не моветонъ ли в наследнике его читать-писать без геттеросеттера?

Дак на то оно и protected, чтобы его читать-писать без геттеросеттера. Иначе должно быть private.

[Racheengel]

А вот если это protected-поле, не моветонъ ли в наследнике его читать-писать без геттеросеттера?

Дак на то оно и protected, чтобы его читать-писать без геттеросеттера. Иначе должно быть private.

да просто некрасиво немного... а вдруг переименуют его в базовам классе?

[sergek]

да просто некрасиво немного... а вдруг переименуют его в базовам классе?

А если геттеры/сеттеры в интерфейсе не нужны? Делать их в защищенной части? Это уже слишком...