Die wichtigsten Richtlinien für schlechte Programme
Nur Doofe lesen Fehlermeldungen
Compiler und Betriebssysteme, ja, eigentlich alle Programme, geben Fehlermeldungen nur zur Befriedigung ihrer SchöpferInnen aus, wahrscheinlich, weil diese ja für irgendwas bezahlt werden müssen. Sie zu lesen, hält nur von der eigentlichen Aufgabe ab: Dem Schreiben von Code. Deshalb kann und soll man Fehlermeldungen schlicht ignorieren.
Fehlermeldungen sind lästig, Warnungen dagegen eine Gelegenheit, richtig cool zu sein. Wer Programme schreibt, die beim Compilieren seitenweise Warnungen werfen und dabei entspannt und mit Weltverachtung das Tanzen der Buchstaben beobachtet, muss offenbar ein echter Profi sein, ohne jede Furcht vor der Maschine. Nur Schwächlinge gucken überhaupt auf so ein Geschwätz.
Bloß nicht nachdenken
Wir wollen programmieren. Also müssen wir ein Programm schreiben. Was ist ein Programm? Code. Code ist das, was nachher die Arbeit tut. Drum hat es auch überhaupt keinen Sinn, mit Antiquitäten wie Kugelschreibern, Bleistiften oder Papier zu operieren -- produzieren die etwa Code?. Genauso sinnlos ist es, endlos Text zu schreiben, der nur sagt, wie es denn gehen könnte, statt es einfach zu tun.
Also: Nicht lang nachdenken, es gibt so viel Code, den man schreiben kann. Wenden wir das gleich auf die erwähnten Fehlermeldungen an: Bloß nicht nachdenken und versuchen, zu verstehen, warum die Maschine sich beschwert. Das wäre unprofessionell und würde außerdem davon abhalten, Code zu schreiben.
Nein, es ist viel besser, einfach wild in den Code zu pfuschen. Früher oder später werdet ihr dem Rechner schon den Mund stopfen oder ihn immerhin so weit bringen, dass er den Code schluckt. Wenn ihr die Fehler ignorieren könnt, weil der Compiler trotzdem was ausspuckt, tut das -- Fehler, die man ignoriert, gehen weg. Früher oder später.
Wenn irgendeine Funktion nicht das tut, was sie soll, macht das auch nichts, ihr könnt es ja später in Ordnung bringen, wenn das Programm fertig ist. Ansonsten siehe das Ende des letzten Absatzes.
Bloß cool bleiben
Wenn das Programm sporadisch Mist baut, ist es garantiert richtig schwierig, den Fehler zu finden. Er taucht auch bestimmt bei der Vorführung nicht auf, und dass irgendwer euren Code ansieht und dann feststellt, dass ihrs irgendwo vermurkst habt, ist auch beliebig unwahrscheinlich. Wenn ihr trotzdem den Drang habt, den Kram in Ordnung zu bringen -- ihr wisst ja, nachdenken ist mal richtig Anfängerstil, ändert einfach irgendwo Code.
Inkrementelle Entwicklung, eine Funktion nach der anderen, ist auch für Schwächlinge. Echte ProgrammiererInnen schreiben 10000 Zeilen am Stück, und zwar alles in einer Funktion. Weil Fehlersuche ohnehin überflüssig ist, klappt das auch, denn den Vorteil, einen Fehler nur in 10 oder 20 Zeilen statt deren 10000 suchen zu müssen, wollen nur ausgesprochen anal fixierte Menschen nutzen.
Wenn man alles in eine Funktion kippt, ergibt sich nebenbei noch der Extrabonus, dass ein ordentliches Codelayout angesichts der Tiefe der notwenigen Einrückungen schlicht keine Option mehr ist. Dann kann man auch den Rest von so komischen Regeln, wo wann welche Blanks und welche Klammern stehen sollen, vergessen und das einfach machen, wie es kommt. Soll doch wer anders indent laufen lassen, um es lesen zu können.
Bei der Gelegenheit: Debugger sind Programme, die allenfalls von DozentInnen eingesetzt werden sollen. Echte Profis machen keine Fehler, und drum müsst ihr euch mit so komischem Kram gar nicht auseinandersetzen, denn ihr werdet ja irgendwann Profis sein.
Zum Problem der Natursprache
Lesen
Dokumentation, Spezifikationen, man-Seiten: Alles Quatsch. Unglaublich langatmig und unnötig aufgeblasenes Gelaber, voll von komischen Wörtern, ständig auf der Suche nach völlig absurden Problemen, die ganz offensichtlich von den AutorInnen (oder, noch schlimmer, den Lehrenden) mit dem einzigen Ziel ersonnen wurden, toll dazustehen.
Ein schneller Blick reicht, vielleicht steht irgendwo ein Beispiel, das ihr einfach kopieren könnt, wozu gibts auch sonst die Maus? Dokumentation und Aufgabenstellungen richtig lesen, gar ein zweites Mal lesen, steht nur im Weg der einzig wahren Beschäftigung, nämlich, ihr wisst es, Code schreiben.
Vor allem die erwähnten Aufgabenstellungen sind mal wirklich was, was höchstens einen kurzen Blick rechtfertigt. Wenn ihr was ganz anderes schreibt als das, was verlangt ist, ist es vielleicht sogar einfacher. Die Tipps und Hilfestellungen, die irgendwer da reingepinselt hat, sind auch nicht zu verstehen, und außerdem passen sie ja auch gar nicht auf das Problem, das ihr gerade zu lösen versucht.
Empfehlungen, wie ihr eure Programme, Abschlussarchive und der Geier weiß was schreiben sollt, zeugen wiederum nur von der Analfixiertheit der Lehrenden. Warum sonst sollte es solche Empfehlungen -- die ja in Wirklichkeit faschistoide Vorschriften sind -- auch geben? Macht da nicht mit, klascht euren Code einfach irgendwie zusammen, lest bloß nicht nach, wie eure Abgabe organisiert sein sollte, schickt den Mist ab, ihr hattet genug Arbeit damit. Und ihr wurdet nicht mal dafür bezahlt, während es der Job der Lehrenden ist, den ganzen Kram auseinanderzupflücken und zu sortieren. Bei deren königlichen Gehältern ist das das mindeste, was ihr von ihnen erwarten könnt.
Schreiben
Kommentare tun nichts. Deshalb sind sie ja Kommentare. Warum sollte man sie dann schreiben? Richtig: Es gibt keinen Grund. Genau genommen sind Kommentare ja eigentlich sogar eine Beleidigung für die AdressatInnen: Wolltet ihr ihnen ernsthaft unterstellen, sie könnten keinen Code lesen? Wenn ihr den Fehler gemacht habt, doch in irgendwelche Vorschriften zum Abgabeformat reinzugucken und da irgendwas von Kommentaren stand, die unverzichtbar sind -- wer würde mehr haben wollen als so etwas wie
def doFoo(arg1, arg2, arg3, *args, **kwargs): """ ******************************** Last Change: does Foo. ******************************** """
Sieht toll aus, und wahrscheinlich merkt eh niemand, dass nichts drinsteht.
Genauso blöd ist es, wenn ihr euch nicht die Ohren zugehalten habt, während jemand das D-Wort gesagt hat. Dokumentation kann man ganz offenbar erst schreiben, wenn man fertig ist. Wie sollte man auch was dokumentieren, was es gar nicht gibt? Überhaupt ist Dokumentation nur so eine weitere Schikane der Lehrenden. Ihr braucht die Doku nicht, ihr habt den Kram ja geschrieben. Und alle anderen sollen halt den gottverdammten Code lesen.
Wenns aber doch dringend sein muss, macht den Deadline-Trick. Das Programm wird erst zwei Stunden vor der Abgabe fertig, und jedeR muss Veständnis haben, dass die Doku in zwei Stunden halt nicht so überwältigend wird.
Wüste Abkürzungen und eigenwillige Orthografie sind auch ok, denn, wie gesagt, die DozentInnen werden dafür bezahlt, rauszukriegen, was ihr meint. Mit etwas Glück werden sie sogar korrekte Dinge reinlesen in den Buchstabensalat, den ihr produziert habt, und von daher ist es besser, komplett kryptische Suppe zu rühren. Außerdem sorgt die Herausforderung bei den Leuten auch für gute Laune. Wer würde das nicht wollen?
DozentInnen und andere Monster
Bloß nicht nachfragen
Wenn irgendwas nicht geht, wäre es die falsche Lösung, in Sprechstunden, Vorlesungen oder Tutorien zu gehen und dort zu fragen. Eigentlich müssten wir gar nicht anfangen, die Gründe aufzuzählen, aber ein paar davon dürfen wir wohl erwähnen:
- Fragen stellen ist, wenn wir ehrlich sind, doch das Eingeständnis der eigenen Dummheit.
- Es ist sicherer, die Dinge nicht so genau wissen zu wollen. Es könnte ja sein, dass die Dinge in Wirklichkeit komplizierter sind oder mehr Arbeit machen.
- Richtig blöd ist, dass nachher alle anderen Studis -- die es ja wohl verstanden haben, sonst würden sie ja fragen -- glauben, dass ihr blöd seid. Das wollen wir ja bestimmt nicht.
Eine Ausnahme von dieser Regel besteht aber: Zwei Stunden vor der Abgabe ist es ok, mit Fragen direkt zum Lehrenden zu kommen. In dieser Not ist euch die volle Aufmerksamkeit gewiss, und außerdem ist es enorm instruktiv, ein an die Wand gefahrenes Projekt in zwei Stunden zu retten.
Herausforderungen bieten
Wer was mit Rechnern zu tun hat, liebt Rätsel. Deshalb ist es wichtig, eine goldene Regel zu beachten, wenn ihr die Ratschläge aus dem letzten Abschnitt idiotischerweise ignorieren solltet: Gebt nicht zu viele Details preis, denn sie würden die Freude an der Problemanalyse verderben.
Am meisten Freude haben die Leute, die ihr fragt, demnach an Fragen wie: "Es geht nicht, was soll ich tun?". Schon verkehrt sind Angaben dazu, ob das Programm nicht baut, ob es coredumpt oder einfach wortlos abbricht, ob es in eine Endlosschleife läuft oder eine falsche Ausgabe produziert.
Richtig grottenfalsch wird so ein Hilfegesuch, wenn ihr auch noch eine konkrete Fehlermeldung gebt oder gar euren Code mitbringt. JedeR könnte einen Fehler finden, wenn ihr sagt: "Der Compiler hat sich über einen Syntaxfehler in der Zeile 23 beschwert, aber if (FOO=bar) ist doch total ok." Richtig ist: "Es hat nicht funktioniert. Das Teil ist abgestürzt. Ich glaub, er hat was von Syntax Error gesagt, aber vielleicht wars auch No such file or directory. Nein, ich habe keine Ahnung, was auf meinem Rechner zu Hause läuft. Wenn ich nochmal nachdenke, habe ich neulich auch mal so einen Blauen Bildschirm gehabt."
Wenn ihr die Lehrenden dringend verärgern wollt, indem ihr sowohl eine Fehlermeldung als auch Code mitbringt und ihnen so den Spaß an der Analyse nehmt, nehmt wenigstens den falschen Quellcode mit. Wenn ihr beispielsweise nach den oben dargestellten Prinzipien so lange an beliebigen Stellen Code geändert habt, bis gar nichts mehr ging, packt den ganzen Rotz zusammen und bringt die Fehlermeldung mit, deren Ignorieren euch zunächst zum willenlosen Rumschmieren verführt hat. Der/die DozentIn wird dann eifrig nach dem Fehler suchen, aber natürlich jede Menge andere finden. Wenn er oder sie einen gefunden hat, sagt: "Oh, richtig, da habe ich was ausprobiert. Lösch einfach die Zeile hier..."
E-Mail macht Spaß und geht schnell. Außerdem ist es einfacher, beim Tippen als beim Reden das Hirn abzuschalten. Wenn ihr denn schon Fragen stellt, ist E-Mail deshalb ein gutes Medium. Ein paar Regeln sind aber auch dabei zu beachten:
- Ihr habt einen Anspruch darauf, dass die Lehrenden genau wissen, was ihr gerade tut. Unterlasst also auf jeden Fall einleitende Worte, aus denen hervorgehen könnte, in welchem Kontext euer Problem aufgetaucht ist.
- Euer bürgerlicher Name ist nicht nur völlig inadäquat für coole Hackerprobleme, er könnte den Lehrenden vielleicht auch Hinweise auf den Kontext geben. Verwendet also für Rückfragen nie die poplige Adresse, die ihr vielleicht am Institut habt, sondern irgendwas Irres, das ihr euch am besten extra für diesen Zweck bei einem Webmailer besorgt -- wie wäre es mit coolBoy3254@hotmail.com? Extra Spaß macht es, wenn ihr diesen Account dann auch gleich wieder löschen lasst. Angesichts dieses Aufwands wäre es natürlich totaler Blödsinn, euren Namen unter die Mail zu schreiben.
- Vermurkst eure Mails in jeder denkbaren Art. Schickt auf jeden Fall HTML (besonders Code macht sich da gut), wenn möglich sogar Word-Dokumente. Seht zu, dass ihr die neueste Word-Version habt, vielleicht auch eine Beta, so dass alle Programme, die das Krickelkrakel alter Versionen dekodieren können, dramatisch versagen. Sorgt dafür, dass ihr alle Word-Tricks einsetzt, damit eine Plain Text-Ausgabe nur Buchstabensalat ist. Code in Excel-Tabellen ist auch gut, vor allem, wenn ihr wisst, dass euer Lehrstuhl Microsoft-Kram nur im Sekretariat hat.
- Lest die Mail auf keinen Fall vor dem Abschicken nochmal durch. Sinnloser Satzbau und abgebrochene Gedanken sind die Würze des Alltags der Lehrenden.
Ein paar Beispiele für kreativen Gebrauch von E-Mail zum Fragen stellen hat Eric S. Raymond zusammengestellt. Studiert einfach alles, wo "Stupid" dabeisteht.
Und das Wichtigste zum Schluss
Bloß nicht zu früh anfangen
Die moralinsaueren Spießer, die euch erzählen, dass ihr frühzeitig mit der Aufgabe anfangen sollt, solltet ihr wie Fehlermeldungen behandeln: ignorieren. Es ist eine heilige Tradition unter ProgrammiererInnen, die Nacht vor der Abgabe mit einem sinnlosen Rausch von Produktivität zuzubringen. Tatsächlich ist das die wichtigste Vorbereitung auf das Berufsleben, die ihr euch vorstellen könnt.
Nur Schwächlinge teilen sich die Arbeit ein. Flaschen erkennt man daran, dass sie am Tag der Abgabe keine gewaltigen Ringe unter den Augen haben.
Bescheißt, dass es kracht
Bedenkt, dass die Aufgaben nur Schikane und Terror sind und bestimmt nichts damit zu tun haben, dass ihr daran was lernen könntet. Benutzt also jeden Trick, der euch einfällt. Es ist klar, dass ihr DozentInnen mit wunderschönen und wohlformulierten Programmen begeistern werdet, auch wenn sie vielleicht nicht ganz die Aufgabe lösen. Umgekehrt wären sie bestimmt entsetzt, würden sie euren Code sehen. Noch mehr: Nachdem ihr die Aufgabe sowieso nur für die Note macht, ist es auch entscheidend wichtig, sich um jeden Preis eine gute Note zu verschaffen.
Das entspricht dann auch dem Geist der Universität, der sagt, dass ihr eure Mitstudis mit möglichst guten Noten niederkonkurrieren sollt. Das sagen Stern, Spiegel und Zeit, und wer würde solchen Autoritäten misstrauen? Die Uni als Platz für Lernen und Lehren? Pah.