G61 hacking sprint
Die Rache des bösen ByRef

Eigentlich ist es ja ein nettes Feature, dass VB.NET (und C#), im Gegensatz zu Java, out Parameter erlaubt. Das kann den Code manchmal wirklich vereinfachen, z.B. wenn mehrere Werte zurückgegeben werden sollen (z.B. bei IDictionary.TryGetValue).

Dummerweise hatte sich in der Anfangsphase der Entwicklung unserer Applikation (“damals”, so gegen Ende der 90’er) unter den VB6 Entwicklern der Aberglaube verbreitet, dass eigene Objekte und Collections immer mit ByRef übergeben werden sollten, unabhängig davon, ob die aufgerufene Methode sie nun ändern sollte oder nicht. Wie dieser Aberglaube zustande kam, weiß ich nicht (Wahrscheinlich eine Altlast: bis einschließlich VB5 konnten benutzerdefinierte Typen nur ByRef übergeben werden.)

Ich sitze also vor einer großen Codebasis, in der es vor ByRefs nur so wimmelt. An allen Ecken lauern sie, und warten darauf, in performantere und vor allem weniger fehlerträchtige ByVals umgewandelt zu werden. Nur ab und zu passiert es: da ist eines dabei, das wirklich einen out Parameter kennzeichnet, und wenn man das in bester Absicht in ByVal umwandelt, passieren seltsame Dinge in der Applikation. Oder vielmehr, meist passieren die seltsamen Dinge, die unsere Applikation so macht, und die von den Benutzer geliebt werden, nicht mehr. Was die Benutzer wiederum nicht lieben würden, und was mich daher gerade mehrere Stunden Arbeit gekostet hat.

Daher fiel heute das schillernde Nachtleben dieses schönen Örtchens für uns aus. Immerhin hat der Kollege was leckeres gekocht, so dass für das leibliche Wohl bestens gesorgt war.

Blog comments powered by Disqus