Por que eu não deveria usar “Hungarian Notation”?

https://stackoverflow.com/questions/111933

02-07-2019
|

Pergunta

Eu sei o húngaro refere-se a - dando informações sobre uma variável, parâmetro ou tipo como um prefixo para o seu nome. Todo mundo parece estar rabidly contra ela, embora em alguns casos, parece ser uma boa idéia. Se eu sentir que a informação útil está sendo transmitida, por que não devo colocá-lo lá onde ele está disponível?

Veja também: que as pessoas usam o convenções de nomenclatura da Hungria no mundo real?

Solução

A maioria das pessoas usam notação húngara em um caminho errado e estão obtendo resultados errados.

Leia este excelente artigo de Joel Spolsky:. Fazendo errado Código Olhe errado

Em suma, Hungarian Notation onde você prefixar seus nomes de variáveis ??com o seu type (string) (Sistemas húngaro) é ruim porque é inútil.

Hungarian Notation como foi planejado pelo autor onde você prefixar o nome da variável com a sua kind (usando o exemplo de Joel: string segura ou string inseguro)., Assim chamado Apps húngara tem seus usos e ainda é valiosa

Outras dicas

vUsing adjHungarian nnotation vmakes nreading nCode adjdifficult.

Joel está errado, e aqui está o porquê.

Essa informação "aplicação" ele está falando sobre deve ser codificado no sistema do tipo . Você não deve depender lançando nomes de variáveis ??para se certificar de que você não passar dados inseguras para funções que exijam dados seguros. Você deve torná-lo um erro de tipo, de modo que é impossível para fazer isso. Quaisquer dados não seguros deve ter um tipo que está marcado como não seguro, para que ele simplesmente não pode ser passado para uma função segura. Para converter de seguro para seguro deve exigir tratamento com algum tipo de uma função sanitize.

Um monte de coisas que Joel fala de como "tipos" não são os tipos; eles são, de fato, tipos.

O que a maioria das línguas não têm, no entanto, é um sistema tipo que do expressivo o suficiente para impor este tipo de distinções. Por exemplo, se C tinha uma espécie de "typedef forte" (onde o nome typedef tinha todas as operações do tipo base, mas não era conversível para isso), então muitos desses problemas desapareceriam. Por exemplo, se você poderia dizer, strong typedef std::string unsafe_string; para introduzir um novo tipo unsafe_string que não poderia ser convertido para um std :: string (e assim poderia participar de resolução de sobrecarga etc. etc.), então não teríamos necessidade prefixos bobos.

Assim, a reivindicação central que Hungarian é para coisas que não são tipos é errado. Ele está sendo usado para informações de tipo. Richer informações de tipo do que a informação tradicional tipo C, certamente; -lo de informações de tipo que codifica algum tipo de detalhe semântico para indicar a finalidade dos objetos. Mas ainda é informação do tipo, e a solução adequada sempre foi o de codificá-lo para o sistema de tipos. Codificação-lo para o sistema de tipo é, de longe, a melhor maneira de obter a validação adequada e aplicação das regras. Variáveis ??nomes simplesmente não cortar a mostarda.

Em outras palavras, o objetivo não deve ser "tornar o código errado olhar errado para o desenvolvedor". Ele deve ser "fazer errado errado código visual para o compilador ".

Eu acho que maciçamente enche-se o código-fonte.

Ele também não ganha-lo muito em uma linguagem fortemente digitado. Se você fizer qualquer tipo de tolice incompatibilidade de tipo, o compilador irá dizer-lhe sobre isso.

notação húngara só faz sentido em línguas sem tipos definidos pelo usuário . Em uma linguagem OO funcional ou moderno, você poderia codificar informações sobre o "tipo" de valor para o tipo de dados ou classe em vez de para o nome da variável.

