Соглашение об именах для Win32 / MFC с C ++

Question

Я работаю над приложением, которое использует среду Win32 / MFC и язык программирования C ++ с использованием Visual Studio 2010.

У меня вопрос, какое соглашение об именах нужно использовать для переменных, имени функции, имени класса и т. Д. Я слышал, что Microsoft предлагает использовать соглашение об именовании «венгерская нотация».

Подскажите, пожалуйста, какой стандарт использовать?

Answer 1

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

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

http://msdn.microsoft.com/en-us/library/ms229042.aspx

С другой стороны, вместо слепого следования какому-либо конкретному документу, вероятно, лучше оценитькаждая отдельная конвенция.Например, когда образцы MFC создают классы и имеют переменные-члены, они начинают имя с m_.У StackOverflow есть вопросы по этой конкретной идее, и вы можете прочитать об альтернативах:

Зачем использовать префиксы для переменных-членов в классах C ++

Я больше согласен со стилем API QtРуководящие принципы и большинство их соглашений работают для меня:

http://doc.qt.nokia.com/qq/qq13-apis.html

Говоря об этом, Qt - хорошее предложение C ++, которое продолжает развиваться и развиваться.Выпускает MFC из воды (полностью) И является кросс-платформенным ...

http://qt.nokia.com/products/developer-tools/

Если вы хотите быть заблокированным во вселенной Microsoft, перейдите на .NET и C #.Это было бы на шаг впереди, и вы не застряли бы с отказом от MFC.

Answer 2

О, мальчик. Это почти то же самое, что спрашивать людей, какой религии вы должны следовать. По крайней мере, вы не спросили, какой текстовый редактор вы должны использовать ...

Мой 2с: делай, что работает для тебя. Также подумайте, пишете ли вы только для себя, или ожидаете, что другие люди будут читать или работать над кодом, который вы пишете, и начинаете ли вы проект с нуля или строите существующий код.

Соглашение об именах действительно не имеет большого значения, пока:

• Вы выбираете имена, которые имеют смысл и описывают назначение переменной / функции / другого. (Ключевой вопрос здесь - цель; пусть компилятор разберется с типом.)

• Будьте последовательны в том, как вы применяете любые другие аспекты соглашения (отступы, регистр, префиксы, использование подчеркивания и т. Д.).

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

Что касается венгерского языка и префиксов: Win32 и C ++ все еще их используют, а .Net и C # - нет.

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

В наши дни я не беспокоюсь о большинстве венгерских префиксов, за исключением некоторых (обратите внимание, что это всего лишь мои личные предпочтения, они мне показались полезными на протяжении многих лет):

• p для указателей, потому что в C ++, в отличие от C #, полезно знать, когда вы имеете дело со ссылкой на объект и сколько уровней косвенности я имею в виду.
• m_ для переменных-членов (иногда _ в C # в зависимости от существующего кода; см. Примечание HostileFork ниже о _ _ ​​префиксе в C ++.)
• cch для количества символов, cb для количества байтов. В Win32 очень важно не путать их; передайте количество символов в memcpy или число байтов в GetWindowText, и у вас возникнут проблемы. Это тот тип использования префиксов, который может помочь сохранить ваш код ясным и, очевидно, правильным (или неправильным, в зависимости от обстоятельств - «ах, конечно, я передаю cch в memcpy, в этом проблема!»).

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