Devo rendere una variabile readonly quando la modifica, ma in realtà non la imposta al di fuori del costruttore?

Question

Devo rendere una variabile readonly quando la modifica, ma in realtà non la imposta al di fuori del costruttore?

#1 da (3 voti)
#2 da (3 voti)
#3 da (1 voti)

2

Sfondo:

Stavo scrivendo del codice. Sembrava qualcosa del genere:

class X
{
    private List<int> _myList = new List<int>();
    public void MyMethod(int x)
    {
        _myList.Add(x);
    }
}

R # ha suggerito di rendere _myList readonly. Non ero così sicuro, come se tecnicamente potessi renderlo in sola lettura, penso che sarebbe un po 'confuso farlo, poiché sto ancora modificando la lista, semplicemente non la riassegnerò. Quindi, mentre potrei farlo in sola lettura, non sono sicuro se dovrei.

Domanda:

Devo rendere variabili come questa in sola lettura? Perché? In caso negativo, perché R # lo suggerisce?

coding-style c#

posta It'sNotALie. 09.08.2013 - 20:12

fonte

3 risposte

3

Dico sì, aggiungi readonly . Per due motivi:

se tu (o un compagno di squadra in futuro) provi a riassegnare a quella variabile in un metodo successivo, ti darà un errore in fase di compilazione. R # noterà l'errore anche prima. Quindi, è meglio pensarlo come un indicatore e un esecutore di intenti. Anche se intendi per riassegnarlo in un secondo momento, ti costringe a pensare al design un po 'di più e non ti farà molto male rimuoverlo.
il compilatore e / o JITter possono utilizzare le conoscenze di assegnazione singola trasmesse per fornire potenzialmente ottimizzazioni. Non garantito, ma lo faccio per la prima ragione - questo è un possibile bonus.

risposta data 09.08.2013 - 21:04

fonte

1

Stai ricevendo il suggerimento perché non stai modificando la lista stessa, ma solo i contenuti. Se hai riassegnato la lista interamente da qualche parte, non sarebbe stata di sola lettura, ma perché stai semplicemente aggiornando i contenuti la lista stessa non cambia.

Questo è simile a come si può avere un oggetto readonly, ma si cambiano ancora i valori su quell'oggetto. La variabile membro non cambia, ma l'oggetto stesso è ancora mutevole.

risposta data 09.08.2013 - 20:22

fonte

Leggi altre domande sui tag coding-style c#

Alcune aspettative di comportamento possono essere parte del contratto di un'interfaccia? Risolvi la sincronizzazione

score 3 · Accepted Answer

Se pensi che sia fonte di confusione, come hai detto, allora non farlo. Se altri membri della tua squadra che probabilmente avranno bisogno di lavorare con questo codice non hanno la differenza tra riferimenti e oggetti sufficientemente radicato nei loro cervelli quindi non farlo per evitare confondendoli. Se tutti voi capite i concetti in modo così efficace che questo non è affatto confuso, e pensate che potrebbe essere d'aiuto nel comunicare che il riferimento alla lista non è cambiato, quindi contrassegnatelo come di sola lettura.

Ricorda che la tua squadra non ha sempre bisogno di fare la stessa cosa di chiunque altro sul pianeta. Fai ciò che funziona meglio per le persone che dovranno effettivamente toccare questo codice (con alcune considerazioni di base per le persone che dovranno toccare il codice che non è ancora presente nel team.)