02 Übung: PEP 8 - Level 4: Vorher/Nachher-Vergleich

Unterschiede

1. Leerzeichen nach Komma in Parametern hinzugefügt: a,b → a, b
2. Funktionskörper in neue Zeile verschoben statt auf derselben Zeile wie def
3. Leerzeichen um + Operator hinzugefügt: a+b → a + b

Angewendete PEP 8-Regeln

1. Leerzeichen nach Kommata verwenden in Parameterlisten
2. Mehrere Anweisungen auf einer Zeile vermeiden (zusammengesetzte Anweisungen sind nicht empfohlen)
3. Binäre Operatoren mit Leerzeichen umgeben

Zusätzliche Verbesserungen

• Funktionsname calc ist vage; besser: calculate_sum oder add_numbers
• Fehlender Docstring
• Fehlende Type Hints:

  def calculate_sum(a: float, b: float) -> float:
      """Gibt die Summe zweier Zahlen zurück."""
      return a + b
  

Wichtigste Erkenntnis

Selbst einfache Einzeiler profitieren von PEP 8-Konformität. Die Nachher-Version ist einfacher zu lesen, zu debuggen und zu warten.

Unterschiede

1. Jeder Import auf separater Zeile
2. Standard-Bibliotheks-Imports alphabetisch sortiert (json, os, sys)
3. Leerzeichen nach Kommata in from-Import hinzugefügt: List,Dict → Dict, List
4. Typing-Imports alphabetisch sortiert: List,Dict → Dict, List
5. Leerzeile zur Trennung von Standard-Bibliothek und Third-Party-Imports
6. Imports nach Typ gruppiert (Standard-Bibliothek, dann Third-Party)

Angewendete PEP 8-Regeln

1. Imports sollten normalerweise auf separaten Zeilen stehen
2. Imports sollten gruppiert werden: Standard-Bibliothek, verwandte Third-Party, lokale Anwendung/Bibliothek
3. Imports innerhalb jeder Gruppe sollten alphabetisch sortiert sein
4. Leerzeichen nach Kommata verwenden
5. Leerzeile zwischen verschiedenen Import-Gruppen einfügen

Warum die Leerzeile wichtig ist

Sie trennt visuell verschiedene Import-Kategorien und macht sofort klar, welche Imports sind:

• Eingebaute Python-Module (Standard-Bibliothek)
• Externe Abhängigkeiten (Third-Party-Pakete)
• Lokaler Anwendungscode

Dies hilft bei:

• Dependency-Tracking: Einfach zu sehen, welche externen Pakete erforderlich sind
• Wartung: Schnelle Identifikation, was entfernt werden kann
• Debugging: Verstehen, welche Imports Probleme in verschiedenen Umgebungen verursachen könnten

Wichtigste Erkenntnis

Import-Organisation scheint trivial, aber in großen Projekten mit Hunderten von Imports spart richtige Gruppierung und Sortierung erheblich Zeit und verhindert Fehler.

Unterschiede

1. Klassenname von snake_case zu PascalCase geändert: dataProcessor → DataProcessor
2. Leerzeichen nach Komma in __init__-Parametern hinzugefügt: self,items → self, items
3. Leerzeichen um = in Zuweisungen hinzugefügt: self.items=items → self.items = items
4. Methodenname von PascalCase zu snake_case geändert: Process → process
5. Methodenkörper auf separate Zeile verschoben (keine zusammengesetzte Anweisung)
6. Leerzeile zwischen Methoden hinzugefügt
7. Leerzeichen um * Operator in List Comprehension hinzugefügt: x*2 → x * 2

Angewendete PEP 8-Regeln

1. Klassennamen sollten PascalCase verwenden (CapWords-Konvention)
2. Methodennamen sollten snake_case verwenden (Kleinbuchstaben mit Unterstrichen)
3. Leerzeichen nach Kommata
4. Leerzeichen um Operatoren (Zuweisung und Arithmetik)
5. Zusammengesetzte Anweisungen vermeiden (mehrere Anweisungen auf einer Zeile)
6. Leerzeile zwischen Methoden in einer Klasse

Produktionsreife Verbesserungen

from typing import List

class DataProcessor:
    """Verarbeitet und transformiert numerische Daten."""
    
    def __init__(self, items: List[float]):
        """
        Initialisiert den Processor mit Items.
        
        Args:
            items: Liste numerischer Werte zur Verarbeitung
        """
        self.items = items
        self.count = len(items)
    
    def process(self) -> List[float]:
        """
        Verdoppelt jeden Wert in der Liste.
        
        Returns:
            Liste verarbeiteter Werte (jeder Wert mit 2 multipliziert)
        """
        return [x * 2 for x in self.items]

Zusätzliche Verbesserungen umfassen:

• Klassen-Docstring zur Erklärung des Zwecks
• Type Hints für Parameter und Rückgabewerte
• Methoden-Docstrings mit Args- und Returns-Abschnitten
• Aussagekräftigerer Methodenname (z.B. double_values statt generischem process)

Wichtigste Erkenntnis

Namenskonventionen sind nicht willkürlich—sie liefern sofortige visuelle Hinweise darauf, womit Sie es zu tun haben (Klasse vs. Methode vs. Variable). Konsistente Benennung macht Code selbstdokumentierend.

Unterschiede

1. Leerzeichen um = Zuweisungsoperator hinzugefügt
2. Leerzeichen nach Doppelpunkten im Dictionary hinzugefügt: 'x':0 → 'x': 0
3. Variablennamen zu UPPER_CASE für Konstanten geändert: max_distance → MAX_DISTANCE

Warum UPPER_CASE?

Die Nachher-Version geht davon aus, dass dies Konstanten auf Modulebene sind, die sich während der Programmausführung nicht ändern sollten. UPPER_CASE signalisiert anderen Entwicklern: “Ändern Sie diesen Wert nicht.”

Dies ist eine semantische Verbesserung, nicht nur stilistisch:

• Absicht ist klar: Dies sind Konfigurationswerte
• Schutz vor Bugs: Versehentliches Neuzuweisen einer Konstante ist offensichtlicher
• Konventionsausrichtung: Folgt Python und breiteren Programmiergemeinschaftsstandards

Wann jede Namenskonvention verwenden

UPPER_CASE (Konstanten):

• Konstanten auf Modulebene: PI = 3.14159
• Konfigurationswerte: MAX_SIZE = 1000, CONFIG_PATH = '/etc/app/config.yml'
• Magische Zahlen, die sich nie ändern: SECONDS_PER_DAY = 86400

snake_case (Variablen):

• Reguläre Variablen, die sich ändern können: camera_x, user_input, temp_result
• Funktionsparameter: def process(data, threshold=10)
• Lokale Variablen in Funktionen/Methoden

Sonderfall - Die camera Variable:

Das camera Dictionary könnte je nach Kontext eine Konstante sein oder nicht:

# Wenn es Konfiguration ist, die sich nie ändert:
CAMERA_DEFAULT_POSITION = {'x': 0, 'y': 2.0, 'z': 1.5}

# Wenn es eine Variable ist, die aktualisiert wird:
camera_position = {'x': 0, 'y': 2.0, 'z': 1.5}
# Später im Code:
camera_position['x'] = user_input.x

Wichtigste Erkenntnis

Namenskonventionen kommunizieren Absicht und Veränderlichkeit. UPPER_CASE sagt Lesern “dies wird sich nicht ändern”, während snake_case sagt “dies kann neu zugewiesen werden”. Wählen Sie weise basierend darauf, wie die Variable verwendet wird.

Unterschiede

1. Leerzeichen nach Kommata in Parametern: data,threshold → data, threshold
2. Leerzeichen um = Zuweisung: result=[] → result = []
3. Leerzeichen um > Vergleich: item>threshold → item > threshold
4. Zusammengesetzte Anweisung aufgeteilt: if item>threshold:result.append(item*2) → zwei Zeilen
5. Zusammengesetzte Anweisung aufgeteilt: if debug:print(...) → zwei Zeilen
6. Leerzeichen um * Operator: item*2 → item * 2

Warum das Aufbrechen zusammengesetzter Anweisungen hilft

Lesbarkeit:

• Jede logische Operation ist auf ihrer eigenen Zeile
• Kontrollfluss ist sofort klar
• Weniger kognitive Last beim Parsen

Debugging:

• Kann Breakpoints auf spezifischen Zeilen setzen
• Stack Traces zeigen exakte Fehlerzeile
• Einfacher print-Anweisungen oder Logging hinzuzufügen

Wartbarkeit:

• Einfach zusätzliche Bedingungen hinzuzufügen: if item > threshold and item < max_value:
• Einfach Logik zu erweitern: Logging, Fehlerbehandlung usw. hinzufügen
• Einfacher in Versionskontrolle zu überprüfen (Änderungen sind zeilenbasiert)

Beispiel für einfache Erweiterung:

# Vorher - schwer zu erweitern:
if item>threshold:result.append(item*2)

# Nachher - einfach Logging hinzuzufügen:
if item > threshold:
    logger.debug(f"Processing item: {item}")
    result.append(item * 2)

Zusätzliche Verbesserungen

from typing import List

def process(
    data: List[float],
    threshold: float = 10,
    debug: bool = False
) -> List[float]:
    """
    Verarbeitet Daten durch Filtern und Verdoppeln von Werten über Schwellenwert.
    
    Args:
        data: Liste numerischer Werte zur Verarbeitung
        threshold: Minimalwert zum Einschließen (Standard: 10)
        debug: Ob Debug-Informationen ausgegeben werden sollen (Standard: False)
        
    Returns:
        Liste verarbeiteter Werte (verdoppelte Items über Schwellenwert)
        
    Example:
        >>> process([5, 15, 20], threshold=10)
        [30, 40]
    """
    result = []
    for item in data:
        if item > threshold:
            result.append(item * 2)
    
    if debug:
        print(f"Processed {len(result)} items")
    
    return result

Weitere Verbesserungen:

• Type Hints für bessere IDE-Unterstützung und Type Checking
• Docstring mit Args, Returns und Example
• Erwägen Sie List Comprehension für pythonischeren Code:

  result = [item * 2 for item in data if item > threshold]
  

Wichtigste Erkenntnis

Zusammengesetzte Anweisungen sparen vertikalen Raum, opfern aber Lesbarkeit, Debuggability und Wartbarkeit. Die zusätzlichen Zeilen sind es wert. Moderne Editoren klappen Code ohnehin zusammen, sodass vertikaler Raum kein echtes Problem ist.

Unterschiede

1. Leerzeichen nach Kommata in Imports hinzugefügt: Dash,html,dcc → Dash, dcc, html
2. Imports innerhalb von Dash-Import alphabetisch sortiert: html,dcc → dcc, html
3. sys Import entfernt (nicht verwendeter Import)
4. Imports neu geordnet: dash, numpy, plotly (Bibliotheksorganisation)
5. Leerzeichen nach Kommata in Funktionsparametern: x_data,y_data → x_data, y_data
6. Leerzeichen um = Zuweisung für fig: fig= → fig =
7. Mehrzeilige Formatierung für add_trace() Aufruf
8. Mehrzeilige Formatierung für update_layout() Aufruf
9. Jeder Parameter auf eigener Zeile in Funktionsaufrufen
10. Konstante von APP_title zu APP_TITLE geändert (konsistentes UPPER_CASE)
11. Leerzeichentrennung zwischen Import-Gruppen

Import-Organisation erklärt

Vorher:

from dash import Dash,html,dcc  # Gemischte Reihenfolge, keine Leerzeichen
import plotly.graph_objects as go
import numpy as np
import sys                      # Nicht verwendet

Nachher:

from dash import Dash, dcc, html  # Alphabetisch, mit Leerzeichen
import numpy as np                 # Alphabetisch innerhalb der Gruppe
import plotly.graph_objects as go

# Hinweis: In größeren Projekten könnte man weiter trennen:
# 1. Standard-Bibliothek (keine hier)
# 2. Third-Party (dash, numpy, plotly)
# 3. Lokale Anwendungs-Imports

Vorteile:

• Alphabetische Sortierung macht Imports leicht auffindbar
• Entfernen nicht verwendeter Imports reduziert Abhängigkeiten und Import-Zeit
• Konsistente Abstände verbessern Lesbarkeit
• Logische Gruppierung zeigt Abhängigkeitsbeziehungen

Warum mehrzeilige Funktionsaufrufe besser sind

Vergleich:

# Vorher - alles auf einer Zeile zusammengedrängt:
fig.add_trace(go.Scatter(x=x_data,y=y_data,mode='lines',name='Data'))

Probleme:

• Schwer zu lesen mit vielen Parametern
• Leicht einen Parameter zu übersehen
• Schwierig zu modifizieren
• Schlechte Git-Diff-Sichtbarkeit

# Nachher - ein Parameter pro Zeile:
fig.add_trace(go.Scatter(
    x=x_data,
    y=y_data,
    mode='lines',
    name='Data'
))

Vorteile:

• Jedes Argument ist klar sichtbar
• Einfach einzelne Argumente hinzuzufügen/zu entfernen/zu ändern
• Einfach zu sehen, welche Parameter gesetzt werden
• Einfacher in Versionskontrolle zu überprüfen (ein Parameter pro Zeile)
• Lesbarer für komplexe Funktionsaufrufe
• Selbstdokumentierend (Parameternamen sichtbar ohne Scrollen)

Auswirkung auf Versionskontrolle (Git Diffs)

