Por que eu não deveria prefixo meus campos? [fechadas]

Question

Eu nunca fui um fã de notação húngara, eu sempre achei bastante inútil a menos que você está fazendo alguma programação nível muito baixo, mas em cada C ++ projeto que eu tenho trabalhado em algum tipo de política de notação húngara foi forçada, e com ela o uso de alguns prefixos 'não-realmente-húngaro', como m_ para os campos, s_ para estática, g_ para globals e assim por diante.

Logo percebi o quanto era inútil em C # e gradualmente começou a cair todos os meus velhos hábitos ... mas a coisa 'm_'. Eu ainda uso o m_ prefixo em campos particulares, porque eu realmente achar que é muito útil para ser capaz de distinguir entre os parâmetros, moradores e campos.

As convenções nomenclatura para página campos no MSDN diz que eu não deveria, mas não diz por que (a forma como por exemplo as convenções do Google em geral, tendem a racionalizar suas prescrições).

Existem razões pelas quais eu não deveria ou é apenas uma questão de estilo. Se for o último, são prefixos geralmente considerada um estilo ruim e eu posso esperar reações negativas de outras pessoas que trabalham na base de código?

Answer 1

I como o prefixo underbar para campos membros. Principalmente eu gosto dele porque dessa forma, todos os meus campos membros são mostrados em ordem alfabética antes de meus métodos na barra de assistente no topo da tela.

Answer 2

Quando você deve:

• Quando seu projeto de codificação diretrizes dizem que você deve

Quando você não deve:

• Quando seu projeto de codificação diretrizes dizem que você não deve

Se você não tem quaisquer orientações, no entanto, você está livre para escolher o que você ou sua falta de equipe e se sinta mais confortável. Pessoalmente quando codificar C ++ I tendem a usar m_ para os membros, isso não ajuda. Quando a codificação em outros idiomas, especialmente aqueles sem aulas verdadeiros (como Javascript, Lua) eu não.

Em suma, eu não acredito que há uma maneira "errada" "direita" e.

Answer 3

O recurso propriedade implementadas automaticamente em C # 3.0 cria menos de uma necessidade para esta convenção de uma forma ou de outra. Em vez de escrever

string m_name;
public string Name { get { return m_name; } }

ou

string _Name;
public string Name { get { return _Name; } }

(ou qualquer outra convenção), agora você pode escrever

public string Name { get; private set; }

Uma vez que você não precisa mais a variável de armazenamento de apoio explícito, você já não tem que vir acima com um nome para ele; evitando assim toda essa discussão.

Obviamente, este argumento não se aplica quando você realmente precisa armazenar apoio explícito, como para executar a validação.

Answer 4

Como alguns têm aludido, as diretrizes MS dizem:

Não use um prefixo para nomes de campo. Por exemplo, não use g_ ou s_ para distinguir estática versus não-estático campos.

Acontece que eu concordo com isso. prefixos tornar seu código olhar espaço feio e resíduos com personagens inconsequentes. Dito isto, muitas vezes é comum o uso de campos para propriedades de trás, onde o campo e a propriedade teria o mesmo nome (com o campo privado sendo caso camelo ea propriedade sendo caso pascal). Em VB, isso não funciona, uma vez que VB não é sensível a maiúsculas. Neste cenário, eu recomendo o uso de um único _ prefixo. Nem mais nem menos. Ele só parece mais limpo, IMHO.

Answer 5

Eu experimentei com m_, s_, apenas _, e nenhum prefixo em tudo. I se instalaram em usar apenas _ para todas as variáveis ??estáticas e de instância. Eu não acho que é importante para distinguir variáveis ??estáticas a partir de variáveis ??de instância. Em teoria soa bem, na prática, não cria um problema.

Um colega de trabalho uma vez fez um argumento convincente para eliminar todos os prefixos, tentámos em um projeto e funcionou melhor do que eu esperava. I levou-a para a frente para o meu próximo projeto e tornou-se irritado que ela "interfere" com Intellisense. Quando você tem a seguinte situação

int foo;
public int Foo
{
  get { return foo; }
}

Iniciando o tipo foo irá sugerir tanto a variável de instância ea propriedade. Prefixar a variável com uma elimina sublinhado a sugestão dupla chato, então eu mudei de volta para usando apenas _.

Answer 6

Eu tento seguir as MSDN . Eles incluem uma seção de diretrizes de nomenclatura .

