Bons exemplos da notação húngara?

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

Edit: I agree that Hungarian for types isn't that necessary, I'm hoping for more specific examples where it increases readability and maintainability, like Joel gives in his article (as per my answer).

16
Essa pergunta foi criada quando o Stack Overflow foi iniciado pela primeira vez e não é realmente o tipo de pergunta permitida hoje para este site. Ainda é um recurso útil e deve ser mantido por razões históricas e pelos sorteios que traz para o site.
adicionado o autor Lance Roberts, fonte

21 Respostas

O problema de pedir bons exemplos da notação húngara é que todos terão uma idéia do que é um bom exemplo. Minha opinião pessoal é que o melhor Notação húngara é não húngaro Notação . A notação foi originalmente destinada a denotar o uso pretendido de uma variável em vez de seu tipo, mas é geralmente usada para informações de tipo, particularmente para controles de formulário (por exemplo, txtFirstName para um texto caixa para o primeiro nome de alguém. Isso torna o código menos sustentável, em termos de legibilidade (por exemplo, "prepIn nounTerms prepOff nounReadability") e refatoração para quando o tipo precisa ser alterado (há "lParams" na API do Win32 que mudaram de tipo).

Você provavelmente deveria considerar não usá-lo em tudo. Exemplos:

  • strFirstName - this can just be firstName since it's obvious what it's for, the type isn't that important and should be obvious in this case. If not obvious, the IDE can help you with that.
  • txtFirstName - this can change to FirstNameTextBox or FirstName_TextBox. It reads better and you know it's a control and not just the text.
  • CAccount - C was used for class names in MFC but you really don't need it. Account is good enough. The uppercase name is the standard convention for types (and they only appear in specific places so they won't get confused with properties or methods)
  • ixArray (index to array) - ix is a bit obscure. Try arrayIndex.
  • usState (unsafe string for State) - looks like "U.S. State". Better go with state_UnsafeString or something. Maybe even wrap it in an UnsafeString class to at least make it type-safe.
37
adicionado
Eu concordo que devemos usá-lo para uso intencional, e é isso que eu espero que as pessoas contribuam, como para o meu próximo aplicativo eu gostaria de criar um padrão desde o início.
adicionado o autor Lance Roberts, fonte
Obrigado por todos os exemplos concretos.
adicionado o autor Lance Roberts, fonte
Se a notação húngara é usada consistentemente com sua intenção original de mostrar intenção , então tudo bem. Mas uma consistência tola é um hobgoblin das mentes dos jovens programadores.
adicionado o autor Mark Cidade, fonte
No PHP, nem todos os tipos são óbvios apenas a partir do nome da variável. Que tal um código de tipo de banco $ BankSortCode ? É "int" ou "string" porque tem hífens? A altura de um usuário $ UserHeight ? Poderia ser "int" se estiver em mm, mas e se for em pés/polegadas e for uma "string" para acomodar as palavras feet/inches , ou "', ou o ponto? Eu uso underscore com camelCase - $ int_BankSortCode , $ str_UserName , $ ary_TeamNames . Sua resposta não é realmente válida para atender para todas as l
adicionado o autor James, fonte
Vale a pena mencionar as Convenções Gerais de Nomenclatura no MSDN ( msdn.microsoft.com/en -us/library/ms229045.aspx ). Eles dizem "Não use a notação húngara".
adicionado o autor Fernando, fonte
Você pode fazer todos os tipos de argumentos que fazem com que certos benefícios das práticas de codificação pareçam supérfluos. Vamos pegar o CamelCase ... Por que precisamos diminuir o início da variável? Por que maiúsculas as próximas palavras? userName = UserName = nome de usuário, todos eles são tão fáceis de ler e entender. Consistência é fundamental quando você está usando convenções de codificação, isso é o mais importante, e sugerindo que a notação húngara é de alguma forma pior, é apenas ignorar que todas as convenções de codificação são válidas e úteis, se seguidas consistentemente.
adicionado o autor Mike, fonte
@ gutofb7: o seu link é para o .NET. Esta não é uma questão específica do .NET. Todos nós devemos entender por que essa recomendação foi feita (pense em "Janela de Definição de Código") antes de tentar aplicar esse argumento para todos os ambientes e idiomas. Há lugares onde AppHungarian corretamente usado é uma bênção, e todos os outros métodos mencionados aqui (hierarquias de classes, usando nomes extra longos, codificando informações de tipos lá) são inferiores a ele.
adicionado o autor Rom, fonte
O último ponto apresentado aqui é a primeira coisa que me veio à mente depois de ler o artigo original de Joel. Esse é um dos propósitos das hierarquias de classes, e usar convenções de nomenclatura para fazer isso não é o ideal.
adicionado o autor Nerdfest, fonte

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

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

