Notação húngara - Hungarian notation

A notação húngara é uma convenção de nomenclatura de identificador em programação de computador , na qual o nome de uma variável ou função indica sua intenção ou tipo e, em alguns dialetos, seu tipo . A notação húngara original usa intenção ou tipo em sua convenção de nomenclatura e às vezes é chamada de Apps húngaro, pois se tornou popular na divisão de aplicativos da Microsoft no desenvolvimento de Word, Excel e outros aplicativos. Conforme a divisão do Microsoft Windows adotou a convenção de nomenclatura, eles usaram o tipo de dados real para nomeação, e essa convenção se espalhou amplamente por meio da API do Windows; isso às vezes é chamado de notação húngara de sistemas.

Simonyi : ... BCPL [tinha] um único tipo que era uma palavra de 16 bits ... não que isso importe.

Booch : A menos que você continue a notação húngara.

Simonyi : Com certeza ... passamos para os idiomas digitados muito mais tarde ... Mas ... olharíamos para um nome e eu diria a você exatamente muito sobre ele ...

A notação húngara foi projetada para ser independente da linguagem e encontrou seu primeiro uso importante com a linguagem de programação BCPL . Como o BCPL não possui tipos de dados além da palavra de máquina , nada na linguagem em si ajuda um programador a lembrar os tipos de variáveis. A notação húngara visa remediar isso, fornecendo ao programador conhecimento explícito do tipo de dados de cada variável.

Na notação húngara, um nome de variável começa com um grupo de letras minúsculas que são mnemônicas para o tipo ou propósito daquela variável, seguido por qualquer nome que o programador tenha escolhido; esta última parte às vezes é identificada como o nome fornecido . O primeiro caractere do nome fornecido pode ser colocado em maiúscula para separá-lo dos indicadores de tipo (veja também CamelCase ). Caso contrário, o caso deste caractere denota escopo.

História

A notação húngara original, que agora seria chamada de Apps húngaro, foi inventada por Charles Simonyi , um programador que trabalhou na Xerox PARC por volta de 1972–1981 e que mais tarde se tornou arquiteto-chefe da Microsoft .

O nome da notação é uma referência à nação de origem de Simonyi; Os nomes das pessoas húngaras são "invertidos" em comparação com a maioria dos outros nomes europeus; o sobrenome precede o nome fornecido . Por exemplo, o nome anglicizado "Charles Simonyi" em húngaro era originalmente "Simonyi Károly". Da mesma forma, o nome do tipo precede o "nome dado" na notação húngara, em vez do estilo de nomenclatura "tipo último" do Smalltalk (por exemplo, aPoint e lastPoint). Este último estilo de nomenclatura era mais comum no Xerox PARC durante o mandato de Simonyi lá.

O nome Apps húngaro foi inventado desde que a convenção foi usada na divisão de aplicativos da Microsoft. Sistemas húngaro desenvolvidos posteriormente na equipe de desenvolvimento do Microsoft Windows . O artigo de Simonyi referia-se a prefixos usados ​​para indicar o "tipo" de informação que está sendo armazenada. Sua proposta estava amplamente preocupada em decorar nomes de identificadores com base nas informações semânticas do que eles armazenam (em outras palavras, a finalidade da variável ), de acordo com o Apps húngaro. No entanto, suas sugestões não eram inteiramente distintas do que ficou conhecido como Sistemas Húngaros, pois alguns de seus prefixos sugeridos contêm pouca ou nenhuma informação semântica (veja exemplos abaixo).

Sistemas húngaro x Apps húngaro

A diferença entre a notação de sistemas e a notação de aplicativos está na finalidade dos prefixos.

Na notação Húngara de Sistemas, o prefixo codifica o tipo de dados real da variável. Por exemplo:

  • lAccountNum : a variável é um inteiro longo ( "l");
  • arru8NumberList : Variável é uma arr ay de u nsigned 8 inteiros -bit ( "arru8");
  • bReadLine(bPort,&arru8NumberList) : função com um código de retorno de valor de byte.
  • strName : A variável representa uma string ( "str") contendo o nome, mas não especifica como essa string é implementada.

A notação húngara do Apps se esforça para codificar o tipo de dados lógico em vez do tipo de dados físicos; desta forma, dá uma dica de qual é o propósito da variável, ou o que ela representa.

  • rwPosition : a variável representa uma linha ( "rw");
  • usName : a variável representa uma string insegura ( "us"), que precisa ser "higienizada" antes de ser usada (por exemplo, consulte injeção de código e script entre sites para exemplos de ataques que podem ser causados ​​pelo uso de entrada bruta do usuário)
  • szName : É uma variável z terminada-ero s tring ( "sz"); este foi um dos prefixos originais sugeridos por Simonyi.