Várias respostas referência Joels artigo . Note, porém, que seu exemplo está em VBScript, que fez classes definidas pelo usuário não suporte (por um longo tempo, pelo menos). Em uma linguagem com tipos definidos pelo usuário que você iria resolver o mesmo problema criando um tipo HtmlEncodedString e deixar que o método Write aceitar apenas isso. Em uma linguagem de tipagem estática, o compilador vai pegar qualquer codificação de erros, em uma dinamicamente digitado que se obtém uma exceção de tempo de execução - mas em qualquer caso você esteja protegido contra escrita cordas não codificados. notação húngara apenas transforma o programador em um tipo-checker humana, com é o tipo de trabalho que normalmente é melhor tratadas por um software.

Joel distingue entre "sistemas húngara" e "aplicativos húngara", onde "sistemas húngaro" codifica o built-in tipos, como int, float e assim por diante, e "aplicativos húngaro" codifica "tipos", que é de nível superior meta-informação sobre variável beyound o tipo de máquina, num OO ou linguagem funcional moderna pode criar tipos definidos pelo usuário, de modo que não há distinção entre o tipo e "tipo" neste sentido - tanto pode ser representado pelo sistema tipo - e "aplicativos" húngara é tão redundante como "sistemas" húngara.

Assim, para responder à sua pergunta: Sistemas húngara só seria útil em uma linguagem fracamente tipada inseguro, onde por exemplo atribuindo um valor flutuante a uma variável int irá travar o sistema. notação húngara foi especificamente inventou nos anos sessenta para uso em BCPL , uma linguagem muito baixo nível que didn 't fazer qualquer verificação de tipo em tudo. Eu não acho que qualquer língua de uso geral hoje tem esse problema, mas a notação viveu como uma espécie de carga programação cult .

Aplicativos húngara fará sentido se você está trabalhando com uma linguagem sem tipos definidos pelo usuário, como legado VBScript ou versões anteriores do VB. Talvez também as primeiras versões do Perl e PHP. Mais uma vez, usá-lo em um languge moderna é culto à carga pura.

Em qualquer outra língua, húngaro é só feio, redundante e frágil. Ele repete informação já conhecida do sistema de tipos, e você não deve repetir-se . Use um nome descritivo para a variável que descreve a intenção desta instância específica do tipo. Use o sistema de tipos de invariantes codificar e informações meta sobre "tipos" ou "classes" de variáveis ??- ou seja. tipos.

O ponto geral do artigo Joels - ter errado errado código de olhar - é um princípio muito bom. No entanto, um ainda melhor proteção contra insetos é - quando possível -. Tem código errado para ser detectado automaticamente pelo compilador

Eu sempre uso notação húngara para todos os meus projetos. Acho que é realmente útil quando eu estou lidando com 100s de diferentes nomes de identificadores.

Por exemplo, quando eu chamar uma função que requer uma string posso digitar 's' e pressione Control-espaço e minha IDE vai me mostrar exatamente os nomes de variáveis ??prefixado com 's'.

Outra vantagem, quando eu prefixo u para não assinado e eu para ints assinados, vejo imediatamente onde eu sou mistura assinados e não assinados de forma potencialmente perigosas.

Eu não consigo lembrar o número de vezes quando em uma enorme base de código 75000 linha, erros foram causados ??(por mim e outros também) devido a nomear as variáveis ??locais da mesma forma que as variáveis ??de membros existentes dessa classe. Desde então, eu sempre membros de prefixo com 'm _'

A sua pergunta de um de gosto e experiência. Não parem com isso até que tentei.

Você está esquecendo a razão número um para incluir esta informação. Não tem nada a ver com você, o programador. Tem tudo a ver com a pessoa descendo a estrada 2 ou 3 anos depois de deixar a empresa que tem que ler essas coisas.

Sim, um IDE irá identificar rapidamente os tipos para você. No entanto, quando você estiver lendo através de alguns longos lotes de código 'regras de negócio', é bom para não ter de fazer uma pausa em cada variável para descobrir que tipo é. Quando vejo coisas como strUserID, intProduct ou guiProductID, faz para muito mais fácil 'ramp up' tempo.

