Home

02 Quiz: Code-Qualität in der Praxis

exercises quiz chapter-02 code-quality pep8

Anleitung


Frage 1: Die Realität von funktionierendem Code

Was ist der grundlegende Unterschied zwischen “funktionierendem Code” und “professionellem Code”?

A) Professioneller Code läuft schneller und verbraucht weniger Speicher
B) Funktionierender Code erfüllt Benutzeranforderungen, aber professioneller Code erfüllt auch Qualitätsstandards für Wartbarkeit, Lesbarkeit und Teamzusammenarbeit
C) Professioneller Code ist immer länger und komplexer
D) Funktionierender Code ist für Studenten, professioneller Code ist für Unternehmen

Antwort anzeigen

Richtige Antwort: B

Das Eröffnungsszenario der Vorlesung demonstriert dies perfekt: Der Road Profile Viewer funktioniert hervorragend, besteht aber die automatisierten Qualitätsprüfungen nicht. Professioneller Code muss sowohl funktionale Anforderungen (er funktioniert) als auch nicht-funktionale Anforderungen (er ist wartbar, lesbar und folgt Teamstandards) erfüllen. Geschwindigkeit (A) und Länge (C) sind nicht die entscheidenden Faktoren, und sowohl Studenten als auch Unternehmen können beide Arten schreiben (D ist zu vereinfacht).


Frage 2: Der Zweck automatisierter Qualitätsprüfungen

Warum verwenden professionelle Entwicklungsteams automatisierte Code-Qualitätsprüfungen, bevor sie Code-Merges zulassen?

A) Um das Leben der Entwickler zu erschweren und die Entwicklung zu verlangsamen
B) Um menschliche Code-Reviewer vollständig zu ersetzen
C) Um Stilprobleme, potenzielle Bugs und Inkonsistenzen frühzeitig zu erkennen und menschlichen Reviewern zu ermöglichen, sich auf Logik und Architektur zu konzentrieren
D) Um die Verwendung spezifischer Programmiersprachen zu erzwingen

Antwort anzeigen

Richtige Antwort: C

Automatisierte Prüfungen dienen als erste Verteidigungslinie und erkennen mechanische Probleme (Stilverstöße, ungenutzte Imports, Typfehler) in Sekundenschnelle. Dies ermöglicht es menschlichen Reviewern, ihre wertvolle Zeit auf übergeordnete Belange wie Algorithmus-Korrektheit, Architekturentscheidungen und Geschäftslogik zu konzentrieren. Automatisierung ergänzt Menschen, ersetzt sie nicht (B ist falsch), und sie beschleunigt die Entwicklung, indem sie Probleme früh erkennt (A ist falsch).


Frage 3: Best Practices für Import-Anweisungen

Warum empfiehlt PEP 8, Imports auf separate Zeilen zu setzen?

A) Python läuft schneller mit separaten Import-Anweisungen
B) Es verbessert die Lesbarkeit und macht es einfacher nachzuvollziehen, welche Module tatsächlich verwendet werden
C) Es ist vom Python-Interpreter erforderlich, sonst läuft der Code nicht
D) Separate Imports nehmen mehr Zeilen ein und lassen die Code-Datei substantieller aussehen

Antwort anzeigen

Richtige Antwort: B

Die Vorlesung demonstriert dies mit dem Beispiel import sys,os. Separate Imports machen es einfacher zu scannen, was importiert wird, ungenutzte Imports aufzuspüren und Abhängigkeiten auf einen Blick zu verstehen. Dies betrifft rein die menschliche Lesbarkeit—Python führt den Code in beiden Fällen aus (A und C sind falsch), und eine künstliche Aufblähung der Zeilenzahl hat keinen Wert (D ist falsch).


Frage 4: Die Kosten von totem Code

Was ist das HAUPTPROBLEM beim Behalten ungenutzter Funktionen in Ihrer Codebasis?

