Gestern habe ich in meinem Blogeintrag Accuracy unter anderem versucht, die Frage zu beantworten, warum Peter Bucher und mir Programmierstandards und deren strikte Einhaltung so wichtig sind:

Aus diesem Grund erachten auch Peter und ich Programmierstandards als dermaßen wichtig: Sie erfüllen eben nicht nur die im Extreme Programming verfolgte Intention, gemeinsame Verantwortlichkeit zu etablieren, sondern ermöglichen uns auch, den Code des anderen schneller zu verstehen und uns gegenseitig zu helfen.

Im Grunde steckt darin auch schon die Antwort auf die im Titel dieses Blogeintrages gestellte Frage: Wozu sollte man sich als Entwickler an Programmierstandards halten?

Nun mag der ein oder andere einwenden, dass er ohnehin nicht im Team, sondern nur alleine entwickelt, dass für ihn also das Argument der Etablierung einer gemeinsamen Verantwortlichkeit nicht zählt. Doch selbst dann bin ich der Meinung, dass es durchaus Sinn ergibt, sich an Programmierstandards zu halten.

Warum? Dafür gibt es mehrere Gründe:

• Verstehen: Auch einem allein arbeitenden Entwickler helfen Programmierstandards, sich auf das Wesentliche zu konzentrieren und der äußeren Form zunehmend weniger Aufmerksamkeit schenken zu müssen, da er sie nach und nach verinnerlicht. Dennoch degeneriert die Form nicht, so dass der Code auch mittel- und langfristig gut lesbar und damit verständlich bleibt.
• Fragen: Viele Entwickler suchen – auch wenn sie prinzipiell alleine arbeiten – ab und an Hilfe in der Community, sei es in Foren oder in Newsgroups. Sofern dann Code gepostet werden muss, ist es für die Antwortenden ausgesprochen hilfreich, wenn sich der Autor an gängige Programmierstandards gehalten hat – das Verständnis fällt leichter, als wenn man sich erst durch die Syntax kämpfen muss, bevor man die eigentliche Frage nachvollziehen kann. Die Einhaltung der Programmierstandards erleichtert in diesem Fall also die Kommunikation nach außen.
• Lernen: Analog dazu vereinfacht die Gewöhnung an Programmierstandards auch die Kommunikation nach innen, denn die meisten Autoren halten sich ebenfalls an gängige und etablierte Standards.

Unabhängig von der Frage, ob man sich an solche Standards halten sollte, ist übrigens die Frage, welche Standards denn als Referenz gelten sollen: Hier gibt es schließlich – je nachdem wen man fragt oder in welchem Projekt man beteiligt ist – ausgesprochen unterschiedliche Auffassungen.

Als Beispiel hierzu kann ein einfaches Hallo Welt-Programm dienen, einmal in C# und einmal in Java. Obwohl es sich bei C# und Java um objektorientierte Sprachen handelt und sich das grundlegende Vorgehen prinzipiell sehr ähnelt, weisen beide Quellcodes doch einige Unterschiede auf.

Während es in C# beispielsweise etabliert ist, geschweifte Klammern in einer eigenen Zeile zu positionieren und Methodennamen groß zu schreiben, gilt in Java das genaue Gegenteil. Zweifelsohne kann ein Entwickler, der C# beherrscht, das Java-Programm problemlos lesen und verstehen – ebenso umgekehrt.

Sobald jedoch Modifikationen vorgenommen werden sollen, fällt die Einhaltung der jeweiligen Standards schwer: Es wird vorkommen, dass geschweifte Klammern falsch gesetzt werden, was dann letztlich die Lesbarkeit verschlechtert.

Natürlich kann man nicht sagen, dass das eine richtig und das andere falsch wäre – es handelt sich bei Programmierstandards immer nur um formale und vor allem willkürliche Übereinkünfte zwischen mehreren Entwicklern: Man hätte es ebensogut anders machen können, hat sich aber für eine Variante entschieden.

Daraus kann man dann die erste Regel im Zusammenhang mit Programmierstandards herleiten: Prinzipiell ist es egal, wie Code formatiert wird – so lange die Formatierung einheitlich durchgeführt wird.

