⚠

Hinweis zur Privatsphäre: Wenn Sie sich mit Ihrem GitHub-Konto anmelden, werden Ihre Quiz-Versuche in Google Firebase gespeichert, damit Sie Ihren Fortschritt verfolgen können. Diese Daten sind nur für den Kursleiter einsehbar, werden nicht anderweitig weitergegeben und nach Semesterende gelöscht. Frühere Löschung auf Anfrage beim Kursleiter. Möchten Sie anonym bleiben? Nutzen Sie den Gastmodus oder ein GitHub-Konto ohne Ihren echten Namen.

Lädt...

Melden Sie sich an, um Ihren Fortschritt zu speichern und auf allen Geräten zu sehen.

● Fortschritt wird gespeichert

02 Übung: PEP 8 Vorher/Nachher-Analyse

Punkte: 0 / 14

Fragen-Übersicht

Offen Richtig Falsch

Anleitung

Dieses Quiz testet Ihre Fähigkeit, PEP 8-Verbesserungen in echtem Python-Code zu analysieren. Sie vergleichen “Vorher” (nicht-konform) und “Nachher” (konform) Versionen von Code-Ausschnitten und identifizieren die spezifischen Unterschiede, angewendeten Regeln und die Begründung hinter jeder Änderung.

Behandelte Themen:

Abstände um Operatoren und nach Kommata
Import-Organisation (Gruppierung, Sortierung, ungenutzte Imports)
Namenskonventionen (PascalCase, snake_case, UPPER_CASE)
Zusammengesetzte Anweisungen vs. separate Zeilen
Mehrzeilige Formatierung für Funktionsaufrufe
Git-Diff-Auswirkungen der Code-Formatierung

Tipp: Lesen Sie beide Code-Versionen sorgfältig, bevor Sie antworten. Kleine Unterschiede wie ein einzelnes Leerzeichen oder ein Zeilenumbruch zählen als eigenständige Verbesserungen.

Frage1 Unterschieds-Analyse

Wie viele PEP 8-Verbesserungen wurden zwischen der Vorher- und Nachher-Version vorgenommen?

Vorher:

def calc(a,b):return a+b

Nachher:

def calc(a, b):
    return a + b

Geben Sie eine Zahl ein:

Frage2 Regel-Identifikation

Welche PEP 8-Regeln wurden in der Nachher-Version angewendet?

Vorher:

def calc(a,b):return a+b

Nachher:

def calc(a, b):
    return a + b

Wählen Sie ALLE zutreffenden aus:

Wählen Sie alle zutreffenden Optionen:

A) Leerzeichen nach Kommata in Parameterlisten verwenden B) Klassennamen sollten PascalCase verwenden C) Mehrere Anweisungen auf einer Zeile vermeiden (zusammengesetzte Anweisungen) D) Binäre Operatoren mit Leerzeichen umgeben E) Imports sollten auf separaten Zeilen stehen

Frage3 Regel-Identifikation

Welche PEP 8-Regeln wurden in der Nachher-Version dieser Imports angewendet?

Vorher:

import sys,os,json
from typing import List,Dict
import numpy as np

Nachher:

import json
import os
import sys
from typing import Dict, List

import numpy as np

Wählen Sie ALLE zutreffenden aus:

Wählen Sie alle zutreffenden Optionen:

A) Imports sollten normalerweise auf separaten Zeilen stehen B) Imports sollten nach Typ gruppiert werden (Standardbibliothek, Third-Party, lokal) C) Imports innerhalb jeder Gruppe sollten alphabetisch sortiert sein D) Leerzeichen nach Kommata verwenden E) Eine Leerzeile zwischen verschiedenen Import-Gruppen einfügen F) Immer 'from'-Imports anstelle von einfachen Imports verwenden

Frage4 Best Practices

Warum ist die Leerzeile zwischen Import-Gruppen wichtig?

import json
import os
import sys
from typing import Dict, List
                                 # <-- diese Leerzeile
import numpy as np

A) Python erfordert sie, sonst läuft der Code nicht B) Sie macht die Datei länger, was immer besser ist C) Sie trennt visuell Standardbibliothek-Imports von Third-Party-Imports und macht Abhängigkeiten sofort erkennbar D) Sie verbessert die Performance des Import-Systems

