Qual é o benefício de não usar a notação húngara?

Uma das coisas com as quais luto é não usar a notação húngara. Eu não quero ter que ir para a definição de variável apenas para ver que tipo é. Quando um projeto é extenso, é bom poder olhar para uma variável prefixada por 'bool' e saber que ele está procurando por true / false em vez de um valor 0/1 .

Eu também faço muito trabalho no SQL Server. Prefixo meus procedimentos armazenados com 'sp' e minhas tabelas com 'tbl', sem mencionar todas as minhas variáveis ​​no banco de dados, respectivamente.

Vejo em toda parte que ninguém realmente deseja usar a notação húngara, a ponto de evitá-la. Minha pergunta é: qual é o benefício de não usar a notação húngara e por que a maioria dos desenvolvedores evita isso como uma praga?

Como sua intenção original (consulte http://www.joelonsoftware.com/articles/Wrong.html e http://fplanque.net/Blog/devblog/2005/05/11/hungarian_notation_on_steroids ) foi mal compreendida e tem sido ( ab) usado para ajudar as pessoas a lembrarem que tipo de variável é quando o idioma usado não é estaticamente digitado. Em qualquer idioma estaticamente digitado, você não precisa do lastro adicional de prefixos para informar qual é o tipo de variável. Em muitas linguagens de script não tipadas, isso pode ajudar, mas muitas vezes foi abusado a ponto de se tornar totalmente pesado. Infelizmente, em vez de voltar à intenção original da notação húngara, as pessoas acabaram de transformá-lo em uma daquelas coisas "más" que você deve evitar.

A notação húngara, em suma, pretendia prefixar variáveis ​​com alguma semântica. Por exemplo, se você tiver coordenadas de tela (esquerda, superior, direita, inferior), prefixaria variáveis ​​com posições absolutas na tela com " abs" e variáveis ​​com posições relativas a uma janela com " rel". Dessa forma, seria óbvio para qualquer leitor quando você passasse uma coordenada relativa para um método que requer posições absolutas.

update (em resposta ao comentário de delnan)

IMHO a versão abusada deve ser evitada como uma praga porque:

• complica a nomeação. Quando (ab) usar a notação húngara, sempre haverá discussões sobre quão específicos os prefixos precisam ser. Por exemplo: listboxXYZou MyParticularFlavourListBoxXYZ.
• torna os nomes das variáveis ​​mais longos sem ajudar no entendimento do objetivo da variável.
• isso meio que derrota o objeto do exercício quando, para evitar prefixos longos, eles são encurtados para abreviações e você precisa de um dicionário para saber o que significa cada abreviação. É um uinúmero inteiro não assinado? uma interface contada não referenciada? algo a ver com interfaces de usuário? E essas coisas podem demorar . Vi prefixos de mais de 15 caracteres aparentemente aleatórios que deveriam transmitir o tipo exato de var, mas realmente apenas mistificar.
• fica desatualizado rapidamente. Quando você altera o tipo de uma variável, as pessoas invariavelmente (lol) esquecem de atualizar o prefixo para refletir a alteração ou, deliberadamente, não atualizam, porque isso acionaria alterações de código em todos os locais em que o var é usado ...
• complica falar sobre código porque como "@g". disse: Nomes variáveis ​​com notação húngara são tipicamente difíceis de pronunciar sopa de letrinhas. Isso inibe a legibilidade e a discussão do código, porque você não pode 'dizer' nenhum dos nomes.
• ... muito mais do que não me lembro no momento. Talvez porque tenha tido o prazer de não ter que lidar com a notação húngara abusada por um longo tempo ...

A notação húngara é um anti-padrão de nomeação nos ambientes de programação modernos e na forma de Tautologia .

Repete inutilmente informações sem benefícios e despesas adicionais de manutenção. O que acontece quando você muda intpara um tipo diferente long, agora você precisa pesquisar e substituir toda a sua base de códigos para renomear todas as variáveis ​​ou elas agora estão semanticamente erradas, o que é pior do que se você não tivesse duplicado o tipo no nome.

Viola o princípio DRY. Se você precisar prefixar suas tabelas de banco de dados com uma abreviação para lembrá-lo de que é uma tabela, você definitivamente não estará nomeando suas tabelas semanticamente descritivamente. O mesmo vale para todas as outras coisas com as quais você está fazendo isso. É apenas uma digitação extra e trabalha sem ganho ou benefício com um ambiente de desenvolvimento moderno.

A Wikipedia tem uma lista de vantagens e desvantagens da notação húngara e, portanto, provavelmente pode fornecer a resposta mais abrangente para essa pergunta. As opiniões notáveis também são uma leitura bastante interessante.

O benefício de não usar a notação húngara é basicamente apenas evitar suas desvantagens:

• A notação húngara é redundante quando a verificação de tipo é feita pelo compilador. Compiladores para idiomas que fornecem verificação de tipo garantem que o uso de uma variável seja consistente com seu tipo automaticamente; as verificações oculares são redundantes e estão sujeitas a erros humanos.

• Todos os ambientes modernos de desenvolvimento integrado exibem tipos variáveis ​​sob demanda e sinalizam automaticamente operações que usam tipos incompatíveis, tornando a notação amplamente obsoleta.

• A notação húngara se torna confusa quando é usada para representar várias propriedades, como em a_crszkvc30LastNameCol: um argumento de referência constante, mantendo o conteúdo de uma coluna LastNamedo banco de dados do tipo varchar(30)que faz parte da chave primária da tabela.

• Isso pode levar a inconsistência quando o código é modificado ou portado. Se o tipo de uma variável for alterado, a decoração no nome da variável será inconsistente com o novo tipo ou o nome da variável deverá ser alterado. Um exemplo particularmente conhecido é o WPARAMtipo padrão e o wParamparâmetro formal associado em muitas declarações de função do sistema Windows. O 'w' significa 'word', onde 'word' é o tamanho da palavra nativa da arquitetura de hardware da plataforma. Era originalmente um tipo de 16 bits em arquiteturas de palavras de 16 bits, mas foi alterado para 32 bits em arquiteturas de palavras de 32 bits ou de 64 bits em arquiteturas de palavras de 64 bits em versões posteriores do sistema operacional, mantendo seu nome original (seu verdadeiro tipo subjacente éUINT_PTR, ou seja, um número inteiro não assinado, grande o suficiente para conter um ponteiro). A impedância semântica e, portanto, a confusão e a inconsistência do programador de plataforma para plataforma, pressupõem que 'w' representa 16 bits nesses diferentes ambientes.

• Na maioria das vezes, conhecer o uso de uma variável implica conhecer seu tipo. Além disso, se o uso de uma variável não for conhecido, não poderá ser deduzido do seu tipo.

• A notação húngara reduz fortemente os benefícios do uso de editores de código ricos em recursos que suportam a conclusão de nomes de variáveis, pois o programador deve inserir primeiro o especificador de tipo inteiro.

• Torna o código menos legível, ofuscando a finalidade da variável com prefixos de tipo e escopo desnecessários.

• As informações de tipo adicionais podem substituir insuficientemente nomes mais descritivos. Por exemplo sDatabase, não diz ao leitor o que é. databaseNamepode ser um nome mais descritivo.

• Quando os nomes são suficientemente descritivos, as informações adicionais do tipo podem ser redundantes. Por exemplo, firstNameé mais provável que seja uma string. Portanto, nomeá-lo sFirstNameapenas adiciona confusão ao código.

Eu mesmo não uso essa notação, porque não gosto do ruído técnico desnecessário. Quase sempre sei com qual tipo estou lidando e quero uma linguagem limpa no meu modelo de domínio, mas escrevo principalmente em linguagens estáticas e com tipos fortes.

Como um problema específico do MS SQL Server:

Qualquer procedimento armazenado com o prefixo 'sp_' é pesquisado primeiro no banco de dados mestre e não no que ele é criado. Isso causará um atraso no procedimento armazenado que está sendo executado.

O IMO, o maior benefício de não usar o húngaro, é o fato de obriga a usar nomes significativos . Se você estiver nomeando as variáveis ​​corretamente, deve saber imediatamente que tipo é ou pode deduzi-las rapidamente em qualquer sistema bem projetado. Se você precisa confiar em strou blnou pior de todos os objprefixos para saber que tipo de uma variável é, eu diria que indica um problema de nomenclatura - ou nomes de variáveis pobres em geral ou demasiado genérico para transmitir um significado.

Ironicamente, por experiência pessoal, o cenário principal que vi húngaro é a programação de "cult de carga" (ou seja, outro código a usa, então vamos continuar a usá-la apenas porque) ou no VB.NET para solucionar o fato de que a linguagem é diferencia maiúsculas de minúsculas (por exemplo, Person oPerson = new Personporque você não pode usar Person person = new Persone Person p = new Personé muito vago); Também vi prefixar "the" ou "my" (nesse caso Person thePerson = new Personou mais feio Person myPerson = new Person), nesse caso específico.

Acrescentarei que a única vez em que uso o húngaro tende a ser para controles do ASP.NET, e isso é realmente uma questão de escolha. Acho muito feio digitar TextBoxCustomerNameou não CustomerNameTextBoxo mais simples txtCustomerName, mas até isso parece "sujo". Sinto que algum tipo de convenção de nomenclatura deve ser usada para controles, pois pode haver vários controles que exibem os mesmos dados.

Vou me concentrar no SQL Server desde que você mencionou. Não vejo razão para colocar 'tbl' na frente de uma mesa. Você pode simplesmente olhar para qualquer código tSQL e distinguir uma tabela pela maneira como ela é usada. Você nunca iria Select from stored_procedure.ou Select from table(with_param)como se fosse uma UDF ou Execute tblTableOrViewNamecomo um procedimento armazenado.

As tabelas podem ser confundidas com uma View, mas quando se trata de como elas são usadas; não há diferença, então qual é o objetivo? A notação húngara pode poupar seu tempo de procurá-la no SSMS (sob tabela ou visualizações?), Mas é isso.

As variáveis ​​podem apresentar um problema, mas precisam ser declaradas e, realmente, a que distância de sua declaração de declaração você planeja usar uma variável? Rolar algumas linhas não deve ser tão importante, a menos que você esteja escrevendo procedimentos muito longos. Pode ser uma boa idéia dividir um pouco o código extenso.

O que você descreve é ​​uma dor, mas a solução da notação húngara não resolve realmente o problema. Você pode olhar o código de outra pessoa e descobrir que o tipo de variável pode ser alterado, o que agora exige uma alteração no nome da variável. Apenas mais uma coisa para esquecer. E se eu usar um VarChar, você precisará examinar a declaração de qualquer maneira para saber o tamanho. Os nomes descritivos provavelmente o levarão mais longe. @PayPeriodStartDate se explica bastante.

Outra coisa a acrescentar é que, quais abreviações você usaria para uma estrutura inteira como o .NET? Sim, é tão simples lembrar que isso btnrepresenta um botão e txtuma caixa de texto. No entanto, o que você tem em mente para algo assim StringBuilder? strbld? Que tal CompositeWebControl? Você usa algo como isto:

CompositeWebControl comWCMyControl = new CompositeWebControl();

Uma das ineficiências da notação húngara era que, por ter estruturas cada vez maiores, provou não apenas adicionar benefícios extras, mas também adicionar mais complexidade aos desenvolvedores, porque agora eles precisavam aprender os prefixos não padronizados cada vez mais.

Para o meu modo de ver as coisas, a notação húngara é uma ilusão para contornar um sistema de tipos insuficientemente poderoso. Nas linguagens que permitem definir seus próprios tipos, é relativamente trivial criar um novo tipo que codifique o comportamento esperado. No discurso de Joel Spolsky sobre notação húngara, ele fornece um exemplo de como usá-lo para detectar possíveis ataques XSS, indicando que uma variável ou função é insegura (nós) ou segura (s), mas que ainda depende do programador para verificar visualmente. Se você possui um sistema de tipos extensível, basta criar dois novos tipos, UnsafeString e SafeString, e usá-los conforme apropriado. Como bônus, o tipo de codificação se torna:

SafeString encode(UnsafeString)

e não acessar as partes internas do UnsafeString ou usar outras funções de conversão torna-se a única maneira de passar de um UnsafeString para um SafeString. Se todas as suas funções de saída tiverem apenas instâncias do SafeString, torna-se impossível gerar uma string não escapada [descobrindo travessuras com conversões como StringToSafeString (someUnsafeString.ToString ())].

Deveria ser óbvio por que permitir que o sistema de tipos verifique corretamente seu código é superior a tentar fazê-lo manualmente, ou talvez esteja de olho nesse caso.

Em um idioma como C, é claro, você está convencido de que int é int e é int, e não há muito o que fazer sobre isso. Você sempre pode jogar com estruturas, mas é discutível se isso é uma melhoria ou não.

Quanto à outra interpretação da notação húngara, o IE prefixa o tipo da variável, isso é estúpido e incentiva práticas preguiçosas como nomear variáveis ​​uivxwFoo em vez de algo significativo como countOfPeople.

A notação húngara é quase completamente inútil em um idioma estaticamente tipado. É um recurso básico do IDE para mostrar o tipo de uma variável colocando o mouse sobre ela ou por outros meios; além disso, você pode ver qual é o tipo procurando algumas linhas onde foi declarado, se não houver inferência de tipo. O ponto principal da inferência de tipo é não repetir o ruído do tipo em todos os lugares; portanto, a notação húngara é geralmente vista como algo ruim em idiomas com inferência de tipo.

Em linguagens de tipo dinâmico, às vezes pode ajudar, mas para mim parece unidiomatic. Você já deixou suas funções restritas a domínios / codomains exatos; se todas as suas variáveis ​​são nomeadas com notação húngara, você está apenas reproduzindo o que um sistema de tipos teria lhe dado. Como você expressa uma variável polimórfica que pode ser um número inteiro ou uma string na notação húngara? "IntStringX"? "IntOrStringX"? O único lugar que eu já usei notação húngara foi no código de montagem, porque eu estava tentando recuperar o que obteria se tivesse um sistema de tipos e foi a primeira coisa que já codifiquei.

De qualquer forma, eu poderia me importar menos com o que as pessoas denominam suas variáveis, o código provavelmente ainda será incompreensível. Os desenvolvedores perdem muito tempo com coisas como estilo e nomes de variáveis ​​e, no final do dia, você ainda recebe uma tonelada de bibliotecas com convenções completamente diferentes no seu idioma. Estou desenvolvendo uma linguagem simbólica (ou seja: não baseada em texto) em que não há nomes de variáveis, apenas identificadores exclusivos e nomes sugeridos para variáveis ​​(mas a maioria das variáveis ​​ainda não tem nome sugerido porque simplesmente não existe um nome razoável para eles); ao auditar código não confiável, você não pode depender de nomes de variáveis.

Como sempre, nesse caso, postarei uma resposta antes de ler as respostas de outros participantes. 

Eu vejo três "bugs" em sua visão: 

1) Se você deseja conhecer o tipo de uma variável / parâmetro / atributo / coluna, pode passar o mouse ou clicar nele e ele será exibido, na maioria dos IDE modernos. Não sei quais ferramentas você está usando, mas a última vez que fui forçado a trabalhar em um ambiente que não fornecia esse recurso foi no século 20, a linguagem era COBOL, oops, não, era Fortran e meu chefe não entendi porque eu fui embora. 

