Pergunta

Esta questão é buscar bons exemplos de notação húngara, para que possamos reunir uma coleção deles.

Editar: Concordo que o húngaro para tipos não é tão necessário, espero exemplos mais específicos onde aumente a legibilidade e a facilidade de manutenção, como Joel fornece em seu artigo (conforme minha resposta).

Foi útil?

Solução 2

O artigo agora clássico, como mencionado em outros posts húngaros, é o do site de Joel:

http://www.joelonsoftware.com/articles/wrong.html

Outras dicas

O problema de pedir bons exemplos de notação húngara é que todos terão sua própria idéia de como é um bom exemplo. Minha opinião pessoal é que o melhor Notação húngara é nenhuma notação húngara. A notação foi originalmente destinada a denotar o uso pretendido de uma variável e não seu tipo, mas geralmente é usado para obter informações de tipo, principalmente para controles de formulário (por exemplo, txtfirstname Para uma caixa de texto para o primeiro nome de alguém.). Isso torna o código menos sustentável, em termos de legibilidade (por exemplo, "Prepin Nounterms PrePof NounReadability") e a refatoração para quando o tipo precisa ser alterado (existem "lparams" na API Win32 que mudou o tipo).

Você provavelmente deve considerar não usá -lo. Exemplos:

  • strfirstname - Isso pode ser apenas primeiro nome Como é óbvio para o que é, o tipo não é tão importante e deve ser óbvio neste caso. Se não for óbvio, o IDE pode ajudá -lo com isso.
  • txtfirstname - Isso pode mudar para FirstNineTextBox ou Primeironame_textbox. Ele lê melhor e você sabe que é um controle e não apenas o texto.
  • Caccount - C foi usado para nomes de classe no MFC, mas você realmente não precisa. Conta é bom o suficiente. O nome da maçaneta é a convenção padrão para tipos (e eles aparecem apenas em lugares específicos para que não sejam confundidos com propriedades ou métodos)
  • ixArray (índice para variedade) - ix é um pouco obscuro. Tentar Arrayindex.
  • USSTATE (string insegura para Estado) - Parece "Estado dos EUA". Melhor ir com Estado_Inseguro ou alguma coisa. Talvez até envolvê -lo em um Inseguro classe para pelo menos torná-la segura.

p

(para ponteiro). É praticamente o único prefixo que eu uso. Eu acho que isso acrescenta muito a uma variável (por exemplo, que é um ponteiro) e, portanto, deve ser tratado um pouco mais respeitosamente.

O húngaro para os tipos de dados é um pouco o que o IDES pode dizer qual é o tipo (em apenas alguns segundos pairando sobre o nome da variável), então não é tão importante. Mas tratar um ponteiro como se seus dados não fossem bons, então você deseja garantir que seja óbvio para o usuário o que é, mesmo que ele faça suposições que não deveria ao codificar.

t

Dados contaminados. Prefixo todos os dados recebidos de uma fonte não confiável para tornar essa variável como contaminada. Todos os dados contaminados devem ser limpos antes que qualquer trabalho real seja feito.

Não faz sentido usar húngaro para indicar tipos porque o compilador já faz isso para você.

Onde o húngaro é útil é distinguir entre tipos de variáveis ​​logicamente diferentes que possuem o mesmo tipo bruto.Por exemplo, se você estiver usando ints para representar coordenadas, poderá prefixar as coordenadas x com x, as coordenadas y com y e as distâncias com d.Então você teria um código parecido com

dxHighlight = xStart - xEnd

yHighlight = yLocation + 3

yEnd = yStart + dyHeight

dyCode = dyField * 2

e assim por diante.É útil porque você pode detectar erros rapidamente:Se você adicionar um dy a um y, sempre obterá um y.Se você subtrair dois x, sempre obterá um dx.Se você multiplicar um dy por um escalar, sempre obterá um dy.E assim por diante.Se você vir uma linha como

yTop = dyText + xButton

você sabe à primeira vista que está errado porque adicionar um dy e um x não faz sentido.O compilador não conseguiu capturar isso para você porque, até onde ele sabe, você está adicionando um int a um int, o que é bom.

Não use prefixos específicos do idioma.

Nós usamos:

n: Number 
p: Percentage 1=100% (for interest rates etc)
c: Currency
s: String
d: date
e: enumeration
o: object (Customer oCustomer=new Customer();)
...

