As pessoas usam as convenções de nomenclatura húngaras no mundo real?[fechado]

StackOverflow https://stackoverflow.com/questions/5428

Pergunta

Vale a pena aprender a convenção ou é uma desgraça para a legibilidade e a manutenção?

Foi útil?

Solução

Considerando que a maioria das pessoas que usam Notação Húngara está seguindo a versão mal compreendida disso, eu diria que é bastante inútil.

Se você quiser usar a definição original, pode fazer mais sentido, mas fora isso, é principalmente açúcar sintático.

Se você ler o Artigo da Wikipédia sobre o assunto, você encontrará duas notações conflitantes, Notação Húngara de Sistemas e Apps Notação Húngara.

A definição original e boa é a Apps Notação Húngara, mas a maioria das pessoas usa o Notação Húngara de Sistemas.

Como exemplo dos dois, considere prefixar variáveis ​​com l para comprimento, a para área e v para volume.

Com tal notação, a seguinte expressão faz sentido:

int vBox = aBottom * lVerticalSide;

mas isso não acontece:

int aBottom = lSide1;

Se você estiver misturando os prefixos, eles devem ser considerados parte da equação, e volume = área * comprimento é adequado para uma caixa, mas copiar um valor de comprimento em uma variável de área deve levantar alguns sinais de alerta.

Infelizmente, a outra notação é menos útil, onde as pessoas prefixam os nomes das variáveis ​​com o tipo do valor, assim:

int iLength;
int iVolume;
int iArea;

algumas pessoas usam n para número, ou i para inteiro, f para float, s para string etc.

O prefixo original foi criado para ser usado para detectar problemas em equações, mas de alguma forma evoluiu para tornar o código um pouco mais fácil de ler, já que você não precisa procurar a declaração da variável.Com os editores inteligentes de hoje, onde você pode simplesmente passar o mouse sobre qualquer variável para encontrar o tipo completo, e não apenas uma abreviatura, esse tipo de notação húngara perdeu muito do seu significado.

Mas você deve decidir por si mesmo.Só posso dizer que também não uso.

Editar Só para acrescentar um breve aviso, enquanto eu não uso Notação Húngara, eu uso um prefixo e é o sublinhado.Eu prefixo todos os campos privados de classes com um _ e, caso contrário, escrevo seus nomes como faria com uma propriedade, título com a primeira letra maiúscula.

Outras dicas

A Convenção de Nomenclatura Húngara pode ser útil quando usada corretamente, mas infelizmente tende a ser mal utilizada na maioria das vezes.

Leia o artigo de Joel Spolsky Fazendo o código errado parecer errado para perspectiva e justificativa apropriadas.

Essencialmente, notação húngara baseada em tipo, onde as variáveis ​​são prefixadas com informações sobre seu tipo (por exemplo,se um objeto é uma string, um identificador, um int, etc.) é praticamente inútil e geralmente apenas adiciona sobrecarga com muito pouco benefício.Esta, infelizmente, é a notação húngara com a qual a maioria das pessoas está familiarizada.No entanto, a intenção da notação húngara, conforme prevista, é adicionar informações sobre o “tipo” de dados que a variável contém.Isso permite particionar tipos de dados de outros tipos de dados que não deveriam ser misturados, exceto, possivelmente, por meio de algum processo de conversão.Por exemplo, coordenadas baseadas em pixels vs.coordenadas em outras unidades ou entrada insegura do usuário versus dados de fontes seguras, etc.

Veja desta maneira: se você estiver vasculhando o código para descobrir informações sobre uma variável, provavelmente precisará ajustar seu esquema de nomenclatura para conter essas informações; essa é a essência da convenção húngara.

Observe que uma alternativa à notação húngara é usar mais classes para mostrar a intenção do uso de variáveis, em vez de depender de tipos primitivos em todos os lugares.Por exemplo, em vez de ter prefixos variáveis ​​para entrada de usuário insegura, você pode ter uma classe wrapper de string simples para entrada de usuário insegura e uma classe wrapper separada para dados seguros.Isso tem a vantagem, em linguagens fortemente tipadas, de ter o particionamento imposto pelo compilador (mesmo em linguagens menos fortemente tipadas, você geralmente pode adicionar seu próprio código tripwire), mas adiciona uma quantidade não insignificante de sobrecarga.

Eu ainda uso a notação húngara quando se trata de elementos da UI, onde vários elementos da UI estão relacionados a um objeto/valor específico, por exemplo,

lblFirstName para o objeto de rótulo, txtFirstName para a caixa de texto.Definitivamente, não posso nomear os dois como "Nome", mesmo que que é preocupação/responsabilidade de ambos os objetos.

Como outras pessoas abordam a nomenclatura de elementos da UI?

É inútil (e perturbador), mas é de uso relativamente intenso na minha empresa, pelo menos para tipos como ints, strings, booleans e doubles.

Coisas como sValue, iCount, dAmount ou fAmount, e bFlag estão em todo lugar.

