Darstellung von Code in Projektdokumentation und Projektpräsentation – IT-Berufe-Podcast-Shorts #6

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.