Schöner Code in Python: klare Namen, Typen, Fehler

Was „schöner Code“ bedeutet, einfach erklärt

Nehmen wir zwei Borschtsch-Rezepte. Das erste: „gieß Wasser ein, schneide die Rote Bete und wirf sie rein, dann Kohl, salz, koch 40 Minuten“. Das zweite: „nimm X, mach Y damit, gib Z dazu, warte T“. Beide funktionieren theoretisch. Aber nach dem ersten kriegt sogar ein Schulkind den Borschtsch hin. Nach dem zweiten nur der, der es geschrieben hat. Und selbst der hat in einer Woche vergessen, was zum Teufel dieses Z war.

Python-Code ist genau so ein Rezept, nur für den Computer. Und es gibt einen Haken, den Anfänger nicht auf dem Schirm haben: Code wird öfter gelesen als geschrieben. Von dir selbst in einem Monat. Von deinem Kollegen. Und - Achtung - von deinem KI-Agenten, wenn du ihm „fix den Bug“ hinwirfst. Schönen Code schnappen sie auf den ersten Blick. Hässlichen entziffern sie Buchstabe für Buchstabe, wie einen Zauberspruch aus einem verstaubten Buch.

Wozu braucht ein Vibecoder, der selbst nicht schreibt, schönen Code

Berechtigte Frage. Du bist Vibecoder. Den Python tippt der Agent Buchstabe für Buchstabe für dich. Was kümmert dich also „schöner Code“? Das hier kümmert dich: die Messlatte für Qualität setzt genau du. Was du verlangst, das kriegst du. Und das ändert sich, wenn die Latte hoch liegt:

• schönen Code ergänzt der Agent im ersten Anlauf, beim hässlichen verheddert er sich und zerstört, was daneben funktioniert hat;
• klare Namen und Typen = weniger Bugs, weil sowohl du als auch der Agent sehen, was wohin fließt;
• kommst du nach einem Monat zum Projekt zurück - blickst du selbst durch deinen Code, statt den Agenten anzuflehen, dir zu erklären, was du da zusammengebastelt hast;
• ein Satz im Prompt - „schreib pythonisch“ - zieht das ganze Projekt fast kostenlos hoch.

Der Unterschied zwischen „der Agent hat mir ein Skript gebaut, und es läuft“ und „der Agent hat mir ein Skript gebaut, das ich weiterentwickeln kann“ - das ist fast immer der Unterschied in der Schönheit des Codes. Los, schauen wir uns an, woraus sie sich zusammensetzt.

Woraus schöner Python besteht: vier Säulen

In der Python-Welt gibt es ein ungeschriebenes Gesetz - „Readability counts“, Lesbarkeit über alles. Gehen wir Schicht für Schicht durch: vom Einfachen zum Spannenden.

Klare Namen für Variablen und Funktionen statt schlauer Tricks

Regel Nummer eins: Code muss offensichtlich sein. Vergleiche zwei Funktionen - sie machen dasselbe, geben nur die aktiven Nutzer zurück.

Gut: get_active_users(users). Du hast doch sogar ohne Python-Kenntnisse schon verstanden, was sie tut? „Gib die Nutzer zurück, die is_active sind“. Der Name hat alles erzählt.

Schlecht: g(u). Und hier? Was ist g? Was ist u? Was steckt drin - x.a? Rätsel über Rätsel, und obendrauf noch ein Rätsel. Funktioniert genau gleich, aber es zu lesen - keine Chance.

Type Hints in Python: Aufkleber auf den Kartons

In Python kannst du beschriften, welche „Fracht“ in eine Funktion reinfährt und was aus ihr rausfährt. Das nennt man Type Hints Type Hints sind Markierungen im Code, die angeben, welcher Datentyp erwartet wird: Text, Zahl, Liste und so weiter. Zum Beispiel bedeutet `name: str` „name ist ein String“. Das Programm ändern sie nicht, aber sie machen es verständlicher für Menschen, den Agenten und Prüfwerkzeuge. .

Schau: Die Notation def process_items(items: list[str]) -> dict[str, int] liest sich als „die Funktion nimmt eine Liste von Strings und gibt ein Dictionary zurück, bei dem die Keys Strings und die Werte Zahlen sind“. Ohne diese Markierungen fahren die Kartons ohne Aufkleber. Und dann rate selbst, was da drin ist.

Was bringt das dem Vibecoder? Der Agent sieht an den Typen sofort, wie die Daten aufgebaut sind, und verheddert sich nicht. Bonus: spezielle Prüfwerkzeuge fangen Fehler ab, noch bevor du auf „Start“ drückst.

Fehler-Handling: fang konkrete ab, nicht alles auf einmal

