Benutzer-Werkzeuge

Webseiten-Werkzeuge


pep8
  • Python-Style-Guide
  • enthält Empfehlungen wie Code geschrieben werden sollte
    • für offizielle Python-Module ist es verpflichtend

Source File Encoding

  • Encoding sollte bei Python 3 UTF-8
  • bei Python 2 ASCII sein
  • Encoding sollte nicht angegeben werden

Tabs oder Spaces für Einrücken

  • im Speziellen seit Python3 wichtig, da es keine Vermischung erlaubt
  • ein Intend sind 4 Spaces
    • also wird jedes Indention-Level vom nächst höheren durch 4 Spaces unterschieden
    • Editoren erlauben über Tab-Width u.ä. Einstellungen Tabs in eine bestimmte Menge Spaces umzuwandeln

Zeilenlänge

  • 79 Zeichen
    • maximal 100 Zeichen
  • 72 für Nicht-Code
  • Sinn ist das man Editor-Fenster nebeneinander auf haben kann

Zeilenumbruch

  • Bei Funktionsaufrufen
    • Fortsetzung geht auf Höhe der öffnenden Klammer
foo = long_function_name(var_one, var_two,
                         var_three, var_four)
  • Hinter der öffnenden Klammer kommen keine Parameter, sondern in der ersten darauf folgend Zeile
    • die Zeile muss weiter eingerückt sein als das höchste Indention-Level
def long_function_name(
        var_one, var_two, var_three,
        var_four):
    print(var_one)
  • Ausdrücke können im Klammern gesetzt werden und dann umgebrochen werden - entsprechend Funktionsaufrufen
if (something 
    and something else):

Leerzeilen

  • Vor und hinter einer Top-Level-Methode oder einer Klassendefinition zwei Zeilen
  • Vor und hinter einer Methode in einer Klasse eine Zeile

import

  • jeder import sollte eine eigene Zeile sein

Module Level Dunders

  • Dunders sind doppelte Unterstriche in Python
  • in der Moduldefinition sollten sie kommen:
    • unter dem Doc-String des Moduls
    • aber bevor irgendetwas relevantes passiert

Anführungszeichen

  • Generell egal ob einfache oder doppelte benutzt
  • nur für Doc-Strings (Markierung Beginn und Ende) sind doppelte Anführungszeichen vorgeschrieben

Leerzeichen

Fälle in denen Leerzeichen genutzt werden:

  • vor und hinter Operatoren
    • +, -, = usw.
    • and, or
    • <>
    • is, is not, in, not in
  • Hinter Doppelpunkten die eine Anweisung abschließen
  • Vor und hinter dem = bei Variablenzuweisungen
  • Hinter Komma die Parameter (zum Beispiel in einem Funktionsaufruf) trenne

Wo keine stehen sollten:

* Vor Semikolons, Doppelpunkten, Komma
* Hinter Klammern (egal ob Rund oder Eckig)
* Hinter Komma die Parameter trennen, wenn hinter dem Komma kein Parameter kommt (weil er ausgelassen wird)
* zwischen Variable und Index
* Zwischen Methodennamen und öffnender Klammer 

Kommentare

  • Komplette Sätze
  • Beginnen mit # gefolgt von einem Leerzeichen
  • Beginnend mit Großbuchstaben (ausnahme Variablen)
  • Blockkommentare liegen auf dem gleichen Level mit dem Code den sie kommentieren
  • Paragraphen in zusammenhängenden Multi-Line-Kommentaren sind eine Zeile mit nur einem #
  • Inline-Kommentare (also am Ende der Zeile) sollten mindestens 2 Spaces vom Code entfernt sein + # + Leerzeichen

Docstrings

  • Beginnen mit „“„ + gefolgt von erster Zeile Text
  • Die Ausführenden “„“ sollten unterhalb der letzten Zeile stehen (also auf einer seperaten Zeile)

Unterstriche

  • Ein führender Unterstrich
    • „private“ Objekte - es gibt keinen technischen Schutz außer das sie bei from <Pakacke> import * nicht importiert werden
  • Ein Unterstrich am Ende
    • zur Vermeidung von Namenskollisionen mit Python-Buildins
  • Zwei führende Unterstriche
    • Name-Mangling - beim Vererben wird der Klassenname aus dem die Methode/das Attribut stammt vorangestellt → vermeidet kollisionen/ungewolltes überschreiben
  • Zwei führende Unterstriche und zwei nachfolgende
    • Magic-Method

Namen

Zu vermeidende Namen

  • Kleines el (da Verwechslung mit mit groß I und 1), O (da verwechselbar mit 0) und I (groß ieh, da verwechselbar mit 1 und kleinem l)
    • jeweils wenn sie als Einzelvariablennamen genutzt werden sollen

Packages und Module

  • Module
    • kleingeschrieben, ggf. Unterschtriche
  • Packages
    • kleingeschrieben, keine Unterstriche

Klassennamen

  • alle Wörter im Namen beginnen mit Großbuchstaben
  • bsp. BrownCat

Exceptions

  • entsprechend Klassen
  • aber Name sollte mit Error starten wenn es sich um einen Error handelt

Methoden, Funktionen und Variablen

  • alles kleingeschrieben
  • soweit nötig sollten Wörter per Underscore getrennt sein

Konstanten

  • Alles Großgeschrieben (also komplett)
  • Unterstriche wenn nötig
pep8.txt · Zuletzt geändert: 2018/11/09 18:32 von root