27
adicionado

p

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

Húngaro para tipos de dados é um pouco ultrapassado agora IDEs pode dizer o que o tipo é (em apenas alguns segundos pairando sobre o nome da variável), por isso não é tão importante. Mas tratar um ponteiro como se seus dados não fossem bons, então você quer ter certeza de que é óbvio para o usuário o que ele é, mesmo que ele faça suposições que ele não deveria ao codificar.

16
adicionado
Eu concordo, embora eu ache muito melhor colocar _p no final. Isto torna as dereferências de ponteiro de estruturas muito mais fáceis de ler, por ex. some_struct_p-> some_member (e some_struct_p.some_member se destacaria como obviamente errado (no significado do artigo de Joel)).
adicionado o autor hlovdal, fonte
Eu também tive uma pergunta semelhante e cheguei a conclusões semelhantes. Escreva aqui [outono de 2014].
adicionado o autor Nick Alexeev, fonte
Sim, esta é a única vez que eu considero usar notação húngara também.
adicionado o autor cheduardo, fonte

t

Dados contaminados. Prefixe todos os dados recebidos de uma fonte não confiável para torná-la corrompida. Todos os dados contaminados devem ser limpos antes de qualquer trabalho real ser feito nele.

15
adicionado

Não use prefixos específicos de 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();)
...

Nós usamos o mesmo sistema para todos os idiomas:

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

É um salva-vidas.

6
adicionado
p como prefixo em linguagens que suportam ponteiros, mas não significam ponteiro ... assustador!
adicionado o autor Greg Beech, fonte
Nós não usamos mais ponteiros (se houver). Em nossa linha de trabalho, veja muitas taxas de juros (porcentagem) e não há ponteiros. A ideia, no entanto, é usar prefixos de idioma cruzado. Não são os prefixos específicos que contam. Escolha o seu.
adicionado o autor pkario, fonte
Eu uso enSomething para a variável que contém a enumeração.
adicionado o autor pkario, fonte
Eu uso enAlgo não apenas eSomething
adicionado o autor Guy Cohen, fonte

Eu acho que a notação húngara às vezes pode ser útil em linguagens dinâmicas. Eu estou pensando especificamente no ActionScript do lado do servidor (essencialmente apenas javascript), mas poderia se aplicar em outro lugar. Como não existe informação de tipo real, a notação húngara pode às vezes ajudar a tornar as coisas um pouco mais fáceis de entender.

5
adicionado

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

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

Você também pode entrar em problemas de ordem com a notação. Se você usa p para ponteiro e um endereço para, você chama sua variável apStreet ou paStreet? A legibilidade é diminuída quando você não tem consistência, e você tem que usar o espaço mental valioso quando precisar lembrar a ordem na qual você deve escrever a notação.

5
adicionado
A notação húngara não deve ser usada para tipos. Você está completamente correto lá. No entanto, a intenção original era usá-lo para coisas não especificadas por tipos, e há usos potenciais lá.
adicionado o autor David Thornley, fonte
Eu concordo que você não precisa usá-lo para todos os tipos, eu estou esperando por bons exemplos como Joel dá, onde aumenta a legibilidade e usabilidade.
adicionado o autor Lance Roberts, fonte

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

4
adicionado

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

Wrong by Joel Spolsky
http://www.joelonsoftware.com/articles/Wrong.html

Rediscovering Hungarian Notation
http://codingthriller.blogspot.com/2007/11/rediscovering-hungarian-notation.html

Acredito que a maioria dos pessimistas nunca tentou isso de verdade e não o entende verdadeiramente. Eu adoraria experimentar em um projeto real.

4
adicionado

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 o mouse' sobre uma variável com seu IDE e descobrir qual classe é, mas se você estiver paginando várias milhares de linhas de código, não precisará parar por alguns segundos - a cada .. .. único .... tempo ....

Lembre-se: você não está escrevendo o código apenas para você ou sua equipe. Você também está escrevendo para a pessoa que tem que pegar esse código daqui a dois ou cinco anos e aprimorá-lo.

