MFC имеет все имена классов, начинающиеся с C. Например, CFile и CGdiObject. Кто-нибудь видел, как он используется в другом месте? Есть ли официальное руководство по именованию от Microsoft, которое рекомендует этот стиль? Идея возникла с MFC или это был какой-то другой проект?Имена классов, начинающиеся с C
что-то немного похоже используются в Symbian C++, где конвенция является то, что:
T классы являются "ценностью", к примеру TCHAR, TInt32, TDes
классов R являются ручками для ядра (или другие) ресурсы, например RFile, RSocket
М-классы - это mixins, которые включают в себя интерфейсы (интерпретируемые как mixins без функциональных реализаций). Основное правило состоит в том, что множественное наследование должно включать не более 1 класса, отличного от M.
Классы C - это почти все остальное, и происходят из CBase, в котором есть кое-что, что помогает в управлении ресурсами.
HBufC существует, прежде всего, для создания путаных сообщений на форумах Symbian, а его собственный префикс - только начало. H означает «да?», Или, возможно, «Хау, haw! У вас нет STL!» ;-)
Это близко по духу к венгерской нотации Apps, а не к венгерским обозначениям систем. Префикс сообщает вам что-то о классе, который вы могли бы найти в документации, но который вы не знали бы иначе. Все, что нужно назвать в программировании, - это предоставить такие подсказки и напоминания, иначе вы просто позвоните в свои классы «Class001», «Class002» и т. Д.
Системы Венгерский просто говорит вам тип переменной, с которой ИМО не в восторге, особенно на языке, таком как C++, где типы обычно повторяются или полностью скрываются параметрами шаблона. Его аналогом, когда типы именования являются практикой Java, обозначающей все интерфейсы с I. Опять же, я не очень взволнован этим (и не стандартными библиотеками Java), но если вы собираетесь определить интерфейс для каждого класса , в дополнение к интерфейсам, которые фактически используются для полиморфизма в не-тестовых ситуациях, тогда вам нужно каким-то образом отличить их.
мы используем его на работе, как и многих других соглашения об именах
многим я имел в виду C для классов, р для указателя, m_ для членов, s_ для статических членов, п для целого ... не много документов
Я не могу ответить на все ваши вопросы, но, насколько я знаю, это просто отличить классы MFC от других классов - формы венгерской нотации.
Интересно, что это, по-видимому спорным не только за пределами MS, но inside as well.
да, что они знают - рекомендации .NET (например) отвергают идею префикса классов, но отлично подходят префиксов. Иногда споры существуют без уважительной причины. – gbjbaanb
Это был старый стиль кодирования на C++, и MFC, вероятно, была одной из последних вещей, которые его использовали.
Обычно это было просто соглашение C++ (и, возможно, несколько других языков), и, следовательно, оно начало падать из-за пользы, поскольку языки стали более интероперабельными, через COM и затем .NET.
Вы все еще видите, что это кузен, префикс «I» для интерфейсов, довольно часто. Мне всегда было интересно, что «я» выжил, когда «С» умер, но это, вероятно, связано с тем, что интерфейсы так сильно использовались в COM-совместимости.
Я думаю, что важно четко понимать факт, что класс должен быть интерфейсом, а префикс с 'I' может все еще широко использоваться, поскольку он короче и яснее, а затем суффикс' Base'. –
Вероятно, он не умер, потому что он обращается к меньшинствам (интерфейс, параметры типового типа), а наиболее распространенные (классы) не получают лишних помех. –
Так кто же еще использовал его? Только Microsoft? – User1
Это зло. Не используйте венгерскую нотацию ни для чего, кроме абстрагированных вещей.
Например, btnSubmit нормально описать кнопку с именем Submit (который будет иметь сопроводительную lblSubmit для метки рядом с кнопкой)
Но такие вещи, как CMyClass для класса и uiCount для целого числа без знака с именем граф не помогают программистам и просто приводят к лишнему расточительному набору текста.
@Earlz: Я не согласен с вашим заявлением о uiCount и дополнительной настройке. Если я прочитал что-то вроде «if (uiXCoord <0)», начинает мигать красный свет, но нет, если я прочитаю «if (xCoord <0)», а xCoord - это unigend int. И ввод некоторых дополнительных символов никогда не станет причиной того, что программное обеспечение не готово вовремя, ввод кода является наименьшей проблемой, которую имеет разработчик программного обеспечения. Знать, что вводить, гораздо важнее. – Habi
@Habi: В таких ситуациях вы можете захотеть прослушать предупреждения компилятора. Кроме того, возможно, используйте более описательные имена переменных - в чем причина, почему общая координата x должна быть без знака? – UncleBens
@Habi: Что происходит, когда тип изменяется для 'uiCount' из' unsigned int' в 'unsigned long',' signed int' или 'double'? Согласно Венгерской нотации, переменную необходимо переименовать, * везде * она используется. Согласно валидации, любая модифицированная функция или метод должны быть проверены. Похоже на начало полного регрессионного тестирования. :-( –
Несколько лет назад соглашение об именах имеет решающее значение для определения класса, типа даже группировки класса. Не забывайте, что тогда не было пространства имен и нет/ограниченного intellisense. C - форма венгерской нотации, но, безусловно, популярная MFC. Borland и Delphi использовали T - как префикс для Type
Другой выбор дизайна MFC, основанный на том, что 20-летняя компилятор MS поддерживал, а не как это было бы сделано на современном C++. –
Помню, компиляторы Borland собирались с библиотеками, где имена классов начинались с 'T'. Вероятно, для «типа» :)
Я всегда считал, что это было из-за T в Turbo Pascal/Turbo C ... кодирования нарциссизма :) – Avio
В то время как MFC и множество программного обеспечения, написанного для Windows, использовали соглашение «C» для классов, вы, как правило, не находите последнее в программном обеспечении, написанном для платформ UNIX. Я думаю, что это была привычка, очень сильно поощряемая Visual C++. Я помню, что Visual C++ 6.0 префикс «C» для любых классов, созданных с помощью мастера классов.
См. Здесь: http://www.jelovic.com/articles/stupid_naming.htm для длинной статьи по этому вопросу.
Очень хорошая статья :) – Avio
Такие соглашения для переменных полезны для таких языков, как Fortran, где вам не нужно объявлять типы переменных перед их использованием. Я, кажется, помню, что переменные, имена которых начинались с «i» или «j», были дефолтными по целым числам, а переменные, имена которых начинались с «r» и других букв, по умолчанию были действительными (float) значениями.
То, что люди используют аналогичные для языков, где вам нужно объявлять переменные, или для определения классов, - это, вероятно, просто религия того, что кто-то неправильно понимает старые условные обозначения кода на таких языках, как Fortran, где это действительно имело значение.
При написании приложений, использующих библиотеки Qt, мы используем соглашение об именах, которое отличает классы, которые прямо или косвенно связаны с QObject от классов, которые этого не делают. Это полезно, потому что вы можете указать из имени класса, поддерживает ли он сигналы/слоты, свойства и все остальные свойства, которые поступают из QObject.
Все, что я знаю, это то, что я рад, что они исправили его с помощью соглашений об именах .NET :) –