/* no comment */

Wer nichts zu sagen hat, sollte einfach mal die Fresse halten. Oder keinen Kommentar hinterlassen, zum Zeugnis des eigenen Unvermögens. Im besten Fall sollte jede/r selbsternannte Programmierer/in respektive aus- oder eingebildete Softwareentwickler natürlich selbsterklärenden Code schreiben. Das aber ist längst nicht immer und überall der Fall, insofern kann man froh sein wenn der hingekrakelte Quelltext oder aber der Kommentar halbwegs verständlich ist, oder zumindest unterhaltsam. Ganze Blogs kümmern sich um eben jene im Grund völlig überflüssigen und dennoch in nicht-öffentlichem Code leider allzu oft aufzufindendem digitalen Nonsens. Ich habe hier mal meine persönliche "Best of" zusammengestellt, und werde sie bei sich bietender Gelegenheit aktualisieren:

/* DO/DON'T DO THIS, THAT OR DO/DON'T CHANGE THIS */

insbesondere in dieser aufdringlichen Form, an der man in jedwedem Editor, vom vi bishin zu Visual Studio 2010, beim besten Willen nicht vorbei kommt. Cool besonders dann, wenn sich bei syntaktischer Analyse herausstellt, das der "DO NOT REMOVE THIS!" markiete Codeabschnitt völlig überflüssig ist, entweder weil er durch andere Programmteile ganz oder in Teilen ersetzt werden könnte, oder noch einfacher: Wenn er schlicht und ergreifend nie aufgerufen wird.

/* WHO MADE THIS CRAPPY/SILLY/DUMB/... CODE!? */

gerade dann wenn der bemängelte Abschnitt nur wenige Zeilen umfasst die ein ach so kundiger Ingenieur mit deratigem Mitteilungsbedürfnis jederzeit im nu in ein Nobellpreis-verdächtigen Mehrwert verwandeln würde, noch vor dem ersten Kaffee

/* WHAT DOES THIS? */ im Speziellen wenn es sich, anhand der Versionskontrolle nachvollziehbar, beim Verfasser des Kommentars wie des verbrochenen Programmabschnitts um die selbe Person handelt.

METHODWITHUSELESSNAME(ARGUMENT LIKE ARG1, VALUE2, etc.)

sind vor allem bei Autoren beliebt, deren gesamter Quelltext oder Teile dessen aus Suchmaschinen stammen und denen es zu viel Mühe bereitete den so übernommenen Code wenigstens noch mit sachgerechten Namen zu versehen.

/* destructor / constructor */

Tatsächlich gibt es Programmierer und Softwareentwickler - insbesondere selbsternannte, dann in der Regel auch: selbsternannte Gurus ihres Fachs - die es für nötig halten jeden einzelnen Konstruktur als solchen zu kennzeichnen, und zwar nur so.

Mein Ziel ist es nicht, mit dieser Aufzählung jemand anzugreifen, sondern vielmehr für das Thema sinnloser Kommentare zu sensibilisieren. Da hilft meist Humor, und Selbstironie: Programmierer lernen nämlich nie aus, und wer über sich selbst lachen kann, tut das meist über eine vorangegangene Inkarnation. Wer hingegen immer auf dem selben Stand bleibt, ohne diese Ratschläge ernst zu nehmen, ist früher oder später überflüssig.

Jahr 2010 Bug

Wer den Schaden hat, braucht für den Spot nicht zu sorgen, so das Sprichwort. In diesem Fall ist der Schaden gewaltig, vermutlich von größerer Tragweite als beim Jahr 2000 Problem mit Ansage. Dabei kann nicht in allen Fällen von einer Überraschung die Rede sein, in Einzelfällen wie bei der OpenSource-AntiSpam-Lösung SpamAssasin von Apache war man längst über das Problem in Kenntnis gesetzt worden, trotzdem beispielsweise klassifiziert die Software seit dem 1. Januar viel mehr Mail als Spam. Kommerzielle Softwareprodukte sind hiervon aber längst nicht ausgenommen, so betrachtet Symantec Virendefinitionen mit einem Datum diesen Jahres als veraltet

.

Das Problem ist fehlendes, qualifiziertes Personal, zu deutsch Fachkräftemangel. Und das wiederum gilt für die OpenSource-Lösung gleichermaßen wie beim weitaus verheerenderen Ausfall der Schnittstelle zur Zahlung per Magnetkarte. Dabei sind magnetische Datenträger so Retro, Old School und letztes Jahrtausend, das man meinen könnte das hochprofitable Bankensystem würde auch auf diese Technik zu Gunsten viel ausgefeilterer einfacher auszulesender Chip-Technologie verzichten, mal ein wenig Geld in die Hand nehmen und zugleich ein wenig Qualitätssicherung zu betreiben.

Unser Dozent machte sich vor der um 8 Uhr sichtlich ausgedünnten Kommilitonenschaar zu recht lustig über das Unvermögen der Industrie und ermahnte alle Studenten Verantwortung für eigenen Code zu übernehmen. Ob das allerdings bei allen zukünftigen Kollegen ankam, darf ich aus Erfahrung bezweifeln.

Mein alter Bekannter, Pascal

Mein lieber Herr Gesangverein, was lief mir ein kalter Schauer über den Rücken, als ich mir nichts, dir nichts Pascal begegnete. Pascal ist ein alter Bekannter, der mir den Glauben an die Informatik rauben sollte, denn Pascal war nicht irgendwer, sondern meine erste an der Hochschule vermittelte Programmiersprache. Prozedurale Programmierung hiermit das Höchstmögliche der Gefühle, und state-of-the-art Mitte/Ende der 1970er, Anfang der 1980er Jahre. Ende der 1990er servierte mir die Frankfurter Fachhochschule dies in der zentralsten Vorlesung meiner ersten studentischen Laufbahn, und angesichts der Tatsache das ich im privaten Umfeld bereits meine ersten, wenig erbaulichen Erfahrungen mit dem Nachfolger Delphi gemacht hatte keine schöne Begegnung eben

Wie die heutige, wieder in einer Vorlesung, dieses Mal allerdings ausdrücklich nicht mehr als beipspielhaftes Programmiermodell, sondern eine Remineszens an die prozedurale Vergangenheit, als Vorlage für einen in C++ abzubildenden Algorithmus. Anders als damals kam das schlecht lesbare Schriftbild - vermutlich aus einem Buch herauskopiert, das mit damaliger Technik vervielfältig wurde - dieses Mal allerdings nicht vom Telefonbuch-schweren Skript des Dozenten, sondern wurde zeitgemäß an die Wand projeziert. Hier wurden wirklich schmerzliche Erinnerungen wach, denen ich mich hiermit entledigen will.

Hello, world!

This is the first post.