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