Венгерская нотация: за или против? - Прочее

Тема перенесена в прочее как никакого отношения непосредственно к языку C++ не имеющая.

Всем привет! В настоящее время мы с сотрудниками разрабатываем стандарт на стиль кодирования программ на Си++. Вопрос о том, каким должен быть стандарт, вызвал в нашем коллективе большие споры, в связи с чем было решено обратиться на форум за поддержкой...
Вот основные вопросы:

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

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

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

4. На счёт префикса "m_" ?

Программеры! Очень важно знать ваше мнение!!! Результаты обсуждения обещаю выслать всем его участникам.

Приложение: Венгерская нотация

Префикс Определение Си/Паскаля Пояснение
с сhar (character)
by byte unsigned char
n short или int
(integer/shortint)
x, y short при использовании в качестве координат (x,y) или размеров
i int(integer) целое
b bool(boolean) true или false
w word unsigned int(0..65535)
h handle unsigned int(0..65535)
i long(longint) длинное целое
dw dword двойное слово
fn function функция
s string строка
sz string(ASCIZ) строка,оканчивающаяся 0
p poiner или * указатель (предпрефикс)
lp far * дальний указатель (предпрефикс)
np near * ближний указатель (предпрефикс)

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

A>1. Нужен ли стандарт на стиль кодирования, не подавленяет ли он творческий подход к написанию программы?
Стандарт на стиль кодирования нужен ОБЯЗАТЕЛЬНО.

A>2. Использование венгерской нотации — это хорошо или плохо?
Это не только хорошо, но и ОБЯЗАТЕЛЬНО. За неиспользование венгерской нотации — высшая мера наказания.

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

A>4. На счёт префикса "m_" ?
Это ОБЯЗАТЕЛЬНО. За неиспользование "m_" — высшая мера наказания.

A>Приложение: Венгерская нотация
Конкретно КАКИЕ будут префисы не столь важно. Главное — чтобы они БЫЛИ.

A>с сhar (character)
Я предпочитаю ch.

A>by byte unsigned char
Я предпочитаю bt.

A>x, y short при использовании в качестве координат (x,y) или размеров
Я предпочитаю cx, cy.

A>i int(integer) целое
A>i long(longint) длинное целое
Я предпочитаю n для обоих. Их разделение обычно не важно.

A>sz string(ASCIZ) строка,оканчивающаяся 0
A>p poiner или * указатель (предпрефикс)

A>lp far * дальний указатель (предпрефикс)
A>np near * ближний указатель (предпрефикс)
Я предпочитаю p. Ближний-дальний уже не актуально.

Еще надо бы для некоторых примитивных библиотеотечных типов тоже иметь что-нибудь типа
std::string, CString — str
CComBSTR — cbs
_bstr_t — bstr
BSTR — bs
VARIANT — vt
CComVariant — cvt
std::vector — vec
iterator — it
CArray — arr
CStringArray — sta

ну и так далее — по вкусу...

Успехов,
Yevgeny.

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

Y>CStringArray — sta
маньяк =)... надо быть проще ...

Igor

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

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

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

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

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

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

Стиль написания скорее зависит от тех средств, которые используются при разработке. Если код MFC, то это один стиль, если это STL — другой, интерфейсы + #import — третий. Я это совмешаю не то что в одном проекте, но даже в одних файлах и методах. Очень удобно, одного взгляда на код достаточно, чтобы настроится на то, какая библиотека (или чего там ещё) используется в данном месте.

A>4. На счёт префикса "m_" ?

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

1. GetComputerName(...);

2. ::GetComputerName(...);

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

A>Программеры! Очень важно знать ваше мнение!!! Результаты обсуждения обещаю выслать всем его участникам.

Будет интересно.

Ещё пара замечаний. Соглашение должно учитывать не только префиксы переменных, но также и способы обработки ошибок и исключений, возможно по разному для разных библиотек (MFC,ATL). Оно должно регламентировать само использование этих и других стандартных библиотек и средств. Что использовать для работы с коллекциями? CArray или vector? Вопрос не такой простой и очевидный. Что использовать для работы со строками? Конкретно в ATL, в MFC. Будут ли использоваться общие библиотеки не входящие в стандартную поставку компилятора? К примеру, та же WTL. Если да, где скачать и как установить. Далее — использование общих модулей, структура каталогов проектов, организация работы с Source Safe и т.д.т.п. В общем, вопросов много. Можно так же регламентировать порядок приёмки работы у программиста. Очень полезно, во избежании недоразумений в будующем, начинать принимать работу не с запуска программы, а со сборки проекта на своей машине (отличной от машины разработчика).

