Quali sono le migliori pratiche attuali riguardo alla parola chiave "this" di fronte al campo e ai metodi in c #?

In base alle linee guida per la progettazione di framework , quando ci si riferisce a campi pubblici o protetti:

DO NOT use a prefix for field names.

Ad esempio, m_ è un prefisso.

Quindi, l'esposizione pubblica di un campo si presta all'utilizzo della parola chiave this come spiegato su MSDN

To qualify members hidden by similar names, for example: Copy

public Employee(string name, string alias) 
{
   this.name = name;
   this.alias = alias;
}

Se ti riferisci ai campi privati, puoi usare m_ se lo desideri. Ma, per i campi pubblici, ti consiglio di seguire le migliori pratiche.

Personalmente, non mi piacciono i caratteri di sottolineatura nei nomi delle variabili. Cerco anche di essere coerente. Pertanto, this.name = name; è una buona regola empirica per lavorare in scenari sia pubblici che privati.

Nel nostro team, abbiamo adottato lo standard di utilizzo del qualificatore di oggetto this. o Me. in classi più grandi per aiutare gli sviluppatori junior a distinguere più facilmente l'ambito esatto / immediato di una variabile semplicemente osservandolo.

Dal punto di vista del codice è un'affettività del tutto inutile, ma non blocca nulla poiché genera lo stesso codice MISL alla fine. L'abbiamo adottato solo perché ha affrontato un problema immediato che abbiamo scoperto con alcuni juniores. Oltre a ciò, non vedo che sia utile includerlo.

StyleCop imporrà l'uso di this. Quindi, se la consideri come best practice (cosa che faccio), l'uso di this. è la migliore pratica.

Lo stile che adotti dipende da te e dai tuoi standard di codifica, "migliore" è qualunque cosa tu definisca che sia. Basta essere coerenti. Usarlo in modo incoerente porta solo alla confusione.

Il mio ragionamento è che l'utilizzo di this. richiama il fatto che stai facendo riferimento alle proprietà dell'istanza, quindi, ad esempio, aiuta a mettere in risalto il fatto che le stai modificando (se hai this.x = ... ), che è qualcosa potresti volerlo sapere. Evidenzia inoltre il fatto che ogni volta che vedi this. il tuo metodo non può mai essere statico. Anche l'uso di alcune convenzioni come m_ lo farà, ma è uno sforzo manuale, se si crea una m_ in una statica, o si rifatta un metodo per passare il valore dall'esterno della classe, allora bisogna ricordare di cambiare la nome, se stavi usando this allora il compilatore ti costringerà a fare la modifica.

Mettere semplicemente usando this è più facile perché se hai sbagliato il tuo codice non verrà compilato, se usi m_ è uno sforzo manuale e non stai sfruttando gli strumenti.

Una delle cose belle dell'utilizzo di m_ è che non appena digiti il piccolo m intellisense ti fornisce un elenco di tutte le tue variabili private, personalmente penso che sia un vantaggio a suo favore; Vorrei anche andare a s_ per le statistiche private e c_ per le costanti private per ragioni simili. È una notazione ungherese, ma nel senso si intendeva perché aggiunge un significato utile al nome della variabile in modo che ogni altro programmatore possa dire le cose a riguardo dal suo nome che potrebbe non essere del tutto ovvio.

Di certo non sono d'accordo con non avere alcun modo di distinguere tra variabili membro e non membro perché sono diverse e quando leggo codice in cui le persone non fanno qualcosa per destituirlo è davvero più difficile da leggere. L'utilizzo di this. sembra più un piatto di caldaia del necessario. Ma in realtà è un gusto personale, se si codifica in un modo per un po 'si finisce per pensare che è giusto e tutto il resto è sbagliato. L'unica cosa che conta davvero se lo schema è sano è che tutti nel team sono coerenti.

this è esplicito. È un segno ottico da non perdere.

Preferisco quasi sempre codice esplicito su codice implicito. Ecco perché uso this frequentemente. Lo considero una buona pratica.

La parola chiave this viene utilizzata in particolare per distinguere 2 variabili esistenti, specialmente quando si dispone di un costruttore o di un metodo con una variabile con lo stesso nome ma può avere lo stesso tipo.

Esempio:

public class Example {

    string reason;
    string cause;

    Example (string reason, string cause) {
        this.reason = reason;
        this.cause = cause;
    }

    //<Setter> if you want to explicitly write your onw
    public void setReason(stirng reason) {
        this.reason = reason;
    }
}

Questo (ad esempio this.reason = reason ) assegna fondamentalmente il valore dai parametri alle variabili nella classe. this prende fondamentalmente la classe reason dal blocco parametri.

Io uso sempre "questo". Il ragionamento si basa su due semplici fatti:

• Il codice di lettura è più difficile della scrittura del codice.
• leggi il codice più spesso di quanto scrivi codice.

L'uso di "questo" lo rende abbastanza esplicito a chiunque stia leggendo (cioè non solo all'autore, ma potrebbe includere l'autore tra 6 mesi dopo che le specifiche dell'implementazione sono state completamente dimenticate) che sì, questa è una classe membro di cui stiamo parlando qui. "m_" e simili sono solo una convenzione e, come qualsiasi altra convenzione, può essere utilizzata in modo improprio (o non utilizzata affatto) - non c'è nulla che imponga "m _" / etc in fase di compilazione o di esecuzione. "questo" è più strong: puoi mettere "m_" su una variabile locale e il compilatore non si lamenterà; non puoi farlo con "questo".