Vorher - Schwer zu sehen, was sich geändert hat:

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

Was hat sich geändert? Sie müssen die gesamte Zeile sorgfältig lesen.

Nachher - Kristallklar:

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

Sofort offensichtlich: Modus von ‘lines’ zu ‘markers’ geändert.

Wann mehrzeiliges Format verwenden

Mehrzeilig verwenden, wenn:

• Funktion hat 3+ Parameter
• Zeile würde 88 Zeichen überschreiten
• Parameter sind komplex (verschachtelte Strukturen, lange Strings)
• Lesbarkeit würde sich verbessern
• Arbeit in Team-Umgebung (besser für Code-Review)

Einzeilig ist OK, wenn:

• Funktion hat 1-2 einfache Parameter
• Gesamtlänge < 60 Zeichen
• Parameter sind selbsterklärend
• Beispiel: print(result), len(data)

Produktionsreife Version

"""Road Profile Visualisierungsmodul."""
from typing import Optional

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

# Anwendungskonstanten
APP_TITLE = "Road Profile Viewer"
DEFAULT_LINE_COLOR = "blue"
DEFAULT_LINE_WIDTH = 2

def create_visualization(
    x_data: np.ndarray,
    y_data: np.ndarray,
    title: str = "Plot",
    line_color: str = DEFAULT_LINE_COLOR,
    line_width: int = DEFAULT_LINE_WIDTH
) -> go.Figure:
    """
    Erstellt eine interaktive Visualisierung von Road-Profile-Daten.
    
    Args:
        x_data: X-Achsen-Koordinaten (horizontale Distanz)
        y_data: Y-Achsen-Koordinaten (Höhe oder Profilhöhe)
        title: Plot-Titel (Standard: "Plot")
        line_color: Farbe der Linie (Standard: blau)
        line_width: Breite der Linie (Standard: 2)
        
    Returns:
        Plotly Figure Objekt bereit zur Anzeige
        
    Example:
        >>> x = np.linspace(0, 100, 50)
        >>> y = np.sin(x / 10)
        >>> fig = create_visualization(x, y, title="Sinuswellen-Profil")
    """
    fig = go.Figure()
    
    fig.add_trace(go.Scatter(
        x=x_data,
        y=y_data,
        mode='lines',
        name='Road Profile',
        line=dict(color=line_color, width=line_width)
    ))
    
    fig.update_layout(
        title=title,
        xaxis_title="Distanz (m)",
        yaxis_title="Höhe (m)",
        hovermode='x unified',
        template='plotly_white'
    )
    
    return fig

Wichtigste Erkenntnis

Komplexität von realem Code erfordert PEP 8-Konformität umso mehr. Mehrzeilige Formatierung, richtige Imports und konsistente Benennung sind nicht nur Stil—sie sind essenziell für Team-Zusammenarbeit, Code-Review und langfristige Wartung. Die Zeit, die beim Verständnis gespart wird, überwiegt die zusätzlichen Tastenanschläge bei weitem.

Mehrere Probleme:

1. Schwer zu debuggen - kann keinen Breakpoint auf Return-Anweisung setzen
2. Schwer zu erweitern - kein Raum für Validierung, Logging usw.
3. Verletzt PEP 8 - zusammengesetzte Anweisung, fehlende Leerzeichen
4. Schlechte Lesbarkeit - erfordert Parsen dichter Syntax
5. Schlechte Benennung - calc ist vage

Fazit: “Funktionieren” ist nicht genug. Professioneller Code muss lesbar, wartbar sein und Standards folgen.

Abhängigkeits-Klarheit.

Wenn Imports richtig gruppiert und sortiert sind, können Sie sofort sehen:

• Welche externen Pakete erforderlich sind (Deployment-Aspekt)
• Was aus Standard-Bibliothek vs. Third-Party ist (Zuverlässigkeitsaspekt)
• Was entfernt werden kann ohne Code zu brechen (Wartungsaspekt)

In einem Projekt mit 50+ Imports spart diese Organisation Stunden an Debugging und Dependency Management.

Mehrzeilige Formatierung verwenden, wenn:

1. Funktion hat 3+ Parameter
2. Zeile überschreitet 88 Zeichen
3. Arbeit in Team-Umgebung (besser für Code-Review)
4. Parameter sind komplex (verschachtelte Strukturen, Berechnungen)
5. Sie selbstdokumentierenden Code wollen

Faustregel: Wenn Sie zögern, verwenden Sie mehrzeilig. Der zusätzliche vertikale Raum ist die Klarheit wert.