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

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

ИМХО это подтверждает только то, что вы поразному IDE настраиваете. Размер и тип шрифта, цвета и т. д.
Но, тем не менее, если говорить о читабельности, то большинство ников на rsdn таки в camelCase, ИМХО...
Наверное это просто к естественному языку юлиже. ЛогоВАЗ там всякие и CuneiForm

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

OE>

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

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

Понимаешь, правила кодирования бывают двух типов. Бывают неформальные правила, ну например такое: "выбирайте идентификаторы так, чтобы из их названия была ясна их семантика и связь с контекстом использования, если такое название для идентификатора придумать не удаётся, то переформулируйте свой код как-то иначе", а может быть такое, очень легко проверяемое формально: "Все фигурные скобки в программе, за исключением содержимого строковых и сомвольных литералов и комментариев должны находиться на отдельной строке. Открывающая должна находиться ровно под началом имеющеё к ней отношения структуре, а закрывающая строго под открывающей"

Так вот от первых толк бывает, а от вторых совсем редко...

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

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

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

тем что используются бессмысленные имена.
идентификатор класса и методов должны нести какой-то смысл.
часто используется такое соглашение:
Имя класса — существительное (англ.), дополнительная характеристика класса — прилагательное или др.описательная часть речи (впереди имени)
т.е. JobMonitor а не MonitorJob (если речь о "мониторе" контролирующем какие-то задания)
если же Job является первичным то например BlowJob


A>>MMS::core::utility::SomeClass вместо CMMSSomeClass
E>А зачем? Ещё MMS::SomwClass я понимаю зачем, но вот зачем там ещё и core::utility:: ?

это необязательно, но в больших проектах состоящих из многих исходников, защищает от коллизий имен.
например есть MMS::Presentation::DataAdapter и MMS::DataAccess::DataAdapter
(можно конечно и так: MMS_Presentation и MMS_DataAccess)

E>а что делать с однословными классами и переменными?
это как? по моему такого быть не должно. если в классе есть переменная член, у нее кейс будет другой.
в С# нотация с разными кейсами первой буквы используется чтоб отличить внешний метод (property),
от внутренней переменной имеющей тот же смысл, например

private int startupTime
public int StartupTime { get; set; }

в C++ можно писать так:

private:
  int startupTime_;
public:
  int StartupTime() const; // "get" - не должно совпадать с именем класса!
  // если же совпадает, то как вариант getStartupTime() / setStartupTime()

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

class KickAss
{
public:
   KickAss() {} // здесь!
   ~KickAss() {}
};

E>А можно ли написать так, например:

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

согласен, это частный случай предыдущего

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

принимается. тут возможны варианты.
достоинство такого способа то что подавляется "неявный" private, что чревато побочными эффектами.
этот способ гарантирует что каждый метод определен под явно описанным идентификатором области видимости

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

typedefы обычно должны нести смысл того типа который они переопределяют.
т.е. то же соглашение что для имен классов.

E>То есть мне кажется, что лучше давать понятные имена переменным, а не приписывать к ним длинные предлинные префиксы. Ну типа вместо sText писать >просто Text да и всё, а вместо nItems писать ItemsCount

осмысленные имена — ключ к хорошо читаемому коду.
например inputToken лучше чем малопонятный strString, даже если это временная переменная.
из названия следует что токен — это элемент какой-то входной строки, скармливаемый парсеру за раз

E>2) Отдельным применением венгерской нотации является использование префикса типа для различения разных представлений одних и тех же данных. Например как-то так:

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

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

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

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

E>Собственно моё ИМХО тут состоит в том, что гребёнку удобнее читать. Да и идентификаторы на число пробелов короче, но гнушный стиль удобнее набирать, особенно слепым десятипальцевым методом... Так что в зависимости от того чего больше предполагается делать с этим кодом читать или писать, такую нотацию и выбираем ТакЧтоЯСвойВыборСделал
+1

E>С другой стороны, когда пишешь код метода и хочешь подчеркнуть, что это таки член, ты в нестатических методах можешь написать this->member...
+1
иногда специально так пишу, хотя это длиннее.

E>Про отличение классов от переменных и функций я уже писал. Остался ещё один аспект. Отличение глобальных имён о локальных.
E>Ну типа там локальных переменных от глобальных, параметров метода от членов класса и т. д.