Frage5 Unterschieds-Analyse

Wie viele PEP 8-Verbesserungen wurden zwischen der Vorher- und Nachher-Version vorgenommen?

Vorher:

class dataProcessor:
    def __init__(self,items):
        self.items=items
        self.count=len(items)
    def Process(self): return [x*2 for x in self.items]

Nachher:

class DataProcessor:
    def __init__(self, items):
        self.items = items
        self.count = len(items)

    def process(self):
        return [x * 2 for x in self.items]

Geben Sie eine Zahl ein:

Frage6 Regel-Identifikation

Welche PEP 8-Namenskonventionsregeln wurden in der Nachher-Version angewendet?

Vorher:

class dataProcessor:
    ...
    def Process(self): return [x*2 for x in self.items]

Nachher:

class DataProcessor:
    ...
    def process(self):
        return [x * 2 for x in self.items]

Wählen Sie ALLE zutreffenden aus:

Wählen Sie alle zutreffenden Optionen:

A) Klassennamen sollten PascalCase verwenden (CapWords-Konvention) B) Methodennamen sollten snake_case verwenden (Kleinbuchstaben mit Unterstrichen) C) Konstanten sollten UPPER_CASE verwenden D) Modulnamen sollten PascalCase verwenden

Frage7 Regel-Identifikation

Welche PEP 8-Regeln wurden in der Nachher-Version angewendet?

Vorher:

camera={'x':0,'y':2.0,'z':1.5}
max_distance=100
default_threshold=0.5

Nachher:

camera = {'x': 0, 'y': 2.0, 'z': 1.5}
MAX_DISTANCE = 100
DEFAULT_THRESHOLD = 0.5

Wählen Sie ALLE zutreffenden aus:

Wählen Sie alle zutreffenden Optionen:

A) Leerzeichen um den Zuweisungsoperator (=) B) Leerzeichen nach Doppelpunkten in Dictionaries C) Konstanten sollten UPPER_CASE-Benennung verwenden D) Dictionary-Schlüssel sollten doppelte Anführungszeichen statt einfacher verwenden E) Variablennamen sollten mit einem Unterstrich beginnen

Frage8 Best Practices

Warum wurden max_distance und default_threshold in MAX_DISTANCE und DEFAULT_THRESHOLD umbenannt?

A) Python erfordert, dass Konstanten großgeschrieben werden, sonst kompiliert der Code nicht B) UPPER_CASE ist einfacher zu tippen als snake_case C) UPPER_CASE signalisiert anderen Entwicklern, dass es sich um Konstanten handelt, die während der Programmausführung nicht geändert werden sollten D) Großgeschriebene Variablennamen laufen schneller im Python-Interpreter

Frage9 Unterschieds-Analyse

Wie viele PEP 8-Verbesserungen wurden zwischen der Vorher- und Nachher-Version vorgenommen?

Vorher:

def process(data,threshold=10,debug=False):
    result=[]
    for item in data:
        if item>threshold:result.append(item*2)
    if debug:print(f"Processed {len(result)} items")
    return result

Nachher:

def process(data, threshold=10, debug=False):
    result = []
    for item in data:
        if item > threshold:
            result.append(item * 2)
    if debug:
        print(f"Processed {len(result)} items")
    return result

Geben Sie eine Zahl ein:

Frage10 Best Practices

Warum ist das Aufteilen zusammengesetzter Anweisungen in separate Zeilen wichtig für das Debugging?

Vorher (zusammengesetzt):

if item>threshold:result.append(item*2)

Nachher (separate Zeilen):

if item > threshold:
    result.append(item * 2)

A) Separate Zeilen lassen den Code schneller laufen, weil der Interpreter jede Zeile unabhängig optimieren kann B) Man kann Breakpoints auf bestimmte Zeilen setzen, Stack Traces zeigen die genaue Fehlerzeile, und es ist einfach, Logging oder zusätzliche Logik hinzuzufügen C) Pythons Debugger kann zusammengesetzte Anweisungen überhaupt nicht parsen D) Separate Zeilen reduzieren den Speicherverbrauch, weil Python jeweils nur eine Zeile lädt

Frage11 Unterschieds-Analyse

