Russian Qt Forum

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

Сначала нужно определиться чем структура отличается от класса, в понимании чистого кода :).

Коротко моё мнение: если структура не инвариант, все поля публичные, нет всяких геттеров/сеттеров, то префикс/суффикс не нужен.

Я не до конца понимаю, зачем писать префикс в членах класса. Я делаю по 2 причинам: во-первых, принято, признак хорошего тона; во-вторых, если вижу префикс, то сразу понимаю, что член класса и немного удобнее разбирать код.

Не знаю, чем отличаются в понимании чистого кода, может смысл закрытости членов класса...

У меня "геттеров/сеттеров" нет, не инвариант

Пара причин для примера:
1. С префиксами нет конфликтов имён с геттерами.
2. В IDE в автодополнении они сгруппированы, по "m_" можно увидеть список членов класса.

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

имхо, геттеры лучше начинать с get.
автодополнение актуально только внутри методов класса(а там и так не так много методов), т.к. публичные члены для класса лучше не делать.

Уже написали в принципе - префикс добавляется к мемберам, чтобы избежать коллизии с геттером:
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; }

имхо:
a.value; // мембер
a.setValue(); // сеттер
a.getValue(); // геттер
геттер это метод, действие, глагол, а не существительное. И если в классе слишком много member, setMember, getMember - то напрашивается сделать класс структурой, или разделить класс на структуру и класс.

getValue() - сразу видно что это геттер.
value() - это некая функция возвращающая значение, непонятно что делающая(просто взять значение или вычислить).
toValue() - преобразование

m_ подкупает автодополнением, но в принципе IDE сама могла бы подсказывать и фильтровать дополнения(например при автодополнении ctrl+M только методы...).

Последнее время (лет 5) взял за правило обязательно использовать префикс для членов класса m_ и ни капли не жалею. Читабельность кода вырастает, саппорт и дальнейший разбор облегчается.
Кроме коллизий с геттерами могут быть и коллизии и с параметрами методов, и с локальными переменными. Когда требуется анализ кода без подсветки синтаксиса префикс сильно помогает.

Предпочитаю classMember_ и structMember.

Что можно сделать, чтобы избежать коллизии с параметрами конструктора? Нормально в конец имени члена добавить "_" или правильнее произвольно поменять имя параметра конструктора?
Например,

class Example
{
  int param1_;
  int param2_;

  Example(int param1, int param2)
  {
     param1_ = param1;
     param2_ = param2;
  }
}

param1(param1)

приватные переменные обычно имеют префикс _ или m_. Для публичных можно в параметры конструктора в конец добавить _

У меня все мемберы приватные, именуются вот так someName_, коллизии с параметрами не возникает, ибо параметры именуются someName.

Извините, опечатался. Структура и все параметры публичные

struct Example
{
  int param1_;
  int param2_;

  Example(int param1, int param2)
  {
     param1_ = param1;
     param2_ = param2;
  }
}

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

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

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

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

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

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


Скорее на УГ.


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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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