Vale a pena cuidar das diretrizes da convenção de nomenclatura?

Eu nomeio minhas variáveis ​​usando as convenções .Net:

• camelCase para variáveis ​​e campos (eu costumo usar _camelCase para campos particulares em uma classe)
• PascalCase para métodos, propriedades e classes

O único lugar que eu desvio é em constantes e Enums, onde eu realmente prefiro o estilo Java SCREAMING_CAPS.

A base de código da minha empresa está repleta do estilo de notação pseudo-húngaro do VB6 e VBScript, se não o húngaro completo, ou seja,

• s ou str para Strings
• i ou int para Ints
• d para decimal (ou algumas vezes o dobro)
• o ou obj para qualquer tipo de objeto

Eu me arrepio sempre que vejo esse estilo de código usado no código de outra pessoa (mesmo no código greenfield, não apenas no legado), e me recuso a usar esse estilo. Eu inventei a padronização das convenções de nomenclatura .Net no passado e isso é simplesmente ignorado - as pessoas que escrevem em notação húngara continuam a fazê-lo, aqueles que não gostam de mim continuam usando nosso próprio estilo; Eu sou um pouco de medo que se nós fazer padronizar (que eu continue pressionando por, mas ninguém parece se importar), vai ser em notação húngara e não a maneira recomendada e então eu vou ser forçado a escrever código como esse .

Estou fazendo uma montanha de uma montanha em relação a isso? Eu não deveria me importar se o código está cheio de identificadores redundantes e não nomes descritivos, e continuar a usar meu próprio caminho e pressionar para que isso se torne o padrão?

A única coisa com que você deve se preocupar é que você está trabalhando em uma equipe em que as pessoas não se importam em limpar um pouco as coisas. Isso é muito triste.

Faça o que você faz, continue a usar o estilo moderno e convide as pessoas (mas não as force) a adotá-lo também. Vai levar tempo, é claro. Depois de algum tempo, você verá se está indo a algum lugar e o que você poderá fazer a seguir.

PS Que tal marcar uma reunião sobre esse assunto e convidar todos os envolvidos. Então você receberá toda a atenção, denotará o problema e apresentará sua abordagem. Isso lhes dará algo em que pensar. Talvez pelas suas tentativas locais eles não estejam levando você muito a sério.

Eu acho que você pode se perguntar se a notação húngara está afetando ou não sua produção / qualidade pessoal ou se está prejudicando mais o seu ego. Por ego, quero dizer que as coisas geralmente funcionam bem, mas você nunca iria querer que alguém que respeitasse de fora visse o código vergonhosamente desatualizado. Embora eu ache que a preocupação tenha seu próprio mérito, você deve ponderá-la contra o impacto de qualidade / produtividade que seria levado a todos que precisassem mudar.

Esta é uma espécie de questão de dívida técnica, já que você está claramente correto de que esse estilo húngaro não faz sentido no .Net (com exceção das interfaces com "I", mas isso é para outra hora); no entanto, esse pode ser o tipo de dívida técnica com a qual sua equipe pode conviver até que desapareça naturalmente .

O melhor argumento contra a notação húngara, além dos IDEs modernos, que têm muitos métodos para mostrar o tipo, a visibilidade e mais itens de uma variável com a cor, com pequenos símbolos e com dicas de ferramentas ao passar o mouse, é levá-lo a sério.

• Incentive mais distintcion (b) ool (f) loat (c) har (l) ong (s) hort (conflitos com a String? No: (S) tring), (v) oid.
• Incentive a codificação da visibilidade. Eu sou da Javaland, e espero que também se encaixe no .net: (pri) vate, (pub) blic, (pro) tected (def) ault deve ser usado.
• .net tem final / const? Faça um prefixo! Eu ouço 'volátil'?
• Por que int e long precisam de um prefixo, mas objetos diferentes não? Isso não é lógico. Crie um abbrev.tab. onde cada novo objeto recebe uma abreviação distinta.
• Variáveis ​​que podem ser nulas e outras que nunca devem ser nulas também podem ser prefixadas. Pessoas inteligentes colocam o DbC inteiro no prefixo de uma variável.

Sério: Na refatoração, você pode alterar uma variável de int para long, de String para char. Você não precisa mudar o nome também.

Nos IDEs, você obtém os nomes geralmente classificados em uma Caixa ao lado. classificados por nome, onde é fácil encontrar. Se a maioria das variáveis ​​começa com o ou i, é perturbador para os olhos chegar à parte significativa do nome.

Os caracteres adicionais perturbam a semântica da variável. Um número inteiro 'sane' obtém 'i_sane', que mais parece 'insano'.

A notação húngara foi útil em idiomas que não possuem um sistema de tipos. Você não precisa se o compilador aplicar tipos específicos. Se você decorar seu lamento sobre a notação húngara com um empático 'sim, para os programadores mais antigos, no passado fazia sentido usá-lo!', Esses programadores mais antigos podem ser vaidosos e preferir não serem identificados como antigos.

Mas você precisa ter cuidado para que a técnica funcione. Talvez você possa abaixar a voz ao falar de 'programadores mais velhos', para que eles sintam, o quanto você é cuidadoso com eles, o quanto eles precisam de cuidados. Para que uma terceira pessoa na sala reconheça, você está tentando esconder alguma coisa, o que naturalmente aumentará sua curiosidade.

Compre uma cópia das diretrizes do Framework Design e solte-a na mesa do seu gerente (ou de quem controla o estilo de codificação). Certifique-se de colocar uma nota anotando claramente a introdução, onde destacam a importância da consistência. Para avançar ainda mais, peça uma cópia do Código Limpo e coloque um marcador na seção sobre convenções de codificação.

Em alguns aspectos, essa é uma questão subjetiva, e é um daqueles debates de programação de minúcias (ortografia?) Que entretenho por um tempo e depois evito. Embora eu ache que a notação húngara é um pecado que deveria ser banido, acho que a consistência é mais importante.

Nesse sentido, farei o possível para convencer uma equipe a usar a nomeação de variáveis ​​centrada no domínio em vez de convenções de nomeação baseadas em tipo, mas se tudo der certo, recuarei para aceitar um padrão de nomeação que todos devem cumprir uma base de código comum.

Não sou a favor de um padrão exigido genericamente imposto por um grupo de padrões, mas as equipes de software desenvolvem seu próprio padrão e, mais importante, cumprem-no.

Com o remodelador, renomear variáveis ​​é tão rápido que eu posso desfazer as convenções de nomenclatura tão rapidamente, que não preciso deixar as convenções antigas e erradas de pé.

Se você não possui ferramentas de refatoração, concordo com os outros comentadores que sugeriram seguir a convenção existente da base de código o máximo que puder, mesmo que tenha sido mal-intencionada. (até certo ponto, existem convenções de nomenclatura variável que se transformarão em geradores de bugs, se você permitir)

A maioria das suas preocupações é válida e facilitaria a vida de um novo desenvolvedor e provavelmente sua sanidade. A única convenção que todos devem adotar é o nome descritivo. Você deve chegar a um consenso sobre isso sem mudar drasticamente os estilos, dependendo de quão ruins eles sejam. Para todo o resto, aguarde até que você esteja no comando ou substitua os membros atuais por novos desenvolvedores que pensam e sentem o que você faz.

Meus desvios:

• _PublicPropertyBacker
• _private_property_backer
• _privateMember
• CONSTANT_MEMBER
• privateFunction
• param_
• botão privado okBU; // etc limite de 3 caracteres
• struct SOMESTRUCT // para estruturas pinvoke

Regiões de código genérico e layout de arquivo:

• Membros
  • (privado | interno | protegido | público) X [estático] X [const / somente leitura]
• Propriedades
  • (privado | interno | protegido | público) X [estático] X [somente leitura]
• Construtores
  • (privado | interno | protegido | público) X [estático]
• Comandos // qualquer coisa com retorno nulo ou retorno de status
  • (público | protegido | interno | privado) X [estático]
• Manipuladores de eventos / particulares /
  • Eventos (Controle | Remoto | Serviço | Outros)
• Funções // consultam o estado, não devem ter efeitos colaterais
  • (público | protegido | interno | privado) X [estático]