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

O$>"...многие классы MFC имеют открытые поля данных. Все эти поля начинаются с m_, не имеющих другого назначения, кроме как увеличить беспорядок. Тем не менее, мы можем использовать эту бессмыслицу для того, чтобы не начинать имена своих собственных полей с m_ и таким образом легко отличать свои члены от унаследованных из базовых классов MFC. "

Я считаю префикс "m_" крайне полезным и в джаве мне его очень нехватает. Сразу видны локальные переменные в функции класса, меньше проблем с изобретением названий временных переменных. Кроме того не возникает проблем с названием аргументов в конструкторах.

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

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

A>>4. На счёт префикса "m_" ?
R>Можно и просто "_" для методов, а переменные скрывать, ибо нефиг

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

V>Префикс "_", насколько я помню, зарезервирован для разработчиков компилятора или типа того (пусть меня поправят). Так что не думаю, что повсеместное использование его это очень хорошая идея...

это нам главный генератор идей Microsoft предлагает... повторюсь, что, я "двумя руками за"... длину имен надо минимизировать, и раз уж тут поднимают руку на "святую нотацию", то от лишней "m" давно пора избавиться

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

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

Где она такое предлагает? В MFC используется "m_".

V>повторюсь, что, я "двумя руками за"... длину имен надо минимизировать, и раз уж тут поднимают руку на "святую нотацию", то от лишней "m" давно пора избавиться

Ну можно тогда просто писать "m" без подчеркивания И shift лишний раз жать не надо...

P.S. А видели исходники STL к VC6.0? Тоже стиль... своеобразный

При всём уважении к автору, он никак не являеться для меня авторитетом в программировании на С++. Некоторое советы из его книги откровенно смешные. Голуб после этого написал книгу о Java и практически полностью на неё переключился. Вот пусть и учит программированию на Java, а с С++ мы уж сами как-нибудь разберёмся.

Что касаеться венгерской нотации, то я применяю её по ситуация. Если программа под Win32 с интенсивным использованием API, а тем более, если используються MFC/WTL, то она просто необходима, иначе программы начинают уродливо выглядеть. Нет ничего хуже смешения стилей. Под Юниксом я её не использую.

Префикс m_... Использую всегда. Полезно и очень удобно, на мой взляд.

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

Здравствуйте, adstra

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

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

A>2. Использование венгерской нотации — это хорошо или плохо?
очень хорошо, особенно для параметров функций и ещё использование префиксов IN и OUT для ссылочных параметров, хотя не всегда обязательно: бывают действительно простые маленькие функции, в которых любой разберётся, например, передаваемых qsort и т.п. Мне приходится иметь дело со страницами текста, где имена переменных состоят из 1-3 букв. Разбираться с таким кодом очень трудно потом, прямо начинаешь ненавидеть того, кто так писал

A>3. Как зависит стиль написания от результатов проектирования (напр., разбиения на классы)?
понятния не имею

A>4. На счёт префикса "m_" ?
в "своих" классах и структурах всегда использую, очень облегчает понимание, когда есть с такими же именами глобальные переменные.

IT>Я бы порекомендовал использовать ещё один префикс — ::, для функций Windows API. Т.е.
IT>

IT>1. GetComputerName(...);

IT>2. ::GetComputerName(...);
IT>

IT>Во втором варианте сразу видно, что это не метод класса, а функция WinAPI.

Я раньше пользовал "::", но со временем отказался. Почему? Именно из-за потенциальной возможности перекрыть вызовы API в текущем namespace. Это может пригодиться для отладки, либо когда используешь чужой код, который нельзя менять. Этакий примитивный API interception

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

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

Достаточно компактный — чтобы люди не испытывали трудностей с запоминанием.

В идеале — это дело надо распечатаь и повесить на стенку на каждом рабочем месте.
Это, кстати, тоже намек на компактность — не надо порождать портянки на всю стену :-)

A>2. Использование венгерской нотации — это хорошо или плохо?
Хорошо — но в меру. Не надо выводить очень длинные префиксы.
Если переменная локальная и ее применение вполне однозначно — префиксы ей не нужны.
Не надо префиксовать тип переменных — лучше перфиксовать их смысл.

Например:
— количество байт в строке: cbSomeString
— количество символов в строке cchSomeString
— статичестки аллоцированная строка (массив): szString
— динамически аллоцированная строка: pszString
— список чегой-то: lstClubMembers
— массив чегой-то: arrMyProjects

A>3. Как зависит стиль написания от результатов проектирования (напр., разбиения на классы)?
Очень сильно. Сильнее чем все остальные вопросы вместе взятые.

A>4. На счёт префикса "m_" ?
Надо, очень надо. А также надо префикс "g_" для глобальных сушностей.

И еще, как заметил IT, есть очень хорошая привычка использовать десигнатор "::" для апишных
функций...

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

A>>2. Использование венгерской нотации — это хорошо или плохо?
TMH>Хорошо — но в меру. Не надо выводить очень длинные префиксы.

А то могут найтись фанатики, порождающие монстров, типа:

const signed char *gxscpy14CorrectionTemplates[14];

ММ> А то могут найтись фанатики, порождающие монстров, типа:
ММ>

ММ>const signed char *gxscpy14CorrectionTemplates[14];
ММ>

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

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

A>>3. Как зависит стиль написания от результатов проектирования (напр., разбиения на классы)?
TMH>Очень сильно. Сильнее чем все остальные вопросы вместе взятые.

