Sublinhar ou não sublinhar, eis a questão

Há algum problema em não prefixar os campos particulares com um sublinhado em C # se a versão binária for consumida por outras linguagens de estrutura? Por exemplo, como o C # diferencia maiúsculas de minúsculas, você pode chamar um campo "foo" e a propriedade pública "Foo" e ele funciona bem.

Isso teria algum efeito em uma linguagem que não diferencia maiúsculas de minúsculas, como o VB.NET, por problemas de conformidade com o CLS (ou outros) se os nomes forem distinguíveis apenas por maiúsculas e minúsculas?

Ela terá nenhum efeito.

Parte das recomendações para a criação de bibliotecas compatíveis com CLS é NÃO ter duas entidades públicas / protegidas que diferem apenas por caso, por exemplo, você NÃO deve ter

public void foo() {...}

e

public void Foo() {...}

o que você está descrevendo não é um problema porque o item particular não está disponível para o usuário da biblioteca

ATUALIZAÇÃO IMPORTANTE (12 de abril de 2016):

Fomos informados de que o padrão interno da equipe do .NET CoreFX insiste em usar a notação de sublinhado sem fornecer informações sobre o porquê. No entanto, se olharmos atentamente para a regra número 3 torna-se evidente que há um sistema de _, t_, s_prefixos que sugere por que _foi escolhido em primeiro lugar.

3. Usamos _camelCasepara campos internos e privados e usamos somente leitura sempre que possível. Prefixar campos de instância com _, campos estáticos com s_e encadear campos estáticos com t_. Quando usado em campos estáticos, readonlydeve vir depois static(ou seja, static readonlynão readonly static).
4. Evitamos, a this.menos que seja absolutamente necessário.

Portanto, se você é como a equipe do .NET CoreFX trabalhando em algum código de desempenho, multithreaded, crítico no nível do sistema , é altamente recomendável que você:

• aderir aos seus padrões de codificação e
• use a notação sublinhada e
• não leia mais esta resposta

Caso contrário, leia em ...

A RESPOSTA ORIGINAL:

Vamos primeiro concordar com o que estamos falando. A questão é como acessamos os membros da instância de métodos não estáticos e construtores de uma classe / subclasses, se modificadores de visibilidade permitirem isso.

Notação de sublinhado

• sugere que você use o prefixo "_" nos nomes dos campos particulares
• também diz que você nunca deve usar "isto", a menos que seja absolutamente necessário

Esta notação

• sugere que você sempre use "isso". para acessar qualquer membro da instância

Por que essa notação existe?

Porque é assim que você

• diferenciar um parâmetro de um campo quando eles compartilham o mesmo nome
• verifique se você está trabalhando no contexto da instância atual

Exemplo

public class Demo
{
   private String name;
   public Demo(String name) {
       this.name = name;
   }
}

Por que existe a notação sublinhada?

Algumas pessoas não gostam de digitar "this", mas ainda precisam distinguir um campo e um parâmetro, então concordaram em usar "_" na frente de um campo

Exemplo

public class Demo
{
   private String _name;
   public Demo(String name) {
      _name = name;
   }
}

Pode-se pensar que é apenas uma questão de gosto pessoal e as duas maneiras são igualmente boas / ruins. No entanto, existem certos aspectos em que essa notação supera a notação de sublinhado:

Clareza

• nomes de desordem de notação sublinhada
• essa notação mantém os nomes intactos

Carga cognitiva

• A notação de sublinhado é inconsistente, faz com que você trate os campos de uma maneira especial, mas você não pode usá-los com outros membros sempre que precisar se perguntar se precisa de uma propriedade ou de um campo.

• esta notação é consistente, você não precisa pensar, você sempre usa "this" para se referir a qualquer membro

UPDATE: como foi apontado, o seguinte não é um ponto de vantagem

Manutenção

• A notação sublinhada exige que você fique de olho _durante a refatoração, digamos, transformando um campo em propriedade (remover _) ou o oposto (adicionar _)

• essa notação não tem esse problema

Preenchimento automático

Quando você precisar ver a lista de membros da instância:

• A notação sublinhada não ajuda muito, porque quando você digita "_" o pop-up de preenchimento automático mostra os campos particulares e todos os tipos disponíveis nos assemblies vinculados misturados com o restante dos membros da instância
• esta notação fornece uma resposta clara, digitando "this" tudo o que você vê é a lista de membros e nada mais

Ambiguidade

Às vezes, você precisa lidar com o código sem a ajuda do Intellisense. Por exemplo, quando você faz revisões de código ou navega online pelo código-fonte.

• A notação sublinhada é ambígua: quando você vê Something.SomethingElse, não é possível dizer se algo é uma classe e SomethingElse é sua propriedade estática ... ou talvez algo é uma propriedade de instância atual que possui sua própria propriedade de SomethingElse

