Const
クライアントコードに組み込まれています。Readonly
そうではありません。しかしconst
、より高速です。ほんの少しかもしれませんが。
問題は、よりも優先すべきシナリオはありますconst
かreadonly
? または言い換えると、実質的に常にreadonly
a の代わりに aを使用する方が良いとは限りませんconst
(上記のベーキングのことを念頭に置いてください)。
「const」が適切なのは、コーディングしている仕様が、作成しているプログラムよりも耐久性がある場合だけだと思います。たとえば、HTTP プロトコルを実装している場合、"GET" の const メンバーを持つことは適切です。なぜなら、それは決して変更されないからです。値は後で。
将来のバージョンで値を変更する必要がある場合は、const を使用しないでください。
おー!また、測定していない限り、const が読み取り専用フィールドよりも高速であると想定しないでください。JIT の最適化により、実際にはまったく同じになる可能性があります。
C# における 'const' と 'readonly' の違いの簡単な概要: 'const':
- 静的にすることはできません。
- 値はコンパイル時に評価されます。
- 宣言時にのみ初期化されます。
「読み取り専用」:
- インスタンスレベルまたは静的のいずれかです。
- 値は実行時に評価されます。
- 宣言またはコンストラクターのコードで初期化できます。
訂正:上記の状態 const は静的にすることはできません。それは誤称です。それらはすでに静的であるため、 static キーワードを適用することはできません。
したがって、コンパイル時に評価する静的アイテムには const を使用します。
switch ステートメント fwiw では、const 値をケースとして使用できます。
私は通常、真空中の光の速度など、決して変わらないことがわかっているものにのみ const を使用します。
変更される可能性があるものについては、読み取り専用を好みます。このようにして、変更が発生した場合に 1 つの dll を再コンパイルするだけで済みます。この経験則の例外は、変数がそれ自体のアセンブリに対してプライベート/保護/フレンドリである場合です。そのような場合は、const を使用しても安全です。
readonly は、初期化が単純でない場合に役立ちます。
const は、コンパイルする前に値が確かな場合に使用できます。
ある意味で、readonly は実行時の const であり、const はコンパイル時の定数値です。
編集: www.koders.com を使用していくつかのコードを見ると、const を使用できた場所で readonly が使用されていることがわかります。その背後にある理由は、コンストラクターで変更可能である可能性があると思います(必要な場合)。const (特にパブリック) の場合、コードによってはクライアント コードが壊れる可能性があります。
const はクラスや構造体 (Skeet 氏が指摘したように文字列定数と null を除く) には使用できず、値型にのみ使用でき、静的フィールドとしてアクセスされます。const の値はコンパイル時に設定され、宣言時に設定する必要があります。
readonly は、列挙以外のすべてに使用でき、静的フィールドまたはインスタンス フィールドのいずれかになります。読み取り専用の値は実行時に設定され、呼び出されるコンストラクターに応じて異なる設定が可能です。
const、readonly、および static キーワードの概要については、こちらのページを参照してください。
実行時にテストされる修飾子よりも、コンパイル時にテストされる修飾子を優先する必要があります(このコンテキストでは、読み取り専用よりもconst)。また、必要なセマンティクスをサポートする修飾子を常に使用する必要があります。何かを変更することを意図していない場合は、それを保護してください。そうしないと、誰かが(偶然または無知によって)何かを書き込みます。
宣言で値を設定でき、コンストラクターを待つ必要がない場合は常に const を使用する必要があります。
const の適切な使用法は、キーと値のペアのキーです。たとえば、(ApplicationSettings ではなく) AppSetting をまだ使用している場合、キーの名前を構成設定に読み込むことはあまり意味がありません。複数の場所で使用する場合は、キーを const に貼り付けます。