Еще стиль очень сильно зависит от используемой библиотеки. Видишь ли ты наследуешься от ее классов(переопределяешь виртуальные функции) и поэтому в твоем классе в любом случае будут имена в стиле библиотеки.

Так что под каждый проект(если ты не все время работаешь с одной и той же либой) нужно выбирать конвенцию.

Что касается префикса m_ то да нужен. Хотя и не обязательно именно такой. Нужно чтобы не путаться в именах. Т.е. у тебя есть переменная и функции accessor-ыю
Варианты

m_value - private переменная
setValue - сеттер
value() - getter

_value - private переменная
setValue - сеттер
getValue() - getter

Ну и так далее.

Во втором варианте появляется соблазн не префиксовать, но это плохо т.к. существует большое количество инициализирующих конструкторов

MyClass::MyClass(int value)
: m_value(value)
{

}

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

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

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

я использую для членов класса постфикс member_, а для глобальных переменных префикс _global (если мне не изменяет память стандартом запрещено только _Global, т. е. использовать заглавные буквы сразу после префикса, поправьте меня если это не так).

что касается getValue() и setValue(T), то я предпочитаю:

T value() const { return value_; } // getValue()
ValueClass& value(T value) { value_ = value; return *this; } // setValue(T)

возвращать указатель на объект удобно для конструкций типа:

theValueClass.value1(1).value2(2).value3(3);

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

IT>Здравствуйте adstra, вы писали:

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

IT>А как же. Code Convention и Code Review могут быть очень полезными вещами, если они не превращаются в самоцель.

A>>2. Использование венгерской нотации — это хорошо или плохо?

IT>Ненавижу венгерку всеми фибрами своей души. Использую редко и неохотно. Без неё живу счастливо и никаких особых проблем не испытиваю.

А я не то чтобы ненавижу, а так... недолюбливаю.
И до сих пор пользуюсь в старых проектах на C++.

Но как перешёл на С#, то смысл венгерка потеряла совсем.

При этом хорошо понимаю любителей венгерки, пишущих на на голом С ?
А программистов на ассемблере я даже за широкое применение макросов
осуждать не могу. Жизнь уних сурова...

A>>lp far * дальний указатель (предпрефикс)
A>>np near * ближний указатель (предпрефикс)

IT>Мда, печальное зрелище. Интересно, как часто вы используете ближние и дальние указатели? Всё это вместе с самой нотацией — пережиток прошлого, рудимент и атавизьм. Тогда был только C, тогда переменные можно было объявлять только в начале блока, тогда не было Source Browser, всплывающих подсказок и компиляторы не умели выводить подсказки для набираемых функций.
IT>Кстати, а почему у вас нет сокращения для структуры или класса. Можно ввести st и cl, будет сразу понятно, что это структура или класс

В одном проекте корпоративного стандарта я видел даже префикс obj — объект, значить.
Содержательный префикс не правда ли?

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

IT>>Ненавижу венгерку всеми фибрами своей души. Использую редко и неохотно. Без неё живу счастливо и никаких особых проблем не испытиваю.

Рек>А я не то чтобы ненавижу, а так... недолюбливаю.
Рек>И до сих пор пользуюсь в старых проектах на C++.

Рек>Но как перешёл на С#, то смысл венгерка потеряла совсем.

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

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

AVK>Здравствуйте, Рек, Вы писали:

IT>>>Ненавижу венгерку всеми фибрами своей души. Использую редко и неохотно. Без неё живу счастливо и никаких особых проблем не испытиваю.

Рек>>А я не то чтобы ненавижу, а так... недолюбливаю.
Рек>>И до сих пор пользуюсь в старых проектах на C++.

Рек>>Но как перешёл на С#, то смысл венгерка потеряла совсем.

AVK>Мужики, расскажите Владу, а то я с ним устал уже по этому поводу воевать

Кстати а как офорлять код при программировании пользовательского интерфейса Тоесть в одной статье Влада было использовать префиксы что есть очень удобно по моему. А так я тож вообще не использую венгерку В шарпе это как то некрасиво смотрится

Здравствуйте, Аноним, Вы писали:

V>>Мне, например, понравилась идея писать _member вместо m_member...

А>а я "_" использую для агрументов методов, например:
А>int Func( int _iValue )
А>{
А> m_iValue = _iValue;
А> int iValue = 0; // другое Value
А>}

Вы неправы. Идентификаторы, начинающиеся с "_", зарезервированы для всех возможных применений разработчиками компиляторов и стандартных библиотек. Так что использовать их не стоит.

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


MS>Кстати а как офорлять код при программировании пользовательского интерфейса Тоесть в одной статье Влада было использовать префиксы что есть очень удобно по моему.

А мне кажется, что решение с префиксами имён контролов не очень удачно.

Гораздо концептуальнее использовать для этих целей атрибуты.

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

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

Это как это?

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

Рек>Здравствуйте, MikaRSDN Soukhov, Вы писали:

Рек>
MS>>Кстати а как офорлять код при программировании пользовательского интерфейса Тоесть в одной статье Влада было использовать префиксы что есть очень удобно по моему.

Рек>А мне кажется, что решение с префиксами имён контролов не очень удачно.

Рек>Гораздо концептуальнее использовать для этих целей атрибуты.

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

A>2. Использование венгерской нотации — это хорошо или плохо?
По моему плохо. Я раньше использовал её постоянно, а сейчас от неё остались лишь "sz" и "p".

A>4. На счёт префикса "m_" ?
В классах использую, в структурах нет.