• this-notation is clear: Quando você vê Something.SomethingElse, isso só pode significar uma classe com uma propriedade estática e quando você vê this.Something.SomethingElse, você sabe que Something é um membro e SomethingElse é sua propriedade

Métodos de extensão

Você não pode usar métodos de extensões na própria instância sem usar "this".

• A notação sublinhada exige que você não use "this", mas com os métodos de extensão você deve
• Esta notação evita que você hesite, você sempre usa "isto", ponto final.

Suporte do Visual Studio

• notação de sublinhado não tem suporte interno no Visual Studio

• Esta notação é suportada pelo Visual Studio naturalmente:

  1. "Este." Qualificação : prefira todos os campos não estáticos usados ​​em métodos não estáticos a serem precedidos this.em C #

Recomendações oficiais

Existem muitas diretrizes oficiais que dizem claramente "não use sublinhados", especialmente em C #

• A notação de sublinhado veio do C ++, onde é uma prática geral que ajuda a evitar conflitos de nomenclatura. Também é recomendado para o VisualBasic.Net superar um problema em que um campo "valor" e uma propriedade "Valor" realmente têm o mesmo nome, porque VisualBasic faz distinção entre maiúsculas e minúsculas

  1. Nomes de elementos declarados no Visual Basic
  2. Campos de backup no VisualBasic.NET

• esta notação é recomendada para C # enquanto "_" é explicitamente proibido:

  1. esta palavra-chave em c #
  2. Diretrizes de uso do campo : não aplique um prefixo a nomes de campos ou nomes de campos estáticos.
  3. Diretrizes para nomes: Nomes dos membros do tipo : Não use um prefixo para nomes de campos.
  4. Convenção de nomenclatura geral : X NÃO use sublinhados, hífens ou outros caracteres não alfanuméricos
  5. Regra de asserção de qualidade CA1707 : Os identificadores não devem conter sublinhados
  6. O uso de sublinhados não é compatível com CLS (para identificadores públicos e protegidos)
  7. Convenção de nomenclatura interna dos desenvolvedores do .NET Framework : Não use um prefixo para variáveis ​​de membro. Se você quiser distinguir entre variáveis ​​locais e membros, use "this". em c # e "eu". no VB.NET.

Retirado do arquivo de Ajuda do Microsoft StyleCop:

TypeName: FieldNamesMustNotBeginWithUnderscore

CheckId: SA1309

Causa: um nome de campo em C # começa com um sublinhado.

Descrição da regra:

Uma violação desta regra ocorre quando um nome de campo começa com um sublinhado.

Por padrão, o StyleCop não permite o uso de sublinhados, m_ etc. para marcar os campos de classe local, em favor do 'this'. prefixo. A vantagem de usar 'this'. é que ele se aplica igualmente a todos os tipos de elementos, incluindo métodos, propriedades, etc., e não apenas aos campos, tornando todas as chamadas para os membros da classe instantaneamente reconhecíveis, independentemente de qual editor esteja sendo usado para exibir o código. Outra vantagem é que ele cria uma diferenciação rápida e reconhecível entre membros da instância e membros estáticos, que não serão prefixados.

Se o nome do campo ou da variável tiver como objetivo corresponder ao nome de um item associado ao Win32 ou COM e, portanto, precisar começar com um sublinhado, coloque o campo ou a variável em uma classe especial NativeMethods. Uma classe NativeMethods é qualquer classe que contenha um nome que termine em NativeMethods e se destina como um espaço reservado para os invólucros Win32 ou COM. StyleCop ignorará essa violação se o item for colocado em uma classe NativeMethods.

Uma descrição de regra diferente indica que a prática preferida, além do acima, é iniciar campos particulares com letras minúsculas e públicos com letras maiúsculas.

Edit: Como acompanhamento, a página do projeto do StyleCop está localizada aqui: https://github.com/DotNetAnalyzers/StyleCopAnalyzers . A leitura do arquivo de ajuda fornece muitas informações sobre por que eles sugerem várias regras estilísticas.

Como estamos falando de um campo particular, ele não afeta um usuário da sua classe.

Mas eu recomendo usar um sublinhado para o campo privado, porque ele pode facilitar a compreensão do código, por exemplo:

private int foo;
public void SetFoo(int foo)
{
  // you have to prefix the private field with "this."
  this.foo = foo;

  // imagine there's lots of code here,
  // so you can't see the method signature



  // when reading the following code, you can't be sure what foo is
  // is it a private field, or a method-argument (or a local variable)??
  if (foo == x)
  {
    ..
  }
}

Em nossa equipe, sempre usamos um prefixo de sublinhado para campos particulares. Assim, ao ler algum código, posso identificar com facilidade campos privados e diferenciá-los de locais e argumentos. De certa forma, o sublinhado pode ser visto como uma versão abreviada de "this".

