Devo preferir propriedades com ou sem campos particulares?

A base de código em que estou trabalhando agora tem a convenção de usar campos privados e propriedades públicas. Por exemplo, a maioria das classes tem seus membros definidos assim:

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

Eu sei que estes podem ser reescritos sem suas propriedades privadas internas:

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

Eu gostaria de alguma entrada sobre isso:

• Existe uma boa razão para preferir o estilo mais antigo e explícito do que o mais novo e conciso?
• Devo escrever novas classes usando o estilo conciso ou devo tentar corresponder o código mais antigo para obter consistência? A consistência vale o suficiente neste caso para justificar o formato mais antigo?

Existem algumas instâncias em que o chamado estilo "mais antigo" ainda é necessário:

R: Tipos imutáveis ​​usando a imutabilidade fornecida pelo idioma. O readonlymodificador em C # congela esse valor após a construção. Ainda não há como imitar isso com propriedades implementadas automaticamente.

public sealed class FooBarBazInator
{
    private readonly double foo;

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

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

B: Seus getters / setters têm qualquer lógica. Os códigos WPF e Silverlight (e similares) vinculados a suas classes serão implementados da seguinte INotifyPropertyChangedmaneira:

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

Além desses, eu diria que use o novo estilo. Mantém seu código conciso e oferece menos área de superfície para os bugs surgirem. Além disso, se precisar mudar para incluir a lógica, não será incompatível com a assinatura.

Eu diria que ter um campo de apoio explícito é apenas uma crosta inútil: torna seu código mais longo e difícil de ler. Ele também adiciona potencial de erro:

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

Acho que um erro como esse poderia acontecer com bastante facilidade e seria bastante difícil de detectar.

E se você deseja consistência, faça o contrário: altere o código que usa campos de backup em código que usa propriedades automáticas. Isso é especialmente fácil se você usar uma ferramenta de refatoração como o ReSharper (e se você não usar algo assim, acho que deveria começar).

Obviamente, ainda existem casos em que ter campo de apoio é necessário, mas acho que isso não é relevante para esta questão.

Embora a pergunta seja bastante antiga, pensei em acrescentar alguns pontos que li em um livro que vale a pena mencionar aqui.

1. Os mecanismos de serialização em tempo de execução mantêm o nome do arquivado em um fluxo serializado. O nome do campo de apoio para uma Propriedade implementada automaticamente (AIP) é determinado pelo compilador e pode realmente alterar o nome desse campo de apoio toda vez que você recompilar seu código, negando a capacidade de desserializar instâncias de qualquer tipo que contenha um AIP. Portanto, não use AIP com nenhum tipo que você queira serializar ou desserializar.

2. Ao depurar, você não pode colocar um ponto de interrupção em um método AIP get ou set, portanto, não é possível detectar facilmente quando um aplicativo está obtendo ou configurando essa propriedade. Você pode definir pontos de interrupção em pontos de interrupção implementados manualmente

Existe uma boa razão para preferir o estilo mais antigo e explícito do que o mais novo e conciso?

Na verdade não. Embora eu argumentasse que sempre que você passou por uma propriedade como essa, deveria ter usado um campo público para começar.

Devo escrever novas classes usando o estilo conciso ou devo tentar corresponder o código mais antigo para obter consistência? A consistência vale o suficiente neste caso para justificar o formato mais antigo?

Supondo que você ignorou o conselho acima e tenha propriedades de passagem, não pretendo corresponder ao estilo. Idealmente, você retornaria e refatoraria o estilo antigo para o novo para ser consistente, mas a chance de as pessoas interpretarem mal esse código é pequena.