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

101

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?

user29981
fonte
39
Qual idioma / IDE você usa? No Visual Studio, você não precisa ir para a definição para saber o tipo de uma variável, pois o IDE a fornece. Nas linguagens em que os tipos não são impostos, como o PHP, você não precisa saber o tipo na maioria das vezes (já que é possível atribuir 0 ou 1 a um booleano).
Arseni Mourzenko
10
@ MainMa Não tenho certeza de que seja uma boa razão para não saber o tipo de valor em PHP.
Rei Miyasaka 22/08
29
"Quando os projetos são extensos" ... não deve importar. Somente deve haver um pequeno número de variáveis ​​no escopo a qualquer momento: um punhado de variáveis ​​de classe e outro punhado de argumentos de método. Se você não pode mantê-los em ordem, a classe é muito grande ou o método é muito longo. A notação húngara foi inventada para a programação do Windows C, basicamente como uma solução alternativa para a horrível API do Windows. Nada semelhante foi sugerido ou desejado para o desenvolvimento do Unix.
Kevin cline
20
qual é a vantagem de não usar notação húngara "Não sendo odiado por seus colegas de trabalho" vem à mente ...
Sean Patrick Floyd
25
nNotação adjúngara vIs preparação preVista vRead.
precisa saber é o seguinte

Respostas:

148

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 ...
Marjan Venema
fonte
9
@ Surfer513: Na verdade, prefiro sufixos ao nomear controles. Para mim, é muito mais interessante encontrar todos os controles que tratam de um assunto / aspecto específico do que encontrar todos os controles de edição ... Quando eu quiser encontrar o controle em que o usuário pode digitar o nome de um cliente, começarei a procurar cliente, em vez de txt, porque ele pode não ser um txt (edit), mas um memorando ou um richedit ou um ... poderia até ser uma caixa de combinação para permitir encontrá-lo em nomes de clientes inseridos anteriormente ...
Marjan Venema
8
@ Surfer513: E hoje em dia eu só uso sufixos ao distinguir entre dois controles que lidam com a mesma coisa. Por exemplo, o rótulo e a edição para o nome do cliente. E, com frequência, os sufixos não estão relacionados ao tipo de controle, mas ao seu objetivo: ClientCaption e ClientInput, por exemplo.
Marjan Venema
3
Também é importante notar que o intellisense no VS 2010 permite pesquisar o nome inteiro , não apenas o começo. Se você nomear seu controle "firstNameTextBox" e digitar "textb", ele encontrará seu controle e o listará.
Adam Robinson
4
'... a versão abusada é evitada como a placa ...' ou seja, evitada um pouco menos que o tártaro e a gengivite? ;-)
Ben Mosher
4
@Marjan: Claro que um compilador poderia ter percebido isso. Se cada unidade é representada por um tipo, você não pode passar acidentalmente uma pela outra. Aqui, se você tiver a AbsoluteXTypee a RelativeYType, não poderá passar erroneamente uma coordenada relativa Y para uma X absoluta. Prefiro que variáveis ​​que representam entidades incompatíveis sejam de tipos incompatíveis, em vez de ter prefixos incompatíveis. O compilador não cuida de prefixos (ou sufixos).
Matthieu M.
74

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.

user7519
fonte
2
"O que acontece quando você muda intpara um tipo diferente como long..." Simples: <sarcasm> Não mude o nome, porque não há como dizer quantos lugares a mudança ocorrerá. </sarcasm> Então agora você tem uma variável cuja O nome húngaro entra em conflito com a sua implementação. Não há absolutamente nenhuma maneira de dizer quão amplos serão os efeitos da alteração do nome se a variável / função tiver visibilidade pública.
David Hammen
2
O artigo vinculado é fantástico e vale a pena ler. +1
Marty Pitt
6
@ David basta olhar para a API do Win32, que está repleta de variáveis, parâmetros e até nomes de métodos que, usando a notação húngara (que é um requisito no MS), indicam um valor de 8 ou 16 bits quando, na verdade, todos eles têm 32 bits valores desde a introdução do Windows 95 em 1994 (quase 17 anos atrás).
jwenting
2
@ Seguro: Eu diria que é o que os testes automatizados devem estar fazendo. Não programadores.
Joel
2
O @Seguro talvez não esteja em um aplicativo interno, mas se você estiver mantendo uma API pública como a API do Windows, é um grande problema.
jwenting
51

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.