A>Приложение: Венгерская нотация

Так что венгерка — это только маленькая часть ;)

A>Префикс Определение Си/Паскаля Пояснение
A>с сhar (character)
A>by byte unsigned char
A>n short или int
A>(integer/shortint)
A>x, y short при использовании в качестве координат (x,y) или размеров
A>i int(integer) целое
A>b bool(boolean) true или false
A>w word unsigned int(0..65535)
A>h handle unsigned int(0..65535)
A>i long(longint) длинное целое
A>dw dword двойное слово
A>fn function функция
A>s string строка
A>sz string(ASCIZ) строка,оканчивающаяся 0
A>p poiner или * указатель (предпрефикс)
A>lp far * дальний указатель (предпрефикс)
A>np near * ближний указатель (предпрефикс)

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

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

A>>i int(integer) целое
A>>i long(longint) длинное целое
Y>Я предпочитаю n для обоих. Их разделение обычно не важно.

Мне казалось, что n используется для переменных значение которых — количество чего либо.
c используется для переменных счетчиков.
i для иных целых.

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

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

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

IT>Кстати, а почему у вас нет сокращения для структуры или класса. Можно ввести st и cl, будет сразу понятно, что это структура или класс ;o)

Я, кстати, не так давно понял что озночают твои cl :)

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

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

"Венгерская запись целесообразна для языка ассемблера, в котором все, что вы знаете о переменной — это ее размер. Включение информации о типе в имя переменной позволяет вам контролировать правильность ее использования. Языки более высокого уровня типа С и С++ используют для этой цели объявление переменных.

Доктор Саймони несколько раз в печати защищал такой метод записи, но я бы не стал его рекомендовать для программ на С или С++. По моему мнению, венгерская запись не дает ничего, кроме ухудшения читаемости программ. Простые str или string значительно легче читаются и содержат ту же информацию. Если вам на самом деле нужно узнать тип, то для этого достаточно вернуться к определению."

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

"ВЕРЕВКА ДОСТАТОЧНОЙ ДЛИНЫ,ЧТОБЫ ВЫСТРЕЛИТЬ СЕБЕ В НОГУ (Правила программирования на С и С++)" Ален И. Голуб
http://prog.dax.ru/index.html?/ccpp/doc_1.html
http://progarc.narod.ru/ccpp/arcs/ccpp_02.zip
http://www.arnika.sci-nnov.ru/kn/info/progr/c/veryovka.htm

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

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

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

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

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

Считаю что это хорошо.
И абсолютно не согласен с IT в том что это "пережиток прошлого, рудимент и атавизьм".
Использование префиксов особенно p (pointer) _значительно_ облегчает чтение кода.
Но не стоит забывать и о том что переменные должны иметь осмысленные названия,
поскольку если называть их p1 p2 p3, то тут никакая нотация не поможет.

A>4. На счёт префикса "m_" ?

Тоже считаю это весьма полезным.
Можно еще для глобальных премменных префикс "g_" использовать.
В этом случае сразу видно что за переменные используются.

A>Приложение: Венгерская нотация

A>Префикс Определение Си/Паскаля Пояснение
A>с сhar (character)
A>by byte unsigned char
A>n short или int
A>(integer/shortint)
A>x, y short при использовании в качестве координат (x,y) или размеров
A>i int(integer) целое
A>b bool(boolean) true или false
A>w word unsigned int(0..65535)
A>h handle unsigned int(0..65535)
A>i long(longint) длинное целое
A>dw dword двойное слово
A>fn function функция
A>s string строка
A>sz string(ASCIZ) строка,оканчивающаяся 0
A>p poiner или * указатель (предпрефикс)
A>lp far * дальний указатель (предпрефикс)
A>np near * ближний указатель (предпрефикс)

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

Насчет "lp" и "np" действительно перебор.
Это уже не актульно.

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

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

A>2. Использование венгерской нотации — это хорошо или плохо?
Бесполезно. Особенно, если использовать "умную" среду — VisualAssist, например.

