プライベートフィールドの有無にかかわらずプロパティを優先する必要がありますか？

現在作業しているコードベースには、プライベートフィールドとパブリックプロパティを使用する規則があります。たとえば、ほとんどのクラスのメンバーは次のように定義されています。

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

内部のプライベートプロパティがなくてもこれらを書き換えることができます。

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

これに関するいくつかの入力をお願いします。

• 新しい、より簡潔なスタイルよりも古い、より明確なスタイルを好む正当な理由はありますか？
• 簡潔なスタイルを使用して新しいクラスを作成する必要がありますか、それとも一貫性のために古いコードと一致させる必要がありますか？この場合、一貫性は古いフォーマットを正当化するのに十分な価値がありますか？

いわゆる「古い」スタイルがまだ必要な場合がいくつかあります。

A：言語提供の不変性を使用した不変型。readonlyC＃の修飾子は、構築後にその値を凍結します。（まだ）自動的に実装されたプロパティでこれを模倣する方法はありません。

public sealed class FooBarBazInator
{
    private readonly double foo;

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

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

B：ゲッター/セッターには、あらゆるロジックがあります。クラスにデータバインドされるWPFおよびSilverlight（および同様の）コードはINotifyPropertyChanged、次のように実装します。

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

それ以外は、新しいスタイルを使用すると思います。コードを簡潔に保ち、バグが入り込む表面積を小さくします。さらに、ロジックを含めるために変更する必要がある場合、署名と互換性がありません。

バッキングフィールドを明示的に指定することは無意味です。コードが長くなり、読みにくくなります。また、エラーの可能性が追加されます。

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

このようなエラーは非常に簡単に発生する可能性があり、見つけるのは非常に難しいと思います。

一貫性が必要な場合は、別の方法で行います。バッキングフィールドを使用するコードを自動プロパティを使用するコードに変更します。ReSharperのようなリファクタリングツールを使用する場合、これは特に簡単です（そのようなものを使用しない場合は、開始する必要があると思います）。

もちろん、バッキングフィールドが必要な場合もありますが、この質問には関係ないと思います。

質問はかなり古いものですが、ここで言及する価値のある本から読んだいくつかのポイントを追加することを考えました。

1. ランタイムシリアル化エンジンは、シリアル化されたストリームにフィールドの名前を保持します。自動実装プロパティ（AIP）のバッキングフィールドの名前はコンパイラーによって決定され、コードを再コンパイルするたびにこのバッキングフィールドの名前を実際に変更する可能性があります。 AIP。したがって、シリアライズまたはデシリアライズする予定のタイプでAIPを使用しないでください。

2. デバッグ時には、AIPのgetメソッドまたはsetメソッドにブレークポイントを設定できないため、アプリケーションがこのプロパティを取得または設定するタイミングを簡単に検出できません。手動で実装されたブレークポイントにブレークポイントを設定できます

新しい、より簡潔なスタイルよりも古い、より明確なスタイルを好む正当な理由はありますか？

あんまり。私はあなたがそのようなパススループロパティを持っているときはいつでも、最初からパブリックフィールドを使用するべきだと主張します。

簡潔なスタイルを使用して新しいクラスを作成する必要がありますか、それとも一貫性のために古いコードと一致させる必要がありますか？この場合、一貫性は古いフォーマットを正当化するのに十分な価値がありますか？

上記のアドバイスを無視し、パススループロパティを持っていると仮定すると、スタイルを一致させるつもりはありません。理想的には、一貫性を保つために古いスタイルを新しいスタイルにリファクタリングしますが、そのコードを誤解する可能性はわずかです。