ни разу еще не видел хорошего стандарта по кодированию C++
либо используется старый майкрософтовский стиль (hungarian notation, классы с буквой C впереди),
либо гнушно-юниксовый стиль (все с прописной буквы и подчеркивания),
либо его вообще нет
вот что мне видится более-менее рациональным:
-не используем C как префикс имени класса (долой наследие MFC!)
-не используем префиксы библиотек в имени класса, используем неймспейсы вместо
-используем вложенные неймспейсы для указания на иерархию библиотек,
впереди название продукта, затем подсистемы и библиотеки
MMS::core::utility::SomeClass вместо CMMSSomeClass
-не используем венгерскую нотацию, за небольшими исключениями (см.ниже)
-идентификаторы классов — с большой буквы, паскаль-стиль: SomeClass
-переменные на стеке — прописными буквами (гнушный стиль): local_variable_x
-переменные члены класса — джавовский стиль с подчеркиванием: _memberVariable
(насчет последнего — не уверен, как красивее. раньше было: m_memberVar )
скобки — попарно друг под другом:
{
}
-области видимости внутри класса идут в порядке: public, protected, private
-аргументы шаблона называем с префиксом T: TArg, TFun

Тебе это надо не тут обсуждать, а с теми, кто по нему жить будет.
Нету "правильного современного стиля кодирования".

Тут как бы возможны следующие случаи:

1. У команды разработчиков уже есть coding guidelines и они уже давно используются в проекте — ИМХО, нет смысла заменять их новыми, разве что по общему согласию избавиться от наиболее устаревших и раздражающих пунктов.
2. Coding guidelines нет вообще (команда разработчиков только что создана, к примеру). Тогда — следующие подпункты:
2.1 Поддержка (вариант — развитие) старого С++ проекта — как правило, коней на переправе не меняют и используют тот стиль coding guidelines который был в этом проекте изначально.
2.2 Написание нового проекта — как правило, проект не пишется с нуля а базируется на каких-то библиотеках. В этом случае имеет смысл взять coding guidelines из той библиотеки которая наиболее часто используется в проекте (к примеру — если ты пишешь COM на ATL, то и guidelines лучше подогнать под него).
2.3 Ситуация не подходит ни под один из пунктов — в этом случае надо писать свои coding guidelines. Лично у меня ни один из пунктов которые ты перечислил принципиальных возражений не вызывает, разве что за исключением яростной борьбы с венгерской нотацией — нотация-то хорошая, но переусердствовать в ней явно не стоит. К примеру, в 99% случаев переменную лучше назвать strWindowCaption вместо lpctstrWindowCaption или iLineCount вместо uiLineCount.

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

A>ни разу еще не видел хорошего стандарта по кодированию C++

Как вариант

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

...
A>-переменные члены класса — джавовский стиль с подчеркиванием: _memberVariable
Начинать имя с подчеркивания — это не хорошо :

17.4.3.1.2 Global names

Certain sets of names and function signatures are always reserved to the implementation:
— Each name that contains a double underscore (_ _) or begins with an underscore followed by an uppercase
letter (2.11) is reserved to the implementation for any use.

— Each name that begins with an underscore is reserved to the implementation for use as a name in the
global namespace.

и всё это без аргументов и обоснований,
ещё скажи goto и макросы не используем.
короче незачёт.

L> 2.3 Ситуация не подходит ни под один из пунктов — в этом случае надо писать свои coding guidelines. Лично у меня ни один из пунктов которые ты >перечислил принципиальных возражений не вызывает, разве что за исключением яростной борьбы с венгерской нотацией — нотация-то хорошая, но

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

копировать стиль из библиотек имхо не есть гуд, если ты не расширяешь саму эту библиотеку.
таким образом мы явно разделяем что вот эти классы — "наши", а иные — из библиотеки
(ну и неймспейсы с названием проекта для того и придумываются)

S>и всё это без аргументов и обоснований,
S>ещё скажи goto и макросы не используем.

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

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

A>обоснования нужны для корпоративного документа, я же тут не документ пишу
A>это обмен опытом по написанию стандартов кодирования
A>может вместе что-нибуьд родим

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

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

S>>и всё это без аргументов и обоснований,
S>>ещё скажи goto и макросы не используем.