Era uma vez uma boa razão para esta convenção.Agora, é um câncer.

Acho que a notação húngara é uma nota de rodapé interessante no 'caminho' para um código mais legível e, se feita corretamente, é preferível a não fazê-lo.

Ao dizer isso, prefiro acabar com isso e, em vez disso:

int vBox = aBottom * lVerticalSide;

escreva isso:

int boxVolume = bottomArea * verticalHeight;

Estamos em 2008.Não temos mais telas de largura fixa de 80 caracteres!

Além disso, se você estiver escrevendo nomes de variáveis ​​​​que são muito mais longos do que isso, você deveria tentar refatorar em objetos ou funções de qualquer maneira.

Desculpe continuar com a pergunta, mas prefixar interfaces com "I" se qualifica como notação húngara?Se for esse o caso, então sim, muitas pessoas estão usando isso no mundo real.Se não, ignore isso.

Vejo a notação húngara como uma forma de contornar a capacidade das nossas memórias de curto prazo.Segundo psicólogos, podemos armazenar aproximadamente 7 mais ou menos 2 pedaços de informação.As informações extras adicionadas pela inclusão de um prefixo nos ajudam a fornecer mais detalhes sobre o significado de um identificador, mesmo sem outro contexto.Em outras palavras, podemos adivinhar para que serve uma variável sem ver como ela é usada ou declarada.Isso pode ser evitado aplicando técnicas de oo, como encapsulamento e a princípio de responsabilidade única.

Não sei se isso foi ou não estudado empiricamente.Eu levantaria a hipótese de que a quantidade de esforço aumenta dramaticamente quando tentamos entender classes com mais de nove variáveis ​​de instância ou métodos com mais de 9 variáveis ​​locais.

O escopo não é mais importante que o tipo hoje em dia, por ex.

  • eu para local
  • um para argumento
  • m para membro
  • g para global
  • etc.

Com técnicas modernas de refatoração de código antigo, pesquisar e substituir um símbolo porque você alterou seu tipo é tedioso, o compilador detectará alterações de tipo, mas geralmente não detectará o uso incorreto do escopo; convenções de nomenclatura sensatas ajudam aqui.

Quando vejo uma discussão húngara, fico feliz em ver as pessoas pensando muito sobre como tornar seu código mais claro e como tornar os erros mais visíveis.Isso é exatamente o que todos nós deveríamos estar fazendo!

Mas não esqueça que você tem algumas ferramentas poderosas à sua disposição além de nomear.

Método de extração Se seus métodos estão ficando tão longos que suas declarações de variáveis ​​rolaram para fora do topo da tela, considere diminuir seus métodos.(Se você tiver muitos métodos, considere uma nova classe.)

Digitação forte Se você descobrir que está tomando CEPs armazenados em uma variável inteira e atribuindo-os a um tamanho de sapato variável inteira, considere criar uma classe para códigos postais e uma classe para tamanho de calçado.Então seu bug será detectado em tempo de compilação, em vez de exigir uma inspeção cuidadosa por um humano.Quando faço isso, geralmente encontro um monte de lógica específica de código postal e tamanho de sapato que coloquei em torno de meu código, que posso então mover para minhas novas classes.De repente, todo o meu código fica mais claro, simples e protegido de certas classes de bugs.Uau.

Resumindo:sim, pense bem em como você usa nomes no código para expressar suas ideias com clareza, mas também observe outras ferramentas OO poderosas que você pode utilizar.

Eu não uso um sentido muito estrito de notação húngara, mas me pego usando-a poupando alguns objetos personalizados comuns para ajudar a identificá-los, e também tendo a prefixar objetos de controle gui com o tipo de controle que eles são.Por exemplo, labelFirstName, textFirstName e buttonSubmit.

Eu uso a nomenclatura húngara para elementos da interface do usuário, como botões, caixas de texto e rótulos.O principal benefício é o agrupamento no pop-up Intellisense do Visual Studio.Se eu quiser acessar meus rótulos, simplesmente começo a digitar lbl....e o Visual Studio irá sugerir todos os meus rótulos, bem agrupados.

No entanto, depois de fazer mais e mais coisas do Silverlight e do WPF, aproveitando a vinculação de dados, eu nem nomeio mais todos os meus controles, já que não preciso referenciá-los do code-behind (já que realmente não existe mais nenhum codebehind). ;)

O que há de errado é misturar padrões.

O certo é garantir que todos façam a mesma coisa.

int Box = iBottom * nVerticleSide

O prefixo original deveria ser usado para identificar problemas nas equações, mas, de alguma forma, se devolveu a tornar o código um pouco mais fácil de ler, pois você não precisa procurar a declaração variável.Com os editores inteligentes de hoje, onde você pode simplesmente pairar sobre qualquer variável para encontrar o tipo completo, e não apenas uma abreviação, esse tipo de notação húngara perdeu muito de seu significado.

Estou quebrando um pouco o hábito, mas prefixar o tipo pode ser útil em JavaScript que não possui digitação de variável forte.