Usamos o mesmo sistema para todos os idiomas:

SQL
C
C#
Javascript
VB6
VB.net
...

É um salva -vidas.

Advogado do Diabo: O melhor exemplo de notação húngara não é usá -lo. : D

Não temos vantagem em usar a notação húngara com os IDEs modernos porque eles sabem o tipo. Ele adiciona trabalho ao refatorar um tipo para uma variável, pois o nome também teria que ser alterado (e na maioria das vezes em que você está lidando com uma variável, você sabe que tipo é de qualquer maneira).

Você também pode fazer problemas com a notação. Se você usa p para ponteiro e um endereço, você chama sua variável apstreet ou plastreet? A legibilidade diminui quando você não tem consistência e precisa usar um espaço mental valioso quando precisa se lembrar da ordem em que precisa escrever a notação.

Acho que a notação húngara às vezes pode ser útil em idiomas dinâmicos. Estou pensando especificamente no ActionScript do servidor (essencialmente apenas JavaScript), mas pode se aplicar em outro lugar. Como não há informações de tipo real, a notação húngara às vezes pode ajudar a tornar as coisas um pouco mais fáceis de entender.

O único húngaro que ainda é realmente útil é m_ para variáveis ​​de membro.(Eu também uso sm_ para membros estáticos, porque esse é o "outro" escopo que ainda existe.) Com monitores widescreen e compiladores que usam nomes de variáveis ​​com oito bilhões de caracteres, abreviar nomes de tipos simplesmente não vale a pena.

A notação húngara (invólucro de camelo, como eu aprendi) é inestimável quando você está herdando um projeto de software.

Sim, você pode 'passar' sobre uma variável com o seu IDE e descobrir que classe é, mas se você estiver pagando por vários milhares de linhas de código, não deseja parar por esses poucos segundos - a cada .. .. solteiro .... tempo ....

Lembre -se - você não está escrevendo código para você ou sua equipe sozinha. Você também está escrevendo para a pessoa que precisa pegar esse código de 2 a 5 anos depois e aprimorá-lo.

Eu era fortemente contra a notação húngara até que realmente comecei a ler sobre isso e tentando entender sua intenção original.
Depois de ler Joels Post "Wrong" e o artigo "Redescobrindo a notação húngara", eu realmente mudei de idéia. Feito correto, eu acredito que deve ser extremamente poderoso.

Errado por Joel Spolsky
http://www.joelonsoftware.com/articles/wrong.html

Redescobrir a notação húngara
http://codingthriller.blogspot.com/2007/11/rediscovering-hungarian-notation.html

Eu acredito que a maioria dos opositores nunca tentou isso de verdade e não entende realmente. Eu adoraria experimentá -lo em um projeto real.

Eu acho que o principal a tirar do artigo de Joel, vinculado acima, e a notação húngara em geral, é usá-lo quando há algo não óbvio na variável.

Um exemplo, do artigo, é codificado versus cordas não codificadas, não é que você use 'nós' húngaros para cordas inseguras e 's' para cordas seguras, é que você deveria ter algum Identificador para indicar que uma string é segura ou não. Se se tornar padrão, fica fácil ver quando o padrão está sendo quebrado.

m

Ao usar um ORM (como Hibernate), você tende a lidar com objetos gerenciados e não gerenciados. A alteração de um objeto gerenciado será refletido no banco de dados sem chamar uma salvamento explícito, enquanto lida com um objeto gerenciado requer uma chamada de salvamento explícita. Como você lida com o objeto será diferente, dependendo do que é.

Acho que o único ponto útil é ao declarar controles de interface, txtUsername, txtPassword, ddlBirthMonth.Não é perfeito, mas ajuda em grandes formulários/projetos.

Não uso para variáveis ​​ou outros itens, apenas controles.

Além de usar 'P' para ponteiro, gosto da idéia de usar 'CB' e 'CCH' para indicar se um parâmetro de tamanho de buffer (ou variável) é uma contagem de bytes ou uma contagem de caracteres (eu também vi - Raramente - 'CE' usado para indicar uma contagem de elementos). Então, em vez de transmitir tipo, o prefixo transmite ou intenção.

Admito, não uso o prefixo tão consistente quanto eu provavelmente deveria, mas gosto da ideia.