A) Sie führen dazu, dass das Programm zur Laufzeit abstürzt
B) Sie verschwenden Festplattenspeicher und machen Dateien größer
C) Sie erzeugen Wartungsaufwand—jemand muss sie während Refactorings aktualisieren, und sie verwirren zukünftige Entwickler darüber, was wichtig ist
D) Sie werden automatisch trotzdem ausgeführt und verlangsamen das Programm

Antwort anzeigen

Richtige Antwort: C

Der Abschnitt “technische Schulden” der Vorlesung erklärt dies klar: Toter Code kostet Wartungsaufwand (Aktualisierung bei API-Änderungen), kognitiven Aufwand (zukünftige Entwickler müssen ihn lesen und verstehen) und erzeugt Verwirrung (“Kann ich das sicher löschen?”). Toter Code wird nicht ausgeführt (D ist falsch), stürzt Programme nicht ab (A ist falsch), und während Festplattenspeicher eine geringfügige Sorge ist, sind die echten Kosten menschliche Zeit (C erfasst das wesentliche Problem besser als B).


Frage 5: Die 10:1-Regel

Worauf bezieht sich laut Vorlesung die “10:1-Regel” in der Softwareentwicklung?

A) 10% des Codes verursachen 90% der Bugs
B) Code wird ungefähr 10-mal häufiger gelesen als geschrieben
C) Code zu schreiben dauert 10-mal länger als ihn zu planen
D) 10 Entwickler können Arbeit 10-mal schneller erledigen als 1 Entwickler

Antwort anzeigen

Richtige Antwort: B

Die Vorlesung stellt explizit fest: “Für jede Stunde, die mit dem Schreiben von Code verbracht wird, werden ungefähr 10 Stunden damit verbracht, ihn zu lesen.” Diese grundlegende Einsicht erklärt, warum Code-Qualität für das Lesen optimiert, nicht für das Schreiben. Der Code, den Sie einmal schreiben, wird beim Debuggen, Code-Review, bei Feature-Ergänzungen, Bug-Fixes und Onboarding gelesen—und akkumuliert dabei weit mehr Lesezeit als Schreibzeit.


Frage 6: Leerraum und Lesbarkeit

Warum verbessert korrekter Leerraum um Operatoren (z.B. x = 5 statt x=5) die Code-Qualität?

A) Python erfordert Leerzeichen, sonst erzeugt es Syntaxfehler
B) Leerzeichen machen die Dateigröße größer, was das Caching verbessert
C) Leerraum schafft visuelle Grenzen, die dem Gehirn helfen, Code in “Chunks” zu parsen, wodurch die kognitive Last um etwa 30% reduziert wird
D) Es ist rein ästhetisch ohne messbare Auswirkung

Antwort anzeigen

Richtige Antwort: C

Die Vorlesung zitiert kognitionspsychologische Forschung, die zeigt, dass Leerraum natürliche Grenzen zwischen Informations-Chunks schafft und Code visuell 30% schneller zu parsen macht. Dies ist nicht nur Ästhetik (D ist falsch)—es geht um die Reduzierung des mentalen Aufwands, der zum Verständnis von Code erforderlich ist. Python erfordert diese Leerzeichen nicht syntaktisch (A ist falsch), und Dateigröße ist irrelevant (B ist unsinnig).


Frage 7: Namenskonventionen als gemeinsame Sprache

Was signalisiert PascalCase (wie HelperFunction) in Python typischerweise?

A) Eine Funktion, die überall im Code verwendet werden sollte
B) Eine Klassendefinition
C) Ein konstanter Wert, der sich nie ändert
D) Eine Variable, die Hilfsdaten speichert

Antwort anzeigen

Richtige Antwort: B

Pythons Namenskonventionen bilden eine gemeinsame Sprache: PascalCase signalisiert Klassen, snake_case signalisiert Funktionen/Variablen, und UPPER_CASE signalisiert Konstanten. Wenn Sie HelperFunction sehen, erwartet Ihr Gehirn eine Klasse. Die Verwendung für eine Funktion erzeugt kognitive Dissonanz und verletzt das Prinzip der geringsten Überraschung. Die Vorlesung demonstriert, wie das Brechen dieser Konventionen Entwicklerzeit verschwendet und Debugging-Verwirrung erzeugt.