2 / Os tipos podem mudar durante o ciclo de desenvolvimento. Um número inteiro de 32 bits pode se tornar um número inteiro de 64 bits em algum momento, por boas razões que não foram detectadas no início do projeto. Portanto, renomear intX para longX ou deixá-lo com um nome que aponte para o tipo errado é um karma ruim. 

3) O que você está pedindo é de fato uma redundância. Redundância não é um padrão ou hábito de design muito bom. Até os humanos relutam em muita redundância. Até os humanos relutam em muita redundância. 

Eu acredito que estar em extrema necessidade de húngaro é um sintoma .
Um sintoma de muitas variáveis ​​globais ... ou de ter funções muito longas para serem sustentáveis .

Se sua definição de variável não estiver à vista, normalmente você terá problemas.
E se suas funções não seguem alguma convenção memorável , novamente há um grande problema.

Essa é ... praticamente a razão pela qual muitos locais de trabalho o resolvem, suponho.

Originou-se nos idiomas que precisavam .
Em tempos de bonança global de variáveis . (por falta de alternativas)
Isso nos serviu bem.

O único uso real que temos para ele hoje é o Joel Spolsky um .
Para rastrear alguns atributos particulares da variável, como sua segurança .

( por exemplo, "A variável safeFoobarpossui uma luz verde para ser injetada em uma consulta SQL?
- Como é chamada safe, sim")

Algumas outras respostas falaram sobre as funcionalidades do editor que ajudaram a ver o tipo de uma variável à medida que você passa o mouse sobre ela. Na minha opinião, esses também são problemáticos para a sanidade do código . Eu acredito que eles foram feitos apenas para refatoração , como muitos outros recursos (como dobrar funções) e não devem ser usados ​​em novos códigos.

Acho que as razões para não usar a notação húngara foram bem cobertas por outros pôsteres. Eu concordo com os comentários deles.

Com bancos de dados, eu uso a notação húngara para objetos DDL que raramente são usados ​​no código, mas que, de outra forma, colidiriam nos espaços para nome. Principalmente, isso se resume a prefixar índices e restrições nomeadas com seu tipo (PK, UK, FK e IN). Use um método consistente para nomear esses objetos e você poderá executar algumas validações consultando os metadados.

o motivo é evitado por causa de sistemas húngaros que violam DRY (o prefixo é exatamente o tipo que o compilador e (um bom) IDE podem derivar)

os aplicativos húngaros OTOH prefixam com o uso da variável (por exemplo, scrxMouse é uma coordenada axial na tela, pode ser um tipo int, curto, longo ou até um tipo personalizado (typedefs permitirá que você a altere facilmente))

o mal-entendido dos sistemas é o que destruiu o húngaro como uma prática recomendada

Digamos que temos um método como este (em C #):

int GetCustomerCount()
{
    // some code
}

Agora, no código, chamamos assim:

var intStuff = GetCustomerCount();
// lots of code that culminates in adding a customer
intStuff++;

O int não nos diz muito. O simples fato de algo ser um int não nos diz o que há nele. Agora vamos supor, em vez disso, chamamos assim:

var customerCount = GetCustomerCount();
// lots of code that culminates in adding a customer
customerCount++;

Agora podemos ver qual é o objetivo da variável. Importa se sabemos que é um int?

O objetivo original do húngaro, porém, era fazer com que você fizesse algo assim:

var cCustomers = GetCustomerCount();
// lots of code that culminates in adding a customer
cCustomers++;

Tudo bem, desde que você saiba o que c significa. Mas você teria que ter uma tabela padrão de prefixos, e todos precisariam conhecê-los, e qualquer pessoa nova precisaria aprendê-los para entender seu código. Considerando que customerCountou countOfCustomersé bastante óbvio à primeira vista.

O húngaro tinha algum objetivo no VB antes de Option Strict Onexistir, porque no VB6 e anterior (e no VB .NET com Option Strict Off) o VB coagiria tipos, portanto, você pode fazer isso:

Dim someText As String = "5"
customerCount = customerCount + someText

Isso é ruim, mas o compilador não diria isso. Então, se você usasse húngaro, pelo menos teria algum indicador do que estava acontecendo:

Dim strSomeText As String = "5"
intCustomerCount = intCustomerCount + strSomeText  // that doesn't look right!

No .NET, com digitação estática, isso não é necessário. E o húngaro era frequentemente usado como substituto de uma boa nomeação. Esqueça o húngaro e escolha bons nomes.

Encontrei muitos argumentos bons contra, mas um que não vi: ergonomia.

Antigamente, quando tudo que você tinha era string, int, bool e float, os caracteres sibf seriam suficientes. Mas com string + short, os problemas começam. Use o nome inteiro para o prefixo ou str_name para a string? (Embora os nomes quase sempre sejam strings - não são?) O que há com uma classe de rua? Os nomes ficam cada vez mais longos, e mesmo se você usar o CamelCase, é difícil dizer onde termina o prefixo do tipo e onde começa o nome da variável.

 BorderLayout boderLayoutInnerPanel = new BorderLayout ();
 panelInner.addLayout (borderLayoutInnerPanel);

Tudo bem - você pode usar sublinhados, se já não os usar para outra coisa, ou usar o CamelCase se você usou sublinhados por tanto tempo:

 BorderLayout boderLayout_innerPanel = new BorderLayout ();
 panel_inner.addLayout (borderLayout_innerPanel);

 Border_layout boder_layoutInner_panel = new Border_layout ();
 panelInner.add_layout (border_layoutInner_panel);

É monstruoso e, se você fizer isso consequentemente, terá

 for (int iI = 0; iI < iMax-1; ++iI)
     for (int iJ = iI; iJ < iMax; ++iMax) 
          int iCount += foo (iI, iJ); 

Você terminará usando prefixos inúteis para casos triviais, como variáveis ​​de loop ou count. Quando você usou recentemente um curto ou um longo para um contador? Se você fizer exceções, muitas vezes perderá tempo, pensando em precisar de um prefixo ou não.

Se você possui muitas variáveis, elas normalmente são agrupadas em um navegador de objetos que faz parte do seu IDE. Agora, se 40% começam com i_ para int e 40% com s_ para string, e eles são classificados em ordem alfabética, é difícil encontrar a parte significativa do nome.

O único lugar em que ainda uso regularmente sufixos húngaros ou análogos é em contextos em que os mesmos dados semânticos estão presentes de duas formas diferentes, como a conversão de dados. Isso pode ocorrer nos casos em que existem várias unidades de medida ou em várias formas (por exemplo, String "123" e número inteiro 123).

Acho as razões aqui apresentadas para não usá-lo convincente por não impor o húngaro a outros, mas apenas levemente sugestivo, para decidir sobre sua própria prática.

O código fonte de um programa é uma interface de usuário por si só - exibindo algoritmos e metadados para o mantenedor - e a redundância nas interfaces de usuário é uma virtude, não um pecado . Veja, por exemplo, as imagens em " O design das coisas cotidianas " e veja as portas rotuladas "Push" que parecem com você puxá-las e as torneiras de cerveja que os operadores invadiram os importantes controles do reator nuclear porque de alguma forma "pairando sobre eles no IDE "não era bom o suficiente.

O "apenas pairar em um IDE" não é um motivo para não usar o húngaro - apenas um motivo pelo qual algumas pessoas podem não achar útil. Sua milhagem pode ser diferente.

A idéia de que o húngaro impõe uma carga significativa de manutenção quando os tipos de variáveis ​​mudam é tola - com que frequência você muda os tipos de variáveis? Além disso, renomear variáveis ​​é fácil:

Basta usar o IDE para renomear todas as ocorrências. -Gander, respondendo a Goose

Se o húngaro realmente ajudar você a inserir rapidamente um pedaço de código e a mantê-lo de forma confiável, use-o. Se não, não. Se outras pessoas lhe disserem que você está errado em relação à sua própria experiência, sugiro que provavelmente elas estejam erradas.