Que as pessoas usam as convenções de nomenclatura da Hungria no mundo real?

votos
29

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

Publicado 07/08/2008 em 23:31
fonte usuário
Em outras línguas...                            


20 respostas

votos
56

Considerando-se que a maioria das pessoas que usam notação húngara está a seguir a versão mal entendido sobre isso, eu diria que é bastante inútil.

Se você quiser usar a definição original do mesmo, pode fazer mais sentido, mas diferente do que é na maior parte açúcar sintático.

Se você ler o artigo da Wikipedia sobre o assunto, você vai encontrar duas notações conflitantes, Sistemas Hungarian Notation e Aplicativos Hungarian Notation .

O original, bom, definição é a Aplicativos Hungarian Notation , mas a maioria das pessoas usam os sistemas de notação húngara .

Como um exemplo de dois, considerar prefixing variáveis ​​com l para o comprimento, uma área para ev para volume.

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

int vBox = aBottom * lVerticalSide;

mas isso não faz:

int aBottom = lSide1;

Se você está misturando os prefixos, eles estão a ser considerada parte da equação, e volume = área * comprimento é bom para uma caixa, mas copiar um valor de comprimento em uma variável de área deve levantar algumas bandeiras vermelhas.

Infelizmente, a outra notação é menos útil, onde as pessoas prefixar os nomes de variáveis ​​com o tipo do valor, como este:

int iLength;
int iVolume;
int iArea;

algumas pessoas usam n para o número, ou i para inteiro, f para float, é para a corda etc.

O prefixo original foi feito para ser usado para detectar problemas em equações, mas, de alguma forma transformou em tornar o código um pouco mais fácil de ler desde que você não tem que ir olhar para a declaração variável. Com de hoje editores inteligentes onde você pode simplesmente pairam sobre qualquer variável para encontrar o tipo completo, e não apenas uma abreviatura para ele, este tipo de notação húngara perdeu muito de seu significado.

Mas, você deve fazer a sua própria mente. Tudo o que posso dizer é que eu não utilizar qualquer um.


Editar Só para acrescentar um curto espaço de tempo, enquanto eu não usar notação húngara , eu faço usar um prefixo, e é o sublinhado. I prefixar todos os campos particulares de classes com uma _ e de outra forma soletrar seus nomes como eu faria uma propriedade, titlecase com a primeira letra maiúscula.

Respondeu 07/08/2008 em 23:39
fonte usuário

votos
19

A convenção de nomenclatura húngara pode ser útil quando usado corretamente, infelizmente, tende a ser mal utilizado mais frequentemente do que não.

Leia o artigo de Joel Spolsky Fazendo errado Código Olhe errada para a perspectiva e justificação adequada.

Essencialmente, o tipo baseada notação húngara, onde as variáveis ​​são prefixados com informações sobre o seu tipo (por exemplo, se um objeto é uma string, uma alça, um int, etc.) é praticamente inúteis e geralmente apenas adiciona sobrecarga com muito pouco benefício. Este, infelizmente, é a notação húngara a maioria das pessoas está familiarizada. No entanto, a intenção de notação húngara como previsto é adicionar informações sobre o "tipo" de dados a variável contém. Isso permite que você particionar os tipos de dados de outros tipos de dados que não devem ser autorizados a ser misturados entre si, exceto, possivelmente, através de algum processo de conversão. Por exemplo, com base coordenadas de pixel versus coordenadas em outras unidades, ou entrada de utilizador inseguro versus os dados a partir de fontes seguras, etc.

Olhe isto deste modo, se você se encontrar espeleologia através de código para descobrir informações sobre uma variável, então você provavelmente precisará ajustar o seu esquema de nomeação para conter essa informação, esta é a essência da convenção húngara.