глобальные переменные мы называли с префиксом g_
g_Logger;
но можно их и не использовать напрямую, а использовать статические методы синглтонов,
т.е. Logger::Instance() . тогда проблема именования отпадет

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

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

еще про именования локальных переменных:
общеупотребимые "бессмысленные" имена допустимы для кратковременно живущих локальных переменных
i,j — счетчики цикла
p — то же для указателей , например в конструкциях типа while (*p++ )
it — временный итератор , например в циклах типа for ( it = v.begin(); it != v.end(); ++it)
ret, retVal — временная копия возвращаемого значения функции (если ее нельзя вычислить в точке возврата)


спец.комментарии (нотация позаимствована с моей предыдущей работы).
состоят из ключевого слова и краткого описания сути проблемы.
спец.комментарии предназначены для привлечения внимания того кто делает code review,
или для облегчения поиска подобных мест скриптами и анализаторами кода
// BUG:
// ISSUE:
-известные проблемы, которые не могут быть пофиксены сейчас. оставлены до след.релиза
// TRICKY:
-нетривиальный, сложный кусок кода или алгоритм. предупредждение "не лезь если не знаешь как работает"
// UGLY:
-"затычка", временное, некрасивое или неоптимальное решение. указание что кусок кода должен быть переписан по возможности
// REFACTOR:
-похоже на предыдущее но менее строгое. код который возможно подвергнется рефакторингу
// TODO:
-указывает на недописанный кусок кода.

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

CC>>Что впрочем лишний раз подтверждает что на вкус и цвет...
E>...все фломастеры невкусные...
Точно!

E>ИМХО это подтверждает только то, что вы поразному IDE настраиваете. Размер и тип шрифта, цвета и т. д.
не поверишь — default

E>Но, тем не менее, если говорить о читабельности, то большинство ников на rsdn таки в camelCase, ИМХО...
E>Наверное это просто к естественному языку юлиже. ЛогоВАЗ там всякие и CuneiForm
Есть такое.

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

E>Assist есть в IDE, а я, например, часто читаю чужой код в чём-то вроде NotePad'а
За что ж тебя так жОстко то?
Впрочем мне после ассиста уже даже в любимом Far + Colorer не так удобно читать. Сильно не хватает find reference

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

E>>ИМХО это подтверждает только то, что вы поразному IDE настраиваете. Размер и тип шрифта, цвета и т. д.
CC>не поверишь — default
Почему не поверю?
Среды-то разные На одних часто на gcc пишут, а на других на MSVC...

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

E>>Assist есть в IDE, а я, например, часто читаю чужой код в чём-то вроде NotePad'а
CC>За что ж тебя так жОстко то?
Ну код подчинённых, код, присланный на аттестацию, код в соседней подсистеме обычно неудобно открывать в IDE, вполне достаточно и NotePad'а...
Во всяком случае если код нормальный
Просто левый проект долго и нудно открывать в целом...

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

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

E>>>Assist есть в IDE, а я, например, часто читаю чужой код в чём-то вроде NotePad'а
CC>>За что ж тебя так жОстко то?
E>Ну код подчинённых, код, присланный на аттестацию, код в соседней подсистеме обычно неудобно открывать в IDE, вполне достаточно и NotePad'а...
Я по старой привычке обычно фаром F3 или F4. Тока вот если сурс больше чем 1 файл и есть зависимости туда-сюда то проще его в визжалку загрузить и там побегать. У нас щас принудительно перешли на 2005-ю, но я себе оставил 2003-ю, она куда шустрее бегает, вот ей и открываю все стороннее. Так заодно и основная среда (2005) не засоряется.

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

Я со всем согласен почти, главное, что рулит не всякие формальные у'роды, а осмысленное именование идентификаторов.

то не согласен откомментил.

A>т.е. JobMonitor а не MonitorJob (если речь о "мониторе" контролирующем какие-то задания)
A>если же Job является первичным то например BlowJob
Это всё хорошо, и в целом просто сводится к рекомендации "изучите английский"
Но в этом причудливом языке часто нельзя сказать что за часть речи мы видим.
Вот, например, LinkMonitor -- это функция или класс