A>3. Как зависит стиль написания от результатов проектирования (напр., разбиения на классы)?
Никак.
A>4. На счёт префикса "m_" ?
А вот это полезно. Хотя мне хватает префикса _.

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

A>2. Использование венгерской нотации — это хорошо или плохо?
Чистая венгерка — зло :) Понятное имя удобнее и читабельнее, чем информация о типе,
не без исключений конечно. Иногда надо стОит тип или размер.

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

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

A>i int(integer) целое
просто "u" для unsigned

A>s string строка
A>sz string(ASCIZ) строка,оканчивающаяся 0
веяния паскаля?

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

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

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

Нужен, и ни фига он не подавляет

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

Скорее хорошо, чем плохо. И смотрится прикольно. (Я использую например)

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

Стиль написания чего?

A>4. На счёт префикса "m_" ?

Нужно

A>Приложение: Венгерская нотация

A>Префикс Определение Си/Паскаля Пояснение
A>с сhar (character)
A>by byte unsigned char
A>n short или int
A>(integer/shortint)
когда количество
A>x, y short при использовании в качестве координат (x,y) или размеров
еще есть cx, cy
A>i int(integer) целое
когда индекс
A>b bool(boolean) true или false
A>w word unsigned int(0..65535)
A>h handle unsigned int(0..65535)
A>i long(longint) длинное целое
A>dw dword двойное слово
A>fn function функция
это нафиг не надо (и так понятно, что функция)
A>s string строка
A>sz string(ASCIZ) строка,оканчивающаяся 0
а еще tsz, wsz
A>p poiner или * указатель (предпрефикс)

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

А еще мне больше нравится szFileName, чем file_name или filename

Но на все случаи жизни все-равно не придумаешь

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

A>Всем привет! В настоящее время мы с сотрудниками разрабатываем стандарт на стиль кодирования программ на Си++. Вопрос о том, каким должен быть стандарт, вызвал в нашем коллективе большие споры, в связи с чем было решено обратиться на форум за поддержкой...
Неплохо бы вынести в форум предмет разногласий — для коллективного обсуждения, а то получите еще бОльшую груду разногласий :))

A>Вот основные вопросы:

A>1. Нужен ли стандарт на стиль кодирования, не подавленяет ли он творческий подход к написанию программы?
Нет, не подавляет, но слегка запудрить мозги может. :) На мой взгляд — не надо накладывать ограничений на способы использования конструкций C++, например — запрещать case (видал такое), goto (ногами не пинать :)) ) и т.п.

A>2. Использование венгерской нотации — это хорошо или плохо?
Это привычно в "мире Windows", не более того. Главное, чтобы было удобно команде. Стороннему программисту должно быть безразлично в какой "нотации" записан код (главное — чтобы не искажался привычный синтаксис и семантика C++).

A>3. Как зависит стиль написания от результатов проектирования (напр., разбиения на классы)?
В общем — никак. На мой взгляд, исключение составляет ситуация, когда при проектировании выделены часто используемые классы (или шаблоны) и для них заводится отдельный префикс. Например, я использовал префикс 'sp' для Smart-указателей.

A>4. На счёт префикса "m_" ?
Мне нравится, даже привык :))

A>Программеры! Очень важно знать ваше мнение!!! Результаты обсуждения обещаю выслать всем его участникам.
Лучше в сетку выложи :))

Вот несколько ссылок по теме:

Стиль программирования в C++ (guideline):
http://www.idt.mdh.se/personal/icc/winsde/CppStyleGuide/CPPGuideline.htm

Пример стандарта кодирования (довольно большой, хорош мотивированными описаниями решений):
http://www.possibility.com/Cpp/CppCodingStandard.html

А это — по венгерской нотации:

Оригинал (для читателей форума, если кто не знает):
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvsgen/html/hunganotat.asp

И "около него":
http://ootips.org/hungarian-notation.html
http://home.jtan.com/~gregleg/hungarian.html

С уважением,
Геннадий

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

A>4. На счёт префикса "m_" ?

Еще полезно:
"_" — для private методотов и данных
"g" — для глобальных переменных
"s_" — для статических переменных, хотя это не факт, может и не надо

A>Приложение: Венгерская нотация

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

Понятно, что lp и np нужны только на очень низком уровне. Если Вы не делает что-нить на уровне железа, то полезно ограничиться "p". Так же полезно "sp" (Smart Pointer) для COM указателей. При кодировании очень важно отличать простые указатели, от умных (CComPtr, _com_ptr_t), что бы, как минимум, не забывать на простых указателях делать ->Release(), когда надо.

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

