Sottolineaturare o non sottolineare, questa è la domanda

Ci sono problemi con il non prefisso dei campi privati ​​con un carattere di sottolineatura in C # se la versione binaria verrà utilizzata da altri linguaggi del framework? Ad esempio, poiché C # fa distinzione tra maiuscole e minuscole, puoi chiamare un campo "pippo" e la proprietà pubblica "pippo" e funziona benissimo.

Ciò avrebbe alcun effetto su un linguaggio senza distinzione tra maiuscole e minuscole come VB.NET, ci sarebbero problemi di conformità CLS (o altri) se i nomi si distinguessero solo per il case?

Non avrà alcun effetto.

Parte delle raccomandazioni per la scrittura di librerie conformi a CLS è di NON avere due entità pubbliche / protette che differiscono solo per caso, ad esempio NON dovresti avere

public void foo() {...}

e

public void Foo() {...}

quello che stai descrivendo non è un problema perché l'elemento privato non è disponibile per l'utente della libreria

IMPORTANTE AGGIORNAMENTO (12 aprile 2016):

È stato portato alla nostra attenzione che lo standard interno del team .NET CoreFX insiste sull'uso della notazione di sottolineatura senza fornire alcuna spiegazione sul perché. Tuttavia, se osserviamo attentamente regola # 3 è evidente che non v'è un sistema di _, t_, s_prefissi che suggerisce perché _è stato scelto in primo luogo.

3. Usiamo _camelCaseper campi interni e privati ​​e usiamo di sola lettura ove possibile. Prefisso campi di istanza con _, campi statici con s_e thread campi statici con t_. Se utilizzato su campi statici, readonlydovrebbe venire dopo static(cioè static readonlynon readonly static).
4. Evitiamo this.se non assolutamente necessario.

Quindi, se sei come il team .NET CoreFX che sta lavorando su un codice a livello di sistema, con prestazioni critiche, multithread, è SUGGERITO VIVAMENTE che:

• aderire ai loro standard di codifica e
• usa la notazione di sottolineatura e
• non leggere più questa risposta

Altrimenti, continua a leggere ...

LA RISPOSTA ORIGINALE:

Concordiamo innanzitutto su ciò di cui stiamo parlando. La domanda è: come accediamo ai membri dell'istanza da metodi e costruttori non statici di una classe / sottoclassi se i modificatori di visibilità lo consentono.

Underscore notazione

• suggerisce di utilizzare il prefisso "_" nei nomi dei campi privati
• dice anche che non dovresti mai usare "questo" a meno che non sia assolutamente necessario

Questa notazione

• suggerisce di usare sempre "questo". per accedere a qualsiasi membro dell'istanza

Perché esiste questa notazione?

Perché è così

• distinguere un parametro da un campo quando condividono lo stesso nome
• assicurati di lavorare nel contesto dell'istanza corrente

Esempio

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

Perché esiste la notazione di sottolineatura?

Ad alcune persone non piace digitare "this", ma hanno ancora bisogno di un modo per distinguere un campo e un parametro, quindi hanno accettato di usare "_" davanti a un campo

Esempio

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

Si potrebbe pensare che sia solo una questione di gusti personali ed entrambi i modi sono ugualmente buoni / cattivi. Tuttavia ci sono alcuni aspetti in cui questa notazione batte la notazione di sottolineatura:

Chiarezza

• nomi di cluster di notazione di sottolineatura
• questa notazione mantiene intatti i nomi

Carico cognitivo

• la notazione di sottolineatura è incoerente, ti fa trattare i campi in un modo speciale, ma non puoi usarli con altri membri, ogni volta che devi chiederti se hai bisogno di una proprietà o di un campo

• questa notazione è coerente, non devi pensare, basta usare sempre "questo" per riferirsi a qualsiasi membro

AGGIORNAMENTO: come è stato sottolineato quanto segue non è un punto di vantaggio

Manutenzione

• la notazione di sottolineatura richiede di tenere d'occhio _durante il refactoring, ad esempio trasformando un campo in proprietà (rimuovi _) o l'opposto (aggiungi _)

• questa notazione non ha questo problema

Completamento automatico

Quando è necessario visualizzare l'elenco dei membri dell'istanza:

• la sottolineatura non ti aiuta molto, perché quando si digita "_" il popup di completamento automatico mostra i campi privati ​​e tutti i tipi disponibili dagli assiemi collegati mescolati con il resto dei membri dell'istanza
• questa notazione ti dà una risposta chiara, digitando "questo" tutto ciò che vedi è l'elenco dei membri e nient'altro

Ambiguità

A volte devi gestire il codice senza l'aiuto di Intellisense. Ad esempio quando si eseguono revisioni del codice o si esplora il codice sorgente online.

• la sottolineatura è ambigua: quando vedi Something.SomethingElse non puoi dire se Something è una classe e SomethingElse è la sua proprietà statica ... o forse Something è una proprietà dell'istanza corrente che ha la sua proprietà di SomethingElse

