Você nomeia controles em formulários usando a mesma convenção de uma variável privada?

Question

Por alguma razão, nunca vejo isso sendo feito.Existe uma razão para não?Por exemplo, eu gosto de _blah para variáveis ​​​​privadas e, pelo menos no Windows Forms, os controles são, por padrão, variáveis ​​​​de membros privados, mas não me lembro de tê-los visto dessa forma.No caso de eu estar criando/armazenando objetos de controle em variáveis ​​locais dentro de uma função membro, é especialmente útil ter alguma distinção visual.

Answer 1

Isso pode ser contra-intuitivo para alguns, mas usamos a temida notação húngara para elementos da IU.

A lógica é simples:para qualquer objeto de dados, você pode ter dois ou mais controles associados a ele.Por exemplo, você tem um controle que indica uma data de nascimento em uma caixa de texto, você terá:

• a caixa de texto
• um rótulo indicando que a caixa de texto é para datas de nascimento
• um controle de calendário que permitirá que você selecione uma data

Para isso, eu teria lblBirthDate para o rótulo, txtBirthDate para a caixa de texto e calBirthDate para o controle de calendário.

Estou interessado em ouvir como outros fazem isso, no entanto.:)

Answer 2

Notação húngara ou não, estou mais curioso para saber se as pessoas acrescentam m_ ou _ ou o que quer que usem para variáveis ​​​​de membros privados padrão.

Answer 3

Eu pessoalmente prefixo objetos privados com _

Os controles de formulário são sempre prefixados com o tipo, o apenas a razão pela qual faço isso é por causa do intellisense.Com formulários grandes fica mais fácil "obter um valor de rótulo" apenas digitando libra e selecionando-o na lista ^_^ Também segue o lógica declarada por Jon Limjap.

Embora isso repita as Diretrizes de codificação .NET da Microsoft, verifique-as aqui.

Answer 4

Para mim, a grande vitória com a convenção de nomenclatura de acrescentar um sublinhado aos membros privados tem a ver com o Intellisense.Como o sublinhado precede qualquer letra do alfabeto, quando pressiono Ctrl-espaço para abrir o Intellisense, todos os meus _privateMembers estão bem no topo.

Os controles, porém, são uma história diferente, no que diz respeito à nomenclatura.Acho que esse escopo é assumido e acrescentar algumas letras para indicar o tipo (txtMyGroovyTextbox, por exemplo) faz mais sentido pelo mesmo motivo;os controles são agrupados no Intellisense por tipo.

Mas no trabalho, é VB completo e fazemos mPrivateMember.Acho que m pode significar módulo.

Answer 5

Passei pelo VB e mantive o prefixo do tipo de controle para controles.Meus membros privados usam letras minúsculas (firstLetterLowercase), enquanto membros públicos usam Pascal/maiúsculas (FirstLetterUppercase).

Se houver muitos identificadores/membros/locais para ter 90% de chance de lembrar/adivinhar como é chamado, provavelmente será necessária mais abstração.

Nunca estive convencido de que um prefixo de tipo de armazenamento seja útil e/ou necessário.No entanto, tenho o forte hábito de seguir o estilo de qualquer código que estou usando.

Answer 6

Não, mas aprecio sua lógica.Acho que a razão pela qual a maioria das pessoas não o faz é que os sublinhados ficariam meio feios na janela Propriedades em tempo de design.Também ocuparia um caráter extra de espaço horizontal, o que é valioso em uma janela encaixada como essa.

Answer 7

Notação húngara ou não, estou mais curioso se as pessoas precenderem M_ ou _ ou o que eles usam para variáveis ​​de membros privados padrão.

Lucas,

Eu uso _ prefixo para meus objetos de biblioteca de classes.Eu uso a notação húngara exclusivamente para a IU, pelo motivo que afirmei.

Answer 8

Eu nunca uso sublinhados em meus nomes de variáveis.Descobri que qualquer coisa além de caracteres alfa (às vezes alfanuméricos) é excessiva, a menos que seja exigida pelo idioma.

Answer 9

Estou no campo Maiúsculas/Minúsculas ("título" é privado, "Título" é público), misturado com a notação "húngara" para componentes de UI (tbTextbox, lblLabel etc.), e estou feliz por não termos Desenvolvedores visuais insensíveis a maiúsculas e minúsculas na equipe :-)

Não gosto do sublinhado porque parece meio feio, mas tenho que admitir que tem uma vantagem (ou uma desvantagem, dependendo do que você quer dizer):No depurador, todas as variáveis ​​privadas estarão no topo devido ao _ estar no topo do alfabeto.Mas, novamente, prefiro que meu par privado/público fique junto, porque isso permite uma depuração mais fácil da lógica getter/setter à medida que você vê as propriedades privada e pública próximas uma da outra,

Answer 10

Anoto o nome da coluna do banco de dados que eles representam.

Answer 11

Eu uso m_ para variáveis ​​de membro, mas estou cada vez mais tentado a usar lowerCamelCase como faço para parâmetros de método e variáveis ​​locais.O material público está em UpperCamelCase.

Esta parece ser uma convenção mais ou menos aceita em toda a comunidade .NET.