Zusammenfassung zum pythonischen Stil (1): PEP8

Hintergrund

Ich bin dabei, den Job zu wechseln und Python bei der Arbeit ernsthaft einzusetzen, daher fasse ich den Python-Codierungsstil zusammen, den ich zuvor als Überprüfung untersucht habe.

UPDATE: Teil 2 wurde aktualisiert.

Inhalt dieser Seite

Die Einhaltung von PEP 8 ist die erste Grundvoraussetzung. Es gibt bereits viele vorhandene Artikel, einschließlich vorhandener japanischer Übersetzungen. Daher möchte ich, dass Sie diesen Artikeln Vorrang einräumen. Original Japanische Übersetzung

Andere Qiita-Artikel: Kompatibel mit dem Python-Codierungsstandard PEP8 Zusammenfassung des Python-Codierungsstandards PEP8 (1)

Zweck der Schöpfung

• Lernen Sie durch Übersetzen + Zusammenfassen
• Qiita-Seitenerstellungspraxis
• Ich möchte, dass möglichst viele Menschen über PEP 8 informiert werden

(Irgendwie habe ich das Gefühl, dass so etwas von jemandem verkündet wird, der regelmäßig ausgräbt.)

Das zweite Mal werde ich die Inhalte zusammenfassen, die nicht in PEP 8 enthalten sind. Wenn Sie Ergänzungen oder Vorschläge haben (ich bin kein Japaner, also weisen Sie bitte auf Japanisch hin), geben Sie mir bitte Masakari. Dann zum Hauptthema ~

Annahme

• Lesbarkeit ist wichtig: Code wird oft gelesen und nicht geschrieben
• Der Stil ändert sich
• Konsistenz ist wichtig: Versuchen Sie, Stile in derselben Funktion oder demselben Modul so weit wie möglich zu vereinheitlichen
• Bevorzugen Sie den lokalen Stil, wenn er mit dem lokalen Codierungsstil des Projekts in Konflikt steht
• Wenn ein Konflikt mit dem früheren Stil des Projekts besteht, wird dem vorhandenen Stil Vorrang eingeräumt

Code-Layout

Einzug

• 4 Felder
• Soft Tab
• Long Code Break Methode 1 - Richten Sie den Start ähnlicher Codes aus

test = long_function(var1, var2,
                     var3, var4)

• Long Code Break Methode 2 - Code mit zusätzlichem Einzug unterscheiden

def long_function(
        var1, var2,var3,
        var4):
    print(val_one)

• Long Code Line Break Methode 3-Hanging Indent

test = long_function(
    var1, var2, var3,
    va4)