Nichtsdestotrotz haben sich einige Programmierstandards mehr und andere minder etabliert. Microsoft selbst schlägt für C# entsprechende Regeln vor, die im Kontext von .NET etabliert sind und als allgemein anerkannt gelten: Sofern von diesen Best Practices abgewichen wird, sollte dies wohlüberlegt und begründet geschehen.

Peter und ich haben uns daher für die nächsten Wochen vorgenommen, die von uns verwendeten Programmierstandards vorzustellen, zu erläutern, warum wir gewisse Dinge so und nicht anders machen, und hoffen, das Thema Programmierstandards auf diesem Wege dem ein oder anderen Entwickler schmackhaft machen zu können.

Wie bereits erwähnt sind natürlich auch die von uns vorgestellten Programmierstandards nur eine mögliche Variante von vielen – sie haben sich jedoch in unserer tagtäglichen Praxis als nützlich erwiesen und etabliert.

Vor zwei Wochen habe ich begonnen, mich ausführlich mit Extreme Programming zu beschäftigen, nicht zuletzt deshalb, weil diese Methodik – zumindest in weiten Teilen –meine persönliche Vorgehensweise widerspiegelt.

Als essenziell wird im Extreme Programming die Einhaltung von Programmierstandards angesehen, da diese als Rahmen für die gemeinsame Verantwortlichkeit aller Entwickler für den geschriebenen Code fungieren.

In einer Diskussion mit Peter Bucher zu diesem Thema kamen wir zu dem Schluss, dass es für uns beide nur schwer vorstellbar ist, nach gänzlich anderen als den von uns eingehaltenen Programmierstandards zu entwickeln. Aus dieser Feststellung resultierte schließlich die Frage, warum uns Standards und deren Einhaltung eigentlich so wichtig sind.

Ich für meinen Teil möchte folgende Antwort auf diese Frage geben: Im Mai 2009 hatten Peter und ich das Thema Woran erkennt man einen guten Entwickler? für unser Streitgespräch ausgewählt. Als wesentlich habe ich damals zwei Eigenschaften genannt:

• Smart: Zum einen muss er “smart” sein. Joel Spolsky meint damit, dass ein guter Entwickler kreativ, aufgeschlossen und neugierig sein muss, dass er zudem bereit sein muss, ungewöhnliche Wege zu gehen, und dabei gleichzeitig in der Lage, gegebenenfalls um eine Ecke mehr zu denken als ein durchschnittlicher Entwickler.
• Gets Things Done: Zum anderen muss er seine Aufgaben allerdings auch erledigt bekommen – und zwar in der vorgegebenen Zeit. Denn all die zuvor genannten positiven Eigenschaften nützen nichts, wenn es einem Entwickler nicht gelingt, auf den Punkt zu kommen und seine Aufgaben zeitgemäß abzuschließen.

Beide Forderungen gehen dabei auf Joel Spolsky und sein Buch Smarts and Gets Things Done zurück. Ralf Westphal hat meinem damaligen Blogeintrag kommentiert und strengere Kriterien gefordert:

Auch wenn ich Joels Kriterien "smart" und "gets things done" gut finde, so sehe ich nicht, dass er damit einen guten Entwickler charakterisiert. Sie sind für ihn nötige, aber keine hinreichenden Beschreibungen. Er benutzt sie ja auch vor allem in Bezug auf die Bewerberauswahl. Da hilt es nämlich, nicht nach dem perfekten Kandidaten zu suchen, sondern sich schon mit einem smarten, der seine Aufgaben auch erledigt, zufrieden zu geben.
Das ist aber nur der Anfang! Denn wenn einer nur smart und verlässlich ist, dann ist er noch lange nicht produktiv. Er muss womögl erst noch lernen, seine Smartness und Verlässlichkeit mit den relevanten Werkzeugen und Materialien einzusetzen.

Ich muss zugeben, dass Ralf damit vollkommen recht hat: Angesprochen und explizit charakterisiert wird dadurch nämlich nur auf die äußere Form der Arbeit – die innere hingegen bleibt verschwommen.

