Top 10 der häufigsten Fehler von C#-Programmierern

21. Mai 2014

Ein Blog-Beitrag – Top 10 Mistakes that C# Programmers Make – hat bei uns intern zu ein paar Diskussionen geführt. Teilweise über die Frage ob das wirklich typische Probleme von Entwicklern sind, teilweise auch über die Aussagen die der Autor trifft.

Der Autor gibt leider keinen Hinweis darauf, woher er diese “Statistik” hat – vermutlich basiert das also auf Erfahrungen in seiner täglichen Arbeit. Leider wird aus seinem Resümee nicht wirklich klar, in welchem Umfeld er sich bewegt und in welcher Rolle…

Ich selbst bin im Projektgeschäft bei Kunden im Einsatz und habe dort mit einer ganzen Bandbreite von Entwicklern zu tun: Vom Entwickler, der die Fachlichkeit beherrscht, aber technisch nicht immer ganz auf der Höhe der Zeit ist, bis hin zu technischen Spezialisten. Vom Anfänger bis hin zum erfahrenen Entwickler. Insbesondere mache ich sehr viel Coaching für Entwickler und Reviews von Anwendungen.

Ich denke also, dass ich mir zu dieser Frage eine Meinung erlauben darf ;-)…

Ich bin in manchen Dingen nicht Patricks Meinung, aber ich will seine Liste nicht ganz verwerfen – in seinem Beitrag sind viele Aussagen enthalten, die Hand und Fuß haben. Daher nehme ich mir seine Punkte einzeln vor und ergänze im Anschluss die Liste mit den Punkten die mir fehlen.

 

Common Mistake #1: Using a reference like a value or vice versa

Programmers of C++, and many other languages, are accustomed to being in control of whether the values they assign to variables are simply values or are references to existing objects. In C#, however, that decision is made by the programmer who wrote the object, not by the programmer who instantiates the object and assigns it to a variable.  This is a common “gotcha” for newbie C# programmers.

   1: Point point1 = new Point(20, 30);

   2: Point point2 = point1;

   3: point2.X = 50;

   4: Console.WriteLine(point1.X);       // 20 (does this surprise you?)

   5: Console.WriteLine(point2.X);       // 50

   6:  

   7: Pen pen1 = new Pen(Color.Black);

   8: Pen pen2 = pen1;

   9: pen2.Color = Color.Blue;

  10: Console.WriteLine(pen1.Color);     // Blue (or does this surprise you?)

  11: Console.WriteLine(pen2.Color);     // Blue

Patrick hat sein Code-Beispiel ganz geschickt gewählt: Auf den schnellen Blick ist nicht sofort ersichtlich, ob die beteiligten Klassen Wert– oder Referenztypen sind. Typisches Beispiel bei dem Erwartung und Realität auseinander laufen ist hier die Klasse String.

Trotzdem hätte es dieser Punkt nicht in meine Liste geschafft, schon gar nicht auf Platz 1.

Mir ist noch kein erfahrener C++-Entwickler untergekommen, der damit Probleme gehabt hätte, dass class und struct in .NET eine etwas andere Bedeutung gehabt hätten. Eher wird der “Kontrollverlust” beklagt, weil manche Optionen (etwa const) nicht in der gleichen Flexibilität zur Verfügung stehen. Und komplett unerfahrene Entwickler (oder auch Entwickler mit Java-Background) haben eher grundsätzliche Probleme mit dem Konzept von Werttypen, insbesondere wenn es um Themen wie Boxing geht.

Aber so oder so: Wenn man dieses Problem hat, dann läuft das Programm nicht richtig. Der Code muss also nur einmal durchlaufen werden (in manchen Konstellationen greift einem auch noch der Compiler unter die Arme) um das Problem offensichtlich zu machen. Damit mag das eine typische Lernschwelle sein, die ein angehender C#-Entwickler überwinden muss. Ist diese Hürde aber erst einmal genommen, dann erledigt sich das Problem damit in der Regel von selbst.

Ergo: Von der Lernphase abgesehen ist das Problem aus meiner Sicht eher akademischer Natur, als von praktischer Relevanz.