• Fügen Sie einen Kommentar oder einen zusätzlichen Einzug hinzu, wenn Sie eine lange if-Anweisung brechen. if ( ist genau ein Einzug, daher kann der Code schwer zu lesen sein

if (hoge1_is_true and
    hoge2_is_true):
    #Kommentar
    do_something()

#OR
if (hoge1_is_true
        and hoge2_is_true):
    do something

• Die schließende Klammer der () [] -Struktur, die unterbrochen ist, kann eingerückt sein oder nicht.

my_list = [
    1, 2, 3,
    4, 5, 6
    ]

#OR
my_list = [
    1, 2, 3,
    4, 5, 6
]

Linienlänge

• Der Code sollte maximal 79 Zeichen lang sein
• Maximal 72 Zeichen für Zeichenfolgendaten und Kommentare mit weniger Formatbeschränkungen
• Es wird empfohlen, den Code zum Zeitpunkt des Zeilenumbruchs in Klammern zu setzen
• Kann "" für Dinge sein, die bereits Klammern haben, wie z. B. mit, assert

Verwenden Sie Klammern:

if (hoge1 and hoge2
        hoge3 and hoge4):
    do_something

""verwenden:

with open(filepath1, "r") as file1, \
     open(filepath2, "r") as file2:
    do_something

Position der Unterbrechungslinie

Unterbrechen Sie die Linie vor dem Bediener, um die Lesbarkeit zu gewährleisten

revenue = gacha1_price * payers1
          + gacha2_price * payers2
          + gacha3_price * payers3

Leerzeile

• 2 Leerzeilen zwischen Klassen der obersten Ebene und globalen Funktionen
• 1 leere Zeile zwischen den Methoden
• Fügen Sie leere Zeilen zu verschiedenen Arten von Methoden und Code hinzu
• Es ist in Ordnung, auch wenn zwischen ähnlichen Einzeilern keine Leerzeile steht

Quelldatei-Codierung

• Verwenden Sie grundsätzlich UTF-8
• Ausnahme:
• Spezieller Testfall
• Wenn Sie unbedingt einen Namen schreiben müssen, der Zeichen enthält, die nicht in UTF-8 enthalten sind

importieren

• Führen Sie alle "Importe" direkt in einer separaten Zeile durch

import pandas
import numpy

• Bei "from ... import" kann es mehrere geben

from sklearn.linear_model import LinearRegression, LogisticRegression

• Der Importort muss nach der Modulbeschreibung und vor der globalen Variablendefinition liegen.
• Der Import ist in die folgenden Gruppen unterteilt, und zwischen den Gruppen wird eine Leerzeile eingefügt.
• standard library
• 3rd party library
• local library
• Verwenden Sie den absoluten Import. Vermeiden Sie relative Importe
• Verwenden Sie nicht from <module> import *! Wenn Sie dies ohne Namespace tun, wissen Sie nicht, was importiert wird

Speicherort der Dunder-Anweisung auf Modulebene

• Nach Modulbeschreibung
• Vor der Importanweisung
• Nach dem Import von future`

"""This is the example module.

This module does stuff.
"""

from __future__ import barry_as_FLUFL

__all__ = ['a', 'b', 'c']
__version__ = '0.1'
__author__ = 'Cardinal Biggles'

import os
import sys

andere

• Vermeiden Sie zusammengesetzte Aussagen

#Yes
if foo == 'blah':
    do_blah_thing()
do_one()
do_two()
do_three()

#No:
if foo == 'blah': do_blah_thing()
do_one(); do_two(); do_three()

Zitat

• Python unterscheidet nicht zwischen "" und "", daher ist es in Ordnung, wenn Sie es in Ihrem Code vereinheitlichen
• Verwenden Sie jedoch "" "" für Dreiviertel-Kommentare.

"""This is how you write 
documentatoin string.
"""

Leerzeichen im Code

Vermeiden Sie die folgenden Leerzeichen

• Nahe in Klammern

#Yes
buger(bread[2], {cheese: 1})
#No
buger( bread[ 2 ], { cheese: 1 } )

• Zwischen Komma und schließender Klammer

#Yes
a_tuple = (0,)
#No
a_tuple = (0, )

• Komma, Semikolon, kurz vor dem Doppelpunkt

#Yes
if a: print x, y; x, y = y, x
#No
if a : print x , y ; x , y = y , x

• Wenn der Doppelpunkt in Scheiben geschnitten wird, wird er als Operator behandelt. Platzieren Sie daher grundsätzlich auf beiden Seiten den gleichen Platz (außer wenn er weggelassen wird).

#Yes
ham[1:9], ham[1:9:3], ham[:9:3], ham[1::3], ham[1:9:]
#No
ham[1: 9], ham[1 :9], ham[1:9 :3]

• Fügen Sie beim Schneiden Leerzeichen auf beiden Seiten des Doppelpunkts für Formeln und Funktionsaufrufe ein.

#Yes
ham[lower+offset : upper+offset], ham[: upper_fn(x) : step_fn(x)]
#No
ham[lower + offset:upper + offset]

• Unmittelbar vor der Variablenliste des Funktionsaufrufs

#Yes
func_call(params)
#No
func_call (params)

• Unmittelbar vor dem Index der Liste oder des Wörterbuchs

#Yes
dct['key'] = lst[index]
#No
dct ['key'] = lst [index]

• Stellen Sie beim Ersetzen sicher, dass neben = nur ein Leerzeichen steht

#Yes
x = 1
y = 2
long_variable = 3

#No
x             = 1
y             = 2
long_variable = 3

• Zusätzlicher Platz am Ende der Zeile
• Zuordnung zur Schlüsselwortvariablen beim Aufruf einer Funktion

#Yes
def complex(real, imag=0.0):
    return magic(r=real, i=imag)
#No
def complex(real, imag = 0.0):
    return magic(r = real, i = imag)

Lassen Sie uns das folgende Leerzeichen setzen

• Normalerweise ein Leerzeichen auf jeder Seite der folgenden Operatoren
• Substitutionssystem =, + =, - = usw.
• Vergleichssystem ==, <,>,! =, <>, <=,> =, In, nicht in, ist, ist nicht
• boolean und oder oder nicht
• Wenn Operatoren mit unterschiedlichen Prioritäten verwendet werden, auf beiden Seiten des Operators mit der niedrigeren Priorität
• Vermeiden Sie mehr als ein Leerzeichen
• Stellen Sie die Anzahl der Leerzeichen auf beiden Seiten gleich ein

#Yes
i = i + 1
submitted += 1
x = x*2 - 1
hypot2 = x*x + y*y
c = (a+b) * (a-b)

#No
i=i+1
submitted +=1
x = x * 2 - 1
hypot2 = x * x + y * y
c = (a + b) * (a - b)

• Zum Zeitpunkt der Funktionsanmerkung
• Einer nach dem Doppelpunkt
• Beide Seiten von ->

#Yes
def munge(input: AnyStr): ...
def munge() -> AnyStr: ...

#No
def munge(input:AnyStr): ...
def munge()->PosInt: ...

• Setzen Sie sowohl die variable Annotation als auch die normale Zuweisung in =, wenn sie gleichzeitig auftreten

#Yes
def munge(sep: AnyStr = None): ...
def munge(input: AnyStr, sep: AnyStr = None, limit=1000): ...

#No
def munge(input: AnyStr=None): ...
def munge(input: AnyStr, limit = 1000): ...

Komma beenden

• Kann beigefügt werden
• Grundsätzlich in Klammern setzen

#Yes
FILES = ('setup.cfg',)
#No
FILES = 'setup.cfg',

• Mehrzeilige Anzeige

#Yes
FILES = [
    'setup.cfg',
    'tox.ini',
    ]
initialize(FILES,
           error=True,
           )

#No
FILES = ['setup.cfg', 'tox.ini',]
initialize(FILES, error=True,)

Kommentar

Allgemeines

• Es ist besser, keine Kommentare abzugeben, die nicht mit dem Code übereinstimmen, und sicherzustellen, dass die Kommentare immer auf dem neuesten Stand sind.
• Machen Sie Kommentare so richtig wie möglich
• Sie können die Satzzeichen für kurze Kommentare weglassen, aber im Grunde fügen wir sie richtig hinzu.
• Fügen Sie nach der Interpunktion zwei Leerzeichen in das Dokument ein
• Schreiben Sie so viele Kommentare wie möglich auf Englisch. Eines Tages kann es von jemandem gelesen werden, der die Sprache des Code-Schreibers nicht kennt

Kommentar blockieren

• Grundsätzlich, was Sie für einen Code schreiben
• Nehmen Sie den gleichen Einzug wie den Zielcode
• Beginnen Sie grundsätzlich jede Zeile mit "#"
• Trennen Sie Dokumentabsätze mit nur "#" Zeilen

Inline-Kommentar

• Verwenden Sie nicht zu viel
• Lassen Sie mindestens 2 Leerzeichen vor dem Inline-Kommentar
• Inline-Kommentare beginnen mit "#"
• Zu offensichtliche Inline-Kommentare sind bedeutungslos. Vermeiden Sie sie daher

Dokumentbeschreibung

• Informationen zum Schreiben finden Sie unter PEP257
• Es wird verwendet, um Module, Klassen und Methoden zu erklären, also setzen Sie es unter die Zeile "def".
• Wenn es mehrere Zeilen gibt, belegt die Endung "" "" eine Zeile, aber im Fall eines Liners platzieren Sie sie in derselben Zeile.

Über die Benennung

Basic

• Dies ist definitiv nicht perfekt, da es bisher ein Chaos war, aber lassen Sie uns diese Regel vorerst so weit wie möglich befolgen, wenn Sie in Zukunft neue Dinge schreiben
• Vom Benutzer sichtbare öffentliche API-Namen sollten im Wesentlichen die Funktionalität und nicht die Implementierung widerspiegeln
• Das Erkennen, welcher Benennungsstil verwendet wird, ist genauso wichtig wie das Erkennen, wo er verwendet wird. Grundsätzlich existieren die folgenden Muster

b  #Einzelne Kleinbuchstaben
B  #Einzelnes Kapital
lowercase  #Alles klein geschrieben
lower_case_with_underscores  # _Kleinbuchstaben mit
UPPERCASE  #Alles Kapital
UPPER_CASE_WITH_UNDERSCORES  # _Mit Kapital
CapitalizedWords  #Großbuchstaben
CapitalizeAbbreviationLikeHTTP  #Bei Großbuchstaben sollten alle richtigen Abkürzungen in Großbuchstaben angegeben werden
mixedCase  #zusammengesetzt
Capitalized_Words_With_Underscores  #Hässliche Kapitalinitialen+ _

_single_leading_underscore  #Bei Verwendung nur im Inneren, wie privat
single_trailing_underscore_ #Um Konflikte mit Python-Schlüsselwörtern zu vermeiden
__double_leading_underscore  #Änderungen beim Benennen von Klassenvariablen
__double_leading_and_trailing_underscore__  #Definiere es niemals selbst

Verwendung des Namensstils

• join_lower wird für ** Modulnamen, Funktionen, Methoden, Instanzvariablen, globale Variablen ** verwendet
• JOINED_UPPER wird für ** Konstante ** verwendet
• CapWords wird für ** Klassen und Typvariablen ** verwendet
• Die Ausnahme ist eine Klasse, also die gleiche ** CapWords-Regel **, aber immer "Fehler" am Ende
• Verwenden Sie niemals 'l' (unteres L), 'O' (Oh), 'I' (oberes i) allein. Schwer zu unterscheiden

Andere Namensregeln

• Die erste Variable der Instanzmethode ist self, die erste Variable der Klassenmethode ist cls. Wenn eine Variable und ein Schlüsselwort kollidieren, setzen Sie am Ende ein'_ ', um zu entsprechen
• Am Anfang der öffentlichen Methode steht kein'_ '
• Für einfache öffentliche Daten ist es besser, die Parameter direkt zu veröffentlichen, als einen Accessor vorzubereiten.
• Variablen in der Klasse, die vererbt werden, können Namenskonflikte vermeiden, indem am Anfang des Variablennamens ein doppelter Unterstrich eingefügt wird.
• Die Abwärtskompatibilität gilt grundsätzlich nur für die öffentliche Schnittstelle.
• Um die Unterscheidung zwischen öffentlichen und privaten Schnittstellen zu vereinfachen, definieren Sie die öffentliche Schnittstelle beim Definieren des Moduls als Liste in __all__.