Que tipo de prefixo que você usa para variáveis ??de membro?

https://stackoverflow.com/questions/111605

02-07-2019
|

Pergunta

Sem dúvida, é essencial para o código de entendimento para dar variáveis ??de membro um prefixo para que eles possam ser facilmente distinguidas das variáveis ??"normais".

Mas que tipo de prefixo que você usa?

Eu tenho trabalhado em projetos em que nós usamos m _ como prefixo, em outros projetos que usamos um sublinhado única (que eu pessoalmente não gosto, porque um sublinhado única não é suficiente demonstrativo).

Em outro projeto foi utilizado um formulário de prefixo de comprimento, que também incluiu o tipo de variável. mul _ por exemplo é o prefixo de uma m variável brasa do tipo u nsigned l ong.

Agora, deixe-me saber que tipo de prefixo você usa (e por favor, dê uma razão para isso).

EDIT: A maioria de vocês parecem código sem prefixos especiais para variáveis ??de membro! Será que isso depende da linguagem? Da minha experiência, o código C ++ tende a usar um sublinhado ou m _ como um prefixo para as variáveis ??de membros. E as outras linguagens?

Solução

Sem dúvida, é essencial para o código de entendimento para dar variáveis ??de membro um prefixo para que eles possam ser facilmente distinguidas das variáveis ??"normais".

I disputar esta reivindicação. Não é nem um pouco necessário se você tem destaque de sintaxe semi-decente. Um bom IDE pode deixá-lo escrever seu código em Inglês legível, e pode mostrar-lhe o tipo eo escopo de um símbolo outras maneiras. Eclipse faz um bom trabalho, destacando declarações e usos de um símbolo quando o ponto de inserção está em um deles.

Editar, graças fino: Um marcador boa sintaxe como Eclipse também permitem que você use texto em negrito ou itálico ou fontes de mudança no total. Por exemplo, eu como itálico para as coisas estáticas.

Outro edit: Pense nisso desta maneira; o tipo e âmbito de uma variável de informação são secundário. Deve estar disponível e fácil de encontrar, mas não gritou com você. Se você usar prefixos como m_ ou tipos, como LPCSTR, que se torna ruído, quando você só quer ler a informação primária -. A intenção do código

Terceira edição:. Isto aplica-se independentemente do idioma

Outras dicas

Eu não uso qualquer prefixo em tudo. Se eu correr em perigo de misturar variáveis ??locais ou parâmetros de método com os alunos, seguida, tanto o método ou a classe é muito longo e os benefícios de divisão .

Este (discutivelmente) não só torna o código mais legível e de certa forma "fluente", mas o mais importante incentiva classes bem estruturados e métodos . No final, se assim se resume a uma questão completamente diferente do que o prefixo ou sem prefixo dillema.

UPDATE: bem, gosto e preferências mudança, não é .. agora estou a usar sublinhado como o prefixo para as variáveis ??de membros como tem provado ser benéfica em reconhecer variáveis ??locais e membros no longo prazo. Especialmente novos membros da equipe às vezes têm dificuldade quando os dois não são facilmente reconhecíveis.

Nenhum. Eu costumava usar sublinhado, mas foi falado fora dele em um projeto onde os outros não como ele, e não ter perdido. A IDE decente ou uma memória decente vai dizer o que é uma variável membro e que não é. Um dos desenvolvedores sobre o nosso projeto insiste em colocar "esse." na frente de cada variável de membro, e nós humor dele quando estamos trabalhando em áreas de código que são nominalmente "seu".

Sublinhado somente.

No meu caso, eu usá-lo porque é isso que o documento padrões de codificação diz no meu local de trabalho. No entanto, eu não posso ver o ponto de adicionar m_ ou alguma coisa húngara horrível no início da variável. O minimalista 'sublinhado apenas' mantém-lo legível.

É mais importante ser consistente do que qualquer coisa, então escolha algo que você e seus companheiros de equipe pode acordar e ficar com ela. E se o idioma que você está codificando em tem uma convenção, você deve tentar cumpri-lo. Nada é mais confuso do que uma base de código que se segue uma regra de prefixo de forma inconsistente.

Para c ++, há uma outra razão para preferir m_ sobre _ além do fato de que às vezes _ prefixos compilador palavras-chave. O símbolo m representa variável membro. Isto também lhe dá a disambiguate capacidade entre moradores e as outras classes de variáveis, s_ para estático e g_ for global (mas é claro que não use globals).