Deshalb möchte ich heute nachlegen und bei dieser Gelegenheit auch direkt die Frage beantworten, warum Peter und mir Standards und deren Einhaltung so wichtig sind.

In dem Computerspiel Quake III Arena gab es einige Auszeichnungen, die man als Spieler erreichen konnte. Eine davon war Accuracy, die für eine Trefferquote von über 50% verliehen wurde. Laut dict.cc bedeutet dieses Wort außer Treffsicherheit und Treffgenauigkeit auch Exaktheit und Sorgfalt.

Und genau damit bezeichnet Accuracy eine aus meiner Sicht ausgesprochen wichtige Anforderung an einen Entwickler: Die Liebe für Details, und die Fähigkeit, auch auf jeden Punkt und jedes Komma zu achten – und nicht nur oberflächlich mal eben schnell über Code hinweg zu gehen.

Interessanterweise verfügen alle Entwickler, die ich kenne und deren Arbeit ich schätze, über diese Eigenschaft – sich nicht mit dem Erstbesten zufrieden zu geben, sondern nachzuhaken und genau hinzusehen. Das merkt man dann nicht nur an der Art, wie Code geschrieben wird, sondern beispielsweise auch daran, wie Code gedebuggt wird.

Für diese Entwickler sind Programmierstandards dann nämlich kein lästiges Hindernis, das es einzuhalten gilt, sondern ein hilfreiches Rahmenwerk für die äußere Form, das es ermöglicht, sich auf das Wesentliche zu konzentrieren.

Aus diesem Grund erachten auch Peter und ich Programmierstandards als dermaßen wichtig: Sie erfüllen eben nicht nur die im Extreme Programming verfolgte Intention, gemeinsame Verantwortlichkeit zu etablieren, sondern ermöglichen uns auch, den Code des anderen schneller zu verstehen und uns gegenseitig zu helfen.

Die spannende Frage ist: Lässt sich diese Liebe zum Detail erlernen, oder ist sie – zumindest zu einem gewissen Grad – angeboren?

Keine tausend Meter von der Technischen Universität Kaiserslautern entfernt liegt das Fraunhofer-Institut für Experimentelles Software Engineering (IESE). Obgleich der Name auf Grund des Wortes experimentell zunächst unwissenschaftlich wirkt, befasst sich das IESE mit einer ausgesprochen anspruchsvollen Thematik: Der Erforschung von Methoden und Prozessen zur industriellen Softwareentwicklung.

Der Leiter des IESE, Prof. Dr. Dieter Rombach, zählt zu den von mir – und nicht nur während meines Studiums – am meisten geschätzten Professoren: Er hat meine Sicht auf Softwareentwicklung im Allgemeinen und das ingenieursmäßige Vorgehen dabei wesentlich geprägt.

Das Studium der Angewandten Informatik an der TU Kaiserslautern war – zumindest während meiner Studienzeit – derart strukturiert, dass das Grundstudium um eine Serie von drei Vorlesungen namens Entwicklung von Softwaresystemen aufgebaut war: Darin wurden die Grundlagen der Programming an Hand von Java vermittelt – angefangen bei den grundlegenden OOP-Konzepten bis hin zu Multithreading.

Was Entwicklung von Softwaresystemen für die Entwicklung im Kleinen war, waren die darauf aufbauenden Vorlesungen Software Engineering während des Hauptstudiums für die Entwicklung von großen Softwaresystemen. Wurde der Schwerpunkt während des Grundstudiums noch auf das Schreiben von Code gelegt, ging es nun um Methoden und Prozesse der Softwareentwicklung.

In einer dieser Vorlesungen habe ich den Begriff Extreme Programming zum ersten Mal gehört: Damals entwickelte sich an Hand dieses Begriffs eine interessante und spannende Diskussion über das Für und Wider agiler Vorgehensweisen.

Für lange Zeit danach war Extreme Programming für mich jedoch nicht mehr als ein Schlagwort, dessen nähere Beschäftigung nicht lohnte – wurden agile Methoden doch häufig als unseriös oder kaschierende Bezeichnung für bewusst in Kauf genommenes Chaos abgetan.

