Это все вкусовщина, а иногда и способ самоутвердиться одних «более опытных товарищей» на фоне их менее опытных друзей, конечно с формулировками об увеличении readability, expressiveness, and consistency. Ты не увидишь других более конкретных объяснений, это всегда вкусовщина, обвешанная этими тремя словами.

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

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

всегда писать перед членами класса this->

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

https://en.wikipedia.org/wiki/Hungarian_notation

Вот, первый клиент. Рассказывай, как this->member выглядит говнее чем m_member.

Считать умеешь? Сравни this-> и _.

Вместо «customer» ты, надо полагать, напишешь просто «с», чтоб не как говно?

Нет, правильно писать «customer». За «c» надо руки отрывать. «this->» же не несёт смысловой нагрузки, только захломляет код, вынуждая тратить силы на чтение.

Представь ты вызываешь метод и передаёшь туда параметры. И перед каждым вынужден писать «this->». К тому же это удлиняет код вызова метода. Придётся делать перенос строки. И т.д.

По-моему это очевидное ухудшение читаемости. Не знаю с чем ты споришь.

Нет, правильно писать «customer».

лучше писать «dear customer».

С тем, что это вкусовщина, если только ты не читаешь по слогам и this становится для тебя непреодолимым препятствием.

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

Какой подход вам видится более последовательным и удобным?

Писать на сях.

Может есть описанный кодстайл

https://www.kernel.org/doc/html/v4.10/process/coding-style.html

лучше писать «dear customer».

Это для html «программистов», которые верстают e-mail

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

В большинстве кодстайлов члены класса явно выделяются. У гугла, например, foo_ член, foo всё остальное. У другой известной компании Foo член, foo всё остальное. У третьей m_* член. Любой из этих вариантов намного лучше this->, как по краткости и отсутствию визуального шума, так и по невозможности забыть приписать this-> и обратиться не к той переменной.

Ну и никаких «using namespace …» - всегда его с :: приставляю

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

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

«Серебряной пули» в этих вопросах ни когда не будет.
Должен быть единый стиль нотации …

Вариантов много. Сам я префиксы не особо люблю и такие параметры называю new_x.

m_* для членов самое адекватное и иногда полезное. _* и *_ дебильные. Некоторые и параметрам дают префиксы i_/o_/io_, а локальным переменным l_, но это уже перебор.

Для глобальных данных: группировка в структуры + префикс g_ для её переменной. :: работает только для действительно глобальных данных вне пространства имён или после using namespace, но вроде не лишнее.

Пространства имён удобнее сокращать, сложности чтению это особо не добавит:

using namespace fs = boost::filesystem;

Мне видится удобным такое: для членов-данных префикс m_, это короче this->, экономит место (правда иногда без this не обойтись - если пишешь шаблон, который наследуется от шаблона и ссылаешся на что-то из него). Для функций префикс f_ (кроме интерфейсных, если таковые есть). Если член помимо всего ещё и статический, то добавляю к нему ‘s’ (sm_ или sf_). Во всяких простых POD агрегатах никаких префиксов не делаю.

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

Для начала главное выработать единое в рамках проекта соглашение о разметке, касательно имён же я бы рекомендовал делать более описательные имена и чем глобальнее имя, тем оно должно быть описательнее-длиннее, а касательно x - во-первых лучше стараться избегать 1-2-ух буквенных имён, во-вторых модные у некоторых конторок приставки m_, g_ и пр. лично по мне перегружает код, т.к. это фиктивная часть имени, лучше использовать что-то содержательное в духе пускай того же coord_x, arr_x и пр. - печатать не сильно-то дольше, но бережёт время от знатной доли опечаток и ошибок по невнимательности, а самые удобные имена желательно оставлять для функций доступа, как например в Qt сделано, доступ к координате x(), прямоугольнику rect() и пр.

ага-ага, также добавляем v для виртуальных методов, b для возвращающих логическое значение и т.д. - короче к сожалению не значит удобнее, а алфавитные соглашения могут порождать разброд и опечатки в духе fm_,mf_