A>обоснования нужны для корпоративного документа, я же тут не документ пишу
A>это обмен опытом по написанию стандартов кодирования
A>может вместе что-нибуьд родим

Известные чуваки, Саттер и Александреску в своих 101 правилах пишут:

0. Don't sweat the small stuff. (Or: Know what not to standardize.)

Do use consistent formatting within each source file or even each project, because it's jarring to jump around among several styles in the same piece of code. But don't try to enforce consistent formatting across multiple projects or across a company.

Don't overlegislate naming, but do use a consistent naming convention: There are only two must-dos: a) never use "underhanded names," ones that begin with an underscore or that contain a double underscore; and b) always use ONLY_UPPERCASE_NAMES for macros and never think about writing a macro that is a common word or abbreviation (including common template parameters, such as T and U; writing #define T anything is extremely disruptive). Otherwise, do use consistent and meaningful names and follow a file's or module's convention. (If you can't decide on your own naming convention, try this one: Name classes, functions, and enums LikeThis; name variables likeThis; name private member variables likeThis_; and name macros LIKE_THIS.)

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

L>> 2.3 Ситуация не подходит ни под один из пунктов — в этом случае надо писать свои coding guidelines. Лично у меня ни один из пунктов которые ты >перечислил принципиальных возражений не вызывает, разве что за исключением яростной борьбы с венгерской нотацией — нотация-то хорошая, но

A>меня в боьлшей степени интересуют мнения людей которые сами эти стандарты придумывают.
A>ибо иногда приходится этим заниматься

Ну тогда без ложной скромности: http://eao197.narod.ru/desc/lower_case.htm
Главная причина выбора lower_case вместо CamelCase (или camelCase, или Camel_Case) в том, что у меня глаза меньше устают при написании и чтении кода. И, как говорят мои коллеги, не только у меня.

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

A>ни разу еще не видел хорошего стандарта по кодированию C++
A>либо используется старый майкрософтовский стиль (hungarian notation, классы с буквой C впереди),
Вообще-то фирма MS многого добилась в групповой разработке ПО. ИМХО их опыт отвергать стоит только понимая почему ты его отвергаешь

A>либо гнушно-юниксовый стиль (все с прописной буквы и подчеркивания),
AFAIK и гиусовцы многого добились на анологичном поприще...

A>либо его вообще нет
A>вот что мне видится более-менее рациональным:
Главное не описано, а зачем нужно то, или иное ограничение?

A>-не используем C как префикс имени класса (долой наследие MFC!)
А чем это плохо?

void foo() {
    goo( too( 5 ) ); // Что тут написано? too -- это конструктор too или таки функция от int?
    const to& xxx = too( 6 ); // а тут что написано? Это безопасно, или опасно?

    // Хорошо ещё, что так пока нельзя: 
    // auto yyy = too( 0x09 ); // yyy -- оно типа too или нет? :)
}

A>-не используем префиксы библиотек в имени класса, используем неймспейсы вместо
A>-используем вложенные неймспейсы для указания на иерархию библиотек,
A>впереди название продукта, затем подсистемы и библиотеки
A>MMS::core::utility::SomeClass вместо CMMSSomeClass
А зачем? Ещё MMS::SomwClass я понимаю зачем, но вот зачем там ещё и core::utility:: ?
A>-не используем венгерскую нотацию, за небольшими исключениями (см.ниже)
ИМХО обсуждаемо
A>-идентификаторы классов — с большой буквы, паскаль-стиль: SomeClass
A>-переменные на стеке — прописными буквами (гнушный стиль): local_variable_x
а что делать с однословными классами и переменными?

A>-переменные члены класса — джавовский стиль с подчеркиванием: _memberVariable
A>(насчет последнего — не уверен, как красивее. раньше было: m_memberVar )
А в чём во всём этом смысл?
A>скобки — попарно друг под другом:
A>{
A>}
Даже в определении класса?
А можно ли написать так, например:

class MyClass 
{ // Это я так понимаю, что ты хочешь такое?
public:
    int Size() const { return size; } // А так можно?
};

A>-области видимости внутри класса идут в порядке: public, protected, private
А если это неудобно почему-то?
А если есть такая секция public:

class MyClass {
public:
   // Тут public интерфейс

protected:
   // Тут protected интерфейс

private:
   // Тут private часть

// Эти методы предназначены только для вызова из кода инициализации/деинициализации приложения!!
public:
   static bool Start();
   static void Stop();
};