A>Всем привет! В настоящее время мы с сотрудниками разрабатываем стандарт на стиль кодирования программ на Си++. Вопрос о том, каким должен быть стандарт, вызвал в нашем коллективе большие споры, в связи с чем было решено обратиться на форум за поддержкой...

Споры в таком деле -- это хорошо. Как говорится, истина рождается в споре.
Стандарт должен буть во-первых конечно же удобным. Во-вторых стандарт должен охватывать всё разнообразие типов, которые будут присутствовать в будущем проекте, но ни в коем случае не более того, и с минимальными эргономическими затратами. В-третьих, он должен быть невероятно разберабельный, те такой, чтобы если даже позвать программера "с улицы", то чтобы и он без особых усилий всё понял.

A>Вот основные вопросы:

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

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

A>2. Использование венгерской нотации — это хорошо или плохо?
Это нормально, если к ней привыкнуть. Но применять ее стоит не строго по правилам, а так как больше нравится всем. То есть взять ее за основной шаблон. К ней все уже давно привыкли. Особенно активно программирующие на mfc.

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

A>4. На счёт префикса "m_" ?
Префикс как префикс.:))

A>Программеры! Очень важно знать ваше мнение!!! Результаты обсуждения обещаю выслать всем его участникам.
Бесплатный соц.опрос??Ж)))

A>Приложение: Венгерская нотация

A>Префикс Определение Си/Паскаля Пояснение
A>с сhar (character)
A>by byte unsigned char
A>n short или int
A>(integer/shortint)
A>x, y short при использовании в качестве координат (x,y) или размеров
A>i int(integer) целое
A>b bool(boolean) true или false
A>w word unsigned int(0..65535)
A>h handle unsigned int(0..65535)
A>i long(longint) длинное целое
A>dw dword двойное слово
A>fn function функция
A>s string строка
A>sz string(ASCIZ) строка,оканчивающаяся 0
A>p poiner или * указатель (предпрефикс)
A>lp far * дальний указатель (предпрефикс)
A>np near * ближний указатель (предпрефикс)

Ну-у-у....

Какая же это венгерская нотация. Это всего лишь маленький кусок оной.

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

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

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

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

Это очень хорошо :-)
Пример из жизни:
В русском языке (слава ему, великому и могучему) у слов есть окончания, и поэтому очень просто распознавать типы данных, ну там существительные, глаголы, прилагательные.

И тогда даже не зная определений, можно легко ориентироваться.
"Жосклая бодриха кудланула бокра и кудрячит бокренка" — за неправильность цитаты ручаюсь :-)

А вот у англичан окончаний нет, многое определяется порядком слов. Так что жить им труднее :-(

Можно рассматривать префиксы как МИКРОКОММЕНТАРИИ, которые совместно с информативно выбранными именами избавляют от необходимости использовать комментарии ВООБЩЕ.

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

Как скоро и быстро ты сможешь себя запутать :-)

A>4. На счёт префикса "m_" ?

Кто его знает ? Вообще непонято, зачем помимо членов класса должны присутствовать другие переменные.
Их применение — это навроде оператора goto

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

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

O>Как скоро и быстро ты сможешь себя запутать :-)

A>>4. На счёт префикса "m_" ?

O>Кто его знает ? Вообще непонято, зачем помимо членов класса должны присутствовать другие переменные.
O>Их применение — это навроде оператора goto

Ну еще есть локальные переменные, и m_ собственно надо, чтоб переменные класса от локальных отличать. Хотя, с другой стороны — я согласен. Как пример — могу сказать что в Java m_ никто не использует, и ничего — не жалуются. Так что, я скорее, потдерживаю :), хотя если пишешь для MFC, то лучше с m_ для сохранения общего стиля

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

ZORK>Ну еще есть локальные переменные, и m_ собственно надо, чтоб переменные класса от локальных отличать. Хотя, с другой стороны — я согласен. Как пример — могу сказать что в Java m_ никто не использует, и ничего — не жалуются.

Я использую. И не жалуюсь. Хотя действительно, там чаще встретишь конструкции типа:

int nCounter = this.nCounter;

а как на счет "новых" веяний типа "camel casing" и "pascal casing"... Мне, например, понравилась идея писать _member вместо m_member...

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

V>а как на счет "новых" веяний типа "camel casing" и "pascal casing"...
V>Мне, например, понравилась идея писать _member вместо m_member...

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

Здравствуйте, 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];

... << RSDN@Home 1.0 beta 4 >>

ММ>

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

ММ>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 же переменные обычно никто не смотрит)

... << RSDN@Home 1.0 beta 3 >>

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

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

я использую для членов класса постфикс 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++.

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

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

... << RSDN@Home 1.0 beta 4 (np: тихо) >>

Здравствуйте, 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_" ?
В классах использую, в структурах нет.

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

A>Всем привет! В настоящее время мы с сотрудниками разрабатываем стандарт на стиль кодирования программ на Си++. Вопрос о том, каким должен быть стандарт, вызвал в нашем коллективе большие споры, в связи с чем было решено обратиться на форум за поддержкой...
A>Вот основные вопросы:
A>1. Нужен ли стандарт на стиль кодирования, не подавленяет ли он творческий подход к написанию программы?
Да нужно.
A>2. Использование венгерской нотации — это хорошо или плохо?
Никак, это всего лишь удобство, раньше было обоснованно отсутсвием инструментов для определения что же за переменная,
сейчас это уже не нужно
A>3. Как зависит стиль написания от результатов проектирования (напр., разбиения на классы)?
A>4. На счёт префикса "m_" ?
m_ и g_ это не стиль, это маст хэв
A>Программеры! Очень важно знать ваше мнение!!! Результаты обсуждения обещаю выслать всем его участникам.
Я думаю собственно надо придерживаться MS методике кодирования, у них в мсдн есть правила что и как должно быть
вот смотри
ms-help://MS.VSCC.2003/MS.MSDNQTR.2003APR.1033/vsent7/html/vxconcodingtechniques.htm
Статья по индексу "Coding Techniques"

A>Приложение: Венгерская нотация

A>Префикс Определение Си/Паскаля Пояснение
A>с сhar (character)
A>by byte unsigned char
A>n short или int
A>(integer/shortint)
A>x, y short при использовании в качестве координат (x,y) или размеров
A>i int(integer) целое
A>b bool(boolean) true или false
A>w word unsigned int(0..65535)
A>h handle unsigned int(0..65535)
A>i long(longint) длинное целое
A>dw dword двойное слово
A>fn function функция
A>s string строка
A>sz string(ASCIZ) строка,оканчивающаяся 0
A>p poiner или * указатель (предпрефикс)
A>lp far * дальний указатель (предпрефикс)
A>np near * ближний указатель (предпрефикс)

От:	adstra	www.akella.com
Дата:	23.09.01 11:26
Оценка:	7 (2)

	От:	Yevgeny
	Дата:	23.09.01 11:58
	Оценка:	-1

	От:	Igor Soukhov
	Дата:	23.09.01 12:18
	Оценка:

От:	IT	linq2db.com
Дата:	23.09.01 16:47
Оценка:	10 (1)

	От:	WindJammer
	Дата:	24.09.01 04:02
	Оценка:

От:	Odi$$ey	http://malgarr.blogspot.com/
Дата:	24.09.01 05:54
Оценка:

От:	rihter	http://rihter.slash-x.net
Дата:	24.09.01 10:56
Оценка:

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	25.09.01 11:30
Оценка:

От:	ZORK	www.zorkaltsev.com
Дата:	07.10.01 12:27
Оценка:

От:	Enox	http://yuryskaletskiy.blogspot.com/
Дата:	20.01.03 12:59
Оценка:

От:	Михаил Можаев	www.mozhay.chat.ru
Дата:	20.01.03 14:05
Оценка:

От:	Anatolix	https://www.linkedin.com/in/anatolix/
Дата:	20.01.03 15:32
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	20.01.03 19:54
Оценка:

От:	MikaRSDN Soukhov	Stock#
Дата:	20.01.03 21:20
Оценка:

От:	LaFlour	blog: http://spaces.live.com/laflour
Дата:	11.12.03 07:08
Оценка:

	От:	PSP
	Дата:	08.10.01 10:58
	Оценка:

	От:	Orion
	Дата:	11.10.01 01:38
	Оценка:

	От:	Snax
	Дата:	11.10.01 04:36
	Оценка:

	От:	_vasily
	Дата:	28.11.02 14:49
	Оценка: