Convenções de nomenclatura variável? [fechadas]

Acabei de começar a usar o ReSharper (para C #) e eu meio que gosto do localizador de cheiros de código, ele mostra algumas coisas sobre a minha escrita que eu pretendia corrigir há muito tempo (principalmente convenções de nomenclatura variável).

Isso me levou a reconsiderar algumas das minhas convenções de nomenclatura para métodos e variáveis ​​de instância. ReSharper sugere que a variável de instância seja minúscula e comece com um sublinhado. Por um tempo, pretendi diminuir todas as minhas variáveis ​​locais, mas o sublinhado é necessário? Você acha confortável? Não gosto desta convenção, mas ainda não a experimentei, qual é a sua opinião?

A segunda coisa que me levou a reavaliar é minhas convenções de nomenclatura para manipuladores de eventos da GUI. Normalmente, eu uso o padrão VS de ControlName_Action e meus controles geralmente usam notação húngara (como sufixo, para ajudar a esclarecer no código o que é visível para o usuário e o que não é quando se lida com a variável com nome semelhante), então termino com OK_btn_Click ( ), qual sua opinião sobre isso? Devo sucumbir à convenção ReSharper ou há outras opções igualmente válidas?

Você pode modificar o ReSharper para usar o esquema de convenções de nomenclatura usado. É bastante flexível, incluindo a personalização de manipuladores de eventos, campos, propriedades, métodos com vários níveis de acessibilidade, etc.

Não deixe a ferramenta definir seus padrões - use-a para impor seus próprios.

Atualização: Dito isto, no trabalho usamos principalmente camel case mais baixo para a maioria das coisas particulares - variáveis, campos e argumentos. Caixa de camelo superior para nomes, constantes e propriedades de métodos. Os manipuladores de eventos são nomeados com base na ação que representam, em vez de algo específico para o controle - por exemplo, HandleCustomerContinue, em vez de HandleContinueButtonClick. Eu tentei o esquema padrão do ReSharper por um tempo e, na verdade, não me importo, eu realmente não estou preocupada.

Em relação a

mas o sublinhado é necessário? você acha confortável?

Uma coisa que eu gosto muito de usar o sublinhado é que reduz drasticamente o uso de "this".

Considerar:

public void Invoke(int size) {
    _size = size;
}

sem o sublinhado, você teria que escrever:

public void Invoke(int size) {
    this.size = size;
}

que potencialmente introduz o erro sutil de:

public void Invoke(int size) {
    size = size;    // urgh ... no this! 
}

Além disso, o preenchimento de código é mais limpo, porque, ao vincular o sublinhado, você obtém uma lista apenas dos campos particulares, enquanto que com "this", você obtém uma lista de tudo.

Em relação a

geralmente usam notação húngara

o Framework Design Guidelines: Convenções, Idoms e Patterns para bibliotecas .NET reutilizáveis ​​diz:

NÃO use notação húngara

Deixando pouco espaço para ambiguidade :)

Consistência é realmente a chave. Isso e clareza, ou seja, não seja enigmático ou tente salvar a digitação abreviando tudo. O Intellisense é o seu protetor de digitação, não nomes enigmáticos (mas curtos!).

Em C #, o início do nome protegido ou público com sublinhado é contra a Especificação de Idioma Comum. É correto apenas no caso de membros privados.

Do MSDN:

Para interagir totalmente com outros objetos, independentemente do idioma em que foram implementados, os objetos devem expor aos chamadores apenas os recursos comuns a todos os idiomas com os quais devem interoperar. Por esse motivo, o Common Language Specification (CLS), que é um conjunto de recursos básicos de linguagem necessários para muitos aplicativos, foi definido.

Consulte: http://msdn.microsoft.com/en-us/library/12a7a7h3.aspx

Aqui você pode ler o aviso sobre o sublinhado:

Os nomes dos elementos iniciados com um sublinhado (_) não fazem parte do Common Language Specification (CLS), portanto, o código compatível com CLS não pode usar um componente que define esses nomes. No entanto, um sublinhado em qualquer outra posição em um nome de elemento é compatível com CLS.

Consulte: http://msdn.microsoft.com/en-us/library/81ed9a62.aspx