Eu concordo que MS foi longe demais com algumas de suas convenções de nomenclatura -. I categorizar que no "muito de uma coisa boa" pilha

Convenções de nomenclatura são coisas boas, desde que você cumpri-los. Eu já passei por código idade suficiente que tinha me constantemente voltando a olhar para as definições para tantas variáveis ??com mesmo nome que eu empurrar "caixa de camelo" (como era chamado em um emprego anterior). Agora eu estou em um trabalho que tem muitos milhares de linhas de código ASP clássico completamente descomentada com VBScript e é um pesadelo tentar descobrir as coisas.

Tacheando em personagens enigmáticas no início de cada nome de variável é desnecessária e mostra que o nome da variável por si só não é suficiente descritivo. A maioria dos idiomas requerem o tipo de variável na declaração de qualquer maneira, para que a informação já está disponível.

Há também a situação em que, durante a manutenção, um tipo de variável precisa mudar. Exemplo: se uma variável declarada como necessidades "uint_16 u16foo" para se tornar um de 64 bits sem sinal, uma das duas coisas vai acontecer:

Você vai passar e mudar o nome de cada variável (tomando cuidado para não Mangueira quaisquer variáveis ??não relacionadas com o mesmo nome), ou
Apenas alterar o tipo e não alterar o nome, que só irá causar confusão.

Joel Spolsky escreveu um bom post sobre isso. http://www.joelonsoftware.com/articles/Wrong.html Basicamente se trata de não fazer seu código mais difícil de ler quando uma IDE decente vai dizer que você quer digitar a variável é se você não consegue lembrar. Além disso, se você faz o seu código compartimentada o suficiente, você não tem que se lembrar do que uma variável foi declarada como três páginas para cima.

Não é escopo mais importante do que o tipo nos dias de hoje, por exemplo.

* l for local
* a for argument
* m for member
* g for global
* etc

Com modernas técnicas de refatoração de código antigo, procurar e substituir de um símbolo, porque você mudou seu tipo é tedioso, o compilador vai pegar mudanças de tipo, mas muitas vezes não vai pegar uso incorreto do escopo, convenções de nomenclatura sensatas ajudar aqui.

Não há nenhuma razão para que você não deve fazer correta uso de notação húngara. É de impopularidade é devido a uma longa back-chicote contra o mis-use de notação húngara, especialmente nas APIs do Windows.

Nos dias ruins de idade, antes de qualquer coisa parecida com um IDE existe há DOS (probabilidades são que você não tem memória suficiente para executar o compilador no Windows, para que o seu desenvolvimento foi feito no DOS), você não conseguir qualquer ajuda de passar o mouse sobre um nome de variável. (Supondo que você tinha um mouse.) O que você fez ter que lidar com eram funções evento de retorno de chamada em que tudo foi passado para você ou como um int de 16 bits (palavra) ou int de 32 bits (palavra longa). Você, então, teve de lançar os parâmetro para o tipo adequado para o tipo de evento. Com efeito, grande parte da API foi digitar menos virtualmente.

O resultado, uma API com nomes de parâmetros como estes:

LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam);

Note que os nomes wParam e lParam, embora horrível, não são realmente pior do que nomeá-los param1 e param2.

Para piorar a situação, Janela 3.0 / 3.1 teve dois tipos de ponteiros, próximos e distantes. Assim, por exemplo, o valor de retorno da função de gerenciamento de memória LocalLock era um PVOID, mas o valor de retorno de GlobalLock era um LPVOID (com o 'L' por muito tempo). Essa notação terrível depois foi estendido para que um l ong ?? p ointer cadeia foi prefixado lp , para distingui-lo a partir de uma string que tinha sido simplesmente malloc 'd.

Não é nenhuma surpresa que houve uma reação contra esse tipo de coisa.

