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

95

Uma das coisas com que tenho dificuldade é não usar a notação húngara. Eu não quero ter que ir para a definição da 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 0/1 valor.

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.

Eu vejo em toda parte que ninguém realmente quer 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 a evita como uma praga?

    
por 5 revs, 3 users 62%user29981 21.08.2011 / 22:01
fonte

16 respostas

141

Porque sua intenção original (veja link e link ) foi mal interpretado e tem sido (ab) usado para ajudar as pessoas a lembrar que tipo é uma variável quando a linguagem que eles usam não é estaticamente digitada. Em qualquer linguagem com tipagem estática, você não precisa do lastro adicional de prefixos para informar que tipo de variável é. Em muitas linguagens de script não tipificadas, isso pode ajudar, mas muitas vezes foi abusado a ponto de se tornar totalmente complicado. Infelizmente, em vez de voltarem à intenção original da notação húngara, as pessoas acabaram de chegar a uma daquelas coisas "malignas" 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), prefixa variáveis com posições de tela absolutas 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 exigisse posições absolutas.

atualização (em resposta ao comentário de delnan)

IMHO a versão abusada é evitada como a peste porque

  • complica a nomeação. Quando (ab) usando a notação húngara, sempre haverá discussões sobre a especificidade dos prefixos. Por exemplo: listboxXYZ ou MyParticularFlavourListBoxXYZ .
  • faz com que os nomes das variáveis sejam mais longos sem ajudar no entendimento do que é a variável.
  • é uma espécie de derrota do objeto do exercício quando, a fim de evitar prefixos longos, eles são abreviados para abreviações e você precisa de um dicionário para saber o que cada abreviação significa. Um ui é um inteiro não assinado? uma interface contada não referenciada? algo a ver com interfaces de usuário? E essas coisas podem ficar longas . Eu tenho visto prefixos de mais de 15 caracteres aparentemente aleatórios que deveriam transmitir o tipo exato do var, mas na verdade apenas mistificam.
  • fica desatualizado rapidamente. Quando você muda o tipo de uma variável, invariavelmente, pessoas (lol) esquecem de atualizar o prefixo para refletir a mudança ou deliberadamente não o atualizam, porque isso acionaria mudanças de código em todos os lugares em que o var fosse usado ...
  • complica falando sobre código porque como "@g." disse: Os nomes de 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 que não consigo lembrar no momento. Talvez porque eu tenha tido o prazer de não ter que lidar com a maldita notação húngara por um longo tempo ...
por 17.04.2012 / 16:38
fonte
72

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

Repete inutilmente informações sem benefício e sobrecarga adicional de manutenção. O que acontece quando você muda seu int para um tipo diferente como long , agora você precisa procurar e substituir toda a sua base de código para renomear todas as variáveis ou elas 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, então você definitivamente não está nomeando suas tabelas semanticamente de forma descritiva o suficiente. O mesmo vale para todas as outras coisas com as quais você está fazendo isso. É apenas uma digitação extra e funciona sem ganho ou benefício com um ambiente de desenvolvimento moderno.

    
por 21.08.2011 / 18:48
fonte
51