fm_,mf

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

О, спасибо за ссылку. А то я давно не могу найти начало в клубке под названием Линукс. Может это поможет.

У коллеги возник похожий вопрос - помогли ему разобраться с подсветкой в IDE и никаких this добавлять не пришлось.

Переходи в джава-программисты, воин с именами. Пиши трехэтажные имена не короче 45 символов юникода, когда мусорного словесного смысла в имени больше, чем логического.

с++

У тебя в тегах 'c' русская

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

Этот вопрос вряд ли где-то рассматривается, потому что ответ очевиден. Писать «this->» там, где можно не писать ничего - значит просто набирать ненужные символы. При этом если где-то в коде написано «x», а не «this->x», это не означает, что х не член, так как для компилятора оба варианта одинаково корректны.

всегда сразу вижу, что вот это вот член класса, а не локальная/глобальная переменая или ещё что

А у тебя что обычно 100500 локальных и глобальных переменных в скоупе?

Какой подход вам видится более последовательным и удобным

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

Всё верно. Лично я предпочитаю автоматическую область видимости(без this) т.к. так проще рефакторить и читать, хотя и есть шансы напороться на проблемки.

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

СМИШНО

У коллеги возник похожий вопрос - помогли ему разобраться с подсветкой в IDE и никаких this добавлять не пришлось.

Код, непонятный без подсветки, это профнекомпетентность.

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

m_* для членов самое адекватное и иногда полезное. * и * дебильные

Это чисто вкусовщина. По мне так наоборот m_* - менее удобно, т.к. набирать постоянно нужно эти два первые символа для всех переменных-членов. А если просто *_ - то сразу набираешь нужно имя и далее автодополнение подсказывает.

Набирать иногда неудобно (если нужны только поля, то удобно), зато читать удобно (область а потом имя, а не наоборот). _ в начале/конце выглядят как опечатки, сильно смахивают на зарезервированные имена и чёрт знает как выглядят с операторами (var_.field, var_->field, &_var). Префикс с буквой такому не подвержен.

Ну тут дело в том, что мы с тобой разным аргументам назначаем разные веса.

зато читать удобно

Читать тоже не удобно. _ на хвосте достаточно заметен, чтобы быть заметным, и не достаточно назойлив, как m_.

_ в начале/конце выглядят как опечатки

Это только если кодовая база совсем без них. В одном-двух экземплярах - да. Если это консистентная схема именования, то быстро привыкаешь.

сильно смахивают на зарезервированные имена

Вообще не похоже.

чёрт знает как выглядят с операторами

Да нормально выглядят. Говорю ж, дело привычки.

сильно смахивают на зарезервированные имена

Вообще не похоже.

http://eel.is/c++draft/lex.name#3:

In addition, some identifiers are reserved for use by C++ implementations and shall not be used otherwise; no diagnostic is required.

• 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.
• Each identifier that begins with an underscore is reserved to the implementation for use as a name in the global namespace.

Именно. У тебя всё настолько плохо, что ты __reserved__ с member_ можешь перепутать?

Не спикаем инглишь? _reserved нельзя использовать глобально, а _Reserved и локально.

И какое отношение это имеет к member_? Не спикаем русишь?

Изначально речь шла о

_ в начале/конце

В начале - это, конечно, чушь, и я такого нигде не видел.

или просто _.

С этими _ в начале переменных код выглядит как говно ещё большее чем с this->.

_ в начале/конце выглядят как опечатки, сильно смахивают на зарезервированные имена и чёрт знает как выглядят с операторами (var_.field, var_->field, &_var). Префикс с буквой такому не подвержен.

+1

Висячие прочерки _field или field_ замусоривают код и смотрятся отвратно, особенно когда с переменной нужно провести какие-то манипуляции. Код в мире был бы куда чище и читался куда как легче, если бы висячие прочерки были бы зарезервированы компилятором точно так же как __field.