5

私はさまざまなプロジェクトで、フィールドのグループの後にプロパティのグループが続くこのレイアウトを見てきました (そして使用しました)。

private int MyIntField;
private string MyStringField;

public int MyInt { 
    get { return MyIntField; }
    set { MyIntField = value; }
}    
public string MyString { 
    get { return MyStringField; }
    set { MyStringField = value; }
}

また、プロパティの横にフィールドがあるこのレイアウトにも遭遇しました。

private int MyIntField;
public int MyInt { 
    get { return MyIntField; }
    set { MyIntField = value; }
}    

private string MyStringField;
public string MyString { 
    get { return MyStringField; }
    set { MyStringField = value; }
}

一方が他方よりも優れていると考える理由はありますか? ほとんどのコーディング標準ではオプション #1 が推奨されていると思いますが、操作するプロパティの横にフィールドがあると便利な場合があります。

注: 自動実装されたプロパティを使用できない重要なプロパティを想定しています。

4

6 に答える 6

7

チームが快適に感じるものなら何でもいいと思います。プロジェクト/会社/言語の基準を決めて、それを守りましょう。私はプライベート変数をすべて一緒に、メソッド/インターフェースを一緒に、プライベートメンバーを好みます....あなたは要点を理解していると思います。

于 2008-11-08T14:12:33.153 に答える
4

私はそれらをクラスのトップにグループ化します。

実際、私のプライベート属性を超える唯一のものは、クラスのすべての定数です。

于 2008-11-08T14:13:47.987 に答える
3

フィールドを上部にグループ化し、プロパティを別の場所に配置するのが好きです。これは、Microsoft StyleCopが推奨するものでもあります。

于 2008-11-08T14:42:30.987 に答える
2

プライベート メンバーがパブリック ゲッター/セッターを持っているかどうかを一目で確認できる規則であるため、後者のアプローチを使用します。ただし、どちらにしても大したことではありません。

于 2008-11-08T14:14:37.393 に答える
1

前述の Kenny の言葉を繰り返しますが、実際には組織のコーディング標準がすべてです。誰もが独自の意見を持っているようですが、あるスタイルを他のスタイルよりも客観的に分類することは困難です.

私は通常、アクセス修飾子ごとにデータとメソッドをグループ化することを好む傾向があるため、この場合はオプション #1 を使用します。これは、デザインではなくインターフェイスを強調するためです。つまり、将来 MyInt 修飾子の実装を透過的に変更することができます (おそらく、バッキング変数を格納する必要はありません)。

于 2008-11-08T14:19:14.437 に答える
1

補足として、自動プロパティはどこに収まりますか?

C# 3.0 自動プロパティ - 役に立つかどうか

于 2008-11-08T15:47:48.890 に答える