A>-аргументы шаблона называем с префиксом T: TArg, TFun
А typedef'ы?
Например такие:

template<typename TElement> class MyArray {
public:
    typedef TElement AndWhatIMustWriteHere;
    // ...
    
};

Могу поделиться своими соображениями по приведённым и неприведённым пунктам.

1) Венгерская нотация, ИМХО устарела почти везде. Дело в том, что она была очень нужна в C, так как там не было таки контроля типов, кроме глаз программиста. Теперь, если писать в С++ стиле, то всё понимает сам компилятор.
То есть мне кажется, что лучше давать понятные имена переменным, а не приписывать к ним длинные предлинные префиксы. Ну типа вместо sText писать просто Text да и всё, а вместо nItems писать ItemsCount
2) Отдельным применением венгерской нотации является использование префикса типа для различения разных представлений одних и тех же данных. Например как-то так:

void processString( const char* pText ) {
    std::string sText( pText );
    // тут что-то делаем с sText
}

ИМХО в таком случае можно применять и венгерскую нотацию, если у тебя есть какой-то простой способ порождать на все типы префиксы, потому что иначе ты упрёшься в такую попу:

void processString( myLib1::string sText ) {
    std::string sText( sText ); // Как назвать вторую строку?
    // тут что-то делаем с sText
}

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

void processString( const char* rawText ) {
    std::string text( rawText );
    // тут что-то делаем с text
}

или даже так:

void processString( const char* cString ) {
    std::string cppString( pText );
    doProcess( cppString );
}

а на крайняк использовать постфиксы, как-то описывающие тип данных, например так:

void processString( const char* textPtr ) {
    std::string text( textPtr );
    // тут что-то делаем с text
}

3) Гребёнка от M$ vs гнушный стиль.
Собственно моё ИМХО тут состоит в том, что гребёнку удобнее читать. Да и идентификаторы на число пробелов короче, но гнушный стиль удобнее набирать, особенно слепым десятипальцевым методом... Так что в зависимости от того чего больше предполагается делать с этим кодом читать или писать, такую нотацию и выбираем ТакЧтоЯСвойВыборСделал
4) Пефиксы имён классов
Собственно префиксы имён классов нужны для того, чтобы подсказать программисту, который читает код что обозначает запись. Преобразование типа или вызов функции или создание временного объекта. Так как у временных объектов иногда другие бывают повадки, чем у функций.
5) Отличие локальных переменных от функций и глобальных переменных и членов
ИМХО лучше всё называть так, чтобы было понятно из названия непосредственно, но это не всегда удобно и даже возможно. Я бы как-то выделял члены (скорее всего при помощи постфикса _m), для которых крайне критично понимать, что они члены внутри реализации методов. ИМХО обычно это не нужно, так как можно дать члену класса такое название, что понятно что это такое.
С другой стороны, когда пишешь код метода и хочешь подчеркнуть, что это таки член, ты в нестатических методах можешь написать this->member...
Про отличение классов от переменных и функций я уже писал. Остался ещё один аспект. Отличение глобальных имён о локальных.
Ну типа там локальных переменных от глобальных, параметров метода от членов класса и т. д.
Я придерживаюсь такого подхода, что локальные сущности называю с маленькой буквы, а нелокальные с большой. Но и даже это, ИМХО, не особо-то и нужно...
6) Размещение скобок.
ИМХО намного важнее, чтобы скобки распалагались симметрично
Ну типа или так:

if( ... ) { 
} else {
}

или так:

if( ... )
{
}
else
{
}

но при этом стоит таки оставить возможность писать методы в одну строку
7) Ещё, ИМХО, очень ценным является принципы "одно действие -- одна строка" и "слишком сложное выражение надо явно разбить на части"

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

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

A>ни разу еще не видел хорошего стандарта по кодированию C++
ИМХО, у каждого программиста рано или поздно возникает желание создать самый лучший в его понимании стандарт кодирования.
А когда программист становится еще опытнее, он начинает понимать, что самого лучшего стандарта кодирования нет и не может быть.
Еще можно говорить о том, чтобы узкая группа, работающая над одним и тем же проектом, соблюдала единоообразие в стиле кодирования.
А как только правила становятся стандартом для всех, тут и начинается — одному такие скобки подавай, другому — другие скобки, одному — префикс Т, другому — префикс С и т.п. И ведь все будут правы.

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