In den vergangenen Jahren habe ich nun immer wieder festgestellt, dass sich meine Art zu entwickeln verändert hat: Man könnte sagen, dass eine gewisse Professionalisierung eingetreten ist – zumindest zu einem bestimmten Grad. Allerdings ist das Ende der Fahnenstange dabei noch lange nicht in Sicht, nach wie vor lerne ich täglich neues dazu.

Interessant an dieser Entwicklung ist, dass es nicht einen einzelnen Faktor gibt, an dem ich dies festmachen könnte – statt dessen gibt es eine ganze Reihe von Faktoren, die mich beeinflusst haben: Das Spektrum reicht dabei von Büchern wie C# in Depth oder Framework Design Guidelines über Personen wie Ralf Westphal oder Peter Bucher bis hin zu Initiativen wie Clean Code Developer.

Vergangene Woche habe ich nun das Buch eXtreme Programming von Henning Wolf, Stefan Roock und Martin Lippert gelesen, weil ich zum einen endlich wissen wollte, was genau sich hinter diesem Begriff verbirgt, und weil ich zum anderen einen Einstieg in das Thema agiler Methoden gesucht habe.

Dabei habe ich festgestellt, dass Extreme Programming ziemlich genau dem Vorgehen entspricht, das ich mir in den vergangenen Jahren angeeignet und für mich als meine persönliche Best Practice erkoren habe. Die meisten der im Extreme Programming vorhandenen Methoden setze ich bereits ein, insbesondere auch in Zusammenarbeit mit Peter Bucher:

• Programmierstandards, gemeinsame Verantwortlichkeit, fortlaufende Integration – all das sind für uns Selbstverständlichkeiten in unserer Entwicklung geworden. Da wir auf Grund der räumlichen Distanz kein Programmieren in Paaren durchführen können, haben wir Reviews als ständigen Prozess für uns etabliert – was seinerseits wiederum der gemeinsamen Verantwortlichkeit zu Gute kommt.
• Auch den Punkt des einfachen oder besser gesagt des iterativen Designs schätzen wir enorm: Wir gestalten unsere Architekturen derart, dass sie nicht mehr erfüllen als das derzeit benötigte, dass sie aber für Erweiterungen offen sind. Gerade dieser Aspekt spielt nicht nur für uns eine sehr große Rolle, sondern auch für das Extreme Programming.
• Einige der in Extreme Programming genannten Methoden wie Retrospektive, Testen oder Planungsspiel setzen wir derzeit noch zu wenig ein – wir sind uns dessen aber bewusst und steuern dieses Ziel an.

Nimmt man all dies zusammen, so kann ich sagen, dass Extreme Programming sehr gut funktioniert – wenn man das richtige Team hat, und das Projekt die erforderliche Agilität zulässt, und zudem eine gewisse Größe nicht übersteigt.

Aus dieser Erkenntnis ziehe ich für mich den Schluss, auf dem richtigen Weg zu sein und diesen Weg auch in Zukunft fortzuschreiten und auszubauen.

Eines der besten und interessantesten Bücher, die ich je gelesen habe, ist Computers and Intractability von Michael R. Garey und David S. Johnson. Obwohl es erstmals bereits im April 1979 veröffentlicht wurde, hat es nichts von seiner Aktualität eingebüßt – im Gegenteil, es hat sich als Referenz etabliert.

Worum geht es in diesem Buch?

Prinzipiell wird die Theorie der NP-Vollständigkeit vorgestellt, über die ich auch in einem Artikel in der dotnetpro 07.2009 unter dem Titel Die Eine-Million-Dollar-Frage berichtet habe:

Manche algorithmischen Probleme lassen sich schnell und unter Einsatz geringer Ressourcen lösen. Andere Aufgaben, etwa die Zerlegung einer sehr großen Zahl in ihre Primfaktoren, sind ausgesprochen aufwendig. Oder geht das auch schneller? Und es hat bloß noch keiner den richtigen Algorithmus gefunden? Diese Frage führt mitten in die Untiefen der theoretischen Informatik.

Das Buch Computers and Intractability legt die Grundlagen für das Verständnis dieser Materie: Nachdem an Hand eines kompakten Beispiels gezeigt wurde, warum diese Frage überhaupt von Bedeutung ist, wird die zugehörige Theorie erläutert. Angenehm ist, dass dies nicht künstlich in die Länge gezogen wird, sondern sich auf das Wesentliche beschränkt – ohne wiederum Details auszulassen.

Ergänzt wird diese Einführung durch einige Beweise, die das Verständnis fördern. So wird beispielsweise für das Problem SAT initial gezeigt, dass es NP-vollständig ist, und erläutert, warum dies für alle weiteren NP-vollständigen Probleme eine so wichtige Grundlage darstellt.

Im Anschluss folgt – und dies macht den Großteil des Buches aus – eine geordnete Übersicht über mehr als 300 Probleme, die als NP-vollständig charakterisiert wurden. Jedes Problem wird dabei in formaler Form beschrieben, ergänzt um Anmerkungen und gegebenenfalls vorhandene Forschungsergebnisse, wie man sich der NP-Vollständigkeit des jeweiligen Problems algorithmisch nähern könnte.

Kurzum: Ein sehr empfehlenswertes Buch, das den Leser zwar geistig sehr fordert, aber gleichzeitig auch sehr viel Potenzial für das theoretische Verständnis von Algorithmen birgt.

Vor ziemlich genau einem Jahr wurde ich von Peter Bucher mit der Frage Was ist Architektur? konfontriert. Eine vernünftige und fundierte Antrwort auf diese zunächst einfach erscheinende Frage geben zu können, hat mich damals einige Wochen in Anspruch genommen.

Vorgestern hat mir Peter nun wieder eine solche Frage gestellt, deren Beantwortung aus dem Stegreif zumindest nicht ganz trivial ist:

Was gehört in den Businesslayer?

Des weiteren ergänzt Peter seine Frage um eine Erklärung, inwiefern er überhaupt Diskussionsbedarf sieht:

[…] alles was Redundanzen im Datalayer verursacht (da es mehrere geben kann), gehört dort hin.

Aber ich höre und lese so viel von Geschäftslogik / Businesslogik und verstehe darunter irgendwelche Logik, wie beispielsweise Preisberechung oder Algorithmen die ausgeführt werden müssen.

Auf jeden Fall habe ich noch nie mehr als Validation / Caching und Logging in einem Businesslayer gesehen. Meistens ist es nur Delegation oder die Transformation von einer DataRow zu einem Objekt […]

Unsere – bislang gemeinsam genutzte Sichtweise – war, dass in die Businesslogik all jenes gehört, was weder in die UI noch in die Datenzugriffsschicht gehört. Allerdings ist eine solche Negativdefinition an Hand einer Exklusion nicht besonders tragfähig: Eine Definition an Hand charakteristischer Merkmale des zu inkludierenden Codes wäre bedeutend nützlicher.

Interessant finde ich, dass die von Peter angesprochenen Aspekte Validierung, Caching und Logging zwar durchaus im Businesslayer zu finden sind, allerdings weder explizite Businesslogik darstellen, noch auf diesen beschränkt wären: So kann sich Validierung durchaus auch zusätzlich in der UI und der Datenzugriffsschicht befinden. Gleiches gilt für die beiden anderen Aspekte Caching und Logging.

Schließlich spricht Peter noch die Transformation und Delegation zwischen Objekten der Datenbank und Objekten des Objektmodells an: Korrekt ist, dass solcher Code häufig im Businesslayer enthalten ist – ob dies jedoch die geeignete Stelle für solchen Code ist, wage ich zu bezweifeln.

Wie also würde ich Peters Frage beantworten?

Ausgehend von meiner Argumentation in Was ist Architektur? verfügt eine Anwendung über einen Sinn: Eine Anwendung wird geschrieben, um ein Problem zu lösen. Bezogen auf diesen Sinn sind die beiden Elemente UI und Datenzugriffsschicht zwar notwendig, aber nicht wesentlich, denn im Gegensatz zum Kern der Anwendung sind sie letztlich beliebig austauschbar.