Wie viele PEP 8-Verbesserungen wurden zwischen der Vorher- und Nachher-Version vorgenommen?

Vorher:

from dash import Dash,html,dcc
import plotly.graph_objects as go
import numpy as np
import sys

def create_visualization(x_data,y_data,title="Plot"):
    fig=go.Figure()
    fig.add_trace(go.Scatter(x=x_data,y=y_data,mode='lines',name='Data'))
    fig.update_layout(title=title,xaxis_title="X",yaxis_title="Y")
    return fig

APP_title="Road Profile Viewer"

Nachher:

from dash import Dash, dcc, html
import numpy as np
import plotly.graph_objects as go

def create_visualization(x_data, y_data, title="Plot"):
    fig = go.Figure()
    fig.add_trace(go.Scatter(
        x=x_data,
        y=y_data,
        mode='lines',
        name='Data'
    ))
    fig.update_layout(
        title=title,
        xaxis_title="X",
        yaxis_title="Y"
    )
    return fig

APP_TITLE = "Road Profile Viewer"

Geben Sie eine Zahl ein:

Frage12 Regel-Identifikation

Welche Kategorien von PEP 8-Regeln wurden im Praxisbeispiel angewendet?

Vorher:

from dash import Dash,html,dcc
import plotly.graph_objects as go
import numpy as np
import sys

def create_visualization(x_data,y_data,title="Plot"):
    fig=go.Figure()
    fig.add_trace(go.Scatter(x=x_data,y=y_data,mode='lines',name='Data'))
    fig.update_layout(title=title,xaxis_title="X",yaxis_title="Y")
    return fig

APP_title="Road Profile Viewer"

Wählen Sie ALLE zutreffenden Kategorien aus:

Wählen Sie alle zutreffenden Optionen:

A) Import-Organisation (Gruppierung, Sortierung, ungenutzte entfernen) B) Abstände um Operatoren und nach Kommata C) Mehrzeilige Formatierung für lange Funktionsaufrufe D) Konstantenbenennungskonventionen (UPPER_CASE) E) Klassenbenennungskonventionen (PascalCase) F) Type Hints zu allen Parametern hinzufügen

Frage13 Best Practices

Warum wird mehrzeilige Formatierung für Funktionsaufrufe mit vielen Argumenten bevorzugt?

Vorher (einzeilig):

fig.add_trace(go.Scatter(x=x_data,y=y_data,mode='lines',name='Data'))

Nachher (mehrzeilig):

fig.add_trace(go.Scatter(
    x=x_data,
    y=y_data,
    mode='lines',
    name='Data'
))

A) Mehrzeiliger Code wird schneller ausgeführt, weil Python jede Zeile parallelisieren kann B) Jedes Argument ist klar sichtbar, einfach hinzuzufügen oder zu entfernen, und erzeugt sauberere Git-Diffs, wenn ein einzelner Parameter geändert wird C) PEP 8 verlangt, dass alle Funktionsaufrufe mehrzeilige Formatierung verwenden, unabhängig von der Länge D) Einzeilige Funktionsaufrufe verursachen Syntaxfehler, wenn es mehr als 3 Argumente gibt

Frage14 Best Practices

Ein Teamkollege ändert mode='lines' zu mode='markers' in einem Funktionsaufruf. Welcher Formatierungsstil erzeugt einen saubereren Git-Diff?

Stil A (einzeilig):

fig.add_trace(go.Scatter(x=x_data, y=y_data, mode='lines', name='Data'))

Stil B (mehrzeilig):

fig.add_trace(go.Scatter(
    x=x_data,
    y=y_data,
    mode='lines',
    name='Data'
))

A) Stil A (einzeilig), weil der Diff insgesamt weniger geänderte Zeilen zeigt B) Stil B (mehrzeilig), weil der Diff nur den geänderten Parameter hervorhebt, ohne den Rest der Zeile zu berühren C) Beide erzeugen identische Diffs, da die gleiche Menge an Code geändert wurde D) Keiner der Stile beeinflusst Git-Diffs, weil Git Zeichen verfolgt, nicht Zeilen

02 Übung: PEP 8 Vorher/Nachher-Analyse

Anleitung

Quiz abgeschlossen!