Quali sono le migliori pratiche attualmente considerate per quanto riguarda la parola chiave "this" davanti al campo e i metodi in c #?

A meno che non sia necessario distinguere tra una variabile e un campo con lo stesso nome, non ho mai messo this.davanti a un campo o l'accesso ai membri in C #. Vedo che questo non è diverso dal m_prefisso che era comune in C ++ e penso che se hai davvero bisogno di specificare che è un membro, la tua classe è troppo grande.

Tuttavia, ci sono un certo numero di persone nel mio ufficio che sono fortemente in disaccordo.

Cosa sono considerate le migliori pratiche attuali in merito this.?

EDIT: Per chiarire, non uso mai m_e uso solo this.quando assolutamente necessario.

Secondo le linee guida di progettazione del Framework , quando si fa riferimento a campi pubblici o protetti:

NON utilizzare un prefisso per i nomi dei campi.

Ad esempio, m_è un prefisso.

Pertanto, l'esposizione pubblica di un campo si presta all'uso della thisparola chiave come spiegato su MSDN

Per qualificare i membri nascosti da nomi simili, ad esempio: Copia

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

Quando si fa riferimento a campi privati, è possibile utilizzare il m_se lo si desidera. Ma, per i settori pubblici, consiglio di seguire le migliori pratiche.

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

Nel nostro team, abbiamo adottato lo standard di utilizzare il qualificatore this.o Me.object in classi più grandi per aiutare gli sviluppatori junior a distinguere più prontamente l'ambito esatto / immediato di una variabile semplicemente osservandola.

Per quanto riguarda il codice, è un'influenza del tutto superflua, ma non blocca nulla poiché genera lo stesso codice MISL esatto alla fine. L'abbiamo adottato solo perché ha risolto un problema immediato che abbiamo scoperto con alcuni juniores. Oltre a ciò, non lo considero utile includerlo.

StyleCop imporrà l'uso di this.So, se lo consideri come best practice (cosa che faccio), allora l'uso di this.è best practice.

Lo stile che adotti dipende da te e dai tuoi standard di codifica, "il migliore" è qualunque cosa tu lo definisca. Sii coerente. L'uso incoerente porta solo alla confusione.

Il mio ragionamento è che l'uso this.richiama il fatto che stai facendo riferimento alle proprietà dell'istanza, quindi, ad esempio, aiuta a evidenziare il fatto che le stai mutando (se ne hai this.x = ...), che è qualcosa che potresti voler sapere. Sottolinea inoltre il fatto che ogni volta che vedi il this.tuo metodo non può mai essere statico. Anche usare una convenzione del genere m_farà questo, ma è uno sforzo manuale, se trasformi un m_metodo statico in un refactor o un metodo per trasferire il valore dall'esterno della classe, devi ricordare di cambiare il nome, se stavi usando thisquindi il compilatore ti costringerà ad apportare la modifica.

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

Una delle cose belle dell'uso m_è che non appena digiti il ​​piccolo mintellisense ti dà un elenco di tutte le tue variabili private, personalmente penso che sia un vantaggio a suo favore; Vorrei anche cercare s_statica privata e c_costanti private per ragioni simili. È notazione ungherese, ma nel senso in cui era inteso perché aggiunge un significato utile al nome della variabile in modo che qualsiasi altro programmatore possa dire cose dal suo nome che potrebbero non essere del tutto ovvie.

Sicuramente non concordo sul fatto di non avere alcun modo di distinguere tra variabili membro e non membro perché sono diverse e quando leggo il codice in cui le persone non fanno qualcosa per distinguere è veramente più difficile da leggere. L'uso this.sembra più una piastra della caldaia di quanto sia necessario. Ma è davvero un gusto personale, se si codifica in un modo per un po 'si finisce per pensare che sia giusto e tutto il resto sia 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 il codice esplicito rispetto al codice implicito. Ecco perché lo uso thisspesso. Lo considero una buona pratica.

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

• Leggere il codice è più difficile che scrivere il codice.
• Leggi il codice più spesso di quanto scrivi il codice.