Hungarian Notation pode ser útil em línguas sem verificação de tipo de tempo de compilação, uma vez que permitiria desenvolvedor se lembrar rapidamente de como a variável particular é usado. Ele não faz nada para o desempenho ou comportamento. Supõe-se para melhorar a legibilidade do código e é principalmente uma questão de gosto e estilo de codificação. Por isso mesmo, é criticado por muitos desenvolvedores - nem todo mundo tem a mesma fiação no cérebro
.
Para os de tempo de compilação línguas de verificação de tipo é praticamente inúteis - rolagem para cima algumas linhas deve revelar a declaração e, assim, digita. Se você variáveis ??globais ou os seus vãos bloco de código para muito mais do que uma tela, você tem problemas de design e reutilização graves. Assim, uma das críticas é que Hungarian Notation permite que os desenvolvedores têm um design ruim e facilmente fugir com ela. Esta é provavelmente uma das razões para hatered.

Por outro lado, pode haver casos em que, mesmo em tempo de compilação línguas de verificação de tipo se beneficiariam de Hungarian Notation - vazio ponteiros ou PUNHO 's em win32 API. Estes ofusca o tipo de dados real, e pode haver um mérito de usar Hungarian Notation lá. No entanto, se se pode saber o tipo de dados em tempo de compilação, por que não usar o tipo de dados apropriado.

Em geral, não há razões difícil não usar Hungarian Notation. É uma questão de gostos, políticas e estilo de codificação.

Como um programador de Python, Hungarian Notation se desfaz muito rápido. Em Python, eu não me importo se algo é a string - Eu me importo se ele pode agir como a string (ou seja, se ele tem um método ___str___() que retorna um string) .

Por exemplo, digamos que temos foo como um inteiro, 12

foo = 12

notação húngara nos diz que devemos chamar isso IFoo ou algo assim, para denotar que é um inteiro, para que mais tarde, nós sabemos o que é. Exceto em Python, que não funciona, ou melhor, não faz sentido. Em Python, eu decidir que tipo eu quero quando eu usá-lo. Eu quero uma string? bem se eu fizer algo como isto:

print "The current value of foo is %s" % foo

Observe o %s - string. Foo não é uma string, mas o operador % chamará foo.___str___() e usar o resultado (assumindo que ela existe). foo ainda é um inteiro, mas nós tratá-lo como uma string se queremos uma string. Se queremos um float, então tratá-lo como um float. Em linguagens de tipagem dinâmica como Python, Húngaro notação é inútil, porque não importa o que algo tipo é até que você usá-lo, e se você precisa de um tipo específico, em seguida, apenas certifique-se lançá-lo aos que tipo (por exemplo float(foo)) quando você usá-lo.

Note que as linguagens dinâmicas como PHP não têm esse benefício - PHP tenta fazer 'a coisa certa' em segundo plano baseado em um conjunto obscura de regras que quase ninguém tem memorizado, o que muitas vezes resulta em messes catastróficos inesperadamente. Neste caso, algum tipo de mecanismo de nomeação, como $files_count ou $file_name, pode ser útil.

Na minha opinião, Húngaro notação é como sanguessugas. Talvez no passado eles eram úteis, ou pelo menos eles pareciam útil, mas hoje em dia é apenas um monte de digitação extra para não um monte de benefício.

O IDE deve transmitir essa informação útil. Húngaro poderia ter feito algum tipo (não um lote inteiro, mas algum tipo) de sentido quando IDE eram muito menos avançada.

Aplicativos húngara é grego para mim - no bom sentido

Como engenheiro, não um programador, eu imediatamente levou para o artigo de Joel sobre os méritos de Aplicativos húngaro: " Fazendo errado Código olhar errado ". Gosto Apps Húngaro porque imita como a engenharia, ciência e matemática representam equações e fórmulas utilizando símbolos sub e super-scripted (como letras gregas, operadores matemáticos, etc.). Tome um exemplo particular de de Newton Lei da Gravitação Universal : pela primeira vez em notação matemática padrão, e depois em Aplicativos húngaro pseudo-código:

frcGravityEarthMars = G * massEarth * massMars / norm(posEarth - posMars)

