Whiz-zarD

Wenn es ehrenamtlich ist, kann man es doch auch mal vorstellen, oder nicht?

Ab C# 6.0 gibt es noch eine elegantere Methode über String Interpolation:
Process.Start(command, $"{var1} {var2}");  

Bei Pi und vordefinierte RGB-Farben (RGB-Farben allerdings nur bedingt. Siehe weiter unten) bin ich dabei, dass es Konstanten sind aber Matrikelnummer und Ablauf- und Erstellungsdaten (die mehrzahl von Datum) sind keine Konstanten. Offenbar vermischst du hier final (Java) bzw. readonly (C#) Variablen mit Konstanten, aber da gibt es einen großen Unterschied:
Konstanten sind während des Kompilierens bekannt. Beim Kompilieren wird überall, wo die Konstante benutzt wird, gegen den konkreten Wert ausgetauscht. Darum können Konstanten auch nur integrierte Datentypen sein. Es läuft also erst mal ein Präprozessor, der die konkreten Werte ermittelt und diesen dann überall einfügt. Darum sollte man auch etwas vorsichtig mit Konstanten aus Drittbibliotheken sein. Wenn sich eine Konstante in einer Fremd-DLL ändern sollte, bekommt dein Code erst mal davon nichts mit, bis du dein Code neu kompilierst. Aufgrund dieser Schritte besitzt eine Konstante auch keine Variablenadresse.
Variablen hingegen werden während der Laufzeit initialisiert und sind zur Kompilierzeit nicht bekannt. Das gilt auch für final bzw. readonly Variablen. Final/Readonly Variablen werden per Initialisierung oder per Konstruktor initialisiert. 
Ob man jetzt die Matrikelnummer oder Ablauf- und Erstellungsdatum wirklich final/readonly machen möchte, ist vom Design abhängig aber ich würde das eher nicht tun. Man schränkt sich dann doch sehr extrem ein. Man müsste dann diese Werte im Konstruktor reinreichen und das sollte man bei Geschäftsobjekten nicht machen. Die XML-Deserialisierung vom .Net Framework erwartet z.B. einen parameterlosen Konstruktor. Wenn du jetzt die Studenten aus einer XML-Datei lesen möchtest, würdest du dann schon Probleme bekommen, da die Matrikelnummer readonly wäre und somit über den Konstruktor mitgegeben werden muss. Auch gängige O/R-Mapper (wie z.B. (N)Hibernate, Entitiy Framework oder Dapper) erwarten einen parameterlosen Konstruktor.  Vielleicht möchte man aber auch einfach mal einen Studenten erzeugen ohne eine Matrikelnummer. Dann wird man wieder Probleme bekommen. Man müsste dann wieder eine Factory-Methode schreiben, die einen Studenten mit einer Dummy-Matrikelnummer zurückgibt. Alles Einschränkungen, die man nicht möchte.
Wann sollte man dann also readonly verwenden?
Mir würden da spontan zwei Beispiele einfallen:
z.B. die o.g. RGB-Farben. Da Konstante nur integrierte Datentypen sein dürfen, müsste man einen ganzzahligen Wert nehmen aber man besitzt vielleicht eine RGBColor-Klasse und man möchte über diese Klasse diverse Farben vordefinieren. Dafür bietet sich dann statische readonly Variablen an. Beispiel: public class RGBColor { public static readonly RGBColor Black = new RGBColor { Red = 0, Green = 0, Blue = 0 }; public static readonly RGBColor White = new RGBColor { Red = 255, Green = 255, Blue = 255 }; public int Red { get; set; } public int Green { get; set; } public int Blue { get; set; } } So hätte man die Farben Schwarz und Weiß als statische readonly Variablen deklariert, die sich per Laufzeit nicht ändern und man kann per RGBColor.Black bzw. RGBColor.White darauf zugreifen.
Als zweites Beispiel würde mir die Verwendung von Dependency Injection einfallen. Beispiel:
public ClassA { private readonly IDependency dependency; public ClassA(IDependency dependency) { if(dependency == null) throw new ArgumentException(); this.dependency = dependency; } public int DoSomething() { return this.dependency.DoSomething(); } } Ist jetzt zwar ein sehr blödes Beispiel, aber es verdeutlicht, dass ClassA von etwas abhängig ist, was das Interface IDependency implementiert und um sicher zu geben, dass es intern nicht überschrieben wird, wird es als readonly deklariert. Dies ist aber eigentlich auch nur eine Sicherheitsmaßnahme, die nicht not tut, denn in der Regel weiß ich, wie die Klasse tickt, wenn ich sie ändern sollte. Von außen habe ich ja sowieso kein Zugriff. 
Man sollte sich also im Klaren sein, was man mit dem readonly-Modifizierer erreichen möchte. Die Matrikelnummer sollte zwar nicht änderbar sein, ja aber wir kennen die Domäne nicht, wo diese Klasse verwendet wird und ggf. ist die readonly-Einschränkung zu viel für den Verbraucher, sodass diese Klasse für ihn unbrauchbar wird. Siehe die Deserialisierung oder es kann ja durchaus möglich sein, dass man die Matrikelnummer mal doch ändern möchte und dann müsste man einen hohen Aufwand betreiben um so etwas realisieren zu können, wenn man nicht in der Lage ist, die Klasse ändern zu dürfen, weil sie vielleicht in einer Drittbibliothek steckt.

Kann ich bestätigen.
Als ich vor über 10 Jahren meine Ausbildung abgeschlossen hatte, wollte auch keiner die Berichtshefte sehen. Nicht mal auf Nachfrage, ob die IHK/Prüfer die Berichtshefte sehen wollten, wurde verneint. Ich hab also diese Dinger umsonst geschrieben.
Ich halte es auch für Zeitverschwendung, wenn die IHK diese doch anschaut, um zu schauen, ob der Betrieb ihre Arbeit gemacht hat, da der Ausbilder die Berichtshefte unterzeichnen muss. Wenn da dann nur drinnensteht, dass der Azubi nur Kaffee gekocht hat, wird der Ausbilder nicht ganz froh sein und fordern, dass der Azubi die Berichte neu schreibt, bis es passt.

Na ja, ich arbeite inzwischen seit einigen Jahren als Softwareentwickler und das, was ich schon in einigen Firmen an Code gesehen habe, geht echt unter keine Kuhhaut. Da schreiben selbst Entwickler, die 20+ Jahre Berufserfahrung haben, den allergrößten Mist an Code, den man sich nur vorstellen kann. Da werden Design Patterns auf abstruse Art- und Weisen oder sogar komplett falsch implementiert oder viele haben selbst nach 20 Jahren die Objektorientierung nicht verstanden und schreiben weiterhin spaghetticode wie in alten C-Zeiten.
An der Software, wo ich jetzt arbeite, hat man statische Klassen aus Faulheit verwendet. Damit man die Klassen nicht instanziieren braucht, hat man sie statisch gemacht (yeeaah! Man spart sich eine Zeile Code...). Hier wurde Mikro-Optimierung auf die Spitze getrieben und von solchen Klassen gibt es hunderte und diese Klassen sorgen in Unittests immer wieder für Probleme, weil z.B. die Methoden Queries an die Datenbank schicken. Der Unittest ist dann von der Datenbank abhängig. Also testet man im Unittest nicht mehr die Methoden an sich, sondern schon komplexe Programm-Strukturen auf einen Schlag. Das Problem ist nun, dass man von statischen Klassen nicht erben und somit nicht mocken kann. Martin Fowler hatte diesbezüglich mal ein Blog-Eintrag geschrieben. Sein Beispiel ist aber relativ trivial. Stell dir mal vor, du hast im Code hunderte solcher Klassen, die hunderte von Abhängigkeiten besitzen, weil man laufe der Jahren die Klassen immer um weitere Methoden ergänzt hat und die Klassen nun mehrere Tausend Zeilen beinhalten. Ist ja auch so schön einfach, einfach statische Klassen zu erweitern ...
Mir persönlich geht es auch eher darum, dass du ein gespürt dafür bekommst, wo die Probleme bei statischen Methoden/Klassen liegen und dass man schon wissen sollte, wann dieses Schlüsselwort angebracht ist und wann nicht. Nur weil man die Syntax versteht, heißt es noch lange nicht, dass man auch sauberen Code schreiben kann und das finde ich viel wichtiger als so manches andere aber das bekommt man von Firmen nicht so richtig beigebracht, weil man lieber aufgrund des Zeitdrucks lieber schmutzigen Code schreibt, der zwar jetzt schnell geschrieben werden kann und somit kostengünstig ist aber spätestens in einem halben Jahr hohe Kosten verursacht, weil der Code unwartbar ist.