A maioria, mas não todos, dos prefixos sugeridos por Simonyi são de natureza semântica. Aos olhos modernos, alguns prefixos parecem representar tipos de dados físicos, como szpara strings. No entanto, esses prefixos ainda eram semânticos, já que Simonyi pretendia a notação húngara para as línguas cujos sistemas de tipos não podiam distinguir alguns tipos de dados que as línguas modernas tomam como certos.

A seguir estão exemplos do artigo original:

  • pXé um ponteiro para outro tipo X ; isso contém muito pouca informação semântica.
  • dé um prefixo que significa diferença entre dois valores; por exemplo, dY pode representar uma distância ao longo do eixo Y de um gráfico, enquanto uma variável chamada y pode ser uma posição absoluta. Isso é inteiramente semântico por natureza.
  • szé uma string terminada em zero ou zero. Em C, isso contém algumas informações semânticas porque não está claro se uma variável do tipo char * é um ponteiro para um único caractere, uma matriz de caracteres ou uma string terminada em zero.
  • wmarca uma variável que é uma palavra. Essencialmente, ele não contém nenhuma informação semântica e provavelmente seria considerado Sistemas Húngaros.
  • bmarca um byte, que em contraste com w pode ter informações semânticas, porque em C o único tipo de dados de tamanho de byte é o char , portanto, às vezes, eles são usados ​​para conter valores numéricos. Esse prefixo pode limpar a ambigüidade entre se a variável está mantendo um valor que deve ser tratado como um caractere ou um número.

Embora a notação sempre use letras minúsculas iniciais como mnemônicos, ela não prescreve os próprios mnemônicos. Existem várias convenções amplamente utilizadas (consulte os exemplos abaixo), mas qualquer conjunto de letras pode ser usado, desde que sejam consistentes dentro de um determinado corpo de código.

É possível que o código que usa a notação húngara do Apps às vezes contenha Sistemas húngaros ao descrever variáveis ​​que são definidas apenas em termos de seu tipo.

Relação com sigilos

Em algumas linguagens de programação, uma notação semelhante agora chamada sigilos é embutida na linguagem e aplicada pelo compilador. Por exemplo, em algumas formas de BASIC , name$nomeia uma string e count%nomeia um inteiro . A principal diferença entre a notação húngara e os sigilos é que os sigilos declaram o tipo da variável na linguagem, enquanto a notação húngara é puramente um esquema de nomenclatura sem nenhum efeito na interpretação da máquina do texto do programa.

Exemplos

  • bBusy : booleano
  • chInitial : char
  • cApples : contagem de itens
  • dwLightYears : palavra dupla (sistemas)
  • fBusy : bandeira (ou flutuante )
  • nSize : inteiro (sistemas) ou contagem (aplicativos)
  • iSize : inteiro (sistemas) ou índice (aplicativos)
  • fpPrice : ponto flutuante
  • dbPi : duplo (sistemas)
  • pFoo : ponteiro
  • rgStudents : matriz ou intervalo
  • szLastName : string terminada em zero
  • u16Identifier : inteiro sem sinal de 16 bits (sistemas)
  • u32Identifier : inteiro sem sinal de 32 bits (sistemas)
  • stTime : estrutura de tempo do relógio
  • fnFunction : nome da função

Os mnemônicos para ponteiros e matrizes , que não são tipos de dados reais, geralmente são seguidos pelo tipo do próprio elemento de dados:

  • pszOwner : ponteiro para string terminada em zero
  • rgfpBalances : array de valores de ponto flutuante
  • aulColors : matriz de longos sem sinal (sistemas)

Embora a notação húngara possa ser aplicada a qualquer linguagem de programação e ambiente, ela foi amplamente adotada pela Microsoft para uso com a linguagem C, em particular para o Microsoft Windows , e seu uso permanece amplamente confinado a essa área. Em particular, o uso de notação húngara foi amplamente evangelizados por Charles Petzold 's 'Windows de programação' , o original (e para muitos leitores, a definitiva) livro sobre Windows API de programação. Assim, muitas construções comumente vistas da notação húngara são específicas do Windows:

  • Para programadores que aprenderam programação Windows em C, provavelmente os exemplos mais memoráveis ​​são wParam(parâmetro de tamanho de palavra) e lParam(parâmetro de número inteiro longo) para a função WindowProc ().
  • hwndFoo : alça para uma janela
  • lpszBar : ponteiro longo para uma string terminada em zero