Falcon
fonte
1
Essa deve ser a resposta correta. É tão legal. +1
Saeed Neamati
Você é muito gentil, Saeed. Agradeço sua apreciação, mas as outras respostas a essa pergunta também são muito boas.
Falcon
11
Promovido um voto para uma única frase: " 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 de seu tipo. " - IMHO, esta é a razão número 1 para evitar a notação húngara.
Daniel Pryden
19

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.

tsundoku
fonte
4
+1 para algumas informações muito legais lá. Eu uso 'sp' como meu prefixo de proc armazenado, não 'sp_'. Mas, mesmo assim, esse é definitivamente um fato muito interessante e uma razão concreta para não usar 'sp_' como um prefixo de proc armazenado.
2
+1 Eu nunca soube disso e, quando comecei a trabalhar no SQL Server, todos os SPs no meu local de trabalho eram prefixados, sp_então fiquei com a convenção.
Michael
Ótimo ponto, mas nada a ver com esta pergunta (usando sq e não _sp). É como deixar de fora o nome do esquema para objetos que não estão no esquema padrão.
precisa saber é o seguinte
1
Para procedimentos armazenados pelo usuário, usei convencionalmente 'usp_'. Isso serviu para evitar o problema mencionado E distinguir para o leitor se o sproc era sistema ou usuário.
Umbrella
15

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.

Wayne M
fonte
13

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.

JeffO
fonte
2
@ Surfista: Uma chave primária é diferente porque "PK" não é do tipo; "PK_TableName" diz "esta é a chave primária para TableName", não "este é um TableName do tipo PK". Quanto ao resto ... não parece que você esteja realmente ouvindo os argumentos aqui. Pare de usar essa prática detestável que até hoje persiste em reduzir a qualidade coletiva de todo o código.
Aaronaught
2
@Aaronaught, você está especificando um aspecto da notação húngara ( en.wikipedia.org/wiki/Hungarian_notation ). Não é apenas o tipo, mas também o uso pretendido. Portanto, prefixar com 'pk' uma chave primária é de fato a notação húngara. Estou ouvindo argumentos aqui, mas há exceções (como a situação da chave primária) em que parece que o HN é benéfico. Talvez talvez não. Ainda estou tentando entender o que é e o que não é para todos os cenários. Hoje aprendi bastante sobre isso e despertou um grande pensamento.
3
@ Surfista: Isso simplesmente não está correto. A notação húngara descreve o tipo (versão incorreta) ou um uso específico do tipo (versão menos incorreta). PK não é nenhum, não está simplesmente descrevendo algo sobre o tipo, está descrevendo um comportamento . Quando falo, digamos, de uma era, é completamente desinteressante que seja um número inteiro, mas ao falar de uma restrição de banco de dados, "chave primária para a tabela X" é exatamente o que é importante.
Aaronaught
4
Eu gosto do seu penúltimo parágrafo. A lógica da minha empresa para usar a notação húngara é "Ela permite ver rapidamente quais variáveis ​​são globais e quais não são". E então você olha para as declarações das variáveis ​​e há 300 variáveis ​​por arquivo, algumas m * para modulares (globais), outras v * para locais, MESMO QUE SÃO DECLARADAS NO NÍVEL MODULAR. "Oh, isso é porque eles apenas pretendem ser usados ​​como locais, não modulares." facepalm
corsiKa
3
@Aaronaught: No meu projeto atual, estamos usando nomes de tabelas com o prefixo tbl_ . Embora eu não seja um grande fã dessa prática, não vejo como isso está "diminuindo a qualidade coletiva de todo o código" . Você pode dar um exemplo?
Treb
6

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.