A>это необязательно, но в больших проектах состоящих из многих исходников, защищает от коллизий имен.
A>например есть MMS::Presentation::DataAdapter и MMS::DataAccess::DataAdapter
A>(можно конечно и так: MMS_Presentation и MMS_DataAccess)
Ну в ОЧЕНЬ БОЛЬШИХ может и надо, хотя тут ещё и коллизия имён файлов начнётся, что при использовании каких-нибудь неудобных условий отладки ещё и IDE нагнуть может.
ИМХО лучше конечно избегать разветвлённых иерархий namespaces, кроме того, для совсем совсем потрохов можно использовать nested classes, ну и два ещё замечания.
1) Вообще-то если у двух классов правильно выбранные имена совпадают -- это часто хинт, что возможно это один класс должен быть.
2) В сложных иерархических системах, особенно если они проектировлаись "по месту" обычно очень трудно ориентироваться...

A>в C++ можно писать так:
A>

A>private:
A>  int startupTime_;
A>public:
A>  int StartupTime() const; // "get" - не должно совпадать с именем класса!
A>  // если же совпадает, то как вариант getStartupTime() / setStartupTime()
A>

ИМХО так и нужно. Просто оригинальный пост я понял так, что ты предлагаешь camelCase и gcc_style использовать для разделения классов ипеременных.
Правда я бы тут сделал небольшое исключение. Вот всякие public, которые "не public на самом деле" тоже с маленькой буквы

Да и вообще мне всё-таки нраыится правило "потроха с маленькой, морда с большой"
E>>А можно ли написать так, например:

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

A>согласен, это частный случай предыдущего

Я бы всё-таки советовал тебе не заморачиваться на точном следовании расстановки скобок именно так. Предложи все популярные вменяемые паттерны, правда я бы запретил if, for, while и do while без скобок использовать. Чтобы такие косяки не сбивали:

 for( int i = 1; i < size; i++ );
    doItOneTime();

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

A>typedefы обычно должны нести смысл того типа который они переопределяют.
A>т.е. то же соглашение что для имен классов.

Очень хорошо. И чте же надо написать тут:

template<typename TElement_> class MyArray {
public:
    typedef TElement_ TElement;

    // есть, кстати, ещё и вторая похожая тема
    MyArray( int size_ ) : size( size_ ) {...}
};

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

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

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

A>глобальные переменные мы называли с префиксом g_
A>g_Logger;
A>но можно их и не использовать напрямую, а использовать статические методы синглтонов,
A>т.е. Logger::Instance() . тогда проблема именования отпадет
Я неточно выразился. Скорее речь шла о внешних для какого-то куска и внутренних..
Ну да с этим всё понятно в целом.

A>внутренняя реализация (включая локальные и временные переменные) — как угодно на усмотрение разработчика
Ну я бы с известными ограничениями. Я думаю, что надо писать в правилах кодирования два глагола. Скажем "нужно" и "рекомендуется", и соответсвенно во внешних требовать соблюдать всё, а в потрохах только "нужно", а "рекомендуется" по желанию, но какой-то вектор лучше таки задавать. Просто чтобы люди которым всё равно писали одинаково, что удобно для всех.

Ещё, кстати, можно забавить слово "категорическиЗапрещается"

Про спец. комменты тоже правильно. Только ещё классно эти все комменты где-то регить.
Их, кстати, можно оформлять и так:

#pragma hintRefact // тут надо бы переписать то и сё

ТОгда при компиляции будут предупреждения о неизвестной прагме

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

CC>Я по старой привычке обычно фаром F3 или F4. Тока вот если сурс больше чем 1 файл и есть зависимости туда-сюда то проще его в визжалку загрузить и там побегать. У нас щас принудительно перешли на 2005-ю, но я себе оставил 2003-ю, она куда шустрее бегает, вот ей и открываю все стороннее. Так заодно и основная среда (2005) не засоряется.

Ну фар или NotePad не так уж и разнятся.
А вообще хинт в том, что даже если у тебя есть пять файлов из проекта, где их 1000, то без проекта IDE тебе не поможет

CC>Я от венгерки лично для себя оставил только m_ для членов класса. Все остальное в сад. Для того, чтоб узнать тип переменной у меня есть Assist
Ты ж не елозишь мышкой (и не бегаешь курсором) по строкам кода по мере чтения. Ну и опять же, не всегда код читают из IDE. Assist это безусловно отличная тулза, но лично моё мнение — префиксы типа перед переменными существенно (настолько существенно, что есть смысл заморачиваться на их написание) увеличивают читабельность кода.

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

