In c# kann man konstante Werte auf 2 Arten definieren: Mit dem Schlüsselwort const oder als static readonly. Mit const werden Werte zur Kompilierungszeit definiert (compile time constants). Als static readonly definierte Konstanten sind Laufzeitkonstanten (runtime constants).

// comile time constant
public const int ValueAddedTax = 19;
// runtime constant
public static readonly int Period = 2012;

Wann soll man jetzt welche Variante verwenden?

Die Konstante wird bei der Kompilierung als Wert übersetzt. Die Zeile

if (product.VAT == ValueAddedTax)

kompiliert also in IL (ungefähr) zu

if (product.VAT == 19)

Dies hat natürlich zur Folge, dass alle Clients einer Anwendung neu kompiliert werden müssen, wenn sich eine Konstante ändert. Bzw. kann es zu merkwürdigem Verhalten kommen, wenn sich ein konstanter Wert ändert und eine abhängige Assembly in einer alten Version vorliegt. Dafür hat die Konstante einen leichten Geschwindigkeitsvorteil.

Eine mit const erstellt Konstante ist Teil des öffentliches Interfaces einer Klasse. Ändert sich die Konstante, dann ändert sich der Vertrag und alle Clients müssen neu kompiliert werden!

Laufzeitkonstanten werden erst zur Laufzeit ausgewertet. Alle Clients halten also eine Referenz auf die Variable – und nicht auf den Wert. Es ist also nicht nötig Clients neu zu kompilieren. Eine Änderung schlägt sich sofort durch und es ist nicht nötig die Clients neu zu kompilieren.

Kompilierungszeitkonstanten können nur einfache Typen (int, string etc.) sein. Komplexe Objekte (z.B. DateTime) müssen eh als Laufzeitkonstante erstellt werden. Dafür gibt es etliche Stellen, an denen nur Kompilierungszeitkonstanten verwendet werden können. Dazu zählen Standardwerte für optionale Parameter oder für Attribute.

Fazit

Verwenden Sie const für alle Konstanten, die sich nie ändern, die Teil des öffentlichen Vertrages einer Klasse sind und bei denen die Geschwindigkeit eine große Rolle spielt. Ansonsten für alle anderen als default static readonly verwenden.

Verwenden Sie nicht const für Konfigurationen wie URL’s oder ähnliches. Dies kann zu schwer auffindbaren Bugs führen, wenn eine abhängige Assembly nicht mit der neuen Version rekompiliert wurde.