Obviamente, estes são secundários às suas diretrizes do projeto.

Answer 7

Eu prefiro marcar campos de propriedade de apoio (embora, como já mencionado .NET 3.0 ou superior reduz a necessidade graças a propriedades automáticas) com sublinhados, mas não o "m". Por um lado isso os coloca no topo da lista Intelisense quando eu venho para usá-los.

Eu vou admitir que eu preciso escovar-se sobre as orientações sobre MSDN, as coisas podem mudar tão rapidamente nos dias de hoje.

Answer 8

Com ferramentas como ReSharper não há realmente nenhuma razão para prefixos. Também se você escrever métodos curtos, você deve ser capaz de dizer muito rapidamente, onde o var está vindo. Finalmente, eu acho que eu realmente não vejo a necessidade de dizer a diferença entre um estático ou não, porque novamente ReSharper está indo para a linha vermelha que se você tentar fazer algo que você não é capaz. Mesmo sem ReSharper provavelmente você está salvo pelo compilador.

Answer 9

variáveis ??de membro Eu sempre prefixo com m _ e variáveis ??estáticas com s _ , pelas mesmas razões que você estado. Algumas pessoas prefixo variáveis ??membro com um sublinhado, mas eu sempre achei isso um pouco de aparência estranha (mas isso é apenas uma preferência pessoal).

A maioria das pessoas que eu trabalho com o uso do m_ / s_ prefixo. Eu realmente não acho que importa muito o que você usa, contanto que você está consistente.

Answer 10

Eu nunca usá-los. Ela incentiva codificação desleixada. O MSDN diretrizes de codificação, que é onde ele está.

Answer 11

Aqui estão algumas razões para usar _ (e não sou _).

(1) Muitos rapazes BCL fazê-lo, apesar de guia de nomenclatura de MS. (Confira seu blogue .) Esses caras escrever no quadro, então eles têm alguns bons hábitos vale a pena copiar. Parte do código exemplo útil mais no MSDN é escrito por eles, e assim usa a convenção sublinhado. É um padrão de fato indústria.

(2) Um único sublinhado é uma forma perceptível e discreto para o método disambiguate e variáveis ??de nível de classe simplesmente lendo a fonte. Ele ajuda as pessoas a compreender novo (ou velho) Código at-a-glance quando lê-lo. Sim, você pode passar o mouse sobre para ver isso em uma IDE, mas não deve ser forçado a. Você pode querer lê-lo em um editor de texto, ou ouso dizer, no papel.

(3) Alguns dizem que você não precisa de nenhum prefixo como métodos será curta, e posteriormente, se necessário você pode alterar o campo para uma propriedade implementadas automaticamente. Mas no mundo real métodos são contanto que eles precisam ser, e há importantes diferenças entre campos e propriedades (por exemplo de serialização e inicialização).

Nota de rodapé: O "m" para o membro em m_ é redundante em nosso uso aqui, mas foi minúsculas porque uma das ideias em muitas dessas convenções de nomenclatura de idade foi que os nomes de tipo começou com caso e instância nomes superiores iniciados com letras minúsculas. Isso não se aplica em .NET por isso é duplamente redundante. Também notação húngara foi por vezes útil com compiladores C antigos (por exemplo inteiro ou ponteiro de fundição e aritmética), mas mesmo em C ++ a sua utilidade foi diminuída quando se lida com classes.

Answer 12

Há uma diferença importante entre C ++ e C #: Ferramenta de suporte. Quando você seguir as diretrizes estabelecidas (ou variações comuns), você vai ter um profundo nível de suporte ferramenta que C ++ nunca teve. Seguindo as normas permite que ferramentas para fazer operações de refatoração / renomear mais profundas do que você de outra forma ser capaz de fazer. ReSharper faz isso. Então, pau com um dos padrões estabelecidos.

Answer 13

Como @ John Kraft menciona, não há resposta "correta". MattJ é o mais próximo - você deve sempre seguir diretrizes de estilo da sua empresa. Quando em Roma, e tudo isso.

Quanto à minha opinião pessoal, uma vez que ele é chamado para aqui, eu voto que você deixar cair m_ inteiramente.

Eu acredito que o melhor estilo é aquele em que todos os membros são PascalCased, independentemente da visibilidade (Isso significa que mesmo os membros private), e todos os argumentos são camelCased. Eu não quebrar este modelo.