A>ни разу еще не видел хорошего стандарта по кодированию C++

Вот эти несколько слов: стиль программирования меня не волнует. Я достаточно краток? Если хотя бы
половина времени, израсходованного на правильную расстановку фигурных скобок, тратилась на
обдумывание программы или еще лучше — на общение с пользователями, то вся отрасль работала бы
намного эффективнее. Конечно, единство стиля — вещь хорошая, но я еще не видел книги или
руководства по стилю, которые бы стоили даже часового собрания группы в начале проекта. К тому же
ни одна книга или руководство по стилю не превратят код неаккуратного программиста в нечто
осмысленное. В сущности, стиль часто используется как оправдание недостатка внимания к самой
программе. Наконец, я еще не видел, чтобы в спорах о стиле один программист в чем-то убедил
другого, поэтому любые дискуссии на эту тему считаю бесполезной тратой времени.
(с)Джефри Элджер С++ for Real Programmers

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

_>[q]
_>Вот эти несколько слов: стиль программирования меня не волнует. Я достаточно краток? Если хотя бы
_>половина времени, израсходованного на правильную расстановку фигурных скобок, тратилась на
_>обдумывание программы или еще лучше — на общение с пользователями, то вся отрасль работала бы
_>намного эффективнее.

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

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

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

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

OE>не превратят, факт. Только вот для того чтобы понять насколько этот код осмысленный и в каких местах, времени, за экономию которого так страдает Элджер, понадобится раз в 10 меньше.

Просто надо находить компромисс. Я считаю, что я достаточно аккуратно оформляю код. Ну то есть соблюдаю отступы (точнее, это делает assist), не пишу сильно длинные строки, не делаю несколько действий в одной строке, стараюсь не писать сильно длинных методов и выбираю осмысленные имена. Однако, подобные стандарты придираются к каждой запятой, и мало кто оговаривает степень их строгости — обычно пишут "следует применять, следует оформлять". В тех станадртах оформления, которые видел я, очень редко встречается слово "рекомендуется".

По-моему, вменяемый программист обычно нормально оформляет код в любом стиле. По своему опыту скажу, что читать и даже писать код в другом стиле привыкаешь за полдня-день (это включает camel-gnu оформление, использование-неиспользование венгерской нотации и т.п.), если не требуется соблюдать все правила фанатично — то есть если меня не будут бить по башке, кодга я вместо uiCount напишу iCount, как тут уже приводили пример.

В общем, хотел сказать, что я не понимаю педантичного следования правилам. Минимум форматирования обеспечит IDE, остальное — придёт с опытом. А доскональное оформление кода по coding guidelines нерационально (ну скажите, какая разница, напишу я f(x, y) или f( x, y )? лично у меня ни один из вариантов отторжения не вызывает). Выбрать и настроить IDE один раз — может быть и стоит, но вручную следить за тем, все ли пробелы я написал, а тем более придираться к другим — меня не тянет.

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

L> ... принципиальных возражений не вызывает, разве что за исключением яростной борьбы с венгерской нотацией — нотация-то хорошая, но переусердствовать в ней явно не стоит. К примеру, в 99% случаев переменную лучше назвать strWindowCaption вместо lpctstrWindowCaption или iLineCount вместо uiLineCount.
Я от венгерки лично для себя оставил только m_ для членов класса. Все остальное в сад. Для того, чтоб узнать тип переменной у меня есть Assist

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

E>Ну тогда без ложной скромности: http://eao197.narod.ru/desc/lower_case.htm
E>Главная причина выбора lower_case вместо CamelCase (или camelCase, или Camel_Case) в том, что у меня глаза меньше устают при написании и чтении кода. И, как говорят мои коллеги, не только у меня.
Как по мне так camelCase читается гораздо естественнее. На lower_case у меня глаза ломаюццо
Что впрочем лишний раз подтверждает что на вкус и цвет...

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

CC>Я от венгерки лично для себя оставил только m_ для членов класса. Все остальное в сад. Для того, чтоб узнать тип переменной у меня есть Assist

Assist есть в IDE, а я, например, часто читаю чужой код в чём-то вроде NotePad'а

Но, тем не менее, я от чего-то похожего на венгерку оставил только префикс C перед именами калссов с нестатическими членами.