Es spielt keine Rolle für die Lösung des zu Grunde liegenden Problems, ob die UI in WPF, in Silverlight oder in einer schlichten Konsole umgesetzt wurde – ebenso wie es keine Rolle spielt, ob die Daten in einem SQL Server oder einer schlichten XML-Datei abgelegt werden.

Der Kern einer Anwendung hingegen ist unverändlich. Würde man diesen grundlegend verändern, so würde damit implizit ein anderes als das ursprüngliche Problem gelöst; Die Anwendung erhielte einen anderen Sinn.

Insofern kann man den Businesslayer also mit dem Kern der Anwendung gleichsetzen, und der Kern enthält zunächst einmal sämtliche anwendungsbezogene Logik – eben die sogenannte Businesslogik. Diese kann in Form von komplexen Workflows definiert sein, aber auch ganz schlicht und rudimentär in Form einiger weniger if-Abfragen.

Zunächst kann man also festhalten, dass ich mit Peters Formulierung

Aber ich höre und lese so viel von Geschäftslogik / Businesslogik und verstehe darunter irgendwelche Logik, wie beispielsweise Preisberechung oder Algorithmen die ausgeführt werden müssen.

einverstanden bin. Doch warum sieht man so wenig von dieser Logik?

Dies liegt schlichtweg darin begründet, dass viele der gängigen kleineren und mittleren Anwendungen – insbesondere im Web – keine ausgefeilte Logik benötigen! Zahlreiche dieser Anwendungen begnügen sich nämlich mit den üblichen CRUD-Funktionen: Im Grunde stellen sie nur eine visualisierte Schnittstelle zur Datenbank dar, und verfügen daher über keine dedizierten Workflows.

Und die wenigen Workflows, die vorhanden sind, nimmt man dann neben dem Berg an CRUD-Funktionen nicht mehr als eigenständiges Regelwerk wahr.

Auf der anderen Seite führt ein derart minimalistischer Businesslayer dann dazu, dass Aspekte wie Validierung – die im Grunde gar keine Businesslogik darstellen – ebenfalls dort angesiedelt werden. Schließlicht macht man sich über eine weitere Unterteilung des Businesslayers gar keine Gedanken mehr – dieser ist ja bereits so klein.

Der Aufwand, einen übergreifend zur Verfügung stehenden dedizierten Servicelayer zu entwickeln, wird dann gerne gescheut – obwohl er gegebenenfalls die bessere Wahl wäre.

Interessanterweise gibt es auch Aspekte, die durchaus in den Businesslayer gehören, und dort häufig nicht angesiedelt werden: Hierzu zählt beispielsweise – und das mag verwundern – das Transaktionsmanagement. Transaktionen sind schließlich nicht per se kurzlebiger Natur und auf die Datenbank bezogen.

Schlussendlich möchte ich Peter also nicht nur recht geben, wenn er den Businesslayer mit Anwendungslogik gleichsetzt, sondern ich möchte auch eine Lanze dafür brechen, dem Businesslayer an sich mehr Aufmerksamkeit zu schenken, und auch mehr darüber nachzudenken, ob eine weitere Unterteilung des Businesslayers in die eigentliche Logik und weitere Komponenten nicht durchaus Sinn ergibt.

Am 13. Oktober 2008 haben Peter Bucher und ich unter dem Titel Noch Fragen, Bucher? Ja, Roden! angekündigt, jeweils zum ersten eines jeden Monats einen Kommentar zu einem vorab gemeinsam gewählten Thema verfassen zu wollen. Bisher sind in dieser Reihe folgende Kommentare erschienen:

• 1. Juli 2009: Primärschlüssel: GUID vs Identity
• 1. Juni 2009: Heißt die Zukunft RIA?
• 1. Mai 2009: Woran erkennt man einen guten Entwickler?
• 1. April 2009: Interfaces vs abstrakte Basisklassen
• 1. März 2009: Sinn und Zweck von AOP
• 1. Februar 2009: Die Forderung nach Softwarequalität
• 1. Januar 2009: SOA vs WOA
• 1. Dezember 2008: Dynamic Language Runtime: .NET, quo vadis?