Eu posso entender o desejo de campo de propriedade backing store prefixo; afinal de contas você deve diferenciar entre o campo ea propriedade, certo? Eu concordo, você deve. Mas usar um pós-correção.

Em vez de m_MyProperty (ou mesmo _MyProperty, o que eu vi e ainda promoveu era uma vez), o uso MyPropertyValue. É mais fácil de ler e compreender e - mais importante - é perto de seu nome da propriedade original no intellisense.

Em última análise, essa é a razão pela qual eu prefiro um postfix. Se eu quiser o acesso MyPropertyValue usando intellisense você (normalmente) tipo "My <down-arrow> <tab>", já que por então você está perto o suficiente que apenas MyProperty e MyPropertyValue estão na lista. Se você deseja acessar m_MyProperty usando intellisense, você terá que digitar "m_My <tab>".

É sobre economia keystroke, na minha opinião.

Answer 14

Eu nunca fazer isso e a razão por que é que eu [tentar] manter meus métodos curta. Se eu posso ver o método inteiro na tela, eu posso ver os parâmetros, eu posso ver os locais e para que eu possa dizer o que é de propriedade da classe e que é um parâmetro ou um local.

Eu normalmente nomear meus parâmetros e moradores utilizando uma notação particular, mas nem sempre. Eu não sou nada se não for incompatível. I contar com o fato de que meus métodos são curtos e tentar mantê-los de fazer X, Y e Z, quando deveriam estar fazendo apenas X.

De qualquer forma, isso é meus dois centavos.

Answer 15

A menos que eu estou preso com vi ou Emacs para edição de código, meu IDE cuida de exibição diferencial de membros para mim, então eu raramente usa as convenções especiais. Isso também vale para prefixar interfaces com I ou classes com C.

Alguém, por favor, explicar o estilo .NET da I-prefixo em interfaces. :)

Answer 16

o que eu estou acostumado a é que propriedades privadas tem pequena underscone f.ex "_name string". o público tem "Nome". e as variáveis ??de entrada em métodos tem letra pequena "vazio MyMethod (string name)".

Se você tem const estático é muitas vezes escritos com letras grandes. static const MYCONST = "hmpf".

Answer 17

Eu nunca usar qualquer verrugas húngaro sempre que eu sou dado a escolha. É digitação extra e não transmite qualquer informação significativa. Qualquer bom IDE (e eu definir "bom" com base na presença desse recurso, entre outros) vai permitir que você tenha uma sintaxe diferente que destaca para membros estáticos, os membros da instância, funções de membro, tipos, etc. Não há nenhuma razão para encher o seu código com informações que podem ser fornecidas pelo IDE. Este é um corolário para não congestionar o seu código com o código antigo comentou-out porque o seu sistema de controle de versão deve ser responsável por isso.

Answer 18

A melhor maneira é chegar a acordo sobre um padrão com os seus colegas, e cumpri-lo. Não absolutamente tem que ser o método que iria trabalhar melhor para todos, apenas concordar com um método é mais importante do que o método que realmente concordar.

O que nós escolhemos para o nosso padrão de código é usar _ como prefixo para as variáveis ??de membros. Uma das razões era que torna mais fácil para encontrar as variáveis ??locais no intellisense.

Antes de nós concordamos com esse padrão que eu usei uma outra. Eu não utilizar qualquer prefixo em tudo, e escreveu this.memberVariable no código para mostrar que eu estava usando uma variável de membro.

Com a abreviação propriedade em C # 3, eu acho que eu usar variáveis ??de membro muito menos explícitas.

Answer 19

A coisa mais próxima de diretrizes oficiais é StyleCop , uma ferramenta da Microsoft que pode analisar automaticamente seus arquivos de origem e detectar violações do estilo de codificação recomendada, e pode ser executado a partir do Visual Studio e / ou compilações automatizadas tais como MSBuild.

Nós a usamos em nossos projetos e ele ajuda a estilo do código de marca e layout mais consistente entre os desenvolvedores, embora lembre faz exame de muito um pouco de tempo para se acostumar!

Para responder à sua pergunta -. Ele não permite que qualquer notação húngara, nem todos os prefixos como m_ (na verdade, ele não permite o uso de sublinhados em tudo)

Answer 20

Não uso esse estilo por mais tempo. Ele foi desenvolvido para ajudar você a ver rapidamente como variáveis ??estavam sendo usados. Os ambientes dev mais recentes permitem-lhe ver que informações ao passar o mouse sobre a variável. A necessidade de que foi embora, se você usar essas ferramentas mais recentes.