Concordo que a notação húngara já não é particularmente útil.Achei que sua intenção original era indicar não o tipo de dados, mas sim o tipo de entidade.Em uma seção de código envolvendo os nomes de clientes, funcionários e usuário, por exemplo, você poderia nomear variáveis ​​de string locais cusName, empName e usrName.Isso ajudaria a distinguir entre nomes de variáveis ​​com sons semelhantes.Os mesmos prefixos para as entidades seriam usados ​​em todo o aplicativo.No entanto, quando OO é usado e você está lidando com objetos, esses prefixos são redundantes em Customer.Name, Employee.Name e User.Name.

O nome da variável deve descrever o que é. Boa variável nomeação torna inútil a notação húngara.

No entanto, às vezes você usaria a notação húngara, além de uma boa variável nomeação. m_numObjects possui dois prefixos: "m_ e num. M_ indica o escopo: é um membro de dados vinculado a isto. num indica qual o valor é.

Não me sinto prejudicado quando leio o código "bom", mesmo que ele contenha algum "húngaro". Certo: eu li o código, não clico nele. (Na verdade, eu dificilmente uso meu mouse de todos os tempos quando codifica, ou qualquer recurso de pesquisa específico de programação do vodu.)

Estou desacelerado quando leio coisas como m_ubscale (Sim, estou olhando para você, Liran!), como tenho que examinar seu uso (sem comentários!) Para descobrir o que ele escala (se é que existe?) E é o Datatype (que por acaso é um char de ponto fixo). Um nome melhor seria m_scalefactor ou m_zoomFactor, com um comentário como um número de ponto fixo, ou mesmo um typedef. (De fato, um typedef seria útil, pois existem vários outros membros de várias classes que usam o mesmo formato de ponto fixo. No entanto, alguns não, mas ainda são rotulados M_UBWHATH!

Eu acho que o húngaro deveria ser um aditivo ao nome da variável, não um substituto para informações. Além disso, muitas vezes a notação húngara não acrescenta nada à legibilidade da variável, desperdiçando bytes e tempo de leitura.

Apenas meus 2 ¢.

Uma pergunta muito antiga, mas aqui estão alguns prefixos "húngaros" que uso regularmente:

meu

para variáveis ​​locais, para distinguir a localidade onde o nome pode fazer sentido em um contexto global.Se você vir myFoo, ele será usado apenas nesta função, independentemente de qualquer outra coisa que fizermos com Foos em qualquer outro lugar.

myStart = GetTime();
doComplicatedOperations();
print (GetTime() - myStart);

e

tmp

para cópias temporárias de valores em loops ou operações de várias etapas.Se você vir duas variáveis ​​tmpFoo a mais de algumas linhas uma da outra, é quase certo que elas não estão relacionadas.

tmpX = X; 
tmpY = Y;
X = someCalc(tmpX, tmpY);
Y = otherCalc(tmpX, tmpY);

e às vezes velho e novo por razões semelhantes às tmp, geralmente em loops ou funções mais longos.

Eu só uso p como ponteiro e é isso.E isso só se eu estiver em C++.Em C# não uso nenhuma notação húngara.por exemplo.

MyClass myClass;
MyClass* pMyClass;

Isso é tudo :)

Editar: Ah, acabei de perceber que isso é mentira.Eu também uso "m_" para variáveis ​​de membro.por exemplo.

class
{
private:
bool m_myVar;
}

Bem, eu uso apenas com variáveis ​​de controle de janela.Eu uso btn_, txt_, lbl_ etc para identificá-los.Também acho útil procurar o nome do controle digitando seu tipo (btn_ etc).

Mas se você realmente precisa de algum motivo para não usá -lo, este é o meu favorito, extraído de Este ótimo link:

Eu me pego usando 'w', que significa 'trabalhando', como um prefixo em vez de 'temp' ou 'tmp', para variáveis ​​locais que existem apenas para movimentar dados, como:

Public Function ArrayFromDJRange(rangename As Range, slots As Integer) As Variant

' this function copies a Disjoint Range of specified size into a Variant Array 7/8/09 ljr

Dim j As Integer
Dim wArray As Variant
Dim rCell As Range

wArray = rangename.Value ' to initialize the working Array
ReDim wArray(0, slots - 1) ' set to size of range
j = 0

For Each rCell In rangename
    wArray(0, j) = rCell.Value
    j = j + 1
Next rCell

ArrayFromDJRange = wArray

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