Wikipedia tem uma lista de vantagens e desvantagens da notação húngara e pode, portanto, fornecer a resposta mais abrangente a esta questão. 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:

  • The Hungarian notation is redundant when type-checking is done by the compiler. Compilers for languages providing type-checking ensure the usage of a variable is consistent with its type automatically; checks by eye are redundant and subject to human error.

  • All modern Integrated development environments display variable types on demand, and automatically flag operations which use incompatible types, making the notation largely obsolete.

  • Hungarian Notation becomes confusing when it is used to represent several properties, as in a_crszkvc30LastNameCol: a constant reference argument, holding the contents of a database column LastName of type varchar(30) which is part of the table's primary key.

  • It may lead to inconsistency when code is modified or ported. If a variable's type is changed, either the decoration on the name of the variable will be inconsistent with the new type, or the variable's name must be changed. A particularly well known example is the standard WPARAM type, and the accompanying wParam formal parameter in many Windows system function declarations. The 'w' stands for 'word', where 'word' is the native word size of the platform's hardware architecture. It was originally a 16 bit type on 16-bit word architectures, but was changed to a 32-bit on 32-bit word architectures, or 64-bit type on 64-bit word architectures in later versions of the operating system while retaining its original name (its true underlying type is UINT_PTR, that is, an unsigned integer large enough to hold a pointer). The semantic impedance, and hence programmer confusion and inconsistency from platform-to-platform, is on the assumption that 'w' stands for 16-bit in those different environments.

  • Most of the time, knowing the use of a variable implies knowing its type. Furthermore, if the usage of a variable is not known, it can't be deduced from its type.

  • Hungarian notation strongly reduces the benefits of using feature-rich code editors that support completion on variable names, for the programmer has to input the whole type specifier first.

  • It makes code less readable, by obfuscating the purpose of the variable with needless type and scoping prefixes.

  • The additional type information can insufficiently replace more descriptive names. E.g. sDatabase doesn't tell the reader what it is. databaseName might be a more descriptive name.

  • When names are sufficiently descriptive, the additional type information can be redundant. E.g. firstName is most likely a string. So naming it sFirstName only adds clutter to the code.

Eu mesmo não uso essa notação, porque não gosto do ruído técnico desnecessário. Eu quase sempre sei com qual tipo estou lidando e quero uma linguagem limpa em meu modelo de domínio, mas escrevo principalmente em idiomas estaticamente e strongmente tipados.

    
por 22.08.2011 / 15:36
fonte
19

Como um problema específico do MS SQL Server:

Any stored procedures prefixed with 'sp_' are first searched for in the Master database rather than the one it is created in. This will cause a delay in the stored procedure being executed.

    
por 21.08.2011 / 19:44
fonte
15

IMO, o maior benefício de não usar o húngaro é o fato de ele forçar você a usar nomes significativos . Se você está nomeando variáveis corretamente, você deve saber imediatamente que tipo é ou ser capaz de deduzi-lo rapidamente em qualquer sistema bem projetado. Se você precisar confiar em str ou bln ou pior de todos os prefixos obj para saber que tipo é uma variável, eu diria que indica um problema de nomenclatura - ou nomes de variáveis ruins em geral ou muito genéricos para transmitir significado.

Ironicamente, por experiência pessoal, o cenário principal que eu vi o húngaro usado é a programação "carga-cult" (ou seja, outro código usa, então vamos continuar a usá-lo apenas porque) ou em VB.NET para contornar o fato o idioma não faz distinção entre maiúsculas e minúsculas (por exemplo, Person oPerson = new Person porque você não pode usar Person person = new Person e Person p = new Person é muito vago); Eu também vi o prefixo "o" ou "meu" em vez disso (como em Person thePerson = new Person ou o mais feio Person myPerson = new Person ), nesse caso em particular.

Eu adicionarei o tempo somente que eu uso húngaro tende a ser para controles ASP.NET e isso é realmente uma questão de escolha. Eu acho muito feio digitar TextBoxCustomerName ou CustomerNameTextBox versus o mais simples txtCustomerName , mas mesmo isso parece "sujo". Eu 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.

    
por 22.08.2011 / 15:15
fonte
13

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

Tabelas podem ser confundidas com um modo de exibição, 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-lhe tempo de consultá-lo no SSMS (sob a tabela ou as visualizações?), Mas isso é tudo.

As variáveis podem representar um problema, mas precisam ser declaradas e, na verdade, a que distância de sua instrução de declaração você planeja usar uma variável? A rolagem de algumas linhas não deve ser um grande negócio, a menos que você esteja escrevendo procedimentos muito longos. Pode ser uma boa ideia quebrar um pouco o longo código.

