Dois-je préférer des propriétés avec ou sans champs privés?

La base de code dans laquelle je travaille a maintenant la convention d'utiliser des champs privés et des propriétés publiques. Par exemple, la plupart des classes ont leurs membres définis comme ceci:

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

Je sais que ceux-ci peuvent être réécrits sans leurs propriétés privées internes:

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

J'aimerais avoir quelques commentaires à ce sujet:

• Y a-t-il une bonne raison de préférer le style plus ancien et plus explicite au nouveau, plus concis?
• Dois-je écrire de nouvelles classes en utilisant le style concis, ou devrais-je essayer de faire correspondre l'ancien code pour plus de cohérence? La cohérence vaut-elle suffisamment dans ce cas pour justifier l'ancien format?

Il y a quelques cas où le style dit "plus ancien" est toujours requis:

R: Types immuables utilisant l'immuabilité fournie par le langage. Le readonlymodificateur en C # gèle cette valeur après la construction. Il n'y a aucun moyen de reproduire cela avec des propriétés implémentées automatiquement (pour l'instant).

public sealed class FooBarBazInator
{
    private readonly double foo;

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

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

B: Vos getters / setters ont une logique quelconque. Le code WPF et Silverlight (et similaire) lié aux données de vos classes sera implémenté INotifyPropertyChangedcomme suit :

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

À part ça, je dirais utiliser le nouveau style. Gardez votre code concis et offre moins de surface pour que les bogues se faufilent. De plus, s'il doit jamais changer pour inclure la logique, il ne sera pas incompatible avec les signatures.

Je dirais qu'avoir un champ de support explicite est tout simplement inutile: cela rend votre code plus long et plus difficile à lire. Cela ajoute également un potentiel d'erreur:

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

Je pense qu'une erreur comme celle-ci pourrait se produire assez facilement et serait assez difficile à repérer.

Et si vous voulez de la cohérence, faites-le dans l'autre sens: changez le code qui utilise les champs de sauvegarde en code qui utilise les propriétés automatiques. C'est particulièrement facile si vous utilisez un outil de refactoring comme ReSharper (et si vous n'utilisez pas quelque chose comme ça, je pense que vous devriez commencer).

Bien sûr, il y a encore des cas où il est nécessaire d'avoir un champ de support, mais je pense que ce n'est pas pertinent pour cette question.

Même si la question est assez ancienne, j'ai pensé à ajouter quelques points que j'ai lus dans un livre qui mérite d'être mentionné ici.

1. Les moteurs de sérialisation au moment de l'exécution conservent le nom du fichier dans un flux sérialisé. Le nom du champ de sauvegarde pour une propriété implémentée automatiquement (AIP) est déterminé par le compilateur, et il pourrait en fait changer le nom de ce champ de sauvegarde chaque fois que vous recompilez votre code, annulant la possibilité de désérialiser les instances de tout type contenant un AIP. N'utilisez donc pas AIP avec un type que vous souhaitez sérialiser ou désérialiser.

2. Lors du débogage, vous ne pouvez pas placer de point d'arrêt sur une méthode AIP get ou set, vous ne pouvez donc pas facilement détecter quand une application obtient ou définit cette propriété. Vous pouvez définir des points d'arrêt sur des points d'arrêt implémentés manuellement

Y a-t-il une bonne raison de préférer le style plus ancien et plus explicite au nouveau, plus concis?

Pas vraiment. Bien que je soutienne que chaque fois que vous aviez une propriété de passage comme celle-ci, vous auriez dû utiliser un champ public pour commencer.

Dois-je écrire de nouvelles classes en utilisant le style concis, ou devrais-je essayer de faire correspondre l'ancien code pour plus de cohérence? La cohérence vaut-elle suffisamment dans ce cas pour justifier l'ancien format?

En supposant que vous ayez ignoré les conseils ci-dessus et que vous ayez des propriétés d'intercommunication, je ne viserais pas à faire correspondre le style. Idéalement, vous devriez revenir en arrière et refaçonner l'ancien style dans le nouveau style pour être cohérent, mais les chances que les gens interprètent mal ce code soient minces.