Você prefixa nomes de variáveis ​​com uma abreviação dos tipos de variáveis? (Notação húngara) [fechado]

No meu trabalho atual, não há diretrizes de codificação. Todo mundo praticamente codifica da maneira que ele quer. O que é bom, já que a empresa é pequena.

No entanto, um novo cara propôs recentemente usar sempre a notação húngara. Até agora, alguns de nós usavam algum tipo de notação húngara, outros não. Como é uma empresa de engenharia, os estilos de codificação não importam desde que os algoritmos sejam sólidos.

Pessoalmente, acho que essas pequenas abreviações de tipo são meio redundantes. Um nome bem pensado geralmente transmite a mesma mensagem. (Além disso, a maior parte do nosso código precisa ser executada em alguns DSPs esquisitos, onde um conceito como boolou floatnão existe de qualquer maneira).

Então, como você se sente sobre a notação húngara? Você usa isso? Por quê?

Quando a maioria das pessoas diz "Notação Húngara", está realmente falando sobre " Sistemas Húngaro ".

Sistemas Húngaro é completamente inútil e deve ser evitado. Não há necessidade de codificar o tipo da variável em seu nome. No entanto, o Systems Hungarian é realmente um mal-entendido do húngaro original e "real": Apps Húngaro.

No Apps Hungarian, você não codifica o "tipo" no nome da variável, codifica o "tipo" da variável. Então não nWidth, mas pxWidthou emWidth(para "largura em pixels" ou "largura em ems" respectivamente). Não, strNamemas sNameou usName(para "nome seguro" ou "nome não seguro", respectivamente - útil ao aceitar informações de usuários: cadeias não seguras).

Pessoalmente, eu também não me importo com isso. A menos que eu esteja fazendo algo que esteja convertendo explicitamente o "tipo" de um valor (por exemplo, eu usei o prefixo "px" e "em" no passado porque comete erros pxArea = emWidth * emHeightóbvios).

Veja também o artigo de Joel, " Fazendo Código Errado parecer Errado ".

pronomeVocê verboDeverá advérbioNunca verboUtilizar adjetivoNome húngaroNotação, preposiçãoIverboFaz coletivounounotudo advérbioTão comparativoAdjetivo sangrentoHard infinitivoPara verboLer.

Primeiramente:

Como é uma empresa de engenharia, os estilos de codificação não importam desde que os algoritmos sejam sólidos.

Os estilos de codificação são importantes, independentemente da empresa. Sim, os algoritmos precisam ser sólidos, mas o código deve ser mantido por todos, não apenas pelo desenvolvedor original. Ter um padrão de codificação que inclua elementos de estilo contribui para isso. Não estou dizendo que todo o código deve ser idêntico em estilo - isso seria contraproducente, mas deveria haver um grau de consistência.

Agora na notação húngara:

Embora tenha sido usado, com um IDE moderno que suporta comportamentos do tipo IntelliSense, não é necessário incluir o tipo da variável em seu nome. Esta informação está disponível para você de outras maneiras. Na pior das hipóteses, pode tornar o código mais difícil de ler se você precisar alterar o tipo da variável no futuro.

Não use. É redundante e dificulta a leitura do código.

Muito do debate sobre a notação húngara (do sistema) depende da área de trabalho. Eu costumava estar muito firme ao lado de "de jeito nenhum!", Mas, tendo trabalhado por alguns anos em uma empresa onde é usado para desenvolvimento incorporado, posso ver algumas vantagens em determinadas aplicações e isso definitivamente cresceu em mim .

Sistemas Húngaro

Pelo que sei, o Systems Hungarian tende a ser muito usado no campo incorporado. Em aplicativos para PC, o compilador lidará com muitos dos problemas associados às diferenças entre (por exemplo) seqüências de caracteres, números inteiros e valores de ponto flutuante. Em uma plataforma profundamente incorporada, você se preocupa com mais freqüência com as diferenças entre números inteiros não assinados de 8 bits, números inteiros assinados em 16 bits etc. O compilador (ou mesmo o fiapo com as regras MISRA impostas) nem sempre percebe isso. Nesse caso, ter nomes de variáveis ​​como u8ReadIndex, s16ADCValuepode ser útil.

Apps Hungarian

O Apps Hungarian possui vantagens definidas quando se trata de aplicativos para PC / Web, por exemplo, oferecendo uma diferença visual entre as strings 'inseguras' e as 'seguras' (ou seja, aquelas inseridas por um usuário e aquelas que foram escapadas ou lidas por recursos internos ou qualquer outra coisa) ) O compilador não tem conhecimento dessa distinção.

Qual é o objetivo?

O uso de (sistemas ou aplicativos) húngaro tem tudo a ver com o código errado parecer errado .

Se você estiver copiando uma sequência insegura diretamente para uma sequência segura sem escapar alguma, parecerá errado se você usar o Apps Hungarian.

Se você estiver multiplicando um número inteiro assinado por um número inteiro não assinado, o compilador (geralmente silenciosamente) promoverá o número assinado para (um possível enorme) número não assinado, possivelmente resultando em um erro: Systems Hungarian faz com que isso pareça errado.