O que você descreve é uma dor, mas a solução de notação húngara não resolve realmente o problema. Você pode olhar para o código de outra pessoa e descobrir que o tipo de variável pode ser alterado, o que agora requer uma mudança no nome da variável. Só mais uma coisa para esquecer. E se eu usar um VarChar, você vai precisar olhar a declaração de declaração de qualquer maneira para saber o tamanho. Nomes descritivos provavelmente irão levá-lo adiante. @PayPeriodStartDate praticamente se explica.

    
por 21.08.2011 / 19:11
fonte
6

Outra coisa a acrescentar é que, que abreviaturas você usaria para um framework inteiro como o .NET? Sim, é tão simples lembrar que btn representa um botão e txt representa uma caixa de texto. No entanto, o que você tem em mente para algo como StringBuilder ? %código%? E quanto a strbld ? Você usa algo assim:

CompositeWebControl comWCMyControl = new CompositeWebControl();

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

    
por 21.08.2011 / 22:57
fonte
6

Para minha maneira de ver as coisas, a notação húngara é uma desculpa para contornar um sistema de tipos insuficientemente poderoso. Em linguagens que permitem que você defina seus próprios tipos, é relativamente trivial criar um novo tipo que codifica o comportamento esperado. No discurso de Joel Spolsky sobre a notação húngara, ele dá um exemplo de uso 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ê tiver 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 curto de acessar os internos do UnsafeString ou usando algumas outras funções de conversão se torna a única maneira de ir de um UnsafeString para um SafeString. Se todas as suas funções de saída, em seguida, tomar apenas instâncias de SafeString, torna-se impossível a saída de uma string un-escaped [baring shenanigans com conversões como StringToSafeString (someUnsafeString.ToString ())].

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

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

Quanto à outra interpretação da notação húngara, I.E. prefixando com o tipo da variável, isso é simplesmente estúpido e encoraja práticas preguiçosas como nomear variáveis uivxwFoo em vez de algo significativo como countOfPeople.

    
por 22.08.2011 / 20:17
fonte
4

A notação húngara é quase completamente inútil em uma linguagem de tipagem estática. É um recurso IDE básico 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, olhando algumas linhas até onde foi declarado, se não houver inferência de tipos. O ponto principal da inferência de tipos é não ter o ruído do tipo repetido em todos os lugares, então a notação húngara é geralmente vista como algo ruim em linguagens com inferência de tipos.

Em idiomas dinamicamente tipificados, pode ajudar algumas vezes, mas para mim parece não-idiomático. Você já desistiu de suas funções sendo restritas a domínios / codomains exatos; se todas as variáveis forem nomeadas com notação húngara, você estará apenas reproduzindo o que um sistema de tipos teria dado a você. Como você expressa uma variável polimórfica que pode ser um inteiro ou uma string na notação húngara? "IntStringX"? "IntOrStringX"? O único lugar em que eu já usei a notação húngara foi em código assembly, porque eu estava tentando recuperar o que recebia se tivesse um sistema de tipos, e foi a primeira coisa que eu já codifiquei.

De qualquer forma, eu poderia me importar menos com o nome das variáveis, o código provavelmente será tão incompreensível. Os desenvolvedores perdem muito tempo com coisas como nomes de estilo e variáveis, e no final do dia você ainda recebe uma tonelada de bibliotecas com convenções completamente diferentes em seu idioma. Estou desenvolvendo uma linguagem simbólica (ou seja: não baseada em texto) onde 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 existe simplesmente não existe um nome razoável para eles); quando auditando código não confiável, você não pode depender de nomes de variáveis.

    
por 21.08.2011 / 22:48
fonte
3

Como de costume, nesse caso, vou postar uma resposta antes de ler as respostas de outros participantes.

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

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

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

3) O que você está pedindo é, na verdade, uma redundância. Redundância não é um padrão de design ou hábito muito bom. Até os seres humanos estão relutantes em demasiada redundância. Até os seres humanos estão relutantes em demasiada redundância.

    
por 22.08.2011 / 01:38
fonte
3

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 mantidas .

