← Blog · 15. April 2026 · ConvertCaseHQ-Team · 6 Min. Lesezeit

Python PEP 8: Namenskonventionen und snake_case für Variablen und Funktionen

PEP 8 schreibt vor, dass Funktions- und Variablennamen kleingeschrieben werden, mit Unterstrichen zwischen den Wörtern, wo es der Lesbarkeit dient. Das ist snake_case: total_price, send_invoice(). Klassen verwenden CapWords (InvoiceSender), Konstanten Großbuchstaben mit Unterstrichen (MAX_RETRIES), und Module bekommen kurze Namen ganz in Kleinbuchstaben. Damit ist der Großteil des Python-Codes abgedeckt, den du schreiben wirst.

Die nützlichen Details stecken im Rest des Abschnitts zur Benennung in PEP 8: was führende und nachgestellte Unterstriche bedeuten, wie du Akronyme behandelst, welche einzelnen Buchstaben du meiden solltest und wann es richtig ist, die Regeln zu brechen. Alles Folgende ist gegen PEP 8 selbst geprüft, und was in Anführungszeichen steht, ist der Originalwortlaut von PEP 8, mit deutscher Übersetzung in Klammern.

PEP-8-Namenskonventionen auf einen Blick

Hier ist das meiste aus der Tabelle in einem kleinen Modul:

# billing.py
MAX_RETRIES = 3
_rate_cache = {}


class PaymentDeclinedError(Exception):
    pass


class InvoiceSender:
    def __init__(self, smtp_host):
        self.smtp_host = smtp_host
        self._attempts = 0

    def send_invoice(self, invoice_id):
        self._attempts += 1
        ...

    @classmethod
    def from_settings(cls, settings):
        return cls(settings["smtp_host"])

Zwei seltenere Zeilen solltest du kennen. Typvariablen können ein Suffix _co oder _contra bekommen, das Kovarianz oder Kontravarianz markiert, wie in VT_co = TypeVar('VT_co', covariant=True). Und globale Variablen folgen den Regeln für Funktionen; ist ein Modul dafür gedacht, mit from module import * verwendet zu werden, empfiehlt PEP 8, seine öffentlichen Namen in __all__ aufzulisten.

Wozu überhaupt snake_case?

PEP 8 stammt vom Juli 2001, und als Autoren sind Guido van Rossum, Barry Warsaw und Alyssa Coghlan aufgeführt. Den Ausgangspunkt bildet eine Beobachtung von Guido: Code wird viel öfter gelesen als geschrieben. Die Namensregeln dienen diesem Ziel. Unterstriche halten Wortgrenzen auch in langen Namen sichtbar (days_since_last_login), und die Trennung zwischen Werten in snake_case und Klassen in CapWords verrät dir, um was für eine Art Ding es sich bei einem Namen handelt, noch bevor du ihn nachschlägst. PEP 8 legt außerdem ein übergeordnetes Prinzip für öffentliche APIs fest: Namen sollen widerspiegeln, wie etwas verwendet wird, nicht wie es implementiert ist.

Was die Unterstriche bedeuten

Python hat kein Schlüsselwort private, also übernehmen Unterstriche diese Aufgabe per Konvention. PEP 8 kennt vier Formen:

• _single_leading: ein schwaches „internal use“-Signal (nur für den internen Gebrauch). from module import * überspringt diese Namen, aber sonst hindert nichts jemanden daran, sie zu benutzen.
• single_trailing_: vermeidet einen Konflikt mit einem Schlüsselwort. class_ ist besser als clss, auch wenn PEP 8 anmerkt, dass ein Synonym noch besser sein kann.
• __double_leading: innerhalb einer Klasse löst das Name Mangling aus. PEP 8 empfiehlt es nur, um Konflikte mit Attributen in Unterklassen zu vermeiden, und räumt ein, dass manche Leute es nicht mögen.
• __double_leading_and_trailing__: „magic“-Namen (magische Namen) wie __init__ und __file__. PEP 8 sagt, man solle solche Namen nie erfinden, sondern nur die dokumentierten verwenden.

Name Mangling überrascht Leute, die es für Zugriffsschutz halten. Es ist eine Umbenennung, kein Schloss:

class Account:
    def __init__(self):
        self.__pin = "1234"

acct = Account()
acct.__pin            # AttributeError
acct._Account__pin    # "1234": the mangled name still works

Konstanten sind eine Konvention, keine Regel

Ein Name in Großbuchstaben hindert niemanden daran, ihn neu zuzuweisen; Python führt MAX_RETRIES = 4 klaglos aus. Soll ein Tool die Regel durchsetzen, annotiere den Namen mit typing.Final:

from typing import Final

MAX_RETRIES: Final = 3
MAX_RETRIES = 4  # still runs, but mypy reports:
                 # Cannot assign to final name "MAX_RETRIES"

Enum-Mitglieder sind die andere Stelle, an der Großbuchstaben auftauchen. Das Enum-HOWTO der Python-Dokumentation empfiehlt nachdrücklich Mitgliedsnamen in UPPER_CASE, zum Teil weil Enums Konstanten darstellen und zum Teil, um Konflikte mit Methodennamen zu vermeiden: class Color(Enum) mit den Mitgliedern RED und GREEN.