Heute, am 1. August 2009, ist es nun wieder so weit, und unser Thema für diesen Monat lautet:

C# oder VB: Welche Sprache soll ich lernen?

So wohl Peter wie auch ich haben uns unabhängig voneinander im Vorfeld unsere Gedanken gemacht, wie wir diesem Thema gegenüberstehen. Außerdem nimmt diesen Monat auch Christian Wenz an unserem Streitgespräch teil.

Peters und Christians Kommentare finden sich zeitgleich in den entsprechenden Blogs, folgend nun mein Kommentar zu diesem Thema:

Die Frage, ob C# oder Visual Basic die bessere Sprache ist, kann pauschal wohl kaum beantwortet werden. Wie so oft hängt die Antwort vom konkreten Kontext ab, in dem die Frage gestellt wird.

Zudem ist man zunächst geneigt, C# und Visual Basic als zwei syntaktische Varianten einer gemeinsamen Sprache zu sehen – und wenn man MSIL als diese Sprache nimmt, ist diese Sichtweise aus rein technischer Sicht auch gar nicht so abwegig.

Es gibt nur wenige Sprachfeatures, auf Grund deren man C# über Visual Basic oder umgekehrt Visual Basic über C# favorisieren könnte: Eines davon könnte die integrierte Unterstützung von XML in Visual Basic sein.

Ob ein derart einzelnes Feature jedoch genügt, um eine Sprache als Grundlage für ein gesamtes Projekt auszuwählen, sei noch einmal dahin gestellt.

Auch die historische Entwicklung, die beispielsweise in Not Another C# Versus VB Article auf CodeProject beschrieben wird, ist nur bedingt geeignet, eine Entscheidung zu fällen: Denn Historie ist für all jene irrelevant, die sich erstmalig mit Programmierung beschäftigen.

Werde ich nach meiner persönlichen Empfehlung gefragt, so rate ich fast durchwegs immer zu C# – jedoch bin ich auf Grund von Projekten wie guide to C# auch nicht unbelastet. zudem fehlt mir die Erfahrung in Visual Basic.

Was also empfehlen, wenn man zumindest ein wenig Objektivität wahren möchte?

Als die Entwicklung für Windows noch nicht auf .NET, sondern auf der Win32-API basierte, gab es für die Frage, ob Visual C++ oder Visual Basic Classic eingesetzt werden sollte, eine relativ einfach anwendbare Richtlinie: Professionelle Entwickler sollten Visual C++ einsetzen, alle anderen Visual Basic Classic:

• Visual C++ hatte für professionelle Entwickler einige entscheidende Vorteile: So war nicht nur der Zugriff auf die gesamte Win32-API möglich, auch die Integration in COM war erstklassig. Diese Vorteile erkaufte man sich mit einer ausgesprochen komplexen Entwicklung.
• Visual Basic Classic hingegen war einfach zu erlernen und einfach anzuwenden. Zwar gab es Grenzen, diese spielten jedoch abseits der professionellen Entwicklung nur selten eine entscheidende Rolle.

Nun haben so wohl Visual C++ wie auch Visual Basic Classic ihren Einfluss verloren und C# und Visual Basic sind die neuen Sterne am Programmiersprachenhimmel. Die spannende Frage lautet nun: Gilt die damalige Rollenverteilung nach wie vor?

Ich meine: Ja, sie gilt nach wie vor. C# ist besser geeignet für professionelle Entwickler, Visual Basic hingegen ist nach wie vor besser geeignet für alle anderen Entwickler. Wie komme ich zu dieser Einschätzung – wo doch so oft zu hören und zu lesen ist, dass es sich faktisch nur um zwei verschiedene syntaktische Varianten einer Sprache handelt? Dass die Entscheidung somit letztlich keine Rolle spielt? Dass es sich eigentlich nur um einen Glaubenskrieg handelt?

Der entscheidende Punkt ist, dass C# von vornherein darauf ausgelegt wurde, eine akademische Sprache zu sein. Eine Sprache, in der alle enthaltenen Sprachkonzepte und -ideen sauber umgesetzt sind. Man könnte auch sagen, C# ist die Sprache des Elfenbeinturms.