Em ambas as situações, a notação húngara (Apps / Systems) tende a tornar as revisões de código formais mais rápidas, pois há menos referências ao tipo da variável.

No geral

No geral, minha opinião é que o mais importante é que você tenha um padrão de codificação. Se isso usa sistemas húngaros, aplicativos húngaros ou não, é uma questão de preferência pessoal ou de grupo, bem como a escolha de tipos de indentação etc. No entanto, existem vantagens definidas para toda a equipe de desenvolvimento que trabalha com a mesma preferência.

O objetivo da notação húngara é codificar informações no identificador que não pode ser codificado no sistema de tipos. Minha opinião é que, se essa informação é importante o suficiente para ser codificada, é importante o suficiente para ser codificada no sistema de tipos, onde pode ser verificada corretamente. E se a informação não é importante, então por que diabos você deseja desorganizar seu código-fonte?

Ou, para ser mais sucinto: as informações de tipo pertencem ao sistema de tipos. (Nota: ele não precisa ser um sistema de tipo estático . Contanto que ele detecte os erros de tipo, eu não me importo quando ele os captura.)

Algumas outras respostas mencionaram Unidades de Medida como usos aceitáveis ​​da Notação Húngara. (Estou meio surpreso que ninguém tenha mencionado a NASA Mars Climate Orbiter, já que isso parece surgir o tempo todo nas discussões sobre a notação húngara).

Aqui está um exemplo simples em F #:

[<Measure>] type m
[<Measure>] type ft

let someLength      = 48.15<m>
let someOtherLength = 16.2342<ft>

someLength + someOtherLength
// someLength + someOtherLength
// -------------^^^^^^^^^^^^^^^
// error FS0001: The unit of measure 'ft' does not match the unit of measure 'm'.

Olha, mãe, não há húngaros!

Se eu fosse usar Hungarian Notation em vez de tipos aqui, que não iria me ajudar um pouco:

let mSomeLength       = 48.15
let ftSomeOtherLength = 16.2342

mSomeLength + ftSomeOtherLength
// > val it : float = 64.3842

O compilador deixou direto. Agora estou confiando em um humano para detectar o que é essencialmente um erro de tipo. Não é para isso que serve um verificador de tipos?

Melhor ainda, usando a linguagem de programação Frink :

someLength      = 48.15m
someOtherLength = 16.2342ft

someLength + someOtherLength
// 53.09818416 m (length)

// Wanna know the answer in a good old fashioned American unit?
someLength + someOtherLength -> yd
// 58.06888031496062992

// Are you an astrophysicist?
someLength + someOtherLength -> parsec
// 1.7207949554318336148e-15

// ... or a fundmentalist Christian who refuses to use units invented 
// less than 2000 years ago?
someLength + someOtherLength -> biblicalcubits
// 95.893563822870765006

Então, em resumo: eu não gosto de notação húngara. Você nunca deve usá-lo.

Dito isto, acho que usar a notação húngara é uma boa ideia. Espere o que?

Sim! Nesse caso específico , você mencionou:

Além disso, a maior parte do nosso código precisa ser executada em alguns DSPs esquisitos, onde um conceito como bool ou float não existe de qualquer maneira

Mas esse é precisamente o único caso de uso sensato para a notação húngara!

PS: Eu recomendo sinceramente olhar para Frink. Seu manual contém algumas das piadas de peido mais impressionantes de todos os tempos. Também é uma linguagem bem legal :-)

Não faz sentido em uma linguagem orientada a objetos - tudo é um tipo que é aparente ao tentar usá-lo.

O único lugar em que o Systems Hungarian é garantido é com uma linguagem de tipo fraco como C. É duplamente importante com C porque não há objeto explícito (ele possui estruturas, mas todas as funções são externas à estrutura). Em algo mais fortemente tipado como C ++, Java e C #, isso não ajuda e, de fato, piora as coisas. O código é alterado e é muito mais fácil alterar um tipo do que alterar todos os locais em que você está usando um nome de variável. Também é trabalho árduo desnecessário que tende a ser ignorado.

Se você possui unidades de medida, pode ser útil codificá-lo em um nome - mas, no final, isso também pode gerar ruído extra. Por exemplo, declararemos a unidade de medida padrão para as diferentes coisas com as quais estamos trabalhando em nosso código. Por exemplo, estamos usando gradientes ou graus, metros ou pés, quadros ou milissegundos? Depois que o padrão é definido para o código, sempre que lemos em uma unidade de medida, sempre convertemos imediatamente na unidade de medida padrão para o código.

Meu conselho : comece com seus pontos de dor atuais e escolha um padrão razoável para essa parte do código. Superespecificar um padrão de codificação é contraproducente. Há muito valor em termos de nomes de variáveis ​​e campos que explicitam o que eles representam e, na maioria das vezes, é possível inferir com segurança o tipo do conceito.

HECK NÃO!

Não use notação húngara ou qualquer outra notação. Como programadores, não devemos usar "notação" para nossos nomes de variáveis.