Akronyme, einzelne Buchstaben und andere Randfälle

Akronyme in Klassennamen

PEP 8 verlangt, in CapWords jeden Buchstaben eines Akronyms großzuschreiben, also ist HTTPServerError besser als HttpServerError. Die Standardbibliothek hält sich an manchen Stellen daran, etwa bei http.server.HTTPServer und json.JSONDecodeError. In snake_case werden Akronyme einfach kleingeschrieben: parse_json, http_status.

Das ist wichtig, wenn du mit einem Tool umbenennst. Unser Case-Konverter macht aus processOrder ein process_order und aus HTTPServerError ein http_server_error, genau richtig für snake_case. Seine PascalCase-Ausgabe schreibt Akronyme aber wie Wörter: Aus HTTP server error wird HttpServerError, und die Großbuchstaben korrigierst du von Hand, damit es zu PEP 8 passt.

Buchstaben, die du meiden solltest

Verwende l (kleines L), O (großes O) oder I (großes i) nie als einbuchstabige Namen. In manchen Schriftarten sind sie von 1 und 0 nicht zu unterscheiden.

mixedCase

Funktionsnamen in camelCase sind nur dort erlaubt, wo das schon der vorherrschende Stil ist, aus Gründen der Abwärtskompatibilität. PEP 8s eigenes Beispiel ist das Modul threading.

Warum die Standardbibliothek ihre eigenen Regeln bricht

PEP 8 räumt ein, dass die Benennung in Pythons Bibliothek „a bit of a mess“ sei (ziemlich chaotisch). Du begegnest logging.getLogger() und assertEqual() aus unittest in mixedCase und kleingeschriebenen Klassen wie datetime.datetime. Eingebaute Typen wie list und dict sind mit Absicht kleingeschrieben: PEP 8 beschreibt für Built-ins eine eigene Konvention, bei der CapWords nur für Exception-Namen und eingebaute Konstanten verwendet wird.

Zwei Regeln aus PEP 8 erklären, warum diese Namen meist bleiben, wie sie sind. Erstens: Hat eine bestehende Bibliothek einen anderen Stil, hat interne Einheitlichkeit den Vorrang. Zweitens der Abschnitt mit dem Titel „A Foolish Consistency is the Hobgoblin of Little Minds“ (Eine törichte Konsistenz ist der Kobold kleiner Geister): Konsistenz mit PEP 8 ist wichtig, Konsistenz innerhalb eines Projekts wichtiger und Konsistenz innerhalb eines Moduls oder einer Funktion am wichtigsten. Brich die Abwärtskompatibilität nicht, nur um die Regeln einzuhalten. Deshalb definiert eine unittest-Testklasse weiterhin setUp(): Das Framework ruft genau diesen Namen auf.

Namen automatisch prüfen mit Ruff oder pep8-naming

Du musst Namen nicht von Hand prüfen. Das flake8-Plugin pep8-naming prüft sie, und Ruff setzt dieselben Prüfungen als seine N-Regeln um. Nehmen wir diese Datei:

maxRetries = 3


class order_processor:
    def processOrder(self, orderId):
        totalPrice = 0
        return totalPrice


class InvalidOrder(Exception):
    pass

Ruff beanstandet jeden Namen darin:

$ ruff check --select N --output-format concise orders.py
orders.py:1:1: N816 Variable `maxRetries` in global scope should not be mixedCase
orders.py:4:7: N801 Class name `order_processor` should use CapWords convention
orders.py:5:9: N802 Function name `processOrder` should be lowercase
orders.py:5:28: N803 Argument name `orderId` should be lowercase
orders.py:6:9: N806 Variable `totalPrice` in function should be lowercase
orders.py:10:7: N818 Exception name `InvalidOrder` should be named with an Error suffix
Found 6 errors.

Um die Regeln für ein ganzes Projekt zu aktivieren, trage sie in pyproject.toml ein:

[tool.ruff.lint]
extend-select = ["N"]

Wenn du einen einzelnen Bezeichner in einer eingefügten Datei umbenennst, zeigt dir unser Werkzeug Suchen & Ersetzen, wie viele Treffer es geändert hat, ein schneller Plausibilitätscheck, bevor du das Ergebnis zurückkopierst. Für eine ganze Codebasis nimm stattdessen das Umbenennen-Refactoring deines Editors, damit Verweise in anderen Dateien mitziehen.

Eine Checkliste für PEP-8-Namen

• snake_case für Funktionen, Methoden, Variablen und Argumente.
• CapWords für Klassen, Akronyme in Großbuchstaben und die Endung Error bei Exceptions.
• Großbuchstaben mit Unterstrichen für Konstanten auf Modulebene, dazu Final, wenn ein Prüfwerkzeug sie durchsetzen soll.
• Kurze Modulnamen in Kleinbuchstaben; in Paketnamen keine Unterstriche.
• Ein führender Unterstrich für interne Namen; doppelte Unterstriche nur, um Konflikte mit Unterklassen zu vermeiden.
• Verwendet eine bestehende Bibliothek einen anderen Stil, richte dich nach der Bibliothek.

Du wechselst zwischen Sprachen? Unser Spickzettel für Entwickler stellt Pythons Regeln denen von JavaScript, Java, Go, Rust und anderen gegenüber.