Answer 21

Também pode haver algumas dicas para ser adquirida a partir de C ++ Coding Standards ( Sutter, Herb e Alexandrescum Andrei , 2004). Item # 0 é intitulado "Não suar as pequenas coisas (Ou:. Saber o que não padronizar).".

Eles tocam sobre esta questão específica um pouco, dizendo: "Se você não pode decidir sobre a sua própria convenção de nomenclatura, tente ... variáveis ??de membro privadas likethis _ ..." (Lembre-se uso de líder sublinhado está sujeita a regras muito específicas em C ++).

No entanto, antes de chegar lá, eles enfatizam um certo nível de consistência "... o importante não é definir uma regra, mas apenas para ser coerente com o estilo já em uso dentro do arquivo ..."

Answer 22

O benefício de que a notação em C / C ++ foi para torná-lo mais fácil de ver que tipo de um símbolo era sem ter que ir a pesquisa para a declaração. Estes estilos apareceram antes da chegada do Intellisense e "Ir para definição" - que muitas vezes tinha que ir em um ganso procurando a declaração em que sabe como muitos arquivos de cabeçalho. Em um projeto grande este poderia ser um aborrecimento significativo que era ruim o suficiente quando se olha para o código-fonte C, mas ainda pior ao fazer forense usando misturado montagem + código-fonte e uma pilha de chamadas cru.

Quando confrontados com estas realidades, utilizando m_ e todas as outras regras começa húngaras a fazer algum sentido, mesmo com a sobrecarga de manutenção por causa de quanto tempo ele iria salvar apenas em olhar-se o tipo de um símbolo quando se olha para o código desconhecido. Agora é claro que temos Intellisense e "Ir para definição", então a principal motivação economizando tempo do que convenção de nomenclatura não é mais lá. Eu não acho que há muito ponto em fazer mais isso, e eu geralmente tentar ir com as diretrizes da biblioteca .NET apenas para ser consistente e possivelmente ganhar um pouco mais de apoio ferramenta.

Answer 23

Estou certo de que vou ficar inflamado por isso, mas que assim seja.

É chamado diretrizes biblioteca .NET da Microsoft, mas é realmente vista de Brad Abrams ( documento aqui ) - existem outros pontos de vista com razões válidas.

As pessoas tendem a ir com a opinião da maioria em vez de ter boas razões sólidas para um estilo específico.

O ponto importante é avaliar por um estilo específico é utilizado e por isso é preferível a um outro estilo - em outras palavras, ter uma razão para a escolha de um estilo não só porque todo mundo diz que é a coisa a fazer -. Pensar por si mesmo

A razão básica para não usar estilo antigo húngaro foi o uso de abreviaturas que era diferente para cada equipe e difícil de aprender -. Isso é facilmente resolvido por não abreviar

Como as ferramentas de desenvolvimento disponíveis alterar o estilo deve mudar para o que faz mais sentido -. Mas têm uma razão sólida para cada item de estilo

Abaixo estão as minhas diretrizes de estilo com as minhas razões - Estou sempre procurando maneiras de melhorar o meu estilo para criar mais confiável e mais fácil de manter o código

.

Naming Convention Variable

Todos nós temos a nossa opinião sobre convenções de nomenclatura de variáveis. Há muitos estilos diferentes que ajudará a produzir facilmente código de qualidade sustentável - qualquer estilo que suporta a informação essencial básicas sobre uma variável estão bem. Os critérios para uma convenção de nomenclatura específica deve ser que ela ajuda na produção de código que é confiável e de fácil manutenção. Critérios que não devem ser utilizados são: É feio Microsoft (ou seja, Brad Abrams) diz não usar esse estilo - Microsoft nem sempre produz o código mais confiável basta olhar para os erros no Expression Blend. É muito importante quando se lê o código que um nome de variável devem instantaneamente transmitir três fatos essenciais sobre a variável: alcance a sua seu tipo a entender claramente sobre o que é usado para Âmbito: Microsoft recomenda confiar totalmente no IntelliSense. IntelliSense é incrível; no entanto, um simplesmente não mouse sobre cada variável para vê-lo do alcance e tipo. Assumindo uma variável está em um escopo que não se pode causar erros significativos. Por exemplo, se uma variável de referência é transmitido como um parâmetro e está alterada em escopo local que a mudança permanecerá após o retorno do método que não podem ser desejados. Se um campo ou uma variável estática é modificado em âmbito local, mas se pensa que é um comportamento inesperado variável local poderia resultar. Por isso, é extremamente importante para ser capaz de simplesmente olhar para uma variável (não mouse sobre) e instantaneamente sabe que é escopo.

O estilo seguinte para indicar escopo é sugerido; no entanto, qualquer estilo é perfeitamente aceitável, desde que de forma clara e consistente indica escopo da variável: variável de campo m_ parâmetro p_ passado para um método variável estática s_ variável local Tipo: Erros graves podem ocorrer se alguém acredita que eles estão trabalhando com um tipo específico quando eles estão realmente trabalhando com um tipo diferente - mais uma vez, nós simplesmente não mouse sobre cada vez variável para determinar o seu tipo, nós simplesmente assumir que sabemos o seu tipo é e é assim que os erros são criados.

Abreviações: As abreviações são maus, porque eles podem significar coisas diferentes para diferentes desenvolvedores. Um desenvolvedor pode pensar que um caso menor de liderança "s" string meios, enquanto outro pode pensar que significa inteiro assinado. Abreviaturas são um sinal de preguiça de codificação - levar um pouco de tempo extra e digite o nome completo para torná-lo claro para o desenvolvedor que tem que manter o código. Por exemplo, a diferença entre "str" ??e "string" é de apenas três personagens - não é preciso muito mais esforço para código make fácilde manter.

Comum e abreviaturas claras para built-in tipos de dados são apenas aceitável, mas deve ser normalizado dentro da equipe.

Auto Código Documentação: Adicionando uma descrição clara de um nome de variável faz com que seja muito fácil para outro desenvolvedor de ler e compreender o código - fazer o nome de modo compreensível que o gerente de equipe pode ler e compreender o código sem ser um desenvolvedor <. / p>

Ordem de Nome partes variáveis: a ordem recomendada é escopo-type-description porque: grupo vontade IntelliSense todos os âmbitos semelhantes e dentro de cada grupo escopo IntelliSense vontade todos os tipos semelhantes que faz pesquisas de fácil - tente encontrar uma variável a outra maneira Torna-se muito fácil de ver e entender o alcance e para ver e compreender o tipo É um estilo bastante comum e fácil de entender Passará FxCop

Exemplos: Aqui estão alguns exemplos: m_stringCustomerName p_stringCustomerDatabaseConnectionString intNumberOfCustomerRecords ou iNumberOfCustomerRecords ou integerNumberOfCustomerRecords Essas regras simples irá melhorar significativamente a confiabilidade do código e sustentabilidade.

Estrutura de Controle Demonstrações linha única Todas as estruturas de controle (se, ao mesmo tempo, para, etc.) declarações única linha deve ser sempre envolto com as cintas, pois é muito fácil de adicionar uma nova declaração não percebendo que uma determinada declaração pertence a uma estrutura de controle que vai quebrar a lógica de código sem gerar erros tempo de compilação.

Método Exceção Embrulho Todos os métodos devem ser embrulhados com um try-catch exterior que armadilha, fornecer um lugar para se recuperar, identificar, localizar, log, e tomar uma decisão de jogar ou não. É a exceção inesperada que causam nossas aplicações a falhar - envolvendo todos os métodos prendendo todas as exceções sem tratamento garantimos identificar e registrar todas as exceções e nós impedir que a nossa aplicação de nunca deixar de funcionar. É preciso um pouco mais de trabalho, mas os resultados vale bem a pena o esforço.

Indentation Recuo não é um grande problema; No entanto, quatro espaços e não usando guias é sugerido. Se o código é impresso, o primeiro guia Impressora geralmente o padrão é 8 espaços. desenvolvedor diferente tendem a usar diferentes tamanhos de tabulação. código da Microsoft é geralmente recuado 4 espaço para que se alguém usa qualquer código e outros de 4 espaços usa o Microsoft, em seguida, o código terá que ser reformatado. Quatro espaços torna mais fácil e consistente.

Answer 24

Se você não está codificando sob uma diretriz particular, você deve continuar a usar a sua notação m_ real e mude-se o projeto de codificação diretrizes diz isso.

Answer 25

Seja funcional.

• Não use variáveis ??globais.
• Não use variáveis ??estáticas.
• Não use variáveis ??de membro.

Se você realmente precisa, mas somente se você realmente tem que, um uso e apenas uma variável para acessar o aplicativo / ambiente.