O que devemos fazer é nomear bem nossas variáveis :

• Evite nomes muito gerais. Não o nomeie zquando for uma variável de classe que representa um objeto nomeado, por exemplo, uma conta telefônica. Ligue phoneBillou PhoneBill.

• Evite nomes muito específicos. Quando algo estiver claro sem informações adicionais, não o inclua. Se é apenas uma variável de índice de string para repetir os caracteres de uma string, e você a usa apenas uma vez na função MyFunc, por que diabos você a chamaria MyFuncTempStringCharacterIndex? Isso é uma piada triste. Ligue Posou mesmo ise quiser. No contexto, o próximo programador entenderá facilmente o que isso significa.

• Ao analisar como um nome deve ser geral ou específico, considere o domínio em que ele se encontra e o contexto de outros possíveis significados. No caso restrito em que existem dois itens de tipo semelhante facilmente confusos que são usados ​​da mesma maneira, é bom criar um prefixo ou sufixo para indicar essa diferença. Mantenha-o o mais curto possível.

Como outros respondentes disseram, é este caso estreito que iniciou o "Apps Hungarian", para distinguir entre medições relativas à janela rwTabPositione relativas ao documento rdTabPosition. Porém, em um aplicativo que faz tudo em relação ao documento, não adicione nenhum aditivo extra! De fato, por que não usar a idéia de Jörg W Mittag de criar um novo tipo real com isso? Então você não pode confundir as coisas.

Em quase todas as áreas, adicionar itens com densidade de significado mínima reduz a importância geral e a facilidade de compreensão. Aqui está um exemplo de Ben Franklin . E outro exemplo: é possível em inglês decorar nossas palavras com sua parte do discurso. É mais informação, não é? No caso de iniciantes em inglês ficarem confusos, pode ser realmente útil para eles, certo? Leia isto e diga-me o quão útil você acha que isso é para a compreensão a longo prazo e a eficiente transmissão de informações:

vrbDo advnot vrbuse nouNotação húngara ou outro adjunção. prepComo outros programadores, a expressão vrb deve não incluir mais a "nomeação" ou os nomes nominários adjuváveis.

Ao adicionar informações, fiz com que fosse uma dor completa de ler.

Então esqueça a notação. Esqueça prefixos especiais que você sempre adiciona. Na minha opinião, a única orientação real aqui deve ser:

Mantenha os nomes das variáveis ​​o mais curtos possível, o mais significativo possível e sempre inequívocos .

O objetivo de um identificador é mais importante que seu tipo. Se você usar nomes descritivos para identificadores em seus programas, não precisará usar notações húngaras. isConnectedé sempre mais legível e fácil de entender do que boolConnected.

Usamos o húngaro quando eu era programador em C ++, e foi ótimo. Você pode ver o tipo de uma variável (fe BSTR, CString, LPCTSTR ou char *) sem procurar a declaração. Naqueles dias, você pesquisaria a declaração fazendo:

1. ctrl-home
2. ctrl-F
3. nome variável
4. entrar

Então isso importava bastante. Mas por volta de 2000, algumas coisas aconteceram:

• editores se tornaram inteligentes o suficiente para exibir o tipo de variável como uma dica de ferramenta
• os editores tinham um atalho "ir para a declaração" e uma maneira rápida de voltar
• O C ++ foi menos usado e a maioria das outras linguagens possui menos tipos de variáveis. Por exemplo, em C #, você tem certeza de que lastNameé um System.String, porque há apenas uma classe de string.

Eu fui um dos últimos a me afastar do húngaro e, agora, quando leio código fonte antigo, isso me incomoda.

Eu odeio a notação húngara, prefiro usar sublinhados para delimitar nomes de variáveis.

Além disso, quando você coloca o tipo como primeira letra no início do nome da sua variável assim: float fvelocity; vect vDirection; string ** ppszWord;

o preenchimento automático classifica todos eles, e você tem dificuldade em encontrar o que deseja, e as pessoas tendem a usar o que acham melhor, e isso não é mais uma notação.

Eu só gosto de escrever ThingsLikeThat quando preciso ser muito descritivo sobre a variável, porque ela economiza espaço e o fato de existirem maiúsculas torna-a mais legível.

O que eu costumo fazer é nomear meus métodos e classes com a primeira letra em maiúscula e minúscula em nomes de variáveis ​​e um sublinhado em nomes de variáveis ​​(acho útil este último).

Sério, prefiro que as pessoas se importem com essas regras: use vírgulas, aritmética e aparelhos com espaços relevantes:

void f(int a, char b);
int a = b + 4 / (3 + 4);

Não mais que 80 caracteres por linha, ou no máximo 90 caracteres, use argumentos de várias linhas para funções ou longos if:

if
(
    checkthat(a, b) == checkthis(b, d) &&
    checkthat(d, b) == checkthis(v, d)
)

Concordo com a maioria, é um estilo antigo.

Com os IDE's modernos, uma passagem rápida sobre uma variável mostra o tipo.