Qual é o apelo da Systems Hungarian? [fechadas]

Em Quais diretrizes de nomenclatura você segue? , o autor diz:

Também prefiro codificar usando a notação húngara de Charles Simonyi.

Encontrei vários programadores que ainda preferem usar o húngaro, principalmente do tipo húngaro da Petzold / Systems. Pense dwLength = strlen(lpszName).

Eu li Fazer o código errado parecer errado e compreendo a lógica do Apps Hungarian, onde informações de tipo de domínio estão incluídas nos nomes das variáveis. Mas eu não entendo o valor em anexar o tipo de compilador ao nome.

Por que os programadores ainda persistem em usar esse estilo de notação? É apenas inércia? Existem benefícios que superam a diminuição da legibilidade? As pessoas simplesmente aprendem a ignorar os decoradores ao ler o código e, em caso afirmativo, como continuam agregando valor?

EDIT: Muitas respostas estão explicando a história, ou por que ela não é mais relevante, ambas abordadas no artigo que citei.

Eu realmente gostaria de ouvir alguém que ainda o usa. Por quê você usa isso? Está no seu padrão? Você usaria se não fosse necessário? Você usaria em um novo projeto? O que você vê como vantagens?

No momento, ainda uso o húngaro por exatamente três razões , evitando -o criteriosamente para todo o resto:

1. Ser consistente com uma base de código existente ao fazer manutenção.
2. Para controles, por exemplo. "txtFirstName". Geralmente, precisamos distinguir entre (digamos) "firstName" o valor e "firstName" o controle. O húngaro fornece uma maneira conveniente de fazer isso. É claro que eu poderia digitar "firstNameTextBox", mas "txtFirstName" é tão fácil de entender e possui menos caracteres. Além disso, o uso do húngaro significa que os controles do mesmo tipo são fáceis de encontrar e geralmente são agrupados por nome no IDE.
3. Quando duas variáveis ​​mantêm o mesmo valor, mas diferem por tipo. Por exemplo, "strValue" para o valor realmente digitado pelo usuário e "intValue" para o mesmo valor depois que ele tiver sido analisado como em número inteiro.

Eu certamente não gostaria de definir minhas idéias como uma prática recomendada, mas sigo essas regras porque a experiência me diz que o uso ocasional da manutenção de códigos de benefícios húngaros, mas custa pouco. Dito isso, reviso constantemente minha própria prática, portanto, pode muito bem fazer algo diferente à medida que minhas idéias se desenvolvem.

Atualizar:

Acabei de ler um artigo perspicaz de Eric Lippert, explicando como o húngaro pode ajudar a fazer com que o código errado pareça errado. Vale a pena ler.

Eu não sou um grande fã de usar notação húngara, mas penso assim:

• Também podemos notar que é mais rápido encontrar uma string referente a uma caixa de texto no seu código: digitando "txt" na sua caixa de pesquisa.

Não, imagine o contrário, onde cada elemento tem seu próprio nome. Pode ser mais lento para você descobrir para onde quer ir, certo?

O mesmo vale para ddl quando queremos nos referir a um DropDownList, é mais fácil ou não? :)

As pessoas não gastam muito tempo para descobrir onde está esse elemento.

O uso do prefixo não é utilizável para compiladores de linguagens modernas como C #, mas é utilizável (legível) para seres humanos.

O Apps Hungarian (tags para denotar propriedades semânticas de objetos que não podem ser expressos através do sistema de tipos) era uma maneira razoável de lidar com alguns erros comuns ao usar as linguagens de tipo fraco do início dos anos 80. Eles têm pouca finalidade nas linguagens fortemente tipadas de hoje.

Os sistemas húngaros (tags para denotar redundantemente o tipo declarado de um objeto) nunca serviram a nenhum propósito, exceto para impor uma aparência superficialmente uniforme em uma base de código. Foi criado e propagado por gerentes não técnicos e programadores inexperientes, que não entenderam a intenção do Apps Hungarian e acreditavam que a qualidade do código poderia ser aprimorada por diretrizes de codificação complexas.