Depois de trabalhar em um ambiente que possuía regras de estilo muito específicas e sem sentido desde então, criei meu próprio estilo. Este é um tipo que eu virei para frente e para trás muito. Eu finalmente decidi que os campos privados sempre serão _field, as variáveis ​​locais nunca terão _ e serão minúsculas, os nomes das variáveis ​​dos controles seguirão vagamente a notação húngara e os parâmetros geralmente serão camelCase.

Eu detesto a this.palavra-chave, apenas adiciona muito ruído de código na minha opinião. Adoro remover o Resharper redundante. palavra-chave

Atualização de 6 anos: eu estava analisando os internos de Dictionary<TKey,T>um uso específico de acesso simultâneo e interpretou mal um campo privado para ser uma variável local. Os campos privados definitivamente não devem ser a mesma convenção de nomenclatura que as variáveis ​​locais. Se houvesse um sublinhado, teria sido incrivelmente óbvio.

Eu gosto do sublinhado, porque então eu posso usar o nome em minúsculas como parâmetros de método como este:

public class Person
{
    string _firstName;

    public MyClass(string firstName)
    {
        _firstName = firstName;
    }

    public string FirstName
    {
        get { return _firstName; }
    }
}

Eu ainda gosto muito de usar sublinhados na frente de campos particulares pelo motivo que Martin mencionou e também porque os campos particulares serão classificados no IntelliSense. Isso apesar da maldade das notações de prefixo húngaro em geral.

No entanto, nos últimos tempos, acho que usar o prefixo de sublinhado para membros privados é desaprovado, mesmo que eu não tenha muita certeza do porquê. Talvez alguém mais saiba? É apenas o princípio do prefixo? Ou havia algo envolvido com a confusão de nomes de tipos genéricos que recebem sublinhados neles em assemblies compilados ou algo assim?

Recomenda-se Style Cop ou não, cavar no .NET Framework mostra muito uso de "_" para variáveis ​​de membro. O que os criadores do Style Cop recomendam, não é o que a maioria dos funcionários da MS está usando. :) Então, eu vou ficar com o sublinhado. Porque eu pessoalmente cometi muito menos erros usando o sublinhado do que este (exemplo: usando varName = varName em vez de this.varName = varName, está realmente preso em mim)

Penso que, em geral, os campos em nível de classe são um erro no design da linguagem. Eu teria preferido se as propriedades do C # tivessem seu próprio escopo local:

public int Foo
{
   private int foo;
   get
   {
      return foo;
   }
   set
   {
      foo = value;
   }
}

Isso tornaria possível parar completamente de usar campos.

A única vez que prefixo um campo privado com sublinhado é quando uma propriedade requer um campo de apoio separado. Essa também é a única vez que uso campos particulares. (E como nunca uso campos protegidos, internos ou públicos, é a única vez que uso o período dos campos.) No que me diz respeito, se uma variável precisa ter escopo de classe, é uma propriedade da classe.

A notação _fieldName para campos particulares é tão fácil de quebrar . Usando "isso". é impossível quebrar a notação. Como você quebraria a notação _? Observar:

private void MyMethod()
{
  int _myInt = 1; 
  return; 
}

Pronto, eu acabei de violar sua convenção de nomenclatura, mas ela é compilada. Eu preferiria ter uma convenção de nomenclatura que não seja húngara eb) explícita. Sou a favor de acabar com a nomeação húngara e isso se qualifica de certa forma. Em vez do tipo de um objeto na frente do nome da variável, você tem seu nível de acesso.

Compare isso com Ruby, onde o nome da variável @my_numbervincula o nome ao escopo e é inquebrável.

edit: Esta resposta foi negativa. Eu não ligo, fica.

Quando você deseja que seu assembly seja compatível com CLS, você pode usar o atributo CLSCompliant em seu arquivo assemblyinfo. O compilador irá reclamar quando seu código contiver itens que não são compatíveis com cls.

Então, quando você tiver duas propriedades que diferem apenas no caso, o compilador emitirá um erro. Por outro lado, quando você possui um campo privado e uma propriedade pública na mesma classe, não haverá problemas.

(Mas também prefixo sempre meus membros privados com um sublinhado. Isso também me ajuda a deixar claro quando leio meu código que uma determinada variável é um campo de membro).

Eu gosto de usar sublinhados na frente dos meus campos particulares por dois motivos. Um já foi mencionado, os campos se destacam de suas propriedades associadas no código e no Intellisense. A segunda razão é que eu posso usar as mesmas convenções de nomenclatura, seja codificando em VB ou C #.

Não há implicações. Quando seu código é compilado, tudo o que é importante para o compilador é o namespace e a visibilidade do campo / propriedade. Um sublinhado é tão significativo quanto qualquer outro caractere ao nomear um identificador. O verdadeiro truque é usar uma convenção que você e as pessoas ao seu redor entenderão.