Quanto aos comentários que o IDE irá sempre cuidar de você, é o IDE realmente a única maneira que você está olhando para o seu código? A sua ferramenta de comparação têm o mesmo nível de qualidade para a sintaxe hilighting como seu IDE? E sobre o seu controle de origem ferramenta de histórico de revisão? Você nunca sequer gato um arquivo de origem para a linha de comando? do IDE modernos são ferramentas de eficiência fantásticas, mas o código deve ser fácil de ler, independentemente do contexto que você está lendo-o em.

Eu prefiro usar palavra-chave this. Isso significa this.data ou this->data em vez de algum nomeação dependentes de comunidade.

Porque:

com hoje em dia IDEs digitação this. popups intellinsense
seu óbvio para todos sem saber nomenclatura definida

BTW prefixo variáveis ??com letras para indicar seu tipo está desatualizado com boas IDEs e me lembra deste o artigo de Joel

Nós usamos m_ e, em seguida, uma notação Simonyi ligeiramente modificada, assim como Rob diz em uma resposta anterior. Então, prefixo parece útil e m_ não é demasiado intrusiva e facilmente pesquisados ??em cima.

Por que a notação em tudo? E por que não basta seguir (para .NET) as recomendações da notação da Microsoft que dependem de invólucro de nomes?