A>ни разу еще не видел хорошего стандарта по кодированию C++
А тут проблема то не в языке, а то, что изначально не было такого стандарта. В WINAPI так, в MFC по другому, в STL по третьему, в сторонних библиотеках четвертое, а сами пишем еще как-то. Тип может называться myType, TMyType, CMyType, t_my_type, c_myType, k_my_type — вариантов до черта можно придумать . В результате однообразно уже боюсь никак не сделать — наследие. В C# что-то похожее наблюдается, единого стандарта нет (даже если и есть — много кода портируется с Java, а там стиль отличается).
А как стандарт — я просто в восторге от жабовского. Куда не плюнь — везде однообразие, и в стандартных библиотеках, и в сторонних, и в собственных, и в библиотеках и коде разных заказчиков. Если я не ошибаюсь — Java это единственный C подобный язык, для которого стиль четко определен. Я бы подумал над тем, чтобы этот стиль переносить на другие языки, хотя бы частично, думаю имеет смысл его использовать в C подобных языках. Главное чтоб IDE была достаточно удобная, чтобы не было необходимости использовать венгерку, префиксы m_ и т.д.

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

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

Сразу бы сказал, что хочешь услышать, а то пост в полувакуум был
http://www.rsdn.ru/Forum/?mid=1999144

Автор: FreshMeat
Дата: 13.07.06

(посмотри док от команды буста)
Специально для лентяев Coding Standard Generator
В гугле первой ссылкой падает http://www.chris-lott.org/resources/cstyle/, подробнее не смотрел.

По твоему стандарту кодирования только одна претензия — пиши к каждому пункту
1. обоснования/достоинства (rationale)
2. возможные претензии/недостатки
Тогда обсуждать документ с коллегами (или объяснять эти правила новичку) будет существенно проще.

Касаемо коментариев по пунктам — Erop раскрыл тему.

>придумать . В результате однообразно уже боюсь никак не сделать — наследие. В C# что-то похожее наблюдается, единого стандарта нет (даже если и есть >- много кода портируется с Java, а там стиль отличается).

в C# как раз стандарт есть. называется Design Guidelines
http://msdn2.microsoft.com/en-us/library/czefa0ke(vs.71).aspx
как его часть, есть и соглашение об именах:
http://msdn2.microsoft.com/en-us/library/xzf533w0(VS.71).aspx

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

E>Ну фар или NotePad не так уж и разнятся.
Раскраской синтаксиса как минимум.

E>А вообще хинт в том, что даже если у тебя есть пять файлов из проекта, где их 1000, то без проекта IDE тебе не поможет
Зачастую все же помогает.

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

CC>>Я от венгерки лично для себя оставил только m_ для членов класса. Все остальное в сад. Для того, чтоб узнать тип переменной у меня есть Assist
L>Ты ж не елозишь мышкой (и не бегаешь курсором) по строкам кода по мере чтения.
Представь себе, еложу. Я еще и мышыным колесом скролю.
Информация о типе лично мне нужна только тогда, если из кода нифига не понятна его логика, или она очень сильно завязана на типах.

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

CC>>>Я от венгерки лично для себя оставил только m_ для членов класса. Все остальное в сад. Для того, чтоб узнать тип переменной у меня есть Assist
L>>Ты ж не елозишь мышкой (и не бегаешь курсором) по строкам кода по мере чтения.
CC>Представь себе, еложу. Я еще и мышыным колесом скролю.
Ну вот — а венгерская нотация позволяет это делать реже за счёт того что основную идею о том какого типа переменная можно понять не елозя мышкой. (Кстати, минусов мне за слово "елозишь" наставили? Не хотел обидеть — просто не нашёл другого слова ).

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

L>>но лично моё мнение — префиксы типа перед переменными существенно (настолько существенно, что есть смысл заморачиваться на их написание) увеличивают читабельность кода.
CC>Мое мнение — префиксы в большинстве своем это рудимент, только засоряющий код. Чтение от их наличия зачастую ИМХО только ухудшается.
Ну вот, а я пытаюсь показать что всё как раз наоборот