• questa notazione è chiara: quando vedi Something.SomethingElse può significare solo una classe con una proprietà statica e quando vedi questo. Qualcosa.SomethingSai che sai che Something è un membro e SomethingElse è la sua proprietà

Metodi di estensione

Non è possibile utilizzare i metodi di estensione sull'istanza stessa senza utilizzare "this".

• la notazione di sottolineatura richiede che non si usi "this", tuttavia con i metodi di estensione che è necessario
• questa notazione ti salva dall'esitazione, usi sempre "questo", punto.

Supporto di Visual Studio

• la sottolineatura non ha un supporto integrato in Visual Studio

• questa notazione è supportata da Visual Studio naturalmente:

  1. "Questo." Qualifica : preferisci che tutti i campi non statici utilizzati nei metodi non statici siano preceduti da this.C #

Raccomandazioni ufficiali

Ci sono molte linee guida ufficiali che dicono chiaramente "non usare i trattini bassi" specialmente in C #

• la notazione di sottolineatura proviene da C ++ dove è una pratica generale che aiuta a evitare conflitti di denominazione, inoltre si consiglia a VisualBasic.Net di superare un problema in cui un campo "valore" e una proprietà "Valore" hanno effettivamente lo stesso nome, poiché VisualBasic non distingue tra maiuscole e minuscole

  1. Nomi degli elementi dichiarati in Visual Basic
  2. Campi di supporto in VisualBasic.NET

• questa notazione è consigliata per C # mentre "_" è esplicitamente vietato:

  1. questa parola chiave in C #
  2. Linee guida per l'uso dei campi : non applicare un prefisso ai nomi dei campi o ai nomi dei campi statici.
  3. Linee guida per i nomi: nomi dei membri del tipo : non utilizzare un prefisso per i nomi dei campi.
  4. Convenzione generale sulla denominazione : X NON utilizzare caratteri di sottolineatura, trattini o altri caratteri non alfanumerici
  5. Regola di certificazione della qualità CA1707 : gli identificatori non devono contenere caratteri di sottolineatura
  6. L'uso di caratteri di sottolineatura non è conforme a CLS (per identificatori pubblici e protetti)
  7. Convenzione di denominazione interna degli sviluppatori .NET Framework : non utilizzare un prefisso per le variabili membro. Se vuoi distinguere tra variabili locali e variabili del membro, dovresti usare "questo". in C # e "Me". in VB.NET.

Tratto dal file della Guida di Microsoft StyleCop:

TypeName: FieldNamesMustNotBeginWithUnderscore

CheckId: SA1309

Causa: il nome di un campo in C # inizia con un trattino basso.

Descrizione della regola:

Una violazione di questa regola si verifica quando un nome di campo inizia con un carattere di sottolineatura.

Per impostazione predefinita, StyleCop non consente l'uso di caratteri di sottolineatura, m_, ecc. Per contrassegnare i campi di classe locali, a favore di "this". prefisso. Il vantaggio di usare "questo". è che si applica allo stesso modo a tutti i tipi di elementi inclusi metodi, proprietà, ecc. e non solo ai campi, rendendo immediatamente riconoscibili tutte le chiamate ai membri della classe, indipendentemente dall'editor utilizzato per visualizzare il codice. Un altro vantaggio è che crea una differenziazione rapida e riconoscibile tra i membri dell'istanza e i membri statici, che non avrà il prefisso.

Se il nome del campo o della variabile deve corrispondere al nome di un elemento associato a Win32 o COM e deve quindi iniziare con un carattere di sottolineatura, posizionare il campo o la variabile in una classe NativeMethods speciale. Una classe NativeMethods è qualsiasi classe che contiene un nome che termina in NativeMethods ed è intesa come segnaposto per wrapper Win32 o COM. StyleCop ignorerà questa violazione se l'elemento viene inserito in una classe NativeMethods.

Una diversa descrizione della regola indica che la pratica preferita in aggiunta a quanto sopra è quella di avviare i campi privati ​​con lettere minuscole e quelli pubblici con lettere maiuscole.

Modifica: come follow-up, la pagina del progetto StyleCop si trova qui: https://github.com/DotNetAnalyzers/StyleCopAnalyzers . La lettura del file della guida fornisce molte informazioni sul perché suggeriscono varie regole stilistiche.

Dal momento che stiamo parlando di un campo privato, ciò non influisce su un utente della tua classe.

Ma raccomando di usare un carattere di sottolineatura per il campo privato, perché può rendere il codice più facile da capire, ad esempio:

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)
  {
    ..
  }
}

Nel nostro team, utilizziamo sempre un prefisso di sottolineatura per i campi privati. Quindi, quando leggo del codice, posso facilmente identificare i campi privati ​​e distinguerli da gente del posto e argomenti. In un certo senso, il carattere di sottolineatura può essere visto come una versione abbreviata di "questo".