Na notação matemática, os símbolos mais proeminentes são aqueles que representam o tipo de informações armazenadas na variável: força, massa, vetor posição, etc. Os subscritos jogar o segundo violino para esclarecer: posição de que? Este é exatamente o que Apps húngara está fazendo; ele está dizendo a tipo de coisa armazenado na variável primeiro e depois entrar em detalhes - sobre o código mais próximo pode começar a notação matemática.

Claramente tipagem forte pode resolver o exemplo corda insegura segura vs. do ensaio de Joel, mas você não iria definir tipos separados para vetores posição e velocidade; ambos são matrizes duplas de tamanho três e qualquer coisa que você é provável que fazer para se poderia aplicar para o outro. Além disso, faz todo o sentido para a posição concatenate e velocidade (para fazer um vetor de estado) ou tomar o seu produto escalar, mas provavelmente não adicioná-los. Como seria digitando permitir que os dois primeiros e proibir o segundo, e como é que tal sistema se estendem a todas as operações possíveis que você pode querer proteger? A menos que você estava disposto a codificar todas matemática e física no seu sistema de digitação.

Em cima de tudo isso, os lotes de engenharia é feito em fracamente tipado linguagens de alto nível como Matlab, ou os antigos como Fortran 77 ou Ada.

Então, se você tem uma linguagem de fantasia e não IDE e Aplicativos húngaro não ajudá-lo, em seguida, esquecê-lo - muita gente aparentemente têm. Mas, para mim, um pior do que um programador novato que está trabalhando em linguagens fracamente ou dinamicamente digitados, eu posso escrever um código melhor mais rápido com Apps húngara do que sem.

É incrivelmente redundante e inútil é IDEs mais modernos, onde eles fazem um bom trabalho de fazer o tipo aparente.

Além disso - para mim - é apenas irritante ver Inti, strUserName, etc.:)

Se eu sentir que a informação útil está sendo transmitida, por que não eu colocá-lo lá onde ele está disponível?

Então quem se importa o que os outros pensam? Se você achar que é útil, então usar a notação.

Im minha experiência, é ruim porque:

1 - então romper todo o código se for necessário alterar o tipo de uma variável (isto é, se necessitar de estender um número inteiro de 32 bits para um número inteiro de 64 bits);

2 -. Esta é uma informação inútil como o tipo é ou já na declaração ou você usa uma linguagem dinâmica, onde o tipo real não deve ser tão importante em primeiro lugar

Além disso, com uma linguagem aceitar programação genérica (ou seja, funções que o tipo de algumas variáveis ??não é determinar quando você escrever a função) ou com o sistema de tipagem dinâmica (ou seja, não quando o tipo é ainda determinar em tempo de compilação), como seria você nomear suas variáveis? E a maioria das línguas modernas apoiar um ou outro, mesmo que de uma forma restrita.

Na Fazendo Errado errado Código Olhe de Joel Spolsky ele explica que o que todo mundo pensa como Hungarian Notation (que ele chama de Sistemas húngaro) não é o que foi que foi realmente a intenção de ser (o que ele chama Apps húngaro). Desça até a eu sou Hungria indo para ver esta discussão.

Basicamente, Sistemas húngara é inútil. Ele só lhe diz a mesma coisa que seu compilador e / ou IDE irá dizer-lhe.

Aplicativos húngara diz-lhe que a variável é suposto média, e pode ser realmente útil.

Eu sempre pensei que um prefixo ou dois no lugar certo não faria mal. Eu acho que se eu posso dar algo útil, como "Hey esta é uma interface, não conte com comportamento específico" ali, como em IEnumerable, eu oughtta fazê-lo. Comentário podem atravancar as coisas muito mais do que apenas um símbolo de um ou dois caracteres.

É uma convenção útil para nomear controles em um formulário (btnOK, txtLastName etc.), se a lista de controles mostra-se em uma ordem alfabética pull-down list em sua IDE.

I tendem a usar Hungarian Notation com controles de servidor ASP.NET única , caso contrário eu achar que é muito difícil descobrir quais são os controles que no formulário.

