Такой вопрос.

Вот, ранее была т.н. Венгерская нотация чуть ли не стандартом. Теперь смотрю — не все ее используют. Вот пример гугла: https://htmlpreview.github.io/?https://github.com/evgenykislov/styleguide/blob/ru_cpp/cppguide.html

Есть ли какой-либо порядок в этом? Что вы используете?

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

> Теперь смотрю — не все ее используют.

Я бы сказал больше — никто ее не использует

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

S>Вот, ранее была т.н. Венгерская нотация чуть ли не стандартом. Теперь смотрю — не все ее используют. Вот пример гугла: https://htmlpreview.github.io/?https://github.com/evgenykislov/styleguide/blob/ru_cpp/cppguide.html

А k в начале названий констант и _ в конце имён NSDM-ов — это не венгерская нотация?

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

S>Вот, ранее была т.н. Венгерская нотация чуть ли не стандартом. Теперь смотрю — не все ее используют.
В современном C++ одна и та же переменная может быть как числом, так и объектом, а объект может быть как смарт указателем, так и функциональным объектом, поэтому венгерская нотация просто неприменима.

S>Есть ли какой-либо порядок в этом? Что вы используете?
Самый разумный стиль, это allman style, но это про выравнивания. Что же касается названий, то главное, чтобы стиль был, а какой — не очень важно.

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

BFE>В современном C++ одна и та же переменная может быть как числом, так и объектом, а объект может быть как смарт указателем, так и функциональным объектом, поэтому венгерская нотация просто неприменима.

А пример можно?

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

S>Есть ли какой-либо порядок в этом? Что вы используете?

Стиль, который определен в файле .clang-format в корне проекта: https://clang.llvm.org/docs/ClangFormat.html

Для личных проектов Allman style с именованием snake_case

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

S>Есть ли какой-либо порядок в этом? Что вы используете?

Я в C++ называю макросы в CamelCase, и мне не стыдно.

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

K>Я бы сказал больше — никто ее не использует

Я использую.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Я в C++ называю макросы в CamelCase, и мне не стыдно.

Но ты в курсе, что повод для стыда существует, все-таки

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

R>Но ты в курсе, что повод для стыда существует, все-таки

Я в курсе, что он исчез примерно тогда, когда стали массово работать в IDE, умеющих в навигацию по коду.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Я в курсе, что он исчез примерно тогда, когда стали массово работать в IDE, умеющих в навигацию по коду.

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

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

R>Тогда что такого героического в том, что тебе не стыдно

Тут речь не о героизме — просто об осознании того, что скрепы должны быть разумными. А то ведь чуть не в каждом втором современном руководстве по C/C++ подчеркивается, что все макросы должны быть uppercase.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Тут речь не о героизме — просто об осознании того, что скрепы должны быть разумными. А то ведь чуть не в каждом втором современном руководстве по C/C++ подчеркивается, что все макросы должны быть uppercase.

А еще "чуть не в каждом втором современном руководстве по C/C++" объясняется, почему следует стремиться минимизировать применение макросов. И как раз для того, чтобы добиться этой минимизации и рекомендуется писать макросы в uppercase. Но, как я догадываюсь, на первую рекомендацию ты забил так же, как и на вторую. А возможно, еще и гордишься этим. Да?

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

R>А еще "чуть не в каждом втором современном руководстве по C/C++" объясняется, почему следует стремиться минимизировать применение макросов.

Все эти руководства идут лесом, ибо там, где я могу написать короткий и понятный с первого взгляда макрос, они предлагают мне сгородить совершенно неестественный шаблон, а еще чаще — пачку шаблонов, использующих друг друга. Ну и сама возможность городить такие шаблоны обычно подразумевает необходимость перехода на жирные и тормозные современные инструменты. Пока есть возможность, я с VS 2008 не слезу.

Здравствуйте, Евгений Музыченко, Вы писали:

R>>А еще "чуть не в каждом втором современном руководстве по C/C++" объясняется, почему следует стремиться минимизировать применение макросов.

ЕМ>Все эти руководства идут лесом, ибо там, где я могу написать короткий и понятный с первого взгляда макрос, они предлагают мне сгородить совершенно неестественный шаблон, а еще чаще — пачку шаблонов, использующих друг друга. Ну и сама возможность городить такие шаблоны обычно подразумевает необходимость перехода на жирные и тормозные современные инструменты. Пока есть возможность, я с VS 2008 не слезу.

Удивительно, как ты еще на VS 2008 залез. А главное, зачем.

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

R>Удивительно, как ты еще на VS 2008 залез. А главное, зачем.

Когда-то я последовательно менял VS 4.0, 4.2 и 6.0 "просто потому, что они новее". На VS 2005 переходить не планировал, но в новых версиях SDK/DDK пошли библиотеки нового формата, решил попробовать. Она зашла как-то очень легко, не было ощущения неудобства или тормознутости, глюков было очень мало, и все непринципиальные. Потом у меня сперли ноутбук, на новый попробовал поставить VS 2010 и 2013, они вызвали резкое ощущение отторжения. Потому и поставил 2008, как последнюю из более-менее сбалансированных.

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

BFE>>В современном C++ одна и та же переменная может быть как числом, так и объектом, а объект может быть как смарт указателем, так и функциональным объектом, поэтому венгерская нотация просто неприменима.
S>А пример можно?
Можно.
Тип value не определён:

template < class T >
struct X
{
   void push_back(T value);
};

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

S>Есть ли какой-либо порядок в этом? Что вы используете?
Qt — camelCase + K&R

Если проект без Qt, то snake_case + K&R.