A notação às vezes é estendida em C ++ para incluir o escopo de uma variável, opcionalmente separada por um sublinhado. Esta extensão também é frequentemente usada sem a especificação de tipo húngara:

  • g_nWheels : membro de um namespace global, inteiro
  • m_nWheels : membro de uma estrutura / classe, inteiro
  • m_wheels, _wheels : membro de uma estrutura / classe
  • s_wheels : membro estático de uma classe
  • c_wheels : membro estático de uma função

No código JavaScript usando jQuery , um $prefixo é freqüentemente usado para indicar que uma variável contém um objeto jQuery (em vez de um objeto DOM simples ou algum outro valor).

Vantagens

(Alguns deles se aplicam apenas aos sistemas húngaro.)

Os defensores argumentam que os benefícios da notação húngara incluem:

  • O tipo de símbolo pode ser visto por seu nome. Isso é útil ao examinar o código fora de um ambiente de desenvolvimento integrado - como em uma revisão de código ou impressão - ou quando a declaração do símbolo está em outro arquivo do ponto de uso, como uma função.
  • Em uma linguagem que usa tipagem dinâmica ou não tipada, as decorações que remetem aos tipos deixam de ser redundantes. Em tais linguagens, as variáveis ​​normalmente não são declaradas como contendo um tipo particular de dados, então a única pista sobre quais operações podem ser feitas são dicas fornecidas pelo programador, como um esquema de nomenclatura de variável, documentação e comentários. Conforme mencionado acima, a notação húngara foi expandida em tal linguagem ( BCPL ).
  • A formatação de nomes de variáveis ​​pode simplificar alguns aspectos da refatoração de código (enquanto torna outros aspectos mais sujeitos a erros).
  • Várias variáveis ​​com semântica semelhante podem ser usadas em um bloco de código: dwWidth, iWidth, fWidth, dWidth.
  • Os nomes das variáveis ​​podem ser fáceis de lembrar sabendo apenas seus tipos.
  • Isso leva a nomes de variáveis ​​mais consistentes.
  • Casting de tipo inadequado e operações usando tipos incompatíveis podem ser detectados facilmente durante a leitura do código.
  • Em programas complexos com muitos objetos globais (VB / Delphi Forms), ter uma notação de prefixo básica pode facilitar o trabalho de encontrar o componente dentro do editor. Por exemplo, pesquisar pela string btnpode localizar todos os objetos Button.
  • Aplicar a notação húngara de maneira mais restrita, como aplicar apenas para variáveis ​​de membro , ajuda a evitar colisão de nomes .
  • O código impresso é mais claro para o leitor no caso de tipos de dados, conversões de tipo, atribuições, truncamentos, etc.

Desvantagens

A maioria dos argumentos contra a notação húngara é contra a notação Systems Hungarian, e não a notação Apps húngara. Alguns problemas potenciais são:

  • A notação húngara é redundante quando a verificação de tipo é feita pelo compilador. Compiladores para linguagens que fornecem verificação de tipo estrita, como Pascal , garantem que o uso de uma variável seja consistente com seu tipo automaticamente; verificações visuais são redundantes e sujeitas a erro humano.
  • A maioria dos ambientes de desenvolvimento integrados modernos exibe tipos de variáveis ​​sob demanda e sinaliza automaticamente as operações que usam tipos incompatíveis, tornando a notação amplamente obsoleta.
  • A notação húngara torna-se confusa quando é usada para representar várias propriedades, como em a_crszkvc30LastNameCol: um argumento de referência constante , contendo o conteúdo de uma coluna de banco de dados do tipo varchar (30) que faz parte da chave primária da tabela . LastName
  • Isso pode levar à inconsistência quando o código é modificado ou transferido. Se o tipo de uma variável for alterado, ou a decoração no nome da variável será inconsistente com o novo tipo, ou o nome da variável deve ser alterado. Um exemplo particularmente conhecido é o tipo WPARAM padrão e o parâmetro formal wParam que o acompanha em muitas declarações de função do sistema Windows. O 'w' significa 'palavra', onde 'palavra' é o tamanho da palavra nativa da arquitetura de hardware da plataforma. Era originalmente um tipo de 16 bits em arquiteturas de palavras de 16 bits, mas foi alterado para um tipo de 32 bits em arquiteturas de palavras de 32 bits, ou o tipo de 64 bits em arquiteturas de palavras de 64 bits em versões posteriores do sistema operacional, mantendo seu nome original (seu verdadeiro tipo subjacente é UINT_PTR, ou seja, um inteiro sem sinal grande o suficiente para conter um ponteiro). A impedância semântica e, portanto, a confusão e inconsistência do programador de plataforma para plataforma, pressupõe que 'w' representa uma palavra de 16 bits e dois bytes nesses ambientes diferentes.
  • Na maioria das vezes, saber o uso de uma variável implica conhecer seu tipo. Além disso, se o uso de uma variável não for conhecido, não pode ser deduzido de seu tipo.
  • A notação húngara reduz os benefícios de usar editores de código que suportam a conclusão de nomes de variáveis, pois o programador tem que inserir o especificador de tipo primeiro, o que é mais provável de colidir com outras variáveis ​​do que ao usar outros esquemas de nomenclatura.
  • Torna o código menos legível, ofuscando o propósito da variável com prefixos de tipo e escopo.
  • As informações de tipo adicionais podem substituir de forma insuficiente nomes mais descritivos. Por exemplo, sDatabase não informa ao leitor o que é. databaseName pode ser um nome mais descritivo.
  • Quando os nomes são suficientemente descritivos, as informações de tipo adicionais podem ser redundantes. Por exemplo, firstName é provavelmente uma string. Portanto, nomeá-lo sFirstName apenas adiciona confusão ao código.
  • É mais difícil lembrar os nomes.
  • Múltiplas variáveis ​​com semânticas diferentes podem ser usadas em um bloco de código com nomes semelhantes: dwTmp, iTmp, fTmp, dTmp .
  • Colocar identificadores de tipo de dados ou caractere de intenção como um prefixo para o nome dado do campo ou variável subverte a capacidade, em alguns ambientes de programação, de saltar para um nome de campo ou variável, em ordem alfabética, quando o usuário começa a digitar o nome. FileMaker, por exemplo, é um desses ambientes de programação. Pode ser preferível, ao usar um desses ambientes de programação, sufocar os nomes dados com esses caracteres de identificação.