Semmai ritengo spiacevole che l'uso di "questo" non sia stato reso obbligatorio nelle specifiche della lingua.

Come bonus, quando esegui il debug puoi passare con il mouse sopra (o aggiungere un watch per) al "this" e ottenere l'ispezione di tutti gli altri membri della classe - informazioni preziose.

Anch'io me lo sono chiesto da un po 'di tempo. Dopo aver fatto una lunga codifica in javascript, mi sono sorpreso a usare this. più spesso nel mio codice c # (prima l'ho usato quasi esclusivamente in costruttori o metodi simili per evitare l'ambiguità). Rende il codice un po 'più chiaro per un piccolo sforzo aggiuntivo, inoltre non si finisce per mutilare i nomi dei membri della classe con prefissi e si può ancora tornare a usare i membri "nel modo più breve" quando il contesto è chiaro o in affermazioni particolarmente complesse. Aggiungo solo this. , quando ho un metodo più lungo, elenco di argomenti più lungo o molte variabili locali dichiarate e penso che il codice potrebbe trarre profitto da una maggiore chiarezza, anche se forzata.

Ma personalmente odio lo stile prefisso m_ , non tanto a causa di ungherese, ma perché il carattere di sottolineatura è un dolore da digitare;) Quindi non lo considero un'alternativa. Devo ammettere che ha i suoi punti forti quando si tratta di intellisense, tuttavia potresti ancora ribattere che se non riesci a ricordare le prime lettere di una variabile membro, la tua classe è troppo grande.

I prever un singolo prefisso di sottolineatura per i membri della classe. _someVar;

Perché? Sai a prima vista che è un membro, non una variabile dello stack. Semplicemente pratico durante una rapida occhiata. E richiede meno ingombro rispetto alla parola chiave "questo".

Usare cose come il prefisso / parola chiave this. che non sono né necessarie né modificare il risultato sono sempre soggettive. Tuttavia, penso che possiamo essere d'accordo sul fatto che molti di noi vogliono differenziare i campi dalle variabili locali. Alcuni usano un prefisso underscore (che trovo brutto e una sorta di notazione ungherese), altri usano la parola chiave this. . Io sono uno di questi ultimi. Si tratta solo di leggibilità e comprensibilità. Non mi spiacerebbe scrivere un po 'di più se è più chiaro o più leggibile. Voglio differenziare campi e variabili in un batter d'occhio.

Definisco sempre campi denominati simili a myField e nomi di parametri e nomi di variabili locali simili a myField . Nessun segno di sottolineatura, nessun prefisso. Uso this ovunque mi riferisca a un campo. In questo modo posso distinguere i campi da variabili locali e argomenti senza alcun tipo di prefisso. Ovviamente, in un caso come questo è richiesta la parola chiave this :

public Person(string firstName)
{
    this.firstName = firstName;
}

Le mie proprietà quindi assomigliano a questo (sì, ho sempre messo il campo con la proprietà, e non da qualche parte non correlato nella parte superiore del mio file):

private string firstName;
public string FirstName
{
    get { return this.firstName; }
}

Si legge bene: restituisce questo nome .

questo. può spesso portare a rumori indesiderati.

Ecco la mia soluzione:

• parameter_names _
• local_variables
• ANY_CONSTANT
• _private_members
• NonPrivateProperties
• _NonPrivateProperty // Backer
• privateProperty
• _privateProperty // backer

EDIT: la mia risposta non è chiaramente una risposta. Quindi ecco una modifica. Lo stato delle linee guida per la codifica di Microsoft:

2.6 Naming

Do not use a prefix for member variables (, m, s_, etc.). If you want to distinguish > between local and member variables you should use “this.” in C# and “Me.” in VB.NET.

Può essere trovato all'indirizzo: link

Quindi sembrerebbe che almeno dalla SM non vi sia una linea guida chiara, sebbene un'altra risposta affermi che StyleCop ne fa una linea guida. Non c'è autorità su queste cose, quindi ti suggerirei di decidere da solo, o in questo caso cedere alla tua squadra. Non è un grosso problema.

La mia risposta originale Personalmente sono d'accordo con te, ma forse un test di comprensione della lettura che mette insieme i due metodi l'uno contro l'altro sarebbe utile. Altrimenti queste cose di stile sono solo fangosi.

La mia salva da seguire: La mia opinione è che le persone complicano inutilmente il loro stile di codice, e se hanno bisogno di indicare che qualcosa è una variabile di livello di classe potrebbero esserci altri gravi problemi strutturali nel codice, come il vecchio metodo della ricetta di mettere variabili private al in cima alla classe che ti obbliga a scorrere continuamente su e giù.

questo mi sembra una di quelle convenzioni "ciò che è" contro le giuste convenzioni di denominazione "ciò che fa". La brezza dovrebbe essere favorita sopra l'esplicita. Questa è una lezione che viene ripetuta spesso dai linguaggi dinamici. Non abbiamo bisogno di tutto il fluff!