Frage 8: Zeilenlängenbegrenzungen

Was ist der HAUPTGRUND für die Begrenzung der Zeilenlänge auf 79-88 Zeichen?

A) Ältere Monitore können längere Zeilen nicht anzeigen
B) Pythons Interpreter verarbeitet kürzere Zeilen schneller
C) Es ermöglicht side-by-side Code-Vergleich, Split-Screen-Entwicklung und verbessert die Lesbarkeit—besonders bei Code-Reviews und Diffs
D) Kürzere Zeilen verbrauchen weniger Festplattenspeicher

Antwort anzeigen

Richtige Antwort: C

Die Vorlesung liefert spezifische Szenarien: side-by-side Code-Review, Split-Screen-Entwicklung und lesbare Diffs. Lange Zeilen erzwingen horizontales Scrollen und machen es schwierig, Versionen zu vergleichen oder mit mehreren Dateien gleichzeitig zu arbeiten. Forschung zeigt, dass das Verständnis bei Zeilen länger als 60-80 Zeichen abnimmt. Dies betrifft nicht Hardware-Limitierungen (A) oder Performance (B und D sind falsch).


Frage 9: Die Kosten von Bugs im Zeitverlauf

Laut der Bug-Kostenanalyse der Vorlesung: Wann ist es AM TEUERSTEN, einen Bug zu beheben?

A) Während der initialen Entwicklung beim Schreiben des Codes
B) Während des Code-Reviews vor dem Merge
C) In der Produktion nachdem Benutzer darauf gestoßen sind
D) Alle Bugs kosten gleich viel zu beheben, unabhängig davon, wann sie gefunden werden

Antwort anzeigen

Richtige Antwort: C

Die Vorlesung präsentiert eine Tabelle, die zeigt, dass Bug-Kosten exponentiell wachsen: Behebung während der Entwicklung dauert Minuten, Code-Review dauert Stunden, Produktions-Bugs dauern Tage und verursachen Benutzerauswirkungen, Reputationsschäden und potenziellen Datenverlust. Früherkennung durch automatisierte Tools verhindert diese teuren Produktions-Bugs. Option D widerspricht der gesamten Prämisse der Vorlesung über frühe Qualitätsprüfungen.


Frage 10: Konsistenz und kognitive Last

Wie reduziert Code-Konsistenz die kognitive Last für Entwickler?

A) Konsistenter Code wird schneller ausgeführt, weil die CPU Muster erkennt
B) Musterererkennende Gehirne erkennen konsistente Muster sofort, entdecken Anomalien schnell und verstehen Absichten schneller ohne Kontextwechsel
C) Konsistenz bedeutet, dass aller Code exakt gleich aussieht, sodass Entwickler frei copy-pasten können
D) Es tut es nicht—Inkonsistenz ist besser, weil sie Code einzigartiger macht

Antwort anzeigen

Richtige Antwort: B

Die Vorlesung erklärt, dass Ihr Gehirn eine Mustererkennungsmaschine ist. Konsistenter Code ermöglicht sofortige Mustererkennung, während inkonsistenter Code Ihr Gehirn zwingt, jede Zeile einzeln zu parsen und ständig den Kontext zu wechseln. Dies hat nichts mit CPU-Performance zu tun (A ist falsch), geht nicht ums Copy-Pasten (C verfehlt den Punkt), und D widerspricht dem gesamten Prinzip.


Frage 11: Was ist PEP 8?

Was ist PEP 8 im Kontext der Python-Entwicklung?

A) Eine Python-Bibliothek zur automatischen Code-Formatierung
B) Pythons offizieller Style Guide, der von der Community vereinbarte Standards für Code-Formatierung und -Stil definiert
C) Ein Type-Checking-Tool, das Funktionssignaturen validiert
D) Die achte Version der Programmiersprache Python

Antwort anzeigen

Richtige Antwort: B