Opiniões notáveis

  • Robert Cecil Martin (contra a notação húngara e todas as outras formas de codificação):

    ... hoje em dia HN e outras formas de codificação de tipo são simplesmente impedimentos. Eles tornam mais difícil alterar o nome ou tipo de uma variável, função, membro ou classe. Eles tornam mais difícil a leitura do código. E eles criam a possibilidade de que o sistema de codificação engane o leitor.

  • Linus Torvalds (contra Systems Hungarian):

    Codificar o tipo de uma função no nome (a chamada notação húngara) causa danos cerebrais - o compilador conhece os tipos de qualquer maneira e pode verificá-los, o que só confunde o programador.

  • Steve McConnell (para Apps húngaro):

    Embora a convenção de nomenclatura húngara não seja mais amplamente usada, a ideia básica de padronizar em abreviações concisas e precisas continua a ter valor. Os prefixos padronizados permitem que você verifique os tipos com precisão quando estiver usando tipos de dados abstratos que seu compilador não pode necessariamente verificar.

  • Bjarne Stroustrup (contra Systems Hungarian for C ++):

    Não, eu não recomendo 'húngaro'. Considero 'húngaro' (incorporar uma versão abreviada de um tipo em um nome de variável) como uma técnica que pode ser útil em linguagens não digitadas, mas é completamente inadequada para uma linguagem que suporta programação genérica e programação orientada a objetos - ambas as quais enfatizam seleção de operações com base no tipo e nos argumentos (conhecidos pela linguagem ou pelo suporte em tempo de execução). Nesse caso, 'construir o tipo de um objeto em nomes' simplesmente complica e minimiza a abstração.

  • Joel Spolsky (para Apps húngaro):

    Se você ler o artigo de Simonyi com atenção, o que ele queria dizer era o mesmo tipo de convenção de nomenclatura que usei no meu exemplo acima, onde decidimos que ussignificava string insegura e ssignificava string segura. Ambos são do tipo string. O compilador não o ajudará se você atribuir um ao outro e o Intellisense [um sistema de completação de código inteligente ] não lhe contará bupkis . Mas eles são semanticamente diferentes. Eles precisam ser interpretados e tratados de forma diferente e algum tipo de função de conversão precisará ser chamada se você atribuir um ao outro ou você terá um bug de tempo de execução. Se tiver sorte. Ainda há uma quantidade enorme de valor para o Apps húngaro, na medida em que aumenta a colocação no código, o que torna o código mais fácil de ler, escrever, depurar e manter e, mais importante, faz com que o código errado pareça errado ... (Sistemas Húngaro) foi um mal-entendido sutil, mas completo, da intenção e prática de Simonyi.

  • As Diretrizes de Design da Microsoft desencorajam os desenvolvedores de usar a notação Húngara de Sistemas ao escolher nomes para os elementos nas bibliotecas de classes .NET, embora isso fosse comum em plataformas de desenvolvimento anteriores da Microsoft, como Visual Basic 6 e anteriores. Estas diretrizes de design não falam sobre as convenções de nomenclatura para variáveis ​​locais dentro das funções.

Veja também

Referências

links externos