Membros protegidos são um problema porque você pode herdar da classe escrita em outro idioma.

Mas talvez não seja um problema no seu caso, se você não precisar de código compilador CLS.

Eu gosto dos sublinhados. Você sabe à primeira vista que a variável é um membro da classe e privada.

Certamente, o IDE pode dizer isso quando você passa o mouse sobre ele, mas o "primeiro olhar" não pode ser batido. Você sabe o que é uma variável local e o que é uma variável membro apenas com seus olhos. Não é necessário rolar o mouse ou passar o mouse.

Você pode usar a palavra-chave "this", mas _ é mais curta para uma melhor digitalização horizontal. Nomes descritivos geralmente são desejados, mas quando algo é uma convenção estabelecida, é melhor ter 1 caractere. por exemplo, usando a letra i como o índice ao percorrer uma matriz. Como é uma convenção estabelecida que eu sou um índice, você obtém o benefício da digitalização sem a desvantagem de se perguntar o que "i" significa.

Eu concordo geralmente com o que está sendo dito por outros, no entanto, quando se trata de ferramentas e cadeias de ferramentas, sou preguiçoso e gosto de uma vida fácil. Acho que a vida costuma ser mais fácil de fazer do jeito que sugerem. As razões são

• É mais fácil de instalar (basta seguir os padrões, até eu posso pressionar Enter 20 vezes e continuar)
• Os erros geralmente são resolvidos nas configurações padrão, geralmente é a configuração esotérica que eu expus, que expõe um defeito pela primeira vez
• O fornecedor da cadeia de ferramentas provavelmente sabe mais sobre isso do que eu; portanto, eles fizeram dessa maneira por um motivo. Quem sou eu para decidir que os especialistas estão errados (eu os considero especialistas, porque comprei a ferramenta deles)
• Você nunca precisará defender a escolha dos fornecedores por um gerente - "É o que eles recomendam"
• O cara novo não vai incomodá-lo com "por que" e "É melhor assim" - Quando toda resposta é "porque eles decidiram ..."

Então, acho que você pode encontrar um motivo válido para reconfigurar as ferramentas nas quais você acabou de gastar uma fortuna, de qualquer maneira. Se você não pode justificar a alteração, não.

Lembre-se de que toda e qualquer mudança tem um custo contínuo (real e oculto) para manter. Quanto menos houver, menor será o custo. Por exemplo - esse novo cara que mencionei - nenhuma alteração significa que ele pode ler o manual. Reconfigurar - você precisa escrever o adendo, guardá-lo com outras coisas, retirá-lo e fazê-lo ler depois de ler o manual. Talvez não seja um problema para uma loja de 2 homens, mas que tal uma loja de 100 homens?

As duas regras que você está perguntando destacam o início dos nomes de campos particulares e os nomes de métodos geralmente são considerados a norma nos círculos de desenvolvimento do C #. Ao se adaptar a essas convenções, seu código será imediatamente mais compreensível para outros desenvolvedores, porque esse é o estado de espírito em que eles estão acostumados a operar.

O sufixo de Label, RadioButton, etc. para seus controles também é geralmente considerado a norma. Freqüentemente, vários controles existirão para um único conceito (por exemplo, um Label e um TextBox), e esse sufixo é bastante útil. A notação húngara verdadeira foi abandonada há muito tempo porque foi bastardizada em algo que não expressa sua intenção original, que era o contexto da variável e não o tipo, tamanho etc.

No meu caso, usar camelcase e sublinhados ajuda com nomes de variáveis ​​descritivos (leia-se: longos) e conclusão de código. Não sei ao certo como o preenchimento automático do Visual Studio funciona, mas no QtCreator e, em menor grau, no Eclipse, pode-se digitar, por exemplo

sDI

e expandi-lo para

someDescriptiveIdentifier

Economiza um pouco de digitação caso você tenha nomes como

someDescriptiveName, someOtherDescriptiveName, someOtherButNotTheSameDescriptiveName

que costumo produzir quando no "modo de nomeação descritiva".

Usando sublinhados, posso determinar qual nome quero preenchimento automático

someDescriptiveIdentifier

ou

_someDescriptiveClassMember

Espero que minha explicação seja clara o suficiente :)