PEP 8 (Python Enhancement Proposal 8) ist Pythons offizieller Style Guide, geschrieben von Guido van Rossum (Pythons Schöpfer) und anderen. Es ist kein Tool (A und C sind Tools wie Ruff und Pyright), und es ist definitiv keine Python-Version (D verwechselt PEP mit Versionsnummern). PEP 8 bildet die Grundlage, die Tools wie Ruff zur Durchsetzung von Qualitätsstandards verwenden.


Frage 12: Automatisierung vs. manuelle Review

Was ist der Hauptvorteil automatisierter Qualitätsprüfungen gegenüber manueller Code-Review?

A) Automatisierte Prüfungen eliminieren komplett die Notwendigkeit menschlicher Reviewer
B) Automatisierung ist konsistent, schnell, skaliert mühelos und erkennt mechanische Probleme sofort—befreit Menschen, sich auf Logik und Architektur zu konzentrieren
C) Automatisierte Tools verstehen Geschäftsanforderungen besser als Menschen
D) Manuelle Review ist veraltet und sollte nie verwendet werden

Antwort anzeigen

Richtige Antwort: B

Der Abschnitt “Automatisierung skaliert, Menschen nicht” der Vorlesung zeigt, wie automatisierte Prüfungen massive Zeitmengen sparen (16,7 Stunden/Woche für ein 10-Personen-Team), indem sie mechanische Prüfungen konsistent und sofort handhaben. Dies eliminiert nicht die menschliche Review (A und D sind falsch)—es macht menschliche Review effektiver, indem es Reviewern ermöglicht, sich auf übergeordnete Belange zu konzentrieren. Automatisierung excelliert bei mechanischen Prüfungen, nicht beim Verstehen von Geschäftslogik (C ist umgekehrt).


Frage 13: Problem ungenutzter Imports

Warum erzeugen ungenutzte Imports Probleme in Produktions-Code?

A) Sie verursachen sofortige Laufzeitfehler, die das Programm zum Absturz bringen
B) Python weigert sich, Dateien mit ungenutzten Imports auszuführen
C) Sie verschwenden Speicher/Startzeit, erzeugen Verwirrung über Abhängigkeiten und akkumulieren als technische Schulden im Zeitverlauf
D) Ungenutzte Imports sind eigentlich kein Problem—alle Imports sollten für alle Fälle behalten werden

Antwort anzeigen

Richtige Antwort: C

Die Vorlesung erklärt, dass ungenutzte Imports Ressourcen verschwenden (wenn auch gering in kleinen Programmen), Verwirrung erzeugen (“Warum brauchen wir das?”) und sich im Laufe der Zeit als technische Schulden ansammeln. Sie verursachen keine Abstürze (A ist falsch), Python führt den Code problemlos aus (B ist falsch), und absichtlich ungenutzte Imports zu behalten (D) verletzt das Prinzip von sauberem Code.


Frage 14: Wert früher Erkennung

Laut dem Type-Checking-Beispiel der Vorlesung: Was ist der HAUPTVORTEIL, Fehler früh durch automatisierte Tools zu erkennen?

A) Es lässt den Code in der Produktion schneller laufen
B) Es eliminiert alle möglichen Bugs aus der Codebasis
C) Probleme, die in Sekunden während der Entwicklung erkannt werden, werden nicht zu teuren Produktions-Bugs, deren Debugging und Behebung Tage dauert
D) Es erlaubt Entwicklern, das Schreiben von Tests zu überspringen

Antwort anzeigen

Richtige Antwort: C

Das find_intersection-Beispiel der Vorlesung zeigt, wie ein Type-Checker eine Rückgabewert-Nichtübereinstimmung in “2 Sekunden, nicht 2 Wochen” erkennt. Früherkennung verhindert das exponentiell Kostenwachstum von Bugs, die die Produktion erreichen. Dies betrifft nicht Laufzeit-Performance (A), kann nicht alle Bugs fangen (B ist unmöglich) und ersetzt nicht das Testen (D ist gefährliches Denken).


Frage 15: Zeitzuteilung bei Code-Review

In einem Workflow mit automatisierten Qualitätsprüfungen: Worauf sollten sich menschliche Code-Reviewer konzentrieren?