Ao usar uma linguagem de digitação dinâmica, ocasionalmente uso o Apps Húngaro.Para linguagens de tipo estaticamente, não.Veja minha explicação no outro tópico.

A notação húngara é inútil em linguagens com segurança de tipo.por exemplo.Um prefixo comum que você verá no código antigo da Microsoft é "lpsz", que significa "ponteiro longo para uma string terminada em zero".Desde o início de 1700, não usamos arquiteturas segmentadas onde existam ponteiros curtos e longos, a representação normal de string em C++ é sempre terminada em zero e o compilador é seguro para o tipo, portanto, não nos permitirá aplicar operações que não sejam de string ao corda.Portanto, nenhuma dessas informações tem qualquer utilidade real para um programador - é apenas mais digitação.

No entanto, uso uma ideia semelhante:prefixos que esclarecem o uso de uma variável.Os principais são:

  • m = membro
  • c = const
  • s = estático
  • v = volátil
  • p = ponteiro (e pp = ponteiro para ponteiro, etc)
  • i = índice ou iterador

Eles podem ser combinados, portanto, uma variável de membro estático que seja um ponteiro seria "mspName".

Onde isso é útil?

  • Onde o uso for importante, é uma boa ideia lembrar constantemente ao programador que uma variável é (por exemplo) um volátil ou um ponteiro
  • A desreferenciação de ponteiro costumava me preocupar até que eu usei o prefixo p.Agora é muito fácil saber quando você tem um objeto (Laranja), um ponteiro para um objeto (pOrange) ou um ponteiro para um ponteiro para um objeto (ppOrange).Para desreferenciar um objeto, basta colocar um asterisco na frente dele para cada p em seu nome.Caso resolvido, chega de bugs deref!
  • Em construtores, geralmente descubro que o nome de um parâmetro é idêntico ao nome de uma variável de membro (por exemplo,tamanho).Prefiro usar "msize = size;" do que "size = thesize" ou "this.size = size".Também é muito mais seguro:Não uso acidentalmente "size = 1" (definindo o parâmetro) quando queria dizer "mSize = 1" (definindo o membro)
  • Em loops, minhas variáveis ​​iteradoras são todas nomes significativos.A maioria dos programadores usa "i" ou "index" e então precisa inventar novos nomes sem sentido ("j", "index2") quando desejam um loop interno.Eu uso um nome significativo com um prefixo i (iHospital, iWard, iPatient) para sempre saber o que um iterador está iterando.
  • Em loops, você pode misturar diversas variáveis ​​relacionadas usando o mesmo nome base com prefixos diferentes:Laranja laranja = pLaranja[iLaranja];Isso também significa que você não comete erros de indexação de array (pApple[i] parece ok, mas escreva como pApple[iOrange] e o erro é imediatamente óbvio).
  • Muitos programadores usarão meu sistema sem saber:adicionando um sufixo longo como "Index" ou "Ptr" - não há nenhum bom motivo para usar um formato mais longo do que um único caractere IMHO, então eu uso "i" e "p".Menos digitação, mais consistente e mais fácil de ler.

Este é um sistema simples que adiciona informações significativas e úteis ao código e elimina a possibilidade de muitos erros de programação simples, mas comuns.

Trabalho para a IBM há 6 meses e não vi isso em lugar nenhum (graças a Deus porque odeio isso). Vejo camelCase ou c_style.

thisMethodIsPrettyCool()
this_method_is_pretty_cool()

Depende do seu idioma e ambiente.Via de regra, eu não o usaria, a menos que o ambiente de desenvolvimento em que você esteja dificulte encontrar o tipo da variável.

Existem também dois tipos diferentes de notação húngara.Veja o artigo de Joel.Não consigo encontrar (os nomes dele não os tornam exatamente fáceis de encontrar), alguém tem um link para o que estou falando?

Editar:Wedge tem o artigo que quero dizer em sua postagem.

Forma original (a notação húngara correta :)) onde prefixo significa tipo (ou seja,comprimento, quantidade) do valor armazenado pela variável é aceitável, mas não é necessário em todos os tipos de aplicações.

A forma popular (A Notação Húngara Errada) onde prefixo significa tipo (String, int) é inútil na maioria das linguagens de programação modernas.

Especialmente com nomes sem sentido como strA.Não consigo entender que usamos nomes sem sentido com prefixos longos que não dão nada.

Eu uso o tipo baseado (Systems HN) para componentes (por exemplo, editFirstName, lblStatus etc.), pois faz com que o preenchimento automático funcione melhor.

Às vezes uso o App HN para variáveis ​​​​onde as informações do tipo são suficientes.Ou seja, fpX indica uma variável pontiaguda fixa (tipo int, mas não pode ser misturada e combinada com um int), rawInput para strings de usuário que não foram validadas, etc.

Sendo um programador PHP onde é digitado de maneira muito livre, não faço questão de usá-lo.No entanto, ocasionalmente identificarei algo como um array ou um objeto dependendo do tamanho do sistema e do escopo da variável.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top