Note-se que uma alternativa à notação húngara é usar mais classes para mostrar a intenção do uso da variável em vez de depender de tipos primitivos em toda parte. Por exemplo, em vez de ter prefixos variável para a entrada do usuário inseguro, você pode ter classe string invólucro simples para a entrada do usuário inseguro, e uma classe de invólucro separado para dados seguros. Isto tem a vantagem, em linguagens de rigidez, de ter particionamento forçado pelo compilador (mesmo em línguas menos rigidez, geralmente, você pode adicionar seu próprio código de arame), mas adiciona uma quantidade não desprezível de sobrecarga.

Respondeu 07/08/2008 em 23:56
fonte usuário

votos
13

Eu ainda uso notação húngara quando se trata de elementos de interface do usuário, onde vários elementos de interface do usuário são relacionados a um objeto / valor específico, por exemplo,

lblFirstName para o objeto rótulo, txtFirstName para a caixa de texto. Eu definitivamente não pode nomeá-los tanto "Nome", mesmo que é a preocupação / responsabilidade de ambos os objetos.

Como os outros abordagem nomear elementos de interface do usuário?

Respondeu 08/08/2008 em 02:44
fonte usuário

votos
9

É inútil (e perturbador), mas está em uso relativamente pesado na minha empresa, pelo menos por tipos como inteiros, strings, booleanos e duplos.

Coisas como sValue, iCount, dAmountou fAmount, e bFlagestão por toda parte.

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

Respondeu 07/08/2008 em 23:45
fonte usuário

votos
8

Acho notação húngara é uma interessante nota de rodapé ao longo do 'caminho' para o código mais legível, e se feito corretamente, é preferível a fazer não-lo.

Ao dizer isso, porém, eu prefiro acabar com ela, e, em vez disso:

int vBox = aBottom * lVerticalSide;

escreva isso:

int boxVolume = bottomArea * verticalHeight;

É 2008. Não temos 80 caracteres fixo telas de largura mais!

Além disso, se você está escrevendo nomes de variáveis ​​que são muito mais tempo do que você deve estar olhando para refatoração em objetos ou funções de qualquer maneira.

Respondeu 07/08/2008 em 23:52
fonte usuário

votos
5

Não é escopo mais importante do que digitar nos dias de hoje, por exemplo,

  • l para locais
  • um para o argumento
  • m para membro
  • g for global
  • etc

Com modernas técnicas de refatoração de código antigo, procurar e substituir de um símbolo, porque você mudou seu tipo é tedioso, o compilador vai pegar mudanças de tipo, mas muitas vezes não vai pegar uso incorreto do escopo, convenções de nomenclatura sensatas ajudar aqui.

Respondeu 20/09/2008 em 09:44
fonte usuário

votos
5

Vejo notação húngara como uma forma de contornar a capacidade das nossas memórias de curto prazo. De acordo com psicólogos, podemos armazenar cerca de 7 plus-ou-menos 2 pedaços de informação. A informação extra adicionado ao incluir um prefixo nos ajuda, fornecendo mais detalhes sobre o significado de um identificador mesmo com nenhum outro contexto. Em outras palavras, podemos adivinhar o que uma variável é para sem ver como ele é usado ou declarada. Isto pode ser evitado através da aplicação oo técnicas, tais como encapsulamento eo princípio da responsabilidade única .

Estou desconhecem ou não isso foi estudado empiricamente. Eu supor que a quantidade de esforço aumenta drasticamente quando tentamos entender as classes com mais de nove variáveis ​​de instância ou métodos com mais de 9 variáveis ​​locais.

Respondeu 17/09/2008 em 04:24
fonte usuário

votos
5

Desculpe a acompanhar com uma pergunta, mas não prefixar interfaces com "I" qualificar como notação húngara? Se for esse o caso, então sim, um monte de pessoas estão usando isso no mundo real. Se não, ignorar isso.

Respondeu 13/08/2008 em 17:31
fonte usuário

votos
4

Quando vejo discussão húngara, eu estou contente de ver as pessoas a pensar seriamente sobre como fazer o seu código mais claro, e como erros mais visíveis. Isso é exatamente o que todos nós devemos estar fazendo!

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

Extrair Método Se os seus métodos estão ficando tanto tempo que suas declarações de variáveis tiver rolado fora do topo da tela, considere fazer seus métodos menor. (Se você tem muitos métodos, considere uma nova classe.)

