Имена классов , начинающиеся на C

Question

В MFC есть все имена классов , которые начинаются с C.Например, CFile и CGdiObject.Кто-нибудь видел, как это используется в другом месте?Существует ли официальное руководство по соглашению об именовании от Microsoft, которое рекомендует этот стиль?Возникла ли идея с MFC или это был какой-то другой проект?

Answer 1

Что-то немного похожее используется в Symbian C ++, где соглашение заключается в том, что:

Классы T - это "значения", например TChar, TInt32, TDes

Классы R являются дескрипторами ресурсов ядра (или других), например RFile, RSocket

Классы M - это миксины, которые включают интерфейсы (интерпретируемые как миксины без реализации функций).Руководство заключается в том, что множественное наследование должно включать не более 1 класса, отличного от M.

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

HBufC существует в первую очередь для создания запутанных сообщений на форумах Symbian, и наличие собственного префикса - это только начало.Буква "Х" означает "ха?" или, возможно, "Ха, ха!У вас нет STL!" ;-)

Это близко по духу к венгерской нотации Apps, а не к системной венгерской нотации.Префикс сообщает вам кое-что о классе, что вы могли бы посмотреть в документации, но о котором иначе вы бы не знали. Весь смысл присвоения имен чему-либо в программировании заключается в предоставлении таких подсказок и напоминаний, в противном случае вы бы просто назвали свои классы "Class001", "Class002" и т.д.

Системный венгерский просто сообщает вам тип переменной, чему, по-моему, не стоит особо волноваться, особенно на таком языке, как C ++, где типы, как правило, либо постоянно повторяются, либо полностью скрыты параметрами шаблона.Его аналогом при именовании типов является практика Java именования всех интерфейсов с помощью I.Опять же, я не в восторге от этого (как и стандартные библиотеки Java), но если вы собираетесь определять интерфейс для каждого класса в дополнение к интерфейсам, которые фактически используются для полиморфизма в нетестовых ситуациях, то вам нужен какой-то способ отличить их друг от друга.

Answer 2

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

Например, btnSubmit можно ли описать кнопку с именем Submit (которая имела бы сопровождающий lblSubmit для надписи рядом с кнопкой)

Но такие вещи, как CMyClass для класса и uiCount для целого числа без знака с именем count это не помогает программистам и просто приводит к дополнительной расточительности при наборе текста.

Answer 3

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

Обычно это было просто соглашение C ++ (и, возможно, нескольких других языков), и, следовательно, оно начало выходить из моды, поскольку языки стали более совместимыми через COM, а затем .NET .

Вы все еще довольно часто видите, что это cousin, префикс "I" для интерфейсов.Мне всегда казалось интересным, что "Я" выжил, когда "C" умер, но это, вероятно, было связано с тем, что интерфейсы так активно использовались для взаимодействия COM.

Answer 4

Я помню, что компиляторы Borland работали с библиотеками, где имена классов начинались с 'T'.Вероятно, для "типа" :)

Answer 5

Соглашение об именовании, принятое много лет назад, имеет решающее значение для определения класса, типа и даже группировки класса.Не забывайте, что тогда не было пространства имен и не было доступно / limited intellisense.C - это форма венгерской нотации, но, безусловно, она стала популярной благодаря MFC.Borland и Delphi использовали T - в качестве префикса для типа

Answer 6

В то время как MFC и множество программ, написанных для Windows, использовали соглашение "C" для классов, вы обычно не найдете последнего в программном обеспечении, написанном для платформ UNIX.Я думаю, что это была привычка, очень сильно поощряемая Visual C ++.Я помню, что Visual C ++ 6.0 добавлял бы префикс "C" к любым классам, созданным с помощью мастера классов.

Answer 7

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

Интересно, что это, по-видимому, спорно не только за пределами MS, но и внутри тоже.

Answer 8

Смотрите здесь : http://www.jelovic.com/articles/stupid_naming.htm для длинной статьи по этому вопросу.

Answer 9

Такие соглашения для переменных полезны для таких языков, как Fortran, где вам не нужно объявлять типы ваших переменных перед их использованием.Кажется, я припоминаю, что переменным, имена которых начинались с "i" или "j", по умолчанию присваивались целые числа, а переменным, имена которых начинались с "r" и других букв, по умолчанию присваивались реальные (плавающие) значения.

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

Answer 10

При написании приложений, использующих библиотеки Qt, мы используем соглашение об именовании, которое отличает классы, прямо или косвенно производные от QObject, от классов, которые таковыми не являются.Это полезно, потому что по имени класса вы можете определить, поддерживает ли он сигналы / слоты, свойства и все другие полезные функции, которые поступают из QObject.

Answer 11

мы используем его на работе, как и многие другие соглашения об именовании

под многими я подразумевал C для классов, p для указателя, m_ для членов, s_ для статических членов, n для целого числа ...не так много документов

Answer 12

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