Nomes de classes que começam com C

Question

O MFC possui todos os nomes de classes que começam com C.Por exemplo, CFile e CGdiObject.Alguém já viu isso usado em outro lugar?Existe um guia oficial de convenção de nomenclatura da Microsoft que recomenda esse estilo?A ideia surgiu do MFC ou foi algum outro projeto?

Answer 1

Algo um pouco semelhante é usado no Symbian C ++, onde a convenção é que:

T classes são "valores", por exemplo, tchar, tint32, tdes

R Classes são alças para o kernel (ou outros) recursos, por exemplo, rfile, rsocket

M classes são mixins, que incluem interfaces (interpretadas como mixins sem implementações de função). A diretriz é que a herança múltipla deve envolver no máximo 1 classe não-m.

C aulas são praticamente todo o resto e derivam do CBASE, que tem algumas coisas para ajudar na manipulação de recursos.

O HBUFC existe principalmente para gerar postagens confusas nos fóruns do Symbian, e ter seu próprio prefixo é apenas o começo. O H significa "hein?", Ou possivelmente "Haw, Haw! Você não tem STL!" ;-)

Isso é próximo em espírito da notação húngara de aplicativos, em vez de à notação húngara de sistemas. O prefixo diz algo sobre a classe que você poderia procurar na documentação, mas que você não saberia o contrário. O objetivo de nomear qualquer coisa na programação é fornecer tais dicas e lembretes, caso contrário, você apenas chamaria suas aulas de "Class001", "Class002", etc.

Os sistemas húngaros apenas informam o tipo de variável, que a IMO não é nada para ficar muito animada, especialmente em um idioma como C ++, onde os tipos tendem a ser repetidos constantemente ou completamente ocultos por parâmetros de modelo. Seu análogo ao nomear tipos é a prática Java de nomear todas as interfaces com I. Novamente, não fico muito empolgado com isso (e nem as bibliotecas Java padrão), mas se você vai definir uma interface para todas as classes , além das interfaces que são realmente usadas para o polimorfismo em situações que não são de teste, você precisa de alguma maneira de distinguir os dois.

Answer 2

É mau. Não use a notação húngara para nada além de coisas abstraídas.

Por exemplo, btnSubmit está ok para descrever um botão chamado Enviar (que teria um acompanhamento lblSubmit Para o rótulo ao lado do botão)

Mas coisas como CMyClass para aula e uiCount Para o número inteiro não assinado, o Count Count não ajuda os programadores e apenas leva a uma digitação desnecessária extra.

Answer 3

Esse era um estilo de codificação C ++ antigo, e o MFC provavelmente foi uma das últimas coisas a usá -lo.

Geralmente, era apenas uma convenção de C ++ (e talvez alguns outros idiomas), e, portanto, começou a cair em desuso quando os idiomas se tornaram mais interoperáveis, através do COM e depois .NET.

Você ainda vê que é primo, o prefixo "I" para interfaces, com bastante frequência. Eu sempre achei interessante que "eu" sobrevivi quando "C" morreu, mas isso provavelmente foi porque as interfaces foram usadas com tanta interoperabilidade.

Answer 4

Lembro -me de que os compiladores de Borland estavam chegando com as bibliotecas onde os nomes das classes começaram com 'T'. Provavelmente para "tipo" :)

Answer 5

Anos atrás, a convenção de nomenclatura é crucial para ajudar a identificar a classe, mesmo o agrupamento da classe. Não se esqueça de então não havia espaço para nome e nenhum intellisense limitado disponível. C é uma forma de notação húngara, mas certamente popularizada pelo MFC. Borland e Delphi estavam usando t - como prefixo para tipo

Answer 6

Embora o MFC e muitos softwares escritos para o Windows usassem a convenção "C" para aulas, você geralmente não encontra o último em software escrito para plataformas UNIX. Eu acho que era um hábito muito fortemente encorajado pelo Visual C ++. Lembro -me de que o Visual C ++ 6.0 prefixaria A "C" para qualquer classes que criasse com o assistente de classe.

Answer 7

Não posso responder a todas as suas perguntas, mas até onde eu sei, é apenas para distinguir as classes do MFC de outras classes - uma forma de notação húngara.

Curiosamente, é aparentemente controverso não apenas fora da MS, mas dentro também.

Answer 8

Veja aqui : http://www.jelovic.com/articles/stupid_naming.htm Para um longo artigo sobre esse assunto.

Answer 9

Tais convenções para variáveis ​​são úteis para linguagens como Fortran, onde você não precisa declarar os tipos de suas variáveis ​​antes de usá-las.Parece que me lembro que as variáveis ​​cujos nomes começavam com "i" ou "j" eram padronizadas como números inteiros, e as variáveis ​​cujos nomes começavam com "r" e outras letras eram padronizadas como valores reais (flutuantes).

O fato de as pessoas usarem algo semelhante para linguagens nas quais você precisa declarar variáveis ​​- ou para definições de classe - é provavelmente apenas uma relíquia de alguém que entendeu mal as antigas convenções de código de linguagens como Fortran, onde isso realmente importava.

Answer 10

Ao escrever aplicativos que usam as bibliotecas QT, usamos uma convenção de nomenclatura que distingue classes que são direta ou indiretamente derivadas do QObject de classes que não são. Isso é útil porque você pode dizer pelo nome da classe, se ele suporta sinais/slots, propriedades e todos os outros presentes que vêm do QObject.

Answer 11

Nós o usamos no trabalho, como muitas outras convenções de nomenclatura

por muitos eu quis dizer c para aulas, p para ponteiro, m_ para membros, s_ para membros estáticos, n para inteiro ... não muitos documentos

Answer 12

pessoalmente, acho que a notação húngara me ajuda, pois posso olhar para uma tela cheia de variáveis ​​e saber instantaneamente o que são enquanto tento absorver a lógica.Vejo que seu único argumento contra isso é "digitação extra"