Leve este trecho de código:

<asp:Label ID="lblFirstName" runat="server" Text="First Name" /> <asp:TextBox ID="txtFirstName" runat="server" /> <asp:RequiredFieldValidator ID="rfvFirstName" runat="server" ... />

Se alguém pode mostrar uma maneira melhor de ter esse conjunto de nomes de controle sem Hungarian eu estaria tentado a mover-se para ele.

O artigo de Joel é grande, mas parece omitir um ponto importante:

húngara faz uma 'idéia' particular (tipo + nome do identificador) único, ou quase exclusivo, através da base de código -. até mesmo uma grande base de código

Isso é enorme para a manutenção do código. Isso significa que você pode usar o bom ol' pesquisa de texto de linha única (Grep, findstr, 'encontrar em todos os arquivos') para encontrar cada menção de que 'ideia'.

Por que é tão importante quando temos de IDE que sabem ler código? Porque eles não são muito bons nisso ainda. Isso é difícil de ver em uma pequena base de código, mas óbvio em um grande - quando a 'idéia' pode ser mencionado nos comentários, arquivos XML, scripts Perl, e também em locais de controle de fonte externa (documentos, wikis, bases de dados de bugs).

Você tem que ser um pouco cuidadoso, mesmo aqui - por exemplo, token-colando em macros C / C ++ pode esconder menciona do identificador. Nesses casos, pode ser tratada com o uso convenções de codificação, e mesmo assim eles tendem a afetar apenas uma minoria dos identificadores na base de código.

P.S. Para o ponto sobre como usar o sistema de tipo vs. húngara - é melhor usar ambos. Você só precisa de código errado errado olhar se o compilador não vai pegá-lo para você. Há uma abundância de casos em que é inviável para fazer o compilador pegá-lo. Mas onde é viável - sim, por favor, faça isso em vez!

Ao considerar viabilidade, porém, não consideram os efeitos negativos da divisão tipos. por exemplo. em C #, envolvimento 'int' com consequências enormes não incorporados-in tipo tem. Portanto, faz sentido em algumas situações, mas não em todos eles.

Debunking os benefícios do Hungarian Notation

Ele fornece uma maneira de distinguir variáveis.

Se o tipo é tudo o que distingue a um valor de outro, então ele pode ser apenas para a conversão de um tipo para outro. Se você tem o mesmo valor que está sendo convertido entre os tipos, as chances são que você deveria estar fazendo isso em uma função dedicada à conversão. (Eu vi sobras VB6 hungarianed usar cordas em todos os seus parâmetros de método simplesmente porque não conseguia descobrir como desserializar um objeto JSON, ou devidamente compreender como declarar ou usar tipos anuláveis. ) Se você tem duas variáveis ??distinguidas apenas pelo prefixo húngara, e eles não são a conversão de um para o outro, então você precisa elaborar sobre a sua intenção com eles.

Isso torna o código mais legível.

Eu descobri que notação húngara faz as pessoas preguiçosas com seus nomes de variáveis. Eles têm algo para distingui-lo por, e eles não sentem necessidade de elaborar a sua finalidade. Isto é o que você encontrará tipicamente em código anotada Húngaro vs. moderno: sSQL vs. groupSelectSql ( ou normalmente não sSQL em todos, porque eles deveriam estar usando o ORM que foi colocado em por desenvolvedores anteriores . ), sValue vs. formCollectionValue (de ou normalmente não sValue também, porque eles acontecem para a MVC e deve estar usando a sua ligação modelo recursos ), stype vs. publishSource, etc.

Não pode ser legibilidade. Eu vejo mais sTemp1, sTemp2 ... sTempN de qualquer dado VB6 hungarianed sobra do que todo mundo combinados.

Ele evita erros.

Este seria em virtude do número 2, o que é falso.

Nas palavras do mestre:

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

Uma leitura interessante, como de costume.

Extratos:

"Alguém, em algum lugar, leia o artigo de Simonyi, onde ele usou a palavra‘tipo’, e pensei que ele queria dizer tipo, como classe, como em um sistema do tipo, como a verificação de tipo que o compilador faz. Ele não o fez. Ele explicou com muito cuidado exatamente o que ele quis dizer com a palavra “tipo”, mas isso não ajuda. o estrago foi feito. "

"Mas ainda há uma quantidade enorme de valor para Aplicativos húngaro, na medida em que aumenta a colocação no código, o que torna o código mais fácil de ler, escrever, depurar e manter, e, mais importante, faz código errado olhar errado . "

Certifique-se que você tem algum tempo antes de ler Joel On Software. :)

Várias razões:

Qualquer IDE moderno irá dar-lhe o tipo de variável, basta passar o mouse sobre a variável.

A maioria dos nomes de tipo são muito longo (pense HttpClientRequestProvider ) para ser razoavelmente usado como prefixo.

As informações de tipo não carrega o direito informações, é apenas parafraseando a declaração de variável, em vez de descrevendo o finalidade da variável (pense myInteger vs. pageSize ).

Eu não acho que todo mundo é rabidly contra ela. Em linguagens sem tipos estáticos, é muito útil. Eu definitivamente prefiro quando ele é usado para dar informações que já não está no tipo. Como em C, char * szName diz que a variável irá se referir a um nulo string terminada - que não é implícita em char * -. Naturalmente, um typedef também ajudaria

Joel teve um ótimo artigo sobre o uso húngara de dizer se uma variável foi HTML codificada ou não:

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

De qualquer forma, eu tendem a não gostar da Hungria, quando ele é usado para informações impart eu já sei.

É claro que quando 99% dos programadores concordam em algo, há algo errado. A razão que eles concordam aqui é porque a maioria deles nunca usou notação húngara corretamente.

Para um argumento detalhado, eu encaminhá-lo para um post que fiz sobre o assunto.

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

Eu comecei a codificação praticamente o sobre o tempo de notação húngara foi inventado e pela primeira vez eu fui forçado a usá-lo em um projeto que eu odiava.

Depois de um tempo eu percebi que quando foi feito adequadamente, ele fez realmente ajuda e esses dias eu adoro isso.

Mas, como todas as coisas boas, tem que ser aprendido e compreendido e para fazê-lo leva adequadamente tempo.

A notação húngara foi abusada, particularmente pela Microsoft, levando a prefixos mais tempo do que o nome da variável, e mostrando que é bastante rígida, especialmente quando você alterar os tipos (o infame lparam / wparam, de diferentes tipos / tamanho em Win16, idênticas em Win32).

Assim, tanto devido a este abuso, e seu uso por M $, ele foi colocado para baixo como inútil.

No meu trabalho, nós código em Java, mas os cames fundador do mundo MFC, então use estilo código semelhante (chaves alinhados, eu como este !, capitais para nomes de métodos, estou habituado a isso, prefixo como m_ para a aula membros (campos), s_ para membros estáticos, etc.).

E eles disseram todas as variáveis ??devem ter um prefixo mostrando seu tipo (por exemplo. Um BufferedReader é nomeado brData). Que mostrada como sendo uma má idéia, como os tipos podem mudar, mas não os nomes não seguem, ou codificadores não são consistentes no uso desses prefixos (I até mesmo ver aBuffer, theProxy, etc.!).

Pessoalmente, eu escolhi para alguns prefixos que eu achar útil, sendo mais importante o b prefixar variáveis ??booleanas, como eles são os únicos onde eu permitem sintaxe como if (bVar) (sem uso de autocast de alguns valores como true ou false ). Quando codificado em C, I utilizado um prefixo para variáveis ??alocados com malloc, como um lembrete de que deve ser libertado mais tarde. Etc.

Então, basicamente, eu não rejeitam esta notação como um todo, mas tomou o que parece apropriado para as minhas necessidades.
E, claro, quando contribuindo para algum projeto (trabalho, open source), eu só uso as convenções no lugar!

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow