Тема перенесена в прочее как никакого отношения непосредственно к языку 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
Здравствуйте adstra, вы писали:
A>1. Нужен ли стандарт на стиль кодирования, не подавленяет ли он творческий подход к написанию программы?
А как же. Code Convention и Code Review могут быть очень полезными вещами, если они не превращаются в самоцель.
A>2. Использование венгерской нотации — это хорошо или плохо?
Ненавижу венгерку всеми фибрами своей души. Использую редко и неохотно. Без неё живу счастливо и никаких особых проблем не испытиваю. Не люблю её как раз то, что чаще всего она используется не ради пользы, а ради того, чтобы её использовать, читабельность программы ухудшает, полезной информации практически не несёт.
A>3. Как зависит стиль написания от результатов проектирования (напр., разбиения на классы)?
Стиль написания скорее зависит от тех средств, которые используются при разработке. Если код MFC, то это один стиль, если это STL — другой, интерфейсы + #import — третий. Я это совмешаю не то что в одном проекте, но даже в одних файлах и методах. Очень удобно, одного взгляда на код достаточно, чтобы настроится на то, какая библиотека (или чего там ещё) используется в данном месте.
A>4. На счёт префикса "m_" ?
Полезная штука.
Я бы порекомендовал использовать ещё один префикс — ::, для функций Windows API. Т.е.
Во втором варианте сразу видно, что это не метод класса, а функция 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)
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте IT, вы писали:
IT>Ненавижу венгерку всеми фибрами своей души. Использую редко и неохотно. Без неё живу счастливо и никаких особых проблем не испытиваю. Не люблю её как раз то, что чаще всего она используется не ради пользы, а ради того, чтобы её использовать, читабельность программы ухудшает, полезной информации практически не несёт.
Не согласен, насчет того, что она не нужна. На мой взгляд очень полезна и программы читабельны. И то, что ты ее не используешь не есть "плюс", с моей точки зрения. По крайней мере читать твои тексты "не очень".
IT>Кстати, а почему у вас нет сокращения для структуры или класса. Можно ввести st и cl, будет сразу понятно, что это структура или класс ;o)
Я, кстати, не так давно понял что озночают твои cl :)
Здравствуйте adstra, вы писали:
A>2. Использование венгерской нотации — это хорошо или плохо?
"Венгерская запись целесообразна для языка ассемблера, в котором все, что вы знаете о переменной — это ее размер. Включение информации о типе в имя переменной позволяет вам контролировать правильность ее использования. Языки более высокого уровня типа С и С++ используют для этой цели объявление переменных.
Доктор Саймони несколько раз в печати защищал такой метод записи, но я бы не стал его рекомендовать для программ на С или С++. По моему мнению, венгерская запись не дает ничего, кроме ухудшения читаемости программ. Простые str или string значительно легче читаются и содержат ту же информацию. Если вам на самом деле нужно узнать тип, то для этого достаточно вернуться к определению."
"...многие классы MFC имеют открытые поля данных. Все эти поля начинаются с m_, не имеющих другого назначения, кроме как увеличить беспорядок. Тем не менее, мы можем использовать эту бессмыслицу для того, чтобы не начинать имена своих собственных полей с m_ и таким образом легко отличать свои члены от унаследованных из базовых классов MFC. "
Здравствуйте 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_" ?
А вот это полезно. Хотя мне хватает префикса _.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте 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) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте adstra, Вы писали:
A>Всем привет! В настоящее время мы с сотрудниками разрабатываем стандарт на стиль кодирования программ на Си++. Вопрос о том, каким должен быть стандарт, вызвал в нашем коллективе большие споры, в связи с чем было решено обратиться на форум за поддержкой...
вот только что наткнулся: http://www.cuj.com/experts/1911/hyslop.htm?topic=experts
Здравствуйте 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_ никто не использует, и ничего — не жалуются.
Я использую. И не жалуюсь. Хотя действительно, там чаще встретишь конструкции типа:
а как на счет "новых" веяний типа "camel casing" и "pascal casing"... Мне, например, понравилась идея писать _member вместо m_member...
Re[2]: Венгерская нотация: за или против?
От:
Аноним
Дата:
28.11.02 15:12
Оценка:
Здравствуйте, _vasily, Вы писали:
V>а как на счет "новых" веяний типа "camel casing" и "pascal casing"... V>Мне, например, понравилась идея писать _member вместо m_member...
а я "_" использую для агрументов методов, например:
int Func( int _iValue )
{
m_iValue = _iValue;
int iValue = 0; // другое Value
}
* thriving in a production environment *
Если нам не помогут, то мы тоже никого не пощадим.