questão Últimos primeira: como fora pontas, VB.NET é indiferente a caixa. Então, são bancos de dados e (especialmente) DBAs. Quando eu tenho que manter customerID reta e CustomerID (em, digamos, C #), faz o meu mal cérebro. Assim caixa é uma forma de notação, mas não um muito eficaz.

notação de prefixo tem o valor de várias maneiras:

Aumenta a compreensão humana de código sem usar o IDE. Como na revisão do código -. Que eu continuo a achar mais fácil de fazer em papel inicialmente
escreve sempre T-SQL ou outros RDBMS procs armazenados? Usando a notação de prefixo em nomes de coluna de banco de dados é realmente útil, especialmente para aqueles de nós que gostam de usar editores de texto para este tipo de coisa.

Talvez em suma, prefixo como uma forma de notação é útil porque ainda existem ambientes de desenvolvimento, onde IDEs inteligentes não estão disponíveis. Pense sobre o IDE (uma ferramenta de software) como permitindo-nos alguns atalhos (como digitação intellisense), mas não compreendendo todo o ambiente de desenvolvimento.

Um IDE é um ambiente de desenvolvimento integrado, da mesma forma que um carro é uma rede de transportes: apenas uma parte de um sistema maior. Eu não quero seguir uma convenção de "carro" Como se hospedar em estradas marcados, quando, por vezes, a sua mais rápido apenas para caminhar por um terreno baldio. Baseando-se no IDE para rastrear digitação variável seria como necessitando de GPS do carro para percorrer o terreno baldio. É melhor ter o conhecimento (estranho que isso possa ser a de ter "m_intCustomerID") em uma forma portátil do que correr de volta para o carro para cada pequena mudança de curso.

Dito isso, a convenção m_ ou o "isto" convenção são ambos legível. Nós como m_ porque facilmente é pesquisado e ainda permite que a variável digitação para segui-lo. Concordaram que um sublinhado simples é usado por muitas outras atividades de código de quadro.

Usando C #, eu mudei a partir do 'm _'- prefixo apenas um sublinhado , uma vez que 'm_' é herança de C ++ .

As Orientações oficial da Microsoft diz-lhe para não usar qualquer prefixo, e uso camel-case sobre membros privados e pascal-caso em membros públicos . O problema é que isso colide com outro guideline da mesma fonte, que afirma que você deve fazer todo o código compatível com todas as linguagens utilizadas em .NET . Por exemplo, VB.NET não faz diferença entre tripas.

Então, basta um sublinhado para mim. Isso também torna mais fácil o acesso através de IntelliSense e código externo somente chamando membros públicos não tem que ver os sublinhados visualmente bagunçado.

Update: Eu não acho que o C # - prefix ajuda o "Me." "Isso." em VB, que ainda vai ver "Me.age" o mesmo que "Me.Age".

Depende de qual quadro que estou usando! Se eu estou escrevendo código MFC então eu uso m _ e notação húngara. Para outras coisas (que tende a ser STL / Boost) então eu adicionar um sufixo sublinhado para todas as variáveis ??de membro e eu não me incomodo com notação húngara.

Class MFC

class CFoo  
{  
private:  
    int m_nAge;  
    CString m_strAddress;  
public:  
    int GetAge() const { return m_nAge; }  
    void SetAge(int n) { m_nAge = n; }  
    CString GetAddress() const { return m_strAddress;  
    void SetAddress(LPCTSTR lpsz) { m_strAddress = lpsz; }  
};

STL Class

class foo  
{  
private:  
    int age_;  
    std::string address_;  
public:  
    int age() const { return age_; }  
    void age(int a) { age_ = a; }  
    std::string address() const { return address_; }  
    void address(const std::string& str) { address_ = str; }  
};

Agora, isso pode parecer um pouco estranho - dois estilos diferentes -. Mas funciona para mim, e escrevendo um monte de código MFC que não usa o mesmo estilo como o próprio MFC só olha feio

I prefixo variáveis ??membro com 'm' e parâmetros (em função) com 'p'. Assim, o código será parecido com:

class SomeClass {
    private int mCount;
    ...
    private void SomeFunction(string pVarName) {...}
}

Eu acho que isso rapidamente diz-lhe o escopo básico de qualquer variável - se nenhum prefixo, então é um local. Além disso, ao ler uma função você não precisa pensar sobre o que está sendo passado eo que é apenas uma variável local.

É realmente depende do idioma. Eu sou um C ++ cara, e prefixo tudo com sublinhado é um pouco complicado. O material reservas de linguagem que começa com underscore para a implementação, em alguns casos (dependendo do escopo). Há também um tratamento especial para sublinhado duplo ou sublinhado seguido de uma letra maiúscula. Então eu digo apenas evitar essa confusão e simplesmente escolher algum outro prefixo. 'M' é ok OMI. 'M_' é um pouco demais, mas não terríveis. Uma questão de gosto realmente.

Mas cuidado com os _leadingUnderscores. Você será surpreendido quantos internos do compilador e da biblioteca são assim chamados, e definitivamente há espaço para acidentes e confusão se você não for extremamente cuidadoso. Basta dizer não.

Na maioria das vezes, eu uso python. Python exige que você use self.foo, a fim de acessar o foo atributo da instância da classe atual. Dessa forma, o problema de confundir variáveis ??locais, parâmetros e atributos da instância você trabalhar é resolvido.
Geralmente, eu gosto desta abordagem, mesmo que eu não gosto de ser forçado a fazê-lo. Assim, a minha maneira ideal para fazer thos é a de não fazê-lo e usar alguma forma de acesso atributo sobre este ou auto, a fim de buscar as variáveis ??de membro. Dessa forma, eu não tenho que encher os nomes com meta-dados.

Se a linguagem suporta o este ou Me palavra-chave, em seguida, usar nenhum prefixo e, em vez uso disse palavra-chave.

Outro truque é convenção de nomenclatura :

Todas as variáveis ??de membros são nomeados como de costume, sem qualquer prefixo (ou 'isso'. É que é habitual a fazê-lo no projeto)

Mas eles serão facilmente diferenciados de variável local, porque no meu projeto, essas variáveis ??locais são sempre nomeados:

a Algo:. Representa um objeto
alguns manythings:. Lista de objetos
é Astate ou tem algo:. Para o estado booleano

Qualquer variável que não começar por 'a', 'alguns' ou 'é / tem' é uma variável de membro.

Desde VB.NET não é sensível a maiúsculas, eu prefixo minhas variáveis ??de membro com um caso de sublinhado e camelo o resto do nome. I capitalizar nomes de propriedades.

Dim _valueName As Integer

Public Property ValueName() As Integer

Eu estou com as pessoas que não usam prefixos.

IDEs são tão bons hoje em dia, é fácil encontrar a informação sobre uma variável em um relance de coloração de sintaxe, mouse-over dicas e fácil navegação à sua definição.

Esta é em cima do que você pode obter a partir do contexto da variável e convenções de nomenclatura (como lowerCamelCase para variáveis ??locais e campos privados, UpperCamelCase para propriedades e métodos etc) e coisas como "hasXXXX" e "isXX" para booleans.

Eu não usei prefixos há anos, mas eu costumava ser um "presente". prefixo monstro, mas eu tenho ido off que a menos que seja absolutamente necessário (graças, ReSharper).

Eu sou esquisita e eu prefixo variáveis ??membro com as iniciais do nome da classe (que é-camelo encaixotado).

TGpHttpRequest = class(TOmniWorker)
strict private
  hrHttpClient  : THttpCli;
  hrPageContents: string;
  hrPassword    : string;
  hrPostData    : string;

A maioria das pessoas Delphi apenas usar F.

TGpHttpRequest = class(TOmniWorker)
strict private
  FHttpClient  : THttpCli;
  FPageContents: string;
  FPassword    : string;
  FPostData    : string;

A única _ usado apenas como um indicador visual. (C #)

ajuda a membros do grupo com intellisense.
mais fácil de detectar as variáveis ??de membro ao ler o código.
mais difícil esconder uma variável de membro com uma definição local.

`_` vez de `this.`

Eu uso _ demais em vez de this. porque é apenas menor ( 4 caracteres menos) e é um bom indicador de variáveis ??de membro. Além disso, usando este prefixo pode evitar conflitos. Exemplo:

public class Person {
  private String _name;

  public Person(String name) {
    _name = name;
  }
}

Compará-lo com o seguinte:

public class Person {
  private String name;

  public Person(String name) {
    this.name = name;
  }
}

Acho que o primeiro exemplo mais curto e mais claro.

Depende meio que língua você está trabalhando.

Em C # você pode fazer referência a qualquer membro usando o 'isto' prefixo, por exemplo, 'This.val', o que significa sem prefixos são necessários. VB tem uma capacidade semelhante com 'Me'.

Em línguas onde há um built-in notação para indicar o acesso de membros não vejo o ponto em usar um prefixo. Em outras línguas, eu acho que faz sentido para usar o que a convenção comumente aceita é para esse idioma.

Note que um dos benefícios do uso de um built-in notação é que você também pode usá-lo ao acessar propriedades e métodos na classe, sem comprometer suas convenções de nomenclatura para aqueles (que é particularmente importante ao acessar membros não-privados) . A principal razão para a utilização de qualquer tipo de indicador é como uma bandeira que você está fazendo com que os possíveis efeitos colaterais da classe, por isso é uma boa idéia para tê-lo ao usar outros membros, independentemente de se tratar de um campo / propriedade / método / etc .

Eu uso o caso camelo e sublinhado como muitos aqui. Eu uso o sublinhado porque eu trabalho com C # e eu me acostumei a evitar o 'isto' palavra-chave nos meus construtores. variantes I caso camelo método escopo para que o sublinhado me lembra o escopo Estou trabalhando com na época. Caso contrário, eu acho que não importa, contanto que você não está tentando adicionar informações desnecessárias que já é evidente no código.

Eu costumava usar m_ prefixo em C ++, mas em C # Eu prefiro usar apenas caso camelo para o campo e caso pascal para a sua propriedade.

private int fooBar;
public int FooBar
{
  get { return fooBar; }
  set { fooBar = value; }
}

Eu como m_ mas enquanto convenção é utilizada na base de código é usado Eu estou bem com isso.

Seu exemplo mul_ está caminhando para a notação Apps húngara Charles Simonyi.

Eu prefiro manter as coisas simples e é por isso que eu gosto de usar m_ como prefixo.

Isso torna muito mais fácil para ver onde você tem que ir para ver a declaração original.

I tendem a usar m_ em C ++, mas não se importaria de deixá-lo afastado em Java ou C #. E isso depende do padrão de codificação. Para código legado que tem uma mistura de sublinhado e M_ eu refatorar o código para um padrão (dado um código tamanho razoável)

Eu uso @.

: D j / k - mas se faz tipo de dependem do idioma. Se ele tem getters / setters, eu costumo colocar uma _ na frente da variável membro privado eo getter / setter terá o mesmo nome sem o _. Caso contrário, eu não costumo usar qualquer.

Para os meus próprios projetos eu uso _ como um postfix (como Martin Iorque observado acima, _ como um prefixo é reserver pela C / C ++ padrão para implementações do compilador) e i quando se trabalha em projetos Symbian .

Em Java, uma convenção comum é membro variáveis ??prefácio com "meu" andUseCamelCaseForTheRestOfTheVariableName.

Nenhum se não é necessário, sublinhado único contrário. Aplica para python.

Se é realmente necessário para variáveis ??de membro prefixo, eu definitivamente prefiro m_ apenas um sublinhado. I encontrar um sublinhado em seu próprio reduz a legibilidade, e pode ser confundido com C ++ palavras reservadas.

No entanto, eu dúvida de que variáveis ??de membro precisa de nenhuma notação especial. Mesmo ignorando IDE ajuda, não é óbvio por que não haveria confusão entre o que é um local e que é uma variável de membro.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow

Que tipo de prefixo que você usa para variáveis ??de membro?

_ vez de this.

`_` vez de `this.`