Существует дурная практика снабжать члены класса префиксом тип m_ .
Это характерный признак кода, созданного в крупных компаниях типа Майкрософт, в рамках "бюрократического программирования".
Не спасает.
На самом деле, если вы хотите выделить в коде работу с членом класса, используйте естественный префикс this->. Например так

struct Point
 {
  int x;
  int y;

  void shift(int x,int y)
   {
    this->x += x ;
    this->y += y ;
   }

  ....
 };

Это гораздо лучше. А ещё лучше делать так

struct Point
 {
  int x;
  int y;

  void shift(int dx,int dy)
   {
    x += dx ;
    y += dy ;
   }

  ....
 };

Тем не менее, существуют нормальные случаи использования префиксов в больших и сложных классах.
Небольшой пример

class SomeWindow
 {
  ....

   void scrollX(ulen pos);

   void scrollY(ulen pos);

   SignalConnector<SomeWindow,ulen> connector_scrollX;
   SignalConnector<SomeWindow,ulen> connector_scrollY;

   void reportOff();

   SignalConnector<SomeWindow> connector_reportOff;

  ....
 };

Здесь для именования коннекторов сигналов используется префикс connector_.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, Шахтер, Вы писали:

Ш>Существует дурная практика снабжать члены класса префиксом тип m_ .

А чем префикс m_ хуже префикса _ или суффикса _ ?
this-> не принято писать из-за излишней многословности.

Здравствуйте, _NN_, Вы писали:

_NN>А чем префикс m_ хуже префикса _ или суффикса _ ?

Суффикс хуже тем, что не позволяет по мере ввода в IDE отфильтровать поля от всего прочего в выпадающем списке по IntelliSense.

Здравствуйте, _NN_, Вы писали:

_NN>this-> не принято писать из-за излишней многословности.

Не только. Префикс «this->» не энфорсится компилятором, в отличие от префикса «m_». Кто-то может писать или не писать «this->» при обращении к полю, а префикс «m_» от имени не оторвёшь.

Здравствуйте, Шахтер, Вы писали:

Ш>Существует дурная практика снабжать члены класса префиксом тип m_ .
Ш>Это характерный признак кода, созданного в крупных компаниях типа Майкрософт, в рамках "бюрократического программирования".
Ш>Не спасает.

Не спасает от чего? Какую проблему решаем?

Ш>На самом деле, если вы хотите выделить в коде работу с членом класса, используйте естественный префикс this->. Например так

Ну это все субъективно. Лично у меня каждая такая стрелочка ассоциируется с доп. косвенностью и действует мне на нервы. Я бы предпочел, при необходимости, написать Point::x вместо this->x. Подчеркиваю — при необходимости. Лучше всего, когда такой необходимости не возникает, а принадлежность имени понятна из самой логики программы без всяких префиксов.

Здравствуйте, rg45, Вы писали:

R>Здравствуйте, Шахтер, Вы писали:

Ш>>Существует дурная практика снабжать члены класса префиксом тип m_ .
Ш>>Это характерный признак кода, созданного в крупных компаниях типа Майкрософт, в рамках "бюрократического программирования".
Ш>>Не спасает.

R>Не спасает от чего? Какую проблему решаем?

Хороший вопрос, действительно, какую проблему решает префикс у членов? Неспособность нормально проектировать классы, превращая их в помойки? Нет, не решает.

Ш>>На самом деле, если вы хотите выделить в коде работу с членом класса, используйте естественный префикс this->. Например так

R>Ну это все субъективно. Лично у меня каждая такая стрелочка ассоциируется с доп. косвенностью и действует мне на нервы.

А это вообще-то хорошо. Напоминает, что тут вообще-то есть эта косвенность. Программистам на С++ иногда полезно вспоминать голый С.

R>Я бы предпочел, при необходимости, написать Point::x вместо this->x. Подчеркиваю — при необходимости.

Имя класса в локальном контексте -- плохо. Начнёшь переименовывать класс -- и пошло-поехало.

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

Золотые слова. И при правильном проектировании классов так и происходит. Но всё-таки иногда возникает необходимость обозначить член.
Решение через this-> -- самое подручное, не требующее ничего дополнительного. Кстати, в eclipse видна разница между членами и аргументами.
Так что использование хорошего редактора тоже помогает.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

использования this-> это тяжелое наследие ява кодеров
которые лезут говнокодить в С++
и обильное использование этого приема в С++ надо бить по рукам и пихать ногами под зад и профессии

все остальные методики подчеркиваний или префиксами всякими, это предпочтение каждого
или если в команде, то как правило есть договоренности

Здравствуйте, Шахтер, Вы писали:

Ш>Хороший вопрос, действительно, какую проблему решает префикс у членов? Неспособность нормально проектировать классы, превращая их в помойки? Нет, не решает.

Спасает. Я сам люблю префикс m_ и везде его использую. Он рулит для Intellisence, помогает быстрее ориентироваться в коде. Также позволяет давать естественные имена аргументам функций.
например:

Point(int x, int y) : m_x(x), m_y(y) {}

