 |
IT-Berufe-PodcastAuthor: Stefan Macke Language: de-de Genres: Business, Careers, Technology Contact email: Get it Feed URL: Get it iTunes ID: Get it |
Listen Now...
Darstellung von Code in Projektdokumentation und Projektpräsentation – IT-Berufe-Podcast-Shorts #6
Sunday, 29 March, 2026
Um die Darstellung von Code in Projektdokumentation und Projektpräsentation geht es in der sechsten Episode der Shorts des IT-Berufe-Podcasts. Zusammenfassung der Episode In der aktuellen Episode meiner Podcast-Shorts dreht sich alles um die Kunst der Codepräsentation in Dokumentationen und Präsentationen – ein Thema, das gerade in der Prüfungsphase viele Prüflinge beschäftigt. Ich gebe praktische Tipps, wie ihr euren Code optimal aufbereitet, um in euren Dokumentationen und Präsentationen zu glänzen. Wir reden darüber, wie der Code in Dokumentationen anders aussehen sollte als in der IDE. Wichtig ist die Lesbarkeit: Setzt auf Struktur und Kontrast, und überlegt euch, ob der Dark Mode wirklich die beste Wahl ist. Ich erkläre, wie ihr den Fokus auf relevante Codeabschnitte legt und unwichtige Details ausblendet. Außerdem teile ich meine besten Hacks für PowerPoint, damit ihr euren Code Schritt für Schritt einblenden könnt – so zieht ihr die Aufmerksamkeit eurer Prüfenden auf eure Erklärungen! Und natürlich gibt es noch Hinweise zur Farbgestaltung, denn Schwarz auf Weiß ist meist der beste Kontrast. Hört rein, holt euch nützliche Tipps und bereitet euch bestens auf eure Prüfungen vor. Ich bin gespannt auf euer Feedback und wünsche euch viel Erfolg bei euren Projekten! ✨🎧 Inhalt Zusammenfassung Die Episode behandelt die Frage, wie Quelltext in Projektdokumentationen und Projektpräsentationen einer Abschlussprüfung für Fachinformatiker Anwendungsentwicklung sinnvoll dargestellt werden sollte. Ausgangspunkt ist die Beobachtung, dass in Prüfungsunterlagen häufig Code-Screenshots aus der IDE verwendet werden, oft zusätzlich im Dark Mode. Die zentrale Aussage lautet, dass Code in der Prüfung nicht so präsentiert werden sollte, wie er in der Entwicklungsumgebung für die tägliche Arbeit angenehm ist, sondern so, dass er im jeweiligen Medium optimal lesbar, verständlich und bewertbar ist. Ausgangslage und Prüfungsbezug Im Kontext der AP2 und der anschließenden Projektdokumentation sowie Projektpräsentation spielt Code eine zentrale Rolle, da er den Kern der Arbeitsleistung von Anwendungsentwicklerinnen und Anwendungsentwicklern darstellt. Dabei wird der Begriff „Code“ weit gefasst: Gemeint ist nicht nur klassischer Programmcode in Sprachen wie Java, C# oder PHP, sondern auch andere textbasierte Artefakte wie Jenkinsfiles, Dockerfiles oder Konfigurationsdateien, sofern sie Teil der technischen Lösung sind. Da diese Artefakte in Dokumentation und Präsentation bewertet werden, müssen sie so aufbereitet sein, dass Prüfende sie ohne unnötige Hürden erfassen können. Zentrale Qualitätsziele Für die Darstellung von Code in Prüfungsartefakten nennt die Episode drei Kernziele: Lesbarkeit Der Code muss visuell gut erfassbar sein. Dazu gehören ausreichende Schriftgröße, geeigneter Kontrast und eine Darstellung, die sich an das Ausgabemedium anpasst. Verständlichkeit Der gezeigte Ausschnitt muss in kurzer Zeit nachvollziehbar sein. Besonders in der Präsentation darf der Umfang nicht so groß sein, dass das Publikum während der Erklärung den Überblick verliert. Bewertbarkeit Gezeigt werden sollte genau das, was die eigene Leistung belegt. Unwichtige oder automatisch erzeugte Inhalte erschweren die Beurteilung und lenken vom eigentlichen Beitrag ab. Unterschied zwischen IDE und Prüfungsmedium Ein zentraler Punkt ist die Trennung zwischen Entwicklungsumgebung und Prüfungsmedium. In der IDE wird Code unter anderen Bedingungen gelesen und bearbeitet als in einer Dokumentation oder Präsentation: In der IDE wird oft an einem Bildschirm mit individueller Konfiguration gearbeitet. Die Dokumentation kann auf Papier, Tablet oder Laptop gelesen werden. Die Präsentation findet typischerweise in einem hellen Raum statt, oft mit Beamer oder Monitor. Daraus folgt, dass Formatierungsentscheidungen aus der IDE nicht automatisch für Doku oder Präsentation geeignet sind. Auch Seitenverhältnisse unterscheiden sich deutlich: Präsentationen meist im Format 16:9 Dokumentationen typischerweise im DIN-A4-Format Code sollte deshalb für jedes Medium separat aufbereitet werden, etwa durch angepasste Zeilenumbrüche und kompaktere Formatierung. Kritik an Screenshots Von Screenshots aus der IDE wird klar abgeraten. Dafür werden mehrere technische Gründe genannt: Screenshots sind nicht verlustfrei skalierbar; beim Zoomen werden sie unscharf oder pixelig. Text bleibt bei Vergrößerung nicht sauber lesbar. Screenshots enthalten oft störende IDE-Elemente wie Fehlermarkierungen, Warnungen, Refactoring-Hinweise oder Hinweise zur Code-Historie. Solche Einblendungen lenken von der eigentlichen Aussage ab und können im Prüfungskontext sogar unerwünschte Fragen auslösen. Empfohlen wird daher, Code als echten Text in Dokumentation oder Präsentation einzufügen. Das verbessert Skalierbarkeit, Lesbarkeit und Bearbeitbarkeit deutlich. Empfehlungen zur Formatierung Für die Formatierung des Codes werden mehrere konkrete Hinweise gegeben: Verwendung einer Monospace-Schriftart, damit Einrückungen und Ausrichtung korrekt bleiben Anpassung von Zeilenlängen und Umbrüchen an das Zielmedium Gegebenenfalls Änderung von Code-Konventionen für die Darstellung, etwa geschweifte Klammern ans Zeilenende statt in eine separate Zeile zu setzen, um Platz zu sparen Nur die relevanten Ausschnitte zeigen, nicht vollständige, kompilierbare Dateien Schlüsselwörter oder Modifier wie public, static, final weglassen, wenn sie für die Aussage nicht relevant sind Syntax-Highlighting verwenden, aber nur in einer Form, die die Lesbarkeit unterstützt Die Episode betont, dass Prüfungsunterlagen keine originalgetreue Abbildung der IDE sein müssen. Erlaubt und sinnvoll ist vielmehr eine auf das Publikum optimierte Darstellung. Bewertung des Dark Mode Ein Schwerpunkt der Episode ist die Kritik am Dark Mode in Dokumentation und Präsentation. Dabei wird ausdrücklich nicht der Dark Mode im Entwicklungsalltag kritisiert, sondern dessen Übertragung in Prüfungsunterlagen. Für Dokumentationen Gegen dunkle Hintergründe in der Dokumentation sprechen laut Episode mehrere Gründe: Schwarzer Text auf weißem Hintergrund bietet den besten Kontrast für das Lesen. Weißer oder farbiger Text auf schwarzem Hintergrund ist schlechter lesbar, insbesondere mit Syntax-Highlighting. Ausdrucke mit schwarzem Hintergrund verbrauchen unnötig viel Toner oder Tinte. Kommentare und Korrekturen auf ausgedruckten Seiten sind auf dunklem Hintergrund schlechter sichtbar. Für Präsentationen Auch in Präsentationen wird der Dark Mode als problematisch beschrieben: In hellen Räumen erscheint Schwarz oft eher grau, wodurch der Kontrast sinkt. Bei Displays oder Monitoren können dunkle Flächen stärker spiegeln. Reflektionen können die Sicht auf den Code zusätzlich erschweren. Die pragmatische Empfehlung lautet daher: Code für die Prüfung möglichst dunkel auf hellem Hintergrund darstellen. Verständlichkeit in der Präsentation Für die Präsentation wird empfohlen, Code nicht in großen Blöcken auf einer Folie zu zeigen. Stattdessen sollte er schrittweise eingeblendet werden, etwa zeilenweise. Begründung: Das Publikum liest sonst sofort den gesamten Code und hört der Erklärung nicht mehr zu. Die Aufmerksamkeit lässt sich besser steuern. Relevante Teile können gezielt erläutert werden. Diese Vorgehensweise ist mit Textobjekten in Präsentationstools deutlich einfacher als mit Screenshots. Auswahl des gezeigten Codes Besonders wichtig ist die Auswahl der Inhalte. Gezeigt werden sollte nur Code, der die eigene fachliche Leistung sichtbar macht. Nicht geeignet sind laut Episode insbesondere: generierte Getter und Setter Standard-Konstruktoren triviale Framework- oder Binding-Logik austauschbare Konfigurationsausschnitte ohne inhaltliche Tiefe HTML-Standardmarkup ohne projektspezifische Aussage Stattdessen sollte der Fokus auf dem fachlich interessanten Teil des Projekts liegen, zum Beispiel: projektspezifische Logik ein selbst entwickelter Algorithmus zentrale Teile der Domäne nicht triviale Datenverarbeitung Logik, die klar die eigene Denk- und Entwicklungsleistung zeigt Fazit der Episode Die Episode versteht Code-Darstellung als Teil der Prüfungsleistung. Ziel ist nicht, die gewohnte IDE-Darstellung zu reproduzieren, sondern die Inhalte so aufzubereiten, dass Prüfende sie schnell erfassen und fair bewerten können. Entscheidend sind dabei eine textbasierte statt bildbasierte Darstellung, hohe Lesbarkeit, reduzierte und zielgerichtete Ausschnitte sowie die Konzentration auf den individuellen fachlichen Beitrag. Die Kernaussage lässt sich so zusammenfassen: Für Dokumentation und Präsentation sollte Code mediengerecht vereinfacht, formatiert und ausgewählt werden, damit er die eigene Leistung klar und ohne Ablenkung zeigt. Höre dir jetzt die Podcast-Episode an! Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Kontrast und Farben Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode [0:20] Während ich das hier aufnehme, sind schon wieder viele Prüflinge im Prüfungsstress, denn die AP2 steht an. Und direkt danach ist bei vielen IHK ja schon die Abgabe der Projektdokumentation. Und danach kommt dann die Projektpräsentation und dann ist endlich die Ausbildung beendet. Und ich werde auch dieses Jahr wieder einige Artefakte mir anschauen dürfen, Projektdokumentation lesen, Projektpräsentation anschauen und natürlich dann bewerten. Und da ich ja nun mal Anwendungsentwicklerinnen prüfe, werde ich da natürlich, solange wir noch Code schreiben müssen, als Anwendungsentwicklerinnen auch Code präsentiert bekommen. Entweder in der Doku oder in der Präsi oder im besten Fall in beiden. Denn das ist ja nun mal der Kern unseres Ausführungsberufs und das gehört natürlich dazu. [1:03] Und Code, damit meine ich nicht nur Programmiersprachencode, Java, C Sharp, PHP, was auch immer. Inzwischen gibt es ja viele andere Artefakte auch, die bei mir als Code durchgehen. Ob es jetzt ein Jenkins-File ist, ein Docker-File, irgendeine Config-Datei, irgendwas, wo halt Text drin geschrieben wird, der irgendwie vom Computer interpretiert wird. Das würde ich jetzt mal sagen, geht als Quelltext, als Code durch und der wird in vielen Dokumentationen und Präsentationen irgendwo gezeigt, weil er natürlich auch Teil des Projekts ist und Kern der Arbeit. Und das soll natürlich vernünftig dargestellt werden. Und ja, ich habe in den letzten Tagen und Wochen öfter auch mal ein paar TikTok-Videos gepostet. Vielleicht kennst du die auch schon. Und ich habe auch mal so eine kleine Doku auseinandergenommen. Und da bin ich dann gestolpert über die Darstellung des Codes in dieser Doku. Und da kamen gleich die wildesten Kommentare, weil ich gesagt habe, man sollte vielleicht nicht unbedingt den Dark Mode benutzen und Screenshots machen, um seinen Code in der Doku zu zeigen. Und deswegen wurde ich natürlich dann direkt auseinandergenommen, Ja, am besten gibt es noch eine Note dafür, weil der Prüfer die richtige Farbe im Hintergrund haben will und bla bla bla. Und naja, das geht alles so ein bisschen in eine Diskussion vorbei, denn eigentlich geht es mir immer darum, dass alle Artefakte in der Doku und der Präsi so aufbereitet werden, dass sie für das Publikum am besten verarbeitbar. [2:18] Verständlich und ja, nachvollziehbar und bewertbar sind. Das ist eigentlich immer mein Kern. Und da geht es mir eigentlich ehrlich gesagt wenig darum, ob es ein schwarz oder weißer Hintergrund ist. Es geht einfach darum, ist das für das Medium passend. Und, Spoiler Alert, Dark Mode ist für die beiden Medien, über die ich jetzt rede, nämlich Doku und Präsi, in den seltensten Fällen passend. Werde ich gleich auch nochmal einmal kurz drauf eingeben. Und deswegen geht es mir heute darum, wie kann man Code vernünftig in einer Doku und in einer Präsi darstellen, damit die Prüfenden den gut bewerten können. Das sollte, glaube ich, das Ziel sein. Und das ist so mein Problem zum Einstieg. Die Präsi, die Doku, das sind halt andere Medien als die gute alte ID, in der wir programmieren. Da sitze ich nicht davor im, weiß nicht, dunkel beleuchteten Zimmer und programmiere vor mich hin, sondern ich habe eine Dokumentation, die ein Prüfender vielleicht ausgedruckt auf Papier liest, vielleicht auf dem iPad oder auf dem Laptop liest und bei einer Präsi bin ich als Prüfender halt Zuschauer und Zuschauerin in einem vielleicht gut beleuchteten, hell beleuchteten Raum und nehme da die Prüfung ab. Und für diese Situation muss der Code optimiert werden und nicht so, wie ich den als Entwickler, Entwicklerin in meiner IDE am liebsten habe. Das muss man einfach trennen. Das ist hier jetzt einfach ein anderes Medium, eine andere Darstellung, eine Prüfungsleistung. Und wenn man im Alltag gerne den Dark Mode benutzt, ich habe kein Problem damit. Mach es gerne, aber überlegst du dreimal, ob es vielleicht für die Doku und Präsi was anderes sein muss. Denn, erste Einschränkung, wir haben in der Doku und der Präsi ganz anderes Seitenverhältnis eventuell in der IDE. [3:45] Präsi üblicherweise 16 zu 9. Das geht noch am ehesten zu unseren Whitescreen-Monitoren heute. Aber die Doku ist halt klassisch DIN A4-Format. Das sieht halt ganz anders aus als in der IDE. Und da muss man vielleicht auch mal ein bisschen umformatieren, damit das vernünftig lesbar ist. Also aus meiner Sicht Ziele für die Prüfung, Lesbarkeit. Die Prüfenden müssen den Code erstmal sehen, lesen, erkennen können. Das ist schon mal der erste Schritt. Da gehört dann sowas rein wie der Kontrast, die Schriftgröße, ja, dass man das einfach vernünftig lesen kann. Und Kontrast ist sowas wie schwarz auf weiß oder halt eben im Dark Mode weiß auf schwarz. Und was dann noch wichtig ist, Verständlichkeit. In der Doku habe ich vielleicht ein bisschen mehr Zeit, den Code in Ruhe zu lesen und zu verstehen. In einer 15-Minuten-Presi, wo du auch noch 27 andere Artefakte hast, ist der Code nur eins davon. Und dann muss man den schnell verstehen können. Und da geht es halt nicht, dass ich seitenweise Code durchgehe. Das kann kein Mensch nachvollziehen. Und dann können wir es auch nicht vernünftig bewerten. Das ist ja das Problem. Es muss bewertbar sein. [4:39] Und deswegen sage ich immer, Fokus auf das Wesentliche. Wesentliche, zeige sinnvollen, spannenden, interessanten Code, der vor allem deine eigene Leistung demonstriert. Nichts, was heutzutage vielleicht durch KI generiert werden kann, aber schon seit zig Jahren auch in der IDE generiert werden kann. Wie zum Beispiel Getter, Setter, Konstruktoren. Das ist dummer Code, den niemand interessiert, weil das sowieso auf Knopfdruck erzeugt wird und in der Zukunft durch KI sogar noch viel stärker. Das heißt, zeig bitte deine eigene Leistung. Darauf kommt es an. Dann ist es ehrlich gesagt völlig egal, was du am liebsten in deiner IDI einstellst. Es geht hier darum, dass die Prüfenden dir optimal die Note dafür geben können. Das muss der Fokus sein. Also weg vom Ego, weg vom Dark Mode eventuell. Und ich wiederhole den Dark Mode heute noch gerne nochmal, weil das immer ein heißes Thema ist. Die Leute fühlen sich sofort angegriffen, wenn man über den Dark Mode herzieht. [5:30] Ich weiß gar nicht warum. Es ist ja einfach, wie gesagt, ein anderes Prüfungsartefakt. Da muss man sich mal ein bisschen Gedanken machen. Und dazu zähle ich dann auch noch sowas wie Code-Konventionen oder auch die Vollständigkeit des Codes. Das meine ich damit, Code-Konventionen, wenn deine IDE, das ist mein Lieblingsbeispiel, die geschweiften Klammern, wenn du eine Sprache benutzt, wo die häufig verwendet werden, in der nächsten Zeile anfangen, anstatt am Zeilenende. Dann kann es durchaus sinnvoll sein, für die Doku oder Präsi das zu verändern und die Klammer einfach ans Ende der vorherigen Zeile zu packen, weil du dann weniger Platz verschwendest. Eine leere Zeile, in der nur eine Klammer steht quasi. Das ist in der IDE sicherlich gut. Ich benutze das übrigens im Alter auch, diesen Stil. Ich finde den super. [6:07] Aber es ist halt für Doku und Präsi Zeilenverschwendung, bin ich mal ganz ehrlich. Das heißt, da musst du einfach anders formatieren, damit es in diesem Medium vernünftig aussieht. Und Vollständigkeit, es geht hier nicht darum, dass du Compiler spielst und dein Code komplett durchkompiliert mit allen Abhängigkeiten, sondern du zeigst nur Ausschnitte. Und dann darfst und sollst du auch gerne die Sachen weglassen, die niemanden interessieren. Und das sind manchmal sogar sowas wie, Bezeichner wollte ich schon sagen, wie irgendwelche Modifizierer, Public, Static, Tralala, alles, was man irgendwo vorschreiben kann, ist für das Verständnis der Logik des Codes erstmal irrelevant. Außer natürlich, du willst gerade irgendwas Architekturelles zeigen und es ist ganz wichtig, wie die Sichtbarkeit ist. Okay, ja. Aber im Kern kannst du im Prinzip alle Schlüsselwörter weglassen, die nicht das, was du da eigentlich zeigen willst, irgendwie unterstützen, unterstreichen. Die lenken dann nämlich nur ab und ich versuche die ganze Zeit zu überlegen, das ist eine Static-Methode, war das denn wohl die richtige Wahl? Hätte er oder sie das nicht doch noch anders machen können? Und schon bin ich abgelenkt und konzentriere mich gar nicht auf das, was du mir zeigen willst. Das heißt, schmeiß deine üblichen Standardsachen aus dem Alltag über Bord und konzentriere dich auf das Medium, das du da gerade vor dir hast und optimiere dafür den Code. Das ist eigentlich schon mal meine Kernaussage heute hier. Und jetzt gehe ich die einzelnen Punkte mal kurz durch, damit du ein bisschen was Konkretes mitnehmen kannst. [7:21] Lesbarkeit, mein erster Punkt, was ich nicht lesen kann als Prüfender, kann ich nicht bewerten. Ja, doof gesagt. Und da geht es schon los, wenn ich zum Beispiel Screenshots habe aus der IDE, die skalieren halt nicht. Wenn ich einen Screenshot mache, speichere das als JPEG, dann ist das nicht mehr skalierbar. Zoome ich da rein, kriege ich alles pixellig, da kann ich nicht vernünftig lesen. Und selbst wenn ich meine Doku oder die Dokus der Prüfenden auf dem iPad lese, kann ich da rein zoomen, aber dadurch wird der Text halt nicht besser, weil es skaliert halt nicht mit. Deswegen mein Punkt, pack den Code wirklich als Text in dein Medium, in die Doku, in die Präsi. Und wenn du dann da reinzoomst, dann skaliert der Text perfekt mit und wird nicht pixellig. Das wäre schon der erste Grund aus meiner Sicht gegen einen Screenshot. Aber wie ihm auch sei, achte vor allem darauf, dass der Text groß genug ist. In der Doku reicht es, wenn er so groß ist wie der Rest deines Textes. In der Präsi sollte er möglichst groß sein, damit die Menschen, die da vorsetzen und dich bewerten, den halt lesen können. Das wäre schon mal der erste Punkt. Der Code wird natürlich genauso gesetzt, wie wir es aus der IDE kennen, also mit einem Monospace-Font, also nicht Proportionalschrift. Du kennst das, Carrier, Carrier New zum Beispiel, wo also jeder Buchstabe gleich breit ist. Denn bei Code kommt es darauf an, teilweise, dass Sachen exakt untereinander stehen, wie zum Beispiel Klammern. Also setz den Code jetzt nicht in Arial oder Times New Roman, sondern schon passend, wie es in der IDE auch aussieht. Aber deswegen musst du ja noch lange keinen Screenshot machen. Du kannst es ja auch in PowerPoint zum Beispiel einstellen, dass das einfach eine andere Front ist. Fertig. [8:43] Ich habe es gerade schon gesagt, pass die Zeilen gerne an, brech die vernünftig um, pack die Klammern an eine andere Stelle, wenn es hilft. Ja, das sehe ich insbesondere in der Präsi, wenn dann ganz viele Sachen untereinander stehen. Es ist halt doof für die Präsi, wenn ich 16 zu 9 Format habe. Dann passt es halt nicht allzu viel auf die Folie. Und umgekehrt genau in der Doku, wenn ich die in der 4 Format habe, dann muss ich vielleicht eher optimieren, dass es vertikal gelesen wird, weil ich halt nach unten heraus mehr Platz habe als zur Seite. Also eventuell in der Präsi die Zeilen länger machen, in der Doku die Zeilen kürzer machen. damit ich den Platz vernünftig ausnutze. Und da darf man dann auch gerne mal einen zusätzlichen Umbruch einbauen. Jetzt mal, ich habe immer so ein bisschen Java-Code im Kopf, aber es ist ja in vielen Programmiersprachen auch ähnlich. Da habe ich sowas wie die ganzen Modifizierer und Final und Rückgabewert und Parameter. Und dann darf man ruhig auch mal vor den Parametern einen Zeilenumbruch machen. Klammer auf, Zeilenumbruch, wenn das besser lesbar ist. Throws Exception, vorher Zeilenumbruch, ja, in der Doku, wenn ich Platz nur nach unten hin habe und nicht zur Seite. Das meine ich damit. Gerne an das Medium passend den Code setzen. [9:44] Und selbstverständlich wollen wir auch gerne Code-Highlighting haben. Das heißt jetzt nicht, ich will einfach nur schwarz auf weißen Code. Natürlich hilft es dem Verständnis, wenn Schlüsselwörter, Variablen und was auch immer vernünftig hervorgehoben sind und da behaupte ich einfach mal, das wirst du mit PowerPoint, das wirst du mit Word oder anderen Tools hinkriegen, dass du das vernünftig formatierst. Du kannst meistens sogar in Word, würde ich sagen, du kopierst es aus der IDE raus, dann nimmt er die Farbinformation schon mit aus der IDE. Ja, musst du bloß noch den schwarzen Hintergrund wieder ausstellen, wenn du Dark Mode nutzt und schon hast du schon schön, vernünftig formatierten Code. Das ist nicht viel Aufwand. Du musst nicht händisch jedes Wort selber formatieren. Das können die modernen Tools schon von alleine. So, jetzt nochmal zum Lieblingsthema Dark Mode. Also ich sag’s gerne nochmal, ich habe nichts gegen den Dark Mode. Wenn du den gut findest, nutz den. Das ist mir egal. Aber denk dran, dass das für die Doku und Präsi vielleicht nicht optimal ist. Warum? Der Kontrast auf Papier ist einfach auch nachgewiesen, dass Schwarz auf Weiß einfach der beste Kontrast ist. Weiß auf Schwarz ist der zweitbeste Kontrast. Er ist auch nicht sehr viel schlechter zu lesen, aber ein bisschen schlechter. Und dann würde ich doch einfach das Optimum nehmen. Also schwarz auf weiß ist das am besten zu lesen fürs menschliche Auge. Warum willst du was anderes machen, wenn Leute diesen Code lesen? Es geht hier ja nicht darum, zu programmieren bei wenig Licht, sondern wie gesagt, damit ich den Code vernünftig lesen kann. Und da ist schwarz auf weiß einfach das Beste. [11:00] Und jetzt überlegen wir mal, eigentlich haben wir ja bei Code gar nicht schwarz auf weiß, weil wir haben ja das Syntax-Highlighting, hätte ich gerade schon gesagt. Das heißt, manchmal haben wir da vielleicht lila oder grün oder braun auf weiß. Und das kann man alles noch relativ gut lesen. Drehst du das jetzt aber um und machst das auf schwarz im Hintergrund, dann wird das sehr schwer zu lesen. Es wird ein schwerer Kontrast. Überleg dir einfach mal, du hast einen schwarzen Hintergrund und druckst das auf Papier aus und willst da drauf dann vielleicht etwas dunklere Schrift lesen. Das ist echt schwierig. Abgesehen davon verbraucht es natürlich ohne Ende Toner beziehungsweise Tinte, wenn ich den Kram ausdrucke. Einfach ein schwarzes Blatt. Und man muss ja gucken, das wenigste von diesem schwarzen Blatt ist tatsächlich Code. Das meiste ist der Hintergrund. Das heißt, du hast einfach ein schwarzes Blatt mit ein ganz bisschen Wörtern drauf. Und das ist eine riesen Papier- und Tonerverschwendung. Und ja, auch im Jahr 2026 drucken sich Prüfende die Dokus noch aus, weil sie vielleicht kein iPad haben mit einem Pencil. Und es geht ja darum, die Doku zu korrigieren. Also macht man sich Anmerkungen. Und das kann man schlecht am PC. Das geht bei vielen Menschen viel einfacher handschriftlich. Und dann gibt es noch Leute, die sich das ausdrucken. Und das ist auch gar nicht schlecht. Und wenn ich mir dann einen Kommentar in deinen Code machen will, auf einem schwarzen Blatt, ja, viel Spaß, das wiederzufinden. Der Rotstift, den ich habe, den sieht man auf dem schwarzen Hintergrund gar nicht, weil alles schwarz ist. Also, es gibt so viele Gründe, gerade in der Doku auf den Dark Mode zu verzichten. Macht das bitte einfach. [12:20] Und auch zu Präsi, jetzt kann man ja sagen, Doku, okay, aber in der Präsi ist das ja nicht so. Ja, da habe ich aber einen Punkt, der dagegen spricht. Du wirst normalerweise irgendwann tagsüber präsentieren und meistens auch in einem gut beleuchteten Raum, würde ich jetzt einfach mal behaupten. Ja, Ausnahmestätigen Regeln, ja. Aber wenn das so ist, dann guck einfach mal, wenn du eine Präsi hast mit einem schwarzen Hintergrund und du bist in einem hellen Raum, dann wirst du nicht schwarzen Hintergrund haben, sondern grauen Hintergrund, weil das Licht einfach das schwarze ein bisschen aufhält. Und schon hast du nicht mehr weiß auf schwarz, sondern du hast weiß auf grau, mit grauem Hintergrund. Und das ist wieder ein schlechterer Kontrast. Das kann man einfach nicht gut lesen. Und wenn du jetzt ganz viel Pech hast, dann bist du in einem Raum, wo es wirklich so hell ist und du hast zum Beispiel einen Monitor, also ein selbstleuchtendes Medium, dann reflektiert dieses Medium. Und wenn du einen schwarzen Hintergrund hast, dann reflektiert das optimal. Das heißt, wenn du dann zum Beispiel auf diesen Monitor guckst, dann spiegeln sich, Das habe ich original mal in der Prüfung gesehen. Dann spiegeln sich die Prüfenden in dem Monitor, weil der Hintergrund schwarz ist. Wenn der weiß ist, spiegeln die sich auch, aber es fällt nicht so auf. Und dann hast du auf einmal in deiner Präsentation irgendwelche Köpfe, die du da siehst, aber siehst den Code gar nicht mehr, weil der schwarze Hintergrund halt so reflektiert. Also das sind alles Punkte aus meiner persönlichen Erfahrung, habe ich schon so oft gesehen. Mach es einfach nicht. Mach den Code schwarz auf weiß, dann gibt es keine Probleme. Alle können das gut lesen. [13:40] Alle freuen sich und geben dir eine gute Note vor allem. So, jetzt habe ich gerade schon gesagt, Code-Highlighting würde ich auch empfehlen, auf jeden Fall. Aber immer geht die Lesbarkeit vor. Das heißt, wenn du gerne deine Kommentare in hellgrün hervorhebst, aber du einen weißen Hintergrund hast, dann ist hellgrün auf weiß vielleicht nicht der optimale Kontrast. Dann macht die Farben doch einen Ticken dunkler. Also bitte nicht eins zu eins die ID übernehmen, sondern guck, wie sieht das in dem Medium, was ich gerade gestalte, aus? Kann man das vernünftig lesen? Und wenn nicht, dann pass es an. Dann macht die Schrift dunkler oder heller oder was auch immer du machen musst. [14:15] Wenn du den Text, äh, nein, wenn du den Code als Text in deiner Präsi zum Beispiel hast, kannst du es auch relativ einfach hinbekommen, den Code Schritt für Schritt einzublenden. So zeilenweise, ne? Das ist ja auch immer, habe ich gerade schon gesagt, die Verständlichkeit ist ganz wichtig. Und wenn du jetzt eine ganze Folie voll mit Code dahin klatschst, und die dann Zeile für Zeile erklärst, dann kannst du davon ausgehen, dass alle Prüfenden und nicht nur Prüfende, auch andere Menschen würden das so machen, sich erstmal den ganzen Code schön in Ruhe durchlesen und versuchen, den zu verstehen, während du dann auch am rumkaspern bist und irgendwas erklärst. Und das heißt, es hört dir keiner mehr zu. Also, mach das doch einfach Zeile für Zeile, das blendest du nacheinander ein und erklärst das dann. Und das kann man super einfach mit drei Klicks in PowerPoint, wenn alles einzelne Zeilen in Text sind. Das geht auch mit Screenshots überhaupt kein Problem. Es ist nur aufwendiger. Da musst du noch, weiß ich nicht, irgendwelche Rechtecke davor machen und die runterschieben oder ausblenden, damit der Code dann sichtbar ist. Und wenn das Text ist, wie gesagt, drei Klicks. Einblenden, Animation einfügen, bumm, läuft. Also macht ihr das Leben doch einfach. [15:13] Wenn du das so machen möchtest. Was ich auch aus der Praxis schon oft gesehen habe, tatsächlich bei Screenshots aus der IDE, es werden natürlich alle Sachen gescreenshortet, nicht nur der Code. Das heißt zum Beispiel in IntelliJ gibt es immer so Hints an den Code-Zeiten, zum Beispiel wie oft die benutzt werden oder wer den letzten Code mitgemacht hat und solche Sachen. Ist natürlich für deine Präsentation völlig irrelevant und ablenkend, wenn man das immer sieht. Am schlimmsten wäre es natürlich, wenn da steht, Moment mal, die Code-Zelle wurde gar nicht vom Prüfling bearbeitet, sondern von irgendwem anders. Oh, oh, oh, das ist natürlich dann ganz problematisch. Aber auch wie, keine Ahnung, Fehler, die in der IDE gefunden wurden, irgendwelche Optimierungen, Rechtschreibfehler in Variablen Namen. Da ist ja alles zu sehen, auch diese kleinen Schlängelchen unter den Wörtern, wenn da irgendwie ein Fehler oder wenn die IDE irgendwas findet. Das ist ja alles mit drin. Und das habe ich original schon in so vielen Präsentationen gesehen, dass die Leute dann einfach gescreenshottet haben mit allen Schlängelchen und allen roten Hinweisen und so weiter da drin. [16:05] Also Fehler, das wäre ja Vollkatastrophe. Aber zum Beispiel auch Refactoring-Tipps oder so. So, da wird quasi, da sagt die IDE, Achtung, Achtung, diese Variable wird nirgendwo benutzt. Ist jetzt nur ein Beispiel. Und dann machen die davon einen Screenshot und zeigen das in ihrer Prüfung. So, hey, ich habe eine Variable deklariert, die ich gar nicht benutze. Das ist doch keine gute Arbeitsleistung. Wenn die IDE einem das schon sagt, dann muss man nur einmal draufklicken und dann wird die Variable gelöscht. Und das ist jetzt wirklich nur ein Beispiel. Es gibt natürlich noch ganz viele andere Möglichkeiten, Refactorings zu zeigen. Und das willst du doch nicht in deiner Prüfung. Also, kopier den Text raus und mach keinen Screenshot. und wenn du Screenshots machst, dann geh wenigstens so weit und schmeiß diesen ganzen Kram, den niemand interessiert. Die Schlängelchen, die Fehler, die Vorschläge etc. Bitte einfach raus, weil das lenkt super ab und ich mache mir nur noch Gedanken, ob du das wirklich selber gemacht hast, ob da jemand mitgeholfen hat, ob du nicht gesehen hast, dass die IDE dir Vorschläge gemacht hat, dass du quasi gar nicht hingeguckt hast. War das vielleicht einfach nur gecopy-pasted? Du hast dich gleich damit auseinandergesetzt. Also ich stelle mir tausend Fragen, wenn ich diese Sachen sehe, die mich eigentlich nur von deinem Code ablenken. Also lass es doch bitte einfach weg. [17:08] So, dann kommen wir auch gleich zum Thema Verständlichkeit. Hier kannst du gerne aus deinem Code, wie gesagt, alles rausschmeißen, was niemanden interessiert. Irgendwelche Modifizierer, Public, Final, Static, was auch immer. Interessiert doch nicht, wenn du gerade einen Algorithmus erklären willst, ja. Getter, Setter zum Beispiel. Oh Gott, lass das doch einfach weg. Du willst eine Klasse zeigen. Ja, dann konzentrier dich auf den wichtigen Kernalgorithmus, den du gebaut hast und nicht auf die generierten Getter und Setter, die alle aus einer Zeile Code bestehen. Das ist einfach langweilig, komme ich gleich nochmal zu, sowieso, aber es brauche ich auch nicht zum Verständnis. Also wenn ich in deinem Code, in deinem Algorithmus irgendwas lese wie GetName, dann kann ich mir wohl herleiten, dass das eine Methode ist, die den Namen zurückgibt. Ja, da brauchst du nicht erklären. Aber wenn du komplizierte Methoden aufrufst, wo es nicht sofort ersichtlich ist, dann solltest du es vielleicht einblenden. Also mach dir doch mal ein bisschen Gedanken. Jemand, der deinen Code noch nie gelesen hat, was braucht der oder die, um zu verstehen, was du da gerade gemacht hast? Und das sollte auf deiner Folie erscheinen. Und alles andere bitte nicht. [18:04] Und dann komme ich zum letzten und aus meiner Sicht nochmal wichtigsten Punkt. Konzentrier dich auf deine eigene Leistung. Das ist hier eine Prüfungsleistung. Es geht hier nicht darum, coolen, fancy Code zu programmieren und keine Ahnung, du bist der geilste Coder, die geilste Coderin. Es geht um eine Prüfungsleistung, die bewertet wird. Und da möchte ich deine eigene Leistung sehen. Da möchte ich weder generierte Getter Setter sehen, da möchte ich auch keinen KI-generierten Code sehen, sondern möchte ich das sehen, was du gemacht hast. Es ist deine Prüfung. Du bekommst die Note. Du bist danach ausgebildete Fachinformatikerin. Deswegen zeig doch auch das Beste, was du gemacht hast. Zeig spannenden Code mit ein bisschen Logik drin, wo du einen kleinen Algorithmus gemacht hast. Das muss nichts Weltbewegendes sein. Das müssen nicht 100 Zeilen sein. Es reicht ein bisschen, weiß ich nicht, wenigstens If, Else und Schleife oder sowas. Oder wenn du in Java arbeitest, irgendwie mal eine kleine Stream-Logik mit Map, Filter, Reduce. Irgendwas, wo du auch selber ein bisschen überlegen musstest. Ja, im besten Fall irgendwie auch den Kern deines Problems, dass du nicht irgendeinen Random-Code im Frontend zeigst, der irgendwie Data-Binding macht, was in jedem Framework immer gleich ist, sondern etwas, was dein Projekt ausmacht. Etwas, was nur du in deinem Projekt gemacht hast, den Kern deiner Domäne. So etwas ist spannend. Ja, und nicht das x-te Mal erklären, wie im Frontend ein Feld an ein Input-Feld gebunden wird. So, das ist maximal generisch und langweilig. Das haben wir schon tausend Mal gesehen. sondern es geht darum, was du in deinem Projekt Besonderes gemacht hast. Das wäre meine Zentrale Empfehlung, damit ich deine Leistungen bewerten kann und dir dafür eine Note geben kann. [19:32] Und ich nehme immer nur Getter und Zetter als Beispiel. Das gibt es in allen Sprachen oder so. Ich habe auch schon Präses gesehen mit Config-Files, mit Zeilenausschnitten aus Config-Files, wo einfach nur Werte gesetzt wurden. Oder HTML-Oberflächen. Ich meine, HTML ist schön und gut, das brauchen wir alles super, aber muss ich jetzt wirklich jedes P und A und Span und irgendwas tagt da sehen? Oder will ich nicht vielleicht das Interessante sehen, was dein Projekt besonders macht? Und Spoiler, natürlich will ich das Interessante sehen und nicht diesen langweiligen Standardkram. [20:02] So, fassen wir nochmal zusammen. Es soll ja nur ein Short sein heute. Ich glaube, den Rahmen habe ich schon fast wieder gesprengt. Meine Empfehlung. Such dir spannenden Code, der deine Arbeitsleistung gut demonstriert und zu deiner Domäne passt. Nichts Generisches, also bitte nicht falsch verstehen, keine generischen Klassen. Darfst du gerne zeigen, wenn du welche gebaut hast, sondern allgemeinen Code, den jeder andere in irgendeinem Projekt auch hätte machen können. Das will keiner sehen, sondern das, was du für dein Projekt individuell besonders gemacht hast. Das ist interessant. Schmeiß alle uninteressanten oder ablenkenden Inhalte raus. Irgendwelche Overlays aus der IDE, am besten noch Fehlerschlängelchen, solche Sachen. Bitte alles rausschmeißen, damit das nicht ablenkt von dem, was du eigentlich zeigen willst. Und dann optimierst du den Code an das Medium. Setz ihn quasi hochkant für deine Projektdokumentation und eher zur Seite für die Projektpräsentation. Dafür darfst du auch gerne Umbrüche einfügen, rausnehmen, Zeilenlängen anpassen. Alles erlaubt, solange man das auf dem Medium gut lesen kann. Das ist der Fokus. Und dann ist es oft sinnvoll, in der Präsentation den Code Schritt für Schritt einzublenden, also Zeile für Zeile, während du es erklärst, damit die Leute nicht abgelenkt sind und den ganzen Code schon lesen. [21:07] Und natürlich darfst du auch ein Syntax-Highlighting einfügen, aber kontrolliere am Ende nochmal, ob es dem Kontrast dienlich ist oder nicht. [21:15] So, das wären meine Tipps für vernünftiges Darstellen von Code in der Projektpräsentation und Dokumentation. Ich hoffe, du konntest ein bisschen was mitnehmen. Und wenn du eine andere Meinung hast und sagst, ich will aber immer ein Datenbot benutzen, dann schreib mir gerne einen Kommentar. Erwarte aber nicht, dass ich darauf sinnvoll antworte, weil meine Erklärung, warum das nicht sinnvoll ist, in vielen Fällen, habe ich ja jetzt hiermit geliefert. Und damit würde ich sagen, viel Erfolg bei deiner Projektdokumentation und Präsentation.