A) Prüfung auf fehlende Leerzeichen um Operatoren
B) Zählen von Zeilenlängen, um sicherzustellen, dass sie unter 88 Zeichen liegen
C) Übergeordnete Belange wie Algorithmus-Korrektheit, Architekturentscheidungen, Geschäftslogik und Grenzfälle
D) Finden ungenutzter Imports und Beheben von Namenskonventionen

Antwort anzeigen

Richtige Antwort: C

Der Automatisierungs-Abschnitt der Vorlesung betont, dass automatisierte Tools mechanische Prüfungen (A, B, D) sofort handhaben und menschliche Reviewer befreien, sich auf komplexe Belange zu konzentrieren, die Domänenwissen, Erfahrung und Urteilsvermögen erfordern. Dies ist das Hauptwertversprechen: Automatisierung handhabt, was Computer am besten können (Mustererkennung), Menschen handhaben, was Menschen am besten können (Verständnis von Kontext und Absicht).


Frage 16: Das Prinzip der geringsten Überraschung

Was bedeutet das “Prinzip der geringsten Überraschung” in der Code-Qualität?

A) Code sollte so viele Überraschungen wie möglich enthalten, um Entwickler interessiert zu halten
B) Code sollte sich so verhalten, wie Leser es basierend auf etablierten Konventionen erwarten—Brechen von Konventionen erzeugt Verwirrung und verschwendet Zeit
C) Entwickler sollten überrascht sein, wie elegant der Code ist
D) Code sollte unerwartete Ansätze verwenden, um Probleme kreativ zu lösen

Antwort anzeigen

Richtige Antwort: B

Die Vorlesung führt dieses Prinzip bei der Diskussion von Namenskonventionen ein: Code sollte sich so verhalten, wie Leser es erwarten. Wenn DatabaseConnection wie eine Klasse aussieht, aber eigentlich eine Funktion ist, verletzt es Erwartungen und verursacht Verwirrung. Dieses Prinzip argumentiert für Vorhersagbarkeit und Konventionsbefolgung, nicht für Überraschungen (A und C sind das Gegenteil), und Kreativität sollte nicht auf Kosten von Klarheit gehen (D verfehlt den Punkt).


Frage 17: Code-Vergleich und Diffs

Warum sind kurze, gut formatierte Zeilen besonders wichtig für Code-Diffs (Versionsvergleich)?

A) Diff-Tools funktionieren nur mit kurzen Zeilen
B) Änderungen, die in langen Zeilen vergraben sind, sind schwer zu erkennen, während Änderungen in gut formatiertem Code sofort offensichtlich sind
C) Kurze Zeilen erzeugen kleinere Git-Repositories
D) Diff-Tools lehnen automatisch Dateien mit langen Zeilen ab

Antwort anzeigen

Richtige Antwort: B

Die Vorlesung demonstriert dies mit dem marker-Dictionary-Beispiel: color='red'color='blue' in einer 120-Zeichen-Zeile zu erkennen ist schwierig, aber wenn jede Eigenschaft auf einer eigenen Zeile steht, springt die Änderung sofort ins Auge. Diff-Tools funktionieren problemlos mit jeder Zeilenlänge (A und D sind falsch), und Repository-Größe ist nicht das Anliegen (C ist falsch).


Frage 18: Optimierung für Lesen vs. Schreiben

Warum fokussiert Code-Qualität auf Optimierung für LESEN statt SCHREIBEN?

A) Weil Code zu lesen schwieriger ist als Code zu schreiben
B) Weil Code viel häufiger gelesen wird als geschrieben—beim Debugging, Review, Wartung und Onboarding
C) Weil die meisten Entwickler Lesen dem Schreiben vorziehen
D) Weil das Schreiben von Code bereits durch IDEs optimiert ist

Antwort anzeigen

Richtige Antwort: B

Die 10:1-Regel der Vorlesung erklärt dies: Jede Stunde des Code-Schreibens resultiert in ungefähr 10 Stunden des Lesens über seine Lebensdauer (Debugging, Review, Feature-Ergänzungen, Bug-Fixes, Onboarding). Diese mathematische Realität treibt den Fokus auf Lesbarkeit. Optionen A, C und D verfehlen die fundamentale Zeitzuteilungs-Einsicht, die dieses Prinzip antreibt.