Saeed Neamati
fonte
6

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.

Orclev
fonte
Como alguém declararia um tipo .NET ou Java para descrever " int[]que pode ser modificado livremente, mas nunca compartilhado" ou " int[]que pode ser compartilhado livremente apenas entre coisas que nunca o modificarão"? Se um int[]campo fooencapsula os valores, {1,2,3}pode-se encapsular {2,2,3}sem saber qual "tipo" int[]dele representa? Eu pensaria que Java e .NET teriam sido muito melhores se - na ausência de suporte ao sistema de tipos, eles tivessem adotado pelo menos uma convenção de nomenclatura para distinguir esses tipos.
Supercat
4

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.

Longpoke
fonte
Também é bastante inútil para a maioria das linguagens digitadas dinamicamente!
James Anderson
2
para IDEs, é ainda pior do que para codificação manual, pois significa que a conclusão do código é drasticamente mais lenta. Se você tiver 100 variáveis ​​inteiras, digitar int <alt-space> (por exemplo) exibe 100 itens para percorrer. Se o que você precisa é intVeryLongVariableName, a conclusão do código fica problemática. Sem o húngaro, você digitaria muito <alt-space> e teria apenas 1 ou 2 opções.
jwenting
3

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. 

Oqaqiq
fonte
Entendo o IDE avançado / moderno e concordo plenamente com você. Mas e o design do banco de dados? Digamos que você tenha uma coluna ou um parâmetro de procedimento armazenado. O truque sobre o mouse realmente não funciona com esse tipo de coisa. Você teria que olhar para a tabela / definição de proc armazenada. O que você faz para isso?
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 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.

ZJR
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, 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.

BillThor
fonte
Costumo achar que esse é o caso quando tenho uma tabela de IDs. Se eu tiver TABLE SomeStringById(int somestringId, varchar somestring)o índice, também seria logicamente, SomeStringByIdmas isso causa uma colisão. Então eu chamo idx_SomeStringById. Então, para seguir o exemplo, farei idx_SomeStringByValueapenas porque é bobagem ter idx_um por um e não por outro.
precisa saber é o seguinte
1

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

catraca arrepiante
fonte
2
Eu tenho que discordar - o que destruiu o húngaro como uma "melhor prática" é que nunca esteve perto da melhor (ou mesmo boa) prática.
Jerry Coffin
2
@haylem: eu vi os artigos e o artigo original de Simonyi e li o código. De qualquer maneira, é uma má idéia que nunca deveria ter visto a luz do dia.
Jerry Coffin
1
Não viola necessariamente o DRY em um idioma dinâmico; é apenas unidiomatic. DRY nem sempre é bom; ex: macros C.
Longpoke
3
O que a IMO "destruiu" o húngaro é o fato de que mesmo a "intenção" não é útil em comparação ao uso de nomes descritivos , embora, para ser justo quando o húngaro foi criado, não houvesse um movimento por ter código legível ...
Wayne Molina
1
@Wayne M: "nomes descritivos" é fácil de dizer quando os compiladores essencialmente permitem que você use um ensaio para um nome de variável. Quando o comprimento de nomes de identificadores foram realmente limitado a um valor baixo, bastante arbitrária (acho que um limite comum era oito ou dez caracteres não que muito há muito tempo, eu não me lembro que Borland Turbo C 2 até tinha uma opção de configuração para o ! comprimento máximo de um nome de identificador), codificação de informações úteis em um nome era apenas um pouco mais complicado ...
um CVn
1

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.

Kyralessa
fonte
1

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.

Usuário desconhecido
fonte
1

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.

Ed Staub
fonte