Devo preferire proprietà con o senza campi privati?

La base di codice in cui sto lavorando ora ha la convenzione di usare campi privati ​​e proprietà pubbliche. Ad esempio, molte classi hanno i loro membri definiti in questo modo:

// Fields
private double _foo;
private double _bar;
private double _baz;

// Properties
public double Foo
{
    get{ return _foo; }
    set{ _foo = value; }
}

public double Bar
{
    get{ return _bar; }
    set{ _bar = value; }
}

public double Baz
{
    get{ return _baz; }
}

So che questi possono essere riscritti senza le loro proprietà private interne:

public double Foo{ get; set; }
public double Bar{ get; set; }
public double Baz{ get; private set; }

Vorrei qualche input su questo:

• C'è una buona ragione per preferire lo stile più vecchio, più esplicito rispetto a quello più nuovo, più conciso?
• Dovrei scrivere nuove classi usando lo stile conciso o devo cercare di abbinare il codice precedente per coerenza? In questo caso vale la coerenza per giustificare il formato precedente?

Ci sono un paio di casi in cui è ancora richiesto il cosiddetto stile "più vecchio":

A: Tipi immutabili usando l'immutabilità fornita dalla lingua. Il readonlymodificatore in C # congela quel valore dopo la costruzione. Non c'è modo di imitare questo con proprietà implementate automaticamente (ancora).

public sealed class FooBarBazInator
{
    private readonly double foo;

    public FooBarBazInator(double foo)
    {
        this.foo = foo;
    }

    public double Foo
    {
        get
        {
            return this.foo;
        }
    }
}

B: I tuoi getter / setter hanno una logica qualsiasi. I codici WPF e Silverlight (e simili) associati ai dati delle tue classi verranno implementati in questo INotifyPropertyChangedmodo:

public class FooBarBazInator : INotifyPropertyChanged
{
    private double foo;

    public event PropertyChangedEventHandler PropertyChanged;

    public double Foo
    {
        get
        {
            return this.foo;
        }

        set
        {
            this.foo = value;
            this.RaisePropertyChanged("Foo");
        }
    }

    private void RaisePropertyChanged(string propertyName)
    {
        var propertyChanged = this.PropertyChanged;

        if (propertyChanged != null)
        {
            propertyChanged(this, new PropertyChangedEventArgs(propertyName));
        }
    }
}

Oltre a quelli, direi di usare il nuovo stile. Mantiene il codice conciso e offre meno superficie per i bug da insinuare. Inoltre, se dovesse mai essere necessario cambiare per includere la logica, non sarà incompatibile con la firma.

Direi che avere un backing field esplicito è solo un'inutile cruft: rende il tuo codice più lungo e più difficile da leggere. Aggiunge anche potenziale di errore:

public double Bar
{
    get { return _baz; }
    set { _bar = value; }
}

Penso che un errore del genere possa accadere abbastanza facilmente e sarebbe piuttosto difficile da individuare.

E se vuoi coerenza, fallo nell'altro modo: modifica il codice che utilizza i campi di supporto in codice che utilizza proprietà automatiche. Questo è particolarmente facile se usi uno strumento di refactoring come ReSharper (e se non usi qualcosa del genere, penso che dovresti iniziare).

Certo, ci sono ancora casi in cui è necessario avere un backing field, ma penso che non sia rilevante per questa domanda.

Anche se la domanda è piuttosto vecchia, ho pensato di aggiungere un paio di punti che ho letto da un libro che vale la pena menzionare qui.

1. I motori di serializzazione runtime persistono il nome dell'archiviato in un flusso serializzato. Il nome del campo di supporto per una proprietà implementata automaticamente (AIP) è determinato dal compilatore e potrebbe effettivamente cambiare il nome di questo campo di supporto ogni volta che si ricompila il codice, annullando la possibilità di deserializzare istanze di qualsiasi tipo che contenga un AIP. Quindi non utilizzare AIP con alcun tipo che si intende serializzare o deserializzare.

2. Durante il debug, non è possibile impostare un punto di interruzione su un metodo get o set AIP, quindi non è possibile rilevare facilmente quando un'applicazione sta ottenendo o impostando questa proprietà. È possibile impostare punti di interruzione su punti di interruzione implementati manualmente

C'è una buona ragione per preferire lo stile più vecchio, più esplicito rispetto a quello più nuovo, più conciso?

Non proprio. Anche se direi che ogni volta che hai avuto un passaggio attraverso tale proprietà, avresti dovuto usare un campo pubblico per cominciare.

Dovrei scrivere nuove classi usando lo stile conciso o devo cercare di abbinare il codice precedente per coerenza? In questo caso vale la coerenza per giustificare il formato precedente?

Supponendo che tu abbia ignorato i consigli di cui sopra e abbia proprietà passthrough, non mirerei ad abbinare lo stile. Idealmente, dovresti tornare indietro e riformattare il vecchio stile nel nuovo stile per renderlo coerente, ma la possibilità che le persone leggano male quel codice è scarsa.