Tipagem forte Se você achar que você está tomando CEP s armazenados em uma variável inteira e atribuir-lhes um sapato tamanho variável inteira, considere fazer uma classe para códigos postais e uma classe para o tamanho do sapato. Então o seu erro vai ser pego em tempo de compilação, em vez de exigir uma inspeção cuidadosa por um ser humano. Quando eu fizer isso, eu costumo encontrar um monte de code-zip e lógica específica de tamanho de sapato que eu salpicado ao redor do meu código, que pode então mover-se para minhas novas classes. De repente, todo o meu código fica mais clara, mais simples e protegido de certas classes de bugs. Uau.

Resumindo: sim, pensar muito sobre como você usa nomes em código para expressar suas idéias com clareza, mas também olhar para as outras ferramentas poderosas OO você pode convocar.

Respondeu 10/09/2008 em 00:05
fonte usuário

votos
2

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

Respondeu 24/10/2008 em 14:46
fonte usuário

votos
1

notação húngara é inútil em linguagens tipo seguro. por exemplo, um prefixo comum que você verá no código Microsoft velho é "lpsz", que significa "ponteiro longo para uma string terminada em zero". Desde o início de 1700 nós não usamos arquiteturas segmentadas onde existem ponteiros curtas e longas, a representação normal em C ++ é sempre terminada em zero, eo compilador é tipo seguro para que não nos deixa aplicar operações não-string para o corda. Portanto nenhuma dessas informações é de qualquer uso real para um programador - é apenas mais digitação.

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

  • m = membro
  • c = const
  • s = estática
  • v = volátil
  • p = ponteiro (e pp = ponteiro para ponteiro, etc)
  • i = índice ou iteração

Estes podem ser combinados, de modo que uma variável membro estático que é um ponteiro seria "mspName".

Onde estão estes útil?

  • Onde o uso é importante, é uma boa idéia para lembrar constantemente o programador que uma variável é (por exemplo) a volátil ou um ponteiro
  • Ponteiro dereferencing costumava fazer minha cabeça até que eu usei o p prefixo. Agora é realmente fácil de saber quando você tem um objeto (laranja) um ponteiro para um objeto (pOrange) ou um ponteiro para um ponteiro para um objeto (ppOrange). Para excluir a referência um objeto, basta colocar um asterisco na frente dele para cada p em seu nome. Caso resolvido, bugs não mais Deref!
  • Em construtores Eu costumo achar que um nome de parâmetro é idêntico ao nome de uma variável de membro (por exemplo, tamanho). Eu prefiro usar "msize = tamanho"; que "size = thesize" ou "this.size = tamanho". É também muito mais seguro: Eu não acidentalmente usar "size = 1" (a definição do parâmetro) quando eu quis dizer "msize = 1" (definindo o membro)
  • Em loops, meus variáveis ​​iteradoras são todos nomes significativos. A maioria dos programadores usar "i" ou "index" e depois ter de fazer novos nomes sem sentido ( "j", "index2") quando eles querem um loop interno. Eu uso um nome significativo com um prefixo i (iHospital, iWard, iPatient) então eu sempre sei o que um iterador é iteração.
  • Em loops, você pode misturar várias variáveis ​​relacionadas usando o mesmo nome de base com diferentes prefixos: Laranja Laranja = pOrange [iOrange]; Isso também significa que você não cometer erros de indexação de matriz (papple [i] parece ok, mas escrevê-lo como papple [iOrange] eo erro é imediatamente óbvio).
  • Muitos programadores irá utilizar o meu sistema sem o saber: por adicionar um sufixo longa como "Index" ou "PTR" - não há nenhuma boa razão para usar uma forma mais longa do que um único IMHO personagem, então eu uso "i" e " p". Menos digitação, mais consistente, mais fácil de ler.

Este é um sistema simples que adiciona informação significativa e útil para o código, e elimina a possibilidade de muitos erros de programação simples, mas comuns.

