¿Debo preferir propiedades con o sin campos privados?

La base de código en la que estoy trabajando ahora tiene la convención de usar campos privados y propiedades públicas. Por ejemplo, la mayoría de las clases tienen sus miembros definidos así:

// 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; }
}

Sé que estos pueden reescribirse sin sus propiedades privadas internas:

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

Quisiera alguna entrada sobre esto:

• ¿Hay una buena razón para preferir el estilo más antiguo y explícito sobre el más nuevo y conciso?
• ¿Debo escribir nuevas clases usando el estilo conciso, o debería tratar de hacer coincidir el código anterior para mantener la coherencia? ¿La coherencia vale lo suficiente en este caso para justificar el formato anterior?

Hay un par de instancias donde aún se requiere el llamado estilo "antiguo":

R: Tipos inmutables que usan la inmutabilidad proporcionada por el lenguaje. El readonlymodificador en C # congela ese valor después de la construcción. No hay forma de imitar esto con propiedades implementadas automáticamente (todavía).

public sealed class FooBarBazInator
{
    private readonly double foo;

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

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

B: Tus captadores / establecedores tienen alguna lógica. El código WPF y Silverlight (y similares) que están vinculados a datos a sus clases se implementarán de la siguiente INotifyPropertyChangedmanera:

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));
        }
    }
}

Aparte de eso, diría que usa el nuevo estilo. Mantiene su código conciso y ofrece menos área de superficie para que se introduzcan los errores. Además, si alguna vez necesita cambiar para incluir la lógica, no será incompatible con la firma.

Diría que tener un campo de respaldo explícito es simplemente inútil: hace que su código sea más largo y difícil de leer. También agrega potencial de error:

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

Creo que un error como este podría ocurrir con bastante facilidad y sería bastante difícil de detectar.

Y si desea coherencia, hágalo de la otra manera: cambie el código que usa campos de respaldo en código que usa propiedades automáticas. Esto es especialmente fácil si usa una herramienta de refactorización como ReSharper (y si no usa algo así, creo que debería comenzar).

Por supuesto, todavía hay casos en los que es necesario tener un campo de respaldo, pero creo que eso no es relevante para esta pregunta.

Aunque la pregunta es bastante antigua, pensé en agregar un par de puntos que leí de un libro que vale la pena mencionar aquí.

1. Los motores de serialización en tiempo de ejecución conservan el nombre del archivado en una secuencia serializada. El compilador determina el nombre del campo de respaldo para una propiedad implementada automáticamente (AIP), y en realidad podría cambiar el nombre de este campo de respaldo cada vez que recompila su código, negando la capacidad de deserializar instancias de cualquier tipo que contenga un AIP Por lo tanto, no use AIP con ningún tipo que desee serializar o deserializar.

2. Al depurar, no puede poner un punto de interrupción en un método get o set de AIP, por lo que no puede detectar fácilmente cuándo una aplicación obtiene o configura esta propiedad. Puede establecer puntos de interrupción en puntos de interrupción implementados manualmente

¿Hay una buena razón para preferir el estilo más antiguo y explícito sobre el más nuevo y conciso?

Realmente no. Aunque podría argumentar que cada vez que tiene un pase a través de una propiedad como esa, debería haber utilizado un campo público para empezar.

¿Debo escribir nuevas clases usando el estilo conciso, o debería tratar de hacer coincidir el código anterior para mantener la coherencia? ¿La coherencia vale lo suficiente en este caso para justificar el formato anterior?

Suponiendo que ignoraste los consejos anteriores y tienes propiedades pasantes, no trataría de hacer coincidir el estilo. Idealmente, volvería y refactorizaría el estilo antiguo en el nuevo estilo para que sea coherente, pero la posibilidad de que la gente lea mal ese código es escasa.