Ambos os estilos tiveram origem na Microsoft. Atualmente, as convenções de nomenclatura da Microsoft dizem categoricamente "Não use a notação húngara".

Se você criar o sistema certo de prefixos, poderá espalhar o desgaste de suas chaves, o que reduziria os gastos com a substituição de teclados.

Suponho que eu poderia expandir isso. Eu tenho usado SH no meu local de trabalho nos últimos, oh, dez anos ou mais (porque está no nosso Padrão). Isso nunca ajudou a resolver um problema.

Por outro lado, usei variáveis ​​não adornadas, mas bem nomeadas, no meu 'código residencial' por quase o mesmo tempo. Eu nunca senti falta de SH.

Nos dois lugares, escrevi um código de protocolo que requer tipos primitivos de tamanho fixo. Este é o caso de uso mais benéfico em que posso pensar em SH. Não ajudou em nada que eu sei quando escrevi com SH e não me impediu quando escrevi sem SH.

Então, em conclusão, a única diferença que posso ver é o desgaste do seu teclado.

Na verdade, comecei a usar SH no novo código que escrevi este mês.

Minha tarefa envolveu reescrever algum código Perl em JS para que ele pudesse ser movido para o lado do cliente de nosso aplicativo da web. Em Perl, SH geralmente não é necessário devido a sigilos ($ string, @array,% hash).

No JavaScript, achei o SH inestimável para rastrear os tipos de estruturas de dados. Por exemplo,

var oRowData = aoTableData[iRow];

Isso recupera um objeto de uma matriz de objetos usando um índice inteiro. A adesão a essa convenção me salvou bastante tempo pesquisando os tipos de dados. Além disso, você pode sobrecarregar nomes de variáveis ​​sucintos ( oRowvs.iRow ).

tl; dr: SH pode ser ótimo quando você tem código complexo em uma linguagem de tipo fraco. Mas se o seu IDE puder rastrear tipos, prefira isso.

Também estou curioso para ver a lógica. Sabemos por que eles o usaram no passado: falta de suporte ao IDE para informações de tipo. Mas agora? Simplificando, acho que é uma tradição. O código C ++ sempre se parecia com isso, então por que mudar as coisas? Além disso, quando você constrói sobre o código anterior que usava a notação húngara, seria muito estranho quando você de repente parasse de usá-lo ...

A notação húngara de sistemas era, de fato, um pouco complicada, um mal-entendido do termo 'tipo'. Os desenvolvedores de sistemas tomaram literalmente o tipo de compilador (palavra, byte, string, ...) em oposição ao tipo de domínio dos aplicativos (índice de linha, índice de coluna, ...).

Mas acho que todo desenvolvedor passa por várias fases de estilo que parecem uma ótima ideia no momento (e o tipo de prefixo parece uma boa idéia para um iniciante) antes de cair nas armadilhas (mudar de tipo, criar novos prefixos significativos, etc). Então, acho que há uma inércia: de desenvolvedores que não melhoram e percebem por que é uma má escolha, de desenvolvedores presos a padrões de codificação que determinam a prática e de pessoas que usam <windows.h>. Seria muito caro para a Microsoft mudar para se livrar da notação de prefixo (que está incorreta em muitos lugares: WPARAM?).

Há uma coisa que falta às pessoas no húngaro. A notação húngara realmente funciona muito bem com o preenchimento automático.

Digamos que você tenha uma variável e o nome seja intHeightOfMonster.

Digamos que você esqueça o nome da variável

Poderia ser heightOfMonster ou MonsterHeight ou MeasurementMonsterHeight

Você deseja digitar uma letra e obter o preenchimento automático sugerindo alguns nomes de variáveis.

Sabendo que heightOfMonster é int, basta digitar i e voila.

Economizar tempo.