Visual Basic hingegen ist auf ein komfortables Entwicklungerlebnis ausgerichtet: Man muss nicht zwingend alle Konzepte von .NET verstehen, um erfolgreich in Visual Basic programmieren zu können – für C# ist ein gutes Verständnis von .NET essenziell.

Dieser Komfort manifestiert sich in Visual Basic in vielen Kleinigkeiten, unter anderem in den folgenden Konzepten:

• Visual Basic unterstützt nach wie vor das On Error Goto-Konstrukt, das an Stelle des wesentlich besser strukturierten try / catch eingesetzt werden kann.
• Visual Basic unterstützt optionale Parameter. Dieses Feature ist zwar nun für eine verbesserte COM-Interoperabilität auch in C# 4.0 enthalten, wird dort allerdings nicht als unproblematisch angesehen, wie beispielsweise in Für und wider C# 4.0 beschrieben.
• Visual Basic unterstützt zahlreiche der Funktionen aus Visual Basic Classic nach wie vor, indem diese in der Assembly Microsoft.VisualBasic.dll nachgebildet worden sind. Im Vergleich zu den moderneren .NET-Varianten lassen diese Funktionen allerdings einiges zu wünschen übrig – insbesondere im Hinblick auf Performance.

Nun kann man all diesen Punkten ankreiden, dass es sich nur um Kleinigkeiten handelt, die zudem aus Gründen der Abwärtskompatibilität enthalten sind. Jedoch hat Microsoft im Rahmen von Visual Studio 2005 ein komplett neues Feature eingeführt, das jedoch interessanterweise nur für Visual Basic zur Verfügung steht: Den Namensraum My.

Auch Uwe Baumann hat bereits im April 2005 mit My, ist das geil! eine Lanze für den Namensraum My gebrochen – nicht jedoch ohne die entsprechende Kritik, nachzulesen als Zitat in Die Freiheit der abweichenden Mynung:

My ist nicht geil. Nicht einmal ansatzweise. Denn My untergräbt die klare Struktur von .NET, die viele Entwickler so lieben, wie es bei PHP auch geschieht. Unter dem Motto “Alles soll einfacher werden” wird ein zusätzlicher Namensraum eingeführt, der Abkürzungen bietet. Diese aber mit eingeschränkter Funktionalität, und nicht mehr nach den klassischen Namensräumen sortiert, es wird also neben der Einführung einer zweiten Schreibweise auch noch die Beschäftigung mit den klassischen Namensräumen vermindert.

Letztlich führt das meiner Meinung nach zum gleichen Ziel wie in PHP, nämlich, dass Einsteiger sich auf My stürzen werden, dann aber irgendwann an die Grenzen stoßen oder fremden Code bearbeiten müssen, und sich dann doch mit den klassischen Strukturen auseinander setzen müssen.

Letztlich wird so wieder ein Parallelweg eingeführt, der eigentlich überflüssig ist, und am Ende die Produktivität eher senkt als steigert, da redundante Abläufe erlernt werden müssen.

In seiner Antwort referenziert Uwe auf genau jene Unterscheidung, die ich in diesem Eintrag auch getroffen habe: C# ist eine Sprache aus dem Elfenbeinturm, akademisch sauber und elegant. Visual Basic hingegen ist die Sprache für den Praktiker, der sein Ziel erreichen will – wobei ihm der Weg relativ gleich ist, und der unter Umständen auch gar kein Interesse an Weiterentwicklung hat.

Aufbauend auf meiner Argumentation und gestützt durch Uwes Antwort möchte ich daher folgendes Fazit ziehen: Wer sich professionell mit .NET beschäftigen will, wissen will, wie .NET intern funktioniert, und bereit ist, Zeit und Aufwand zu investieren, der ist mit C# besser beraten.

Wer jedoch nur gelegentlich eine kleine Anwendung zusammenbasteln will, wem das Erreichen des Ziels wichtiger ist als der dafür eingeschlagene Weg, der ist mit Visual Basic besser beraten.