4
adicionado
Invólucro de camelo e notação húngara são coisas diferentes. Camel Casing está apenas fazendo ThisWithYourNames (cada palavra começa com uma letra maiúscula). A notação húngara envolve a inserção de algum tipo de ID no nome.
adicionado o autor Herms, fonte
só é útil se você incluir uma legenda para os prefixos, caso contrário eles podem ser muito crípticos para um futuro leitor.
adicionado o autor Mark Cidade, fonte
Interessante. Eu estava originalmente sob a suposição de que eles eram os mesmos, porque sempre usamos os mesmos prefixos (str, int, dbl, obj, dat, etc) e isso foi em dois lugares diferentes.
adicionado o autor David, fonte

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

Um exemplo, do artigo, é codificado com strings não codificadas, não é que você deva usar 'us' húngaro para strings inseguras e 's' para strings seguras, é que você deve ter algum identificador para indica que uma string é segura ou não. Se se tornar padrão, torna-se fácil ver quando o padrão está sendo quebrado.

3
adicionado

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

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

2
adicionado

The name of the variable should describe what it is. Good variable naming makes Hungarian notation useless.

However, sometimes you'd use Hungarian notation in addition to good variable naming. m_numObjects has two "prefixes:" m_ and num. m_ indicates the scope: it's a data member tied to this. num indicates what the value is.

Eu não me sinto prejudicado quando leio código "bom", mesmo que ele contenha algum "húngaro". Direita: Eu li o código, não clico nele. (Na verdade, eu quase não uso meu mouse quando codifico, ou qualquer recurso específico de programação de voodoo).

I am slowed when I read things like m_ubScale (yes, I'm looking at you, Liran!), as I have to look at its usage (no comments!) to find out what it scales (if at all?) and it's datatype (which happens to be a fixed-point char). A better name would be m_scaleFactor or m_zoomFactor, with a comment as a fixed-point number, or even a typedef. (In fact, a typedef would be useful, as there are several other members of several classes which use the same fixed-point format. However, some don't, but are still labeled m_ubWhatever! Confusing, to say the least.)

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

Apenas meu 2 ¢.

2
adicionado

Além de usar 'p' para ponteiro, eu 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, ao invés de transmitir o tipo, o prefixo transmite o uso ou a intenção.

Eu admito, eu não uso o prefixo tão consistentemente quanto eu provavelmente deveria, mas eu gosto da idéia.

2
adicionado

Concordo que a notação húngara já não é particularmente útil. Eu pensei que sua intenção original era indicar não tipo de dados, mas sim 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 as variáveis ​​de cadeia local cusName, empName e usrName. Isso ajudaria a distinguir entre nomes de variáveis ​​de som similar. Os mesmos prefixos para as entidades seriam usados ​​em todo o aplicativo. No entanto, quando o OO é usado e você está lidando com objetos, esses prefixos são redundantes em Customer.Name, Employee.Name e User.Name.

2
adicionado
Ponto excelente lá.
adicionado o autor strager, fonte
não apenas datatype também o escopo .... :)
adicionado o autor Guy Cohen, fonte

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ê ver myFoo, ele é usado apenas nesta função, independentemente de qualquer outra coisa que fazemos 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ê ver duas variáveis ​​tmpFoo mais do que algumas linhas uma da outra, elas certamente não estão relacionadas.

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

esometimes old enew in for similar reasons to tmp, usually in longer loops or functions.

2
adicionado

m

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

2
adicionado

Eu só uso p para um 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 :)

Edit: Oh, I just realised that's a lie. I use "m_" for member variables too. e.g.

class
{
private:
bool m_myVar;
}
1
adicionado

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

1
adicionado

Eu me encontro usando 'w' significando 'working', como um prefixo ao invés de 'temp' ou 'tmp', para variáveis ​​locais que estão lá apenas para manipular 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
0
adicionado

Não existe um bom exemplo de notação húngara. Apenas não use. Nem mesmo se você estiver usando uma linguagem com tipagem fraca. Você vai viver mais feliz.

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

Um truque de acompanhamento na notação húngara é "alterar o tipo de uma variável, mas deixar o nome da variável inalterado". Isso é quase invariavelmente feito em aplicativos do Windows com a migração do Win16: - WndProc (HWND hW, WORD wMsg, WORD wParam, LONG lParam) para Win32 WndProc (HWND hW, UINT wMsg, WPARAM wParam, LPARAM lParam) onde a dica de valores de w que são palavras, mas elas realmente se referem a longs. O valor real dessa abordagem fica claro com a migração do Win64, quando os parâmetros terão 64 bits de largura, mas os antigos prefixos "w" e "l" permanecerão para sempre.

0
adicionado