Очень часто аргументы или локальные переменные дублирую имена членов класса. А this-> это нечитабельная хрень, которую можно или писать, или нет — компилятор ничего не скажет.

P. S. Если человек, форумный долгожитель не может нормально выбрать цитируемый текст и оверквотит, то вон с форума?

Здравствуйте, Шахтер, Вы писали:

Ш>Хороший вопрос, действительно, какую проблему решает префикс у членов? Неспособность нормально проектировать классы, превращая их в помойки? Нет, не решает.

Отсутствие данного префикса, аналогично, ничем не помогает проектированию. Точно так же как использование какого-нибудь суффикса вместо него.

Ш>>>На самом деле, если вы хотите выделить в коде работу с членом класса, используйте естественный префикс this->. Например так

Это Питон: self.x, self.y. Там это неизбежно. Но это всё равно шум. Собственно вопрос — этот шум полезен или вреден?

Здравствуйте, Шахтер, Вы писали:

Ш>А это вообще-то хорошо. Напоминает, что тут вообще-то есть эта косвенность. Программистам на С++ иногда полезно вспоминать голый С.

Да, но только a->b->c->d — совсем не то же самое, что a.b.c.d по уровню косвенности, хоть в C, хоть в C++. Нет необходимости объяснять мне, что использование this-> никакого ущерба не несет. Но на нервы действует.

Здравствуйте, netch80, Вы писали:

N>Это Питон: self.x, self.y. Там это неизбежно. Но это всё равно шум. Собственно вопрос — этот шум полезен или вреден?

Лучший вариант у Ruby: @instanceMember.
Коротко, ясно и ничего не нужно придумывать.

Здравствуйте, Шахтер, Вы писали:

Ш>Существует дурная практика снабжать члены класса префиксом тип m_ .
Ш>Это характерный признак кода, созданного в крупных компаниях типа Майкрософт, в рамках "бюрократического программирования".
Ш>Не спасает.
Ш>На самом деле, если вы хотите выделить в коде работу с членом класса, используйте естественный префикс this->.

Я для членов, которые public, префиксов не использую, имхо так же неестественно, как имена методов с префиксом. Также, не использую префиксов для статических членов. Для всех остальных использую префикс _. this-> а шаблоном коде иногда разве что, много букв лишних.

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

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

И это я не про методы на пяток экранов , всё что длиннее двух-трехстрочника позволяет на этом залететь, незаметнее всего аргументы.

Здравствуйте, andyp, Вы писали:

A>Я для членов, которые public, префиксов не использую, имхо так же неестественно, как имена методов с префиксом. Также, не использую префиксов для статических членов. Для всех остальных использую префикс _.

Использование подчеркивания в качестве префикса чревато неприятностями:

https://timsong-cpp.github.io/cppwp/lex.name#3

In addition, some identifiers are reserved for use by C++ implementations and shall not be used otherwise; no diagnostic is required.
(3.1)
Each identifier that contains a double underscore __ or begins with an underscore followed by an uppercase letter is reserved to the implementation for any use.
(3.2)
Each identifier that begins with an underscore is reserved to the implementation for use as a name in the global namespace.

Здравствуйте, rg45, Вы писали:


R>Использование подчеркивания в качестве префикса чревато неприятностями:

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

Здравствуйте, rg45, Вы писали:

R>Здравствуйте, andyp, Вы писали:

A>>Я для членов, которые public, префиксов не использую, имхо так же неестественно, как имена методов с префиксом. Также, не использую префиксов для статических членов. Для всех остальных использую префикс _.

R>Использование подчеркивания в качестве префикса чревато неприятностями:

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

https://en.cppreference.com/w/cpp/language/identifiers

the identifiers that begin with an underscore followed by an uppercase letter are reserved;
the identifiers that begin with an underscore are reserved in the global namespace.

Здравствуйте, _NN_, Вы писали:

_NN>Мы же про члены класса говорим.
_NN>Это не глобальный идентификатор, не начинается на заглавную букву, а значит и проблем нет.

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

Здравствуйте, rg45, Вы писали:

R>Здравствуйте, _NN_, Вы писали:

_NN>>Мы же про члены класса говорим.
_NN>>Это не глобальный идентификатор, не начинается на заглавную букву, а значит и проблем нет.

R>И откуда взялась уверенность, что после подчеркивания не будет заглавной буквы? И область видимости тут не спасает, ибо пересечься может с имененм макроса.

Ну если кто-либо напишет с заглавной то его код не валидный по определению.
А вот насчёт имени макроса то это к разработчикам библиотек обращайтесь, чтобы не создавали макроса с такими именами

Здравствуйте, _NN_, Вы писали:

_NN>А вот насчёт имени макроса то это к разработчикам библиотек обращайтесь, чтобы не создавали макроса с такими именами

Ага, прямо так и скажу: "забейте на стандарт и слушайте, меня..."

Здравствуйте, reversecode, Вы писали:

R>использования this-> это тяжелое наследие ява кодеров
R>которые лезут говнокодить в С++

а почему в яве так можно, а в C++ — нет?

Здравствуйте, sergii.p, Вы писали:

SP>а почему в яве так можно, а в C++ — нет?

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