Dopo aver lavorato in un ambiente che aveva regole di stile molto specifiche e molto inutili da allora ho continuato a creare il mio stile. Questo è un tipo che ho girato avanti e indietro molto. Ho finalmente deciso che i campi privati ​​saranno sempre _field, le variabili locali non avranno mai _ e saranno in minuscolo, i nomi delle variabili per i controlli seguiranno vagamente la notazione ungherese e i parametri saranno generalmente camelCase.

Detesto il this. parola chiave che aggiunge solo troppo rumore di codice secondo me. Adoro la rimozione di Resharper ridondante. parola chiave.

Aggiornamento di 6 anni: stavo analizzando gli interni di Dictionary<TKey,T>un uso specifico di accesso simultaneo e ho letto male un campo privato per essere una variabile locale. I campi privati ​​sicuramente non dovrebbero essere la stessa convenzione di denominazione delle variabili locali. Se ci fosse stata una sottolineatura, sarebbe stato incredibilmente ovvio.

Mi piace il trattino basso, perché poi posso usare il nome minuscolo come parametri di metodo come questo:

public class Person
{
    string _firstName;

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

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

Mi piace ancora molto usare i trattini bassi davanti ai campi privati ​​per il motivo menzionato da Martin, e anche perché i campi privati ​​verranno ordinati in IntelliSense. Questo nonostante la malvagità delle notazioni del prefisso ungherese in generale.

Tuttavia, negli ultimi tempi ho scoperto che l'uso del prefisso di sottolineatura per i membri privati ​​è malvisto, anche se non sono del tutto sicuro del perché. Forse qualcun altro lo sa? È solo il principio del prefisso? O c'era qualcosa in questione con la manipolazione del nome di tipi generici che ha ottenuto caratteri di sottolineatura negli assiemi compilati o qualcosa del genere?

Raccomandazione di Style Cop o meno, scavare in .NET Framework mostra molto "_" utilizzo per le variabili membro. Qualunque cosa i creatori di Style Cop raccomandino, non è ciò che la maggior parte dei dipendenti MS sta usando. :) Quindi continuerò con il trattino basso. Perché personalmente commetto molti meno errori usando il trattino basso quindi questo (esempio: usando varName = varName invece di this.varName = varName, è davvero bloccato in me)

Penso che nel complesso i campi di livello di classe siano un errore nella progettazione della lingua. Lo avrei preferito se le proprietà di C # avessero il loro ambito locale:

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

Ciò consentirebbe di smettere di usare interamente i campi.

L'unica volta in cui ho mai anteposto un campo privato con un carattere di sottolineatura è quando una proprietà richiede un campo di supporto separato. È anche l'unica volta che utilizzo campi privati. (E dal momento che non uso mai campi protetti, interni o pubblici, questa è l'unica volta in cui uso il periodo dei campi.) Per quanto mi riguarda, se una variabile deve avere un ambito di classe, è una proprietà della classe.

La notazione _fieldName per i campi privati ​​è così facile da interrompere . Usando "questo". la notazione è impossibile da rompere. Come spezzeresti la notazione _? Osservare:

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

Ecco fatto, ho appena violato la tua convenzione di denominazione ma si compila. Preferirei avere una convenzione di denominazione che sia a) non ungherese eb) esplicita. Sono a favore di eliminare il nome ungherese e questo si qualifica in un certo senso. Invece del tipo di un oggetto davanti al nome della variabile hai il suo livello di accesso.

In contrasto con Ruby, dove il nome della variabile @my_numberlega il nome all'ambito ed è infrangibile.

modifica: questa risposta è diventata negativa. Non mi interessa, rimane.

Quando si desidera che l'assembly sia conforme a CLS, è possibile utilizzare l'attributo CLSCompliant nel file assemblyinfo. Il compilatore si lamenterà quindi quando il codice contiene elementi non conformi a cls.

Quindi, quando si hanno 2 proprietà che differiscono solo nel caso, il compilatore genererà un errore. D'altra parte, quando hai un campo privato e una proprietà pubblica nella stessa classe, non ci saranno problemi.

(Ma prefisso sempre i miei membri privati ​​con un carattere di sottolineatura. Mi aiuta anche a chiarire quando leggo il mio codice che una determinata variabile è un campo membro).

Mi piace usare i trattini bassi davanti ai miei campi privati ​​per due motivi. Uno è già stato menzionato, i campi si distinguono dalle proprietà associate nel codice e in Intellisense. Il secondo motivo è che posso usare le stesse convenzioni di denominazione sia che sto programmando in VB o C #.

Non ci sono implicazioni di sorta. Quando viene compilato il codice, tutto ciò che è importante per il compilatore è lo spazio dei nomi e la visibilità del campo / proprietà. Un carattere di sottolineatura è altrettanto significativo di qualsiasi altro carattere quando si nomina un identificatore. Il vero trucco è usare una convenzione che tu e le persone intorno a voi capirete.