Se a sua definição de variável não está à vista, geralmente você tem problemas.
E se suas funções não seguirem alguma convenção memorável , haverá novamente um grande problema.

Isso é ... mais ou menos a razão pela qual muitos locais de trabalho se esgotam, suponho.

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

O único uso real que temos hoje é o Joel Spolsky

Para rastrear alguns atributos particulares da variável, como sua segurança .

( por exemplo. “A variável safeFoobar tem uma luz verde para ser injetada em uma consulta SQL?
- Como é chamado safe , sim ”)

Algumas outras respostas falaram sobre as funcionalidades do editor que ajudaram a ver o tipo de variável conforme você passa. Na minha opinião, esses também são um tipo de problemático para a sanidade do código . Eu acredito que eles, onde apenas significou para refatorar , como muitos outros recursos também (como dobrar função) e não devem ser usados em um novo código.

    
por 23.08.2011 / 05:55
fonte
2

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, colidem em namespaces. Principalmente, isso se resume a prefixar índices e nomear restrições 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.

    
por 21.08.2011 / 22:45
fonte
1

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

aplicativos húngaro O.T.O.H. prefixos com o uso da variável (por exemplo, scrxMouse é uma coordenada ax na tela, pode ser um int, curto, longo ou até mesmo um tipo personalizado (typedefs permitirão que você o altere facilmente))

a incompreensão dos sistemas é o que destruiu o húngaro como uma melhor prática

    
por 21.08.2011 / 18:31
fonte
1

Digamos que tenhamos 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 que algo é um int não nos diz o que há nele. Agora vamos supor, em vez disso, nós chamamos assim:

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

Agora podemos ver qual é o objetivo da variável. Importaria se soubéssemos que é um int?

O propósito original do húngaro 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 teriam que conhecê-los, e qualquer nova pessoa teria que aprendê-los para entender seu código. Considerando que customerCount ou countOfCustomers é bastante óbvio à primeira vista.

O húngaro tinha algum propósito no VB antes de Option Strict On existir, porque no VB6 e anterior (e no VB .NET com Option Strict Off ) o VB coagia os tipos, então você poderia fazer isso:

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

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

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

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

    
por 22.08.2011 / 20:05
fonte
1

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

Nos tempos antigos, quando tudo que você tinha era string, int, bool e float, os caracteres sibf teriam sido suficientes. Mas com string + short, os problemas começam. Use o nome completo para o prefixo, ou nome_string para string? (Enquanto os nomes são quase sempre cordas - não são?) O que é uma aula de Street? 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);

Ok - você pode usar sublinhados, se você não usá-los para algo mais, 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, você 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 longo para um contador? Se você fizer exceções, muitas vezes perderá tempo, pensando em precisar de um prefixo ou não.

Se você tem 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.

    
por 23.08.2011 / 01:30
fonte
1

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

Eu acho que as razões dadas aqui para não usá-lo são convincentes por não impor húngaro a outras pessoas, mas apenas levemente sugestivas, 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 em interfaces de usuário é uma virtude, não um pecado . Veja, por exemplo, as fotos em " O design das coisas cotidianas ", e olhe para as portas com o rótulo "Push" parece que você os puxa, e nas torneiras de cerveja os operadores invadiram os importantes controles do reator nuclear porque, de alguma forma, "pairar sobre eles na IDE" não era bom o suficiente.

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

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

Just use the IDE to rename all the occurences. -Gander, replying to Goose

Se o húngaro realmente ajudar você a criar rapidamente um código e mantê-lo de maneira confiável, use-o. Se não, não faça. Se outras pessoas lhe disserem que você está errado sobre sua própria experiência, sugiro que elas provavelmente sejam as que estão erradas.

    
por 26.08.2011 / 20:03
fonte