Respondeu 25/05/2009 em 16:48
fonte usuário

votos
1

Ao usar uma linguagem de tipagem dinâmica, eu ocasionalmente usar Apps húngara. Para linguagens de tipagem estática eu não. Veja minha explicação em outro segmento .

Respondeu 27/08/2008 em 15:21
fonte usuário

votos
1

O prefixo original foi feito para ser usado para detectar problemas em equações, mas, de alguma forma transformou em tornar o código um pouco mais fácil de ler desde que você não tem que ir olhar para a declaração variável. Com de hoje editores inteligentes onde você pode simplesmente pairam sobre qualquer variável para encontrar o tipo completo, e não apenas uma abreviatura para ele, este tipo de notação húngara perdeu muito de seu significado.

Eu estou quebrando o hábito um pouco, mas prefixar com o tipo pode ser útil em JavaScript que não tem tipagem forte variável.

Respondeu 27/08/2008 em 14:55
fonte usuário

votos
1

O que está errado é misturar padrões.

O que é certo é ter certeza de que todo mundo faz a mesma coisa.

int Box = iBottom * nVerticleSide
Respondeu 13/08/2008 em 18:17
fonte usuário

votos
1

Eu uso Naming Húngaro para elementos de interface do usuário como botões, caixas de texto e lables. O principal benefício é o agrupamento no Popup Visual Studio IntelliSense. Se eu quiser acessar meus lables, eu simplesmente começar a digitar LBL .... e Visual Studio irá sugerir todos os meus lables, nicley agrupados.

No entanto, depois de fazer mais e mais Silverlight e WPF coisas, aproveitando a ligação de dados, eu nem mesmo nomear todos os meus controles mais, desde que eu não tenho que referenciá-los de codebehind (desde não há realmente qualquer codebehind mais ;)

Respondeu 08/08/2008 em 07:09
fonte usuário

votos
1

Eu tenho trabalhado para a IBM nos últimos 6 meses e eu não vi isso em qualquer lugar (graças a Deus, porque eu odeio isso.) Eu vejo tanto camelCase ou c_style.

thisMethodIsPrettyCool()
this_method_is_pretty_cool()
Respondeu 07/08/2008 em 23:39
fonte usuário

votos
0

Ser um programador de PHP onde ele é muito vagamente digitado, eu não fazer um ponto para usá-lo. No entanto I irá ocasionalmente identificar algo como uma matriz ou como um objecto, dependendo do tamanho do sistema e do âmbito da variável.

Respondeu 03/09/2009 em 03:19
fonte usuário

votos
0

Eu uso tipo base (Sistemas HN) para componentes (por exemplo editFirstName, lblStatus etc), uma vez que torna o trabalho autocomplete melhor.

Eu às vezes uso App HN para variáveis ​​onde o tipo infomation é isufficient. Ou seja FPx indica uma variável pontiagudo fixo (int tipo, mas não podem ser misturados e combinados com um int), rawInput para cordas de utilizador que não foram validados etc.

Respondeu 10/09/2008 em 00:41
fonte usuário

votos
0

forma original (A notação húngara direito :)) em que prefixo significa o tipo (isto é, o comprimento, a quantidade) do valor armazenado pelo variável é OK, mas não é necessário em todos os tipos de aplicações.

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

Especialmente com nomes sem sentido como strA. Eu não consigo entender que as pessoas usam nomes sem sentido, com longos prefixos que dá nada.

Respondeu 27/08/2008 em 15:14
fonte usuário

votos
0

Depende da sua linguagem e ambiente. Como regra geral eu não iria utilizá-lo, a menos que o ambiente de desenvolvimento que você está em torna difícil encontrar o tipo da variável.

Há também dois tipos diferentes de notação húngara. Veja o artigo de Joel. Eu não posso encontrá-lo (seus nomes não exatamente torná-los fáceis de encontrar), Alguém tem um link para o que eu quero dizer?

Edit: Wedge tem o artigo que quero dizer em seu post.

Respondeu 07/08/2008 em 23:43
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more