Irgendwas kann immer kaputtgehen, und Python lässt dich das abfangen. Aber zwischen „wie man abfängt“ klafft ein Abgrund.

Schlecht - „alles auf einmal“ abfangen und still schlucken. Das Programm ist abgestürzt, und du weißt nicht mal davon. Das ist, als würdest du die „check engine“-Lampe mit Klebeband überkleben: blinkt nicht mehr, geschenkt, aber der Motor stirbt derweil leise. Der heimtückischste Bug ist der, den du vor dir selbst versteckt hast.

Gut - einen konkreten Fehler abfangen und ehrlich sagen, was passiert ist: „die Konfigurationsdatei wurde unter diesem Pfad nicht gefunden“. Und fertig. Du siehst die Ursache, der Agent sieht die Ursache, ihr repariert gezielt, statt im Kaffeesatz zu lesen.

Pythonischer Stil statt „wie in anderen Sprachen“

Python hat seine eigene Handschrift - kurze, lesbare Konstrukte, die Zeilen sparen und den Code klarer machen. Auswendig pauken musst du sie nicht. Es reicht zu wissen, dass es sie gibt, und den Agenten zu bitten, sie zu nutzen:

• f-Strings für Text: Werte werden direkt in den String eingefügt - schön und ohne Plus-Geklebe.
• List Comprehensions für einfache Umwandlungen: „nimm die Namen aller aktiven Nutzer“ - eine Zeile statt einer fünfzeiligen Schleife.
• with für die Arbeit mit Dateien: geöffnet - und sie wird garantiert geschlossen, selbst wenn unterwegs etwas abstürzt. Ans Schließen von Hand denken musst du nicht.
• pathlib für Dateipfade - statt Strings von Hand mit Slashes zusammenzukleben.

Beispiel aus dem Leben: funktionierender, aber hässlicher Code

Du bittest den Agenten: „schreib ein Skript, das eine Liste von Links aus einer Datei liest und jeden herunterlädt“. Er spuckt munter funktionierenden Code aus. Du startest - die Hälfte der Links wurde heruntergeladen, die andere nicht, und warum - Grabesstille: das Skript hat die Fehler still geschluckt. Die Variablennamen - a, b, tmp. Eine Woche vergeht, du willst noch „und speicher auch die Dateigröße“ hinzufügen - und der Agent stolpert über diesen Code und zertrümmert, was eben noch lief.

Wo ist der Haken? Der Code war funktionierend, aber hässlich. Ohne Namen, ohne Typen, mit „nacktem except“, das alle Probleme unter den Teppich gekehrt hat.

Und jetzt schau, wie man von Anfang an bittet, um ein schönes und ausbaubares Ergebnis zu kriegen:

Schreib ein Python-Skript, das eine Liste von Links aus einer Datei liest und jeden herunterlädt. Schreib den Code schön und pythonisch:

Gib Funktionen und Variablen klare Namen - aus dem Namen soll klar sein, was die Funktion tut. Keine Namen aus einem Buchstaben.
Setz Type Hints bei allen Funktionen: was rein- und was rausgeht.
Fang Fehler konkret ab (zum Beispiel Datei nicht gefunden oder Netzwerk weg) und gib eine verständliche Meldung aus, was genau schiefgelaufen ist. Kein „nacktes except“, das still alles schluckt.
Nutze pythonische Kniffe: f-Strings für Text, with für die Arbeit mit Dateien, pathlib für Pfade.
Halte dich an den Formatierungsstandard PEP 8.
Erklär am Ende kurz und in einfachen Worten, was jede Funktion tut.

Häufige Anfängerfehler beim Vibecoding

• Sich freuen, dass es „läuft“, und nicht schauen wie. Funktionierender, aber hässlicher Code ist eine Zeitbombe. Ihn später weiterzuentwickeln ist reine Qual.
• Keine Typen und Namen verlangen. Standardmäßig wirft dir der Agent locker ein g(u) hin. Bittest du schön, kriegst du schön. Alles liegt in deiner Hand.
• Fehler verstecken. „Nacktes except“ macht Bugs unsichtbar. Verlange immer, konkret abzufangen und über das Problem zu berichten.
• Der „Cleverness“ hinterherjagen. In Python zählt nicht der schlaue Einzeiler-Trick, sondern Verständlichkeit. Klarheit schlägt Angeberei.
• Keinen Standard vorgeben. Schreib in den Prompt „nach PEP 8“ - das ist der allgemein anerkannte Formatierungsstandard für Python, und der Agent zieht die Ordentlichkeit sofort hoch.
• Monster-Funktionen wachsen lassen. Die Funktion macht zehn Dinge auf einmal? Die ist schwer zu lesen, für dich und für den Agenten. Bitte ihn, sie in kleine Stücke mit klaren Namen zu zerschneiden.