L'uso di "questo" rende abbastanza esplicito a chiunque legga (cioè non solo l'autore, ma può includere l'autore in 6 mesi dopo che i dettagli dell'implementazione sono stati completamente dimenticati) che sì, questo è un membro della classe che stai parlando di qui. "m_" e simili sono solo una convenzione e, come qualsiasi altra convenzione, possono essere utilizzati in modo improprio (o non utilizzati affatto) - non c'è nulla che imponga "m _" / etc in fase di compilazione o runtime. "this" è più forte: puoi mettere "m_" su una variabile locale e il compilatore non si lamenterà; non puoi farlo con "questo".

Semmai ritengo deplorevole che l'uso di "questo" non sia stato reso obbligatorio nelle specifiche del linguaggio.

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

La thisparola chiave viene utilizzata in particolare per distinguere 2 variabili esistenti, in particolare quando si dispone di un costruttore o di un metodo con una variabile con lo stesso nome ma che 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 (es. this.reason = reason) Assegna sostanzialmente il valore dai parametri alle variabili nella classe. thisfondamentalmente prende la classe reasondal blocco parametri.

Mi chiedevo anche questo da qualche tempo. Dopo aver fatto un po 'di codifica estesa in javascript, mi sono sorpreso a usarethis. più spesso nel mio codice c # (prima che l'ho usato quasi esclusivamente in costruttori o metodi simili per evitare 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 utilizzare i membri "in breve" quando il contesto è chiaro o in istruzioni particolarmente complesse. Aggiungo solo this., quando ho un metodo più lungo, un elenco di argomenti più lungo o molte variabili locali dichiarate e penso che il codice potrebbe trarre vantaggio da una maggiore chiarezza, anche se è forzato.

Ma personalmente odio assolutamente lo m_stile del prefisso, non tanto per l'ungherese, ma perché la sottolineatura è un dolore da scrivere;) Quindi non lo considero un'alternativa. Devo ammettere che ha i suoi punti di forza quando si tratta di intellisense, tuttavia potresti ancora sostenere che se non ricordi le prime lettere di una variabile membro, la tua classe è troppo grande.

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

Perché? A prima vista sai che è un membro, non una variabile di stack. Solo praticità a colpo d'occhio. E richiede meno ingombro rispetto alla parola chiave "this".

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

Definisco sempre campi con myFieldnomi simili e nomi di parametri e nomi di variabili locali anche simili myField. Nessun carattere di sottolineatura, nessun prefisso. Uso thisovunque mi riferisco a un campo. In questo modo posso distinguere i campi da variabili e argomenti locali senza alcun tipo di prefisso. Naturalmente, in un caso come questo thisè richiesta la parola chiave:

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 .

EDIT: la mia risposta non è chiaramente una risposta. Quindi ecco una modifica. Le linee guida sulla codifica Microsoft indicano:

2.6 Denominazione

Non utilizzare un prefisso per le variabili membro ( , m , s_, ecc.). Se si desidera distinguere> tra variabili locali e variabili del membro, è necessario utilizzare "this". In C # e "Me." In VB.NET.

Può essere trovato su: http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx

Quindi sembrerebbe che almeno dalla SM non ci siano linee guida chiare, sebbene un'altra risposta affermi che StyleCop la rende una linea guida. Non c'è autorità su queste cose, quindi suggerirei di prendere una decisione, o in questo caso arrendersi alla propria squadra. Non è un grosso problema.

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

La mia salva da seguire: la mia opinione è che le persone stiano complicando inutilmente il loro stile di codice, e se hanno bisogno di indicare che qualcosa è una variabile a livello di classe potrebbero esserci altri seri problemi strutturali nel codice, come il vecchio metodo di ricetta di mettendo le variabili private ai vertici della classe che ti costringono a scorrere costantemente su e giù.

questo mi sembra una di quelle convenzioni di denominazione "che cosa è" rispetto alle convenzioni di denominazione "cosa fa". La brevità dovrebbe essere favorita sopra essendo esplicita. Questa è una lezione che si ripete spesso con linguaggi dinamici. Non abbiamo bisogno di tutta la lanugine!

Questo. spesso può portare a rumori indesiderati.

Ecco la mia soluzione:

• parameter_names_
• local_variables
• ANY_CONSTANT
• _private_members
• NonPrivateProperties
• _NonPrivateProperty // Backer
• proprietà privata
• _privateProperty // backer