Frage 19: Technische Schulden-Metapher

In der Diskussion der Vorlesung über toten Code: Was bedeutet “technische Schulden”?

A) Geld, das Entwicklern für das Schreiben des Codes geschuldet wird
B) Code, der mit einer Lizenz bezahlt werden muss
C) Abkürzungen und Qualitätsprobleme, die zukünftige Wartungskosten erzeugen—wie finanzielle Schulden akkumuliert es “Zinsen” im Zeitverlauf
D) Die Menge an Zeit, die mit Debugging verbracht wird

Antwort anzeigen

Richtige Antwort: C

Technische Schulden sind eine Metapher: So wie finanzielle Schulden Zinsen akkumulieren, akkumulieren Code-Qualitätsprobleme Wartungskosten im Zeitverlauf. Toter Code, schlechte Benennung, fehlende Dokumentation—alles erzeugt zukünftige Kosten, wenn jemand sie aktualisieren, verstehen oder umgehen muss. Dies betrifft nicht wörtliches Geld (A und B) oder nur Debugging-Zeit (D ist zu eng gefasst).


Frage 20: Der Zweck von Style Guides

Was ist der ULTIMATIVE Zweck, einem Style Guide wie PEP 8 zu folgen?

A) Damit aller Python-Code identisch aussieht, sodass niemand weiß, wer ihn geschrieben hat
B) Eine gemeinsame Sprache und konsistente Erwartungen zu schaffen, die kognitive Last reduzieren und Team-Zusammenarbeit verbessern
C) Python-Code wie Java-Code aussehen zu lassen
D) Entwicklung zu verlangsamen, indem zusätzliche Regeln hinzugefügt werden

Antwort anzeigen

Richtige Antwort: B

Die Vorlesung betont, dass PEP 8 eine “gemeinsame Sprache” für Python-Entwickler weltweit schafft. Konsistenz reduziert kognitive Last, beschleunigt das Verständnis und ermöglicht effektive Zusammenarbeit über Teams und Projekte hinweg. Anonymität (A) und Ähnlichkeit zu anderen Sprachen (C) sind keine Ziele, und die Regeln beschleunigen die Entwicklung, indem sie Probleme verhindern (D ist umgekehrt).


Bewertungsleitfaden


Wichtige Erkenntnisse zum Merken

  1. Funktionierend vs. Professionell - Code, der funktioniert, ist nicht genug; professioneller Code erfüllt Qualitätsstandards für Wartbarkeit und Zusammenarbeit
  2. Die 10:1-Regel - Code wird 10x häufiger gelesen als geschrieben, also optimieren Sie für das Lesen, nicht das Schreiben
  3. Früherkennung - Bugs, die in der Entwicklung erkannt werden, kosten Minuten; Bugs in der Produktion kosten Tage
  4. Automatisierung skaliert - Automatisierte Prüfungen handhaben mechanische Probleme konsistent und befreien Menschen für übergeordnete Reviews
  5. Konsistenz reduziert Last - Musterererkennende Gehirne verarbeiten konsistenten Code 30% schneller als inkonsistenten Code
  6. PEP 8-Grundlage - Pythons offizieller Style Guide schafft eine gemeinsame Sprache für alle Python-Entwickler
  7. Toter Code kostet - Ungenutzter Code erzeugt Wartungsaufwand, kognitive Verwirrung und technische Schulden
  8. Leerraum ist wichtig - Korrekte Abstände schaffen visuelle Grenzen, die Gehirnen helfen, Code in Chunks zu parsen
  9. Namenskonventionen - PascalCase/snake_case/UPPER_CASE signalisieren verschiedene Code-Elemente; Verstöße erzeugen Überraschung
  10. Zeilenlängen-Logik - Kurze Zeilen ermöglichen side-by-side-Vergleich, Split-Screens und lesbare Diffs
© 2026 Dominik Mueller   •  Powered by Soopr   •  Theme  Moonwalk