CC>А какая свистопляска начинается при смене типа переменной — этож везде где она используется надо имена поменять. А нормальные тулы для рефакторинга для С++ не так уж давно появились.
Но ведь появились же! К тому же — давай рассмотрим чуть подробнее аргумент про изменение типа. Я вижу 2 основных случая — меняется тип локальной переменной или меняется тип переменной — члена класса. В обоих случаях место где используется переменная чётко локализовано (в первом случае — контекст функции или блока, во втором — файлом с реализацией класса). Так что даже банальный Find&Replace в большинстве случаев решает проблему. Реальные проблемы при смене типа начинаются тогда, когда переменная торчит наружу класса как public и используется в системе повсеместно. ИМХО, широкораспространённость такой ситуации говорит о неудачном дизайне.

CC>>Информация о типе лично мне нужна только тогда, если из кода нифига не понятна его логика, или она очень сильно завязана на типах.
L>Логика довольно часто завязана на типы. Не завязана на типы она, пожалуй, в основном только в шаблонном коде. А шаблонного кода обычно в проекте мало или очень мало по сравнению с нешаблонным.

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

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

если следовать этим же правилам в C++ , получается что нужно перед каждым именем переменной-экземпляра класса,
писать имя его типа

Dick clsDickClintonDick;
Job clsJobMonikaJob;

бредово и громоздко не правда ли?
так почему мы для одних типов делаем исключения, а для других нет? нотация не консистентна

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

L>>>Ты ж не елозишь мышкой (и не бегаешь курсором) по строкам кода по мере чтения.
CC>>Представь себе, еложу. Я еще и мышыным колесом скролю.
L>Ну вот — а венгерская нотация позволяет это делать реже за счёт того что основную идею о том какого типа переменная можно понять не елозя мышкой.
Набор везде по коду префиксов гораздо более трудооемко чем пару раз шевельнуть мышой когда уж очень припрет узнать какой же тип у этой переменной.

L>(Кстати, минусов мне за слово "елозишь" наставили? Не хотел обидеть — просто не нашёл другого слова ).
Нет, думаю за пропаганду "удобности" венгерки.

L>>>но лично моё мнение — префиксы типа перед переменными существенно (настолько существенно, что есть смысл заморачиваться на их написание) увеличивают читабельность кода.
CC>>Мое мнение — префиксы в большинстве своем это рудимент, только засоряющий код. Чтение от их наличия зачастую ИМХО только ухудшается.
L>Ну вот, а я пытаюсь показать что всё как раз наоборот
За это и огреб минусов.

CC>>А какая свистопляска начинается при смене типа переменной — этож везде где она используется надо имена поменять. А нормальные тулы для рефакторинга для С++ не так уж давно появились.
L>Но ведь появились же! К тому же — давай рассмотрим чуть подробнее аргумент про изменение типа. Я вижу 2 основных случая — меняется тип локальной переменной или меняется тип переменной — члена класса. В обоих случаях место где используется переменная чётко локализовано (в первом случае — контекст функции или блока, во втором — файлом с реализацией класса). Так что даже банальный Find&Replace в большинстве случаев решает проблему. Реальные проблемы при смене типа начинаются тогда, когда переменная торчит наружу класса как public и используется в системе повсеместно. ИМХО, широкораспространённость такой ситуации говорит о неудачном дизайне.
Ничего менять не понадобится вообще если нет префиксов. Так что мимо кассы

A>проблема венгерки в том что она не консистентна.
A>она разрабатывалась для Си, где есть только простые типы.
Как так — только простые типы?? А структуры?

A>если следовать этим же правилам в C++ , получается что нужно перед каждым именем переменной-экземпляра класса,
A>писать имя его типа

A>Dick clsDickClintonDick;
A>Job clsJobMonikaJob;

A>бредово и громоздко не правда ли?
Правда. Бредово и громоздко. А поэтому — давайте не доводить идею до абсурда. Давайте писАть так:

Job jobMonika;
jobMonika = jobKlinton; // Пусть Моника почувствует себя президентом. Сразу видно что мы присваиваем переменной переменную того же типа.

A>так почему мы для одних типов делаем исключения, а для других нет? нотация не консистентна
Честно говоря мне абсолютно пофигу консистентность Мне важна читабельность кода, ничего более.