Da unzählige Python-Best Practices online im Umlauf sind, können die Meinungen zu den einzelnen Methoden unterschiedlich sein, je nachdem, wen Sie fragen. Das Internet hat das Fachwissen demokratisiert und ermöglicht es jedem – auch mir –, seine Ansichten zu teilen. In diesem Artikel konzentrieren wir uns jedoch auf 10 zeitlose Python-Best Practices, die einen breiten Konsens gefunden haben und weithin als grundlegend angesehen werden.

Pandas-Spickzettel

Spickzettel für Git-Befehle

Die 50 wichtigsten SQL-Interviewfragen

Tipp 1: Funktionen sollten den Parameter und den Rückgabetyp angeben
Beim Definieren einer Funktion möchten Sie immer angeben, welche Typen die Argumente haben und welchen Datentyp das Ergebnis der Funktion zurückgibt. Dies würde sowohl Ihnen als auch den Entwicklern in Ihrem Team helfen, zu wissen, was sie erwartet, ohne immer Druckanweisungen verwenden zu müssen, um ein visuelles Verständnis zu erhalten.

Tipp 2: Funktionen sollten auf dem gleichen Abstraktionsniveau sein
Wenn wir davon sprechen, dass sich Funktionen auf derselben Abstraktionsebene befinden, beziehen wir uns auf die Idee, dass eine Funktion eine einzelne, genau definierte Aufgabe ausführen sollte. Diese Aufgabe sollte während der gesamten Funktion auf einem konsistenten Abstraktionsniveau liegen. Mit anderen Worten: Die Funktion sollte sich auf eine bestimmte Detailebene oder Komplexität konzentrieren und alle Operationen der Funktionen sollten auf derselben Ebene ablaufen.

Tipp 3: Funktionen sollten klein sein
Eine Funktion soll wiederverwendbar sein. Und je größer die Funktion wird, desto geringer ist die Wahrscheinlichkeit, dass sie wiederverwendbar ist. Dies hängt auch damit zusammen, warum eine Funktion nur eine Sache tun sollte. Wenn es nur eine Sache tut, besteht eine hohe Wahrscheinlichkeit, dass es klein ist.

Tipp 4: Offene geschlossene Prinzipien
Das Open-Closed-Prinzip (OCP) besagt, dass eine Klasse, Methode oder Funktion zur Erweiterung, aber nicht zur Änderung offen sein muss. Dies bedeutet, dass jede definierte Klasse, Methode oder Funktion problemlos für mehrere Instanzen wiederverwendet oder erweitert werden kann, ohne ihren Code zu ändern.
Dies entspricht nicht der OCP, da wir jedes Mal, wenn es ein neues Land gibt, eine neue if-Erklärung schreiben müssten, um diese zu ergänzen. Das mag jetzt vielleicht einfach erscheinen, aber stellen Sie sich vor, wir müssten 100 oder mehr Länder berücksichtigen. Wie würde das aussehen?

Tipp 5: Kommentare unbedingt vermeiden
Kommentare neigen dazu, falsch wahr zu sein. Sie lenken die Gedanken des Lesers von dem, was der Code tatsächlich tut, von dem ab, was jemand anderes sagt.

Dies kann mit der Zeit sehr problematisch werden und der Code Aktualisierungen oder Änderungen erhält. Irgendwann wird der Kommentar zur Lüge und jeder muss nun die Wahrheit durch die Linse der Lüge betrachten.

Kommentare müssen unbedingt vermieden werden. Ein Kommentar zwingt den Leser, Ihr Denken zu übernehmen, das bestenfalls in der Vergangenheit liegt. Wenn sich eine Funktion oder Klasse ändert, ändern sich höchstwahrscheinlich nicht gleichzeitig ihre Kommentare. Höchstwahrscheinlich hindern sie den Leser daran, nach vorne zu denken.

Ein Kommentar bedeutet, dass der Autor geistig nicht in der Lage war, einen gut beschreibenden Klassen-, Funktions- oder Variablennamen bereitzustellen. Es offenbart die glanzlose Einstellung des Programmierers und zwingt das Team, eine solche Einstellung zu übernehmen.

Tipp 6: Vermeiden Sie magische Zahlen
Eine Magic Number ist ein fest codierter Wert, der sich zu einem späteren Zeitpunkt ändern kann, aber daher schwer zu aktualisieren sein kann.

Angenommen, Sie haben eine Seite, auf der die letzten 50 Bestellungen auf einer Übersichtsseite „Ihre Bestellungen“ angezeigt werden. 50 ist hier die magische Zahl, da sie nicht durch Standards oder Konventionen festgelegt ist, sondern eine Zahl, die Sie aus den in der Spezifikation dargelegten Gründen erfunden haben.

Was Sie nun tun, ist, dass Sie die 50 an verschiedenen Orten haben – Ihrem SQL-Skript (SELECT TOP 50 * FROMOrders), Ihrer Website (Ihre letzten 50 Bestellungen), Ihrem Bestell-Login (für (i = 0; i

Tipp 7: Vermeiden Sie tiefes Nesting
Beschränken Sie die Verschachtelungsebenen innerhalb von Schleifen, Bedingungen oder Funktionen, um die Lesbarkeit zu verbessern.

Tipp 8: Vermeiden Sie Hardcodierungspfade
Verzichten Sie darauf, Dateipfade oder URLs fest zu kodieren; Verwenden Sie stattdessen Konfigurationsdateien oder Umgebungsvariablen.

Tipp 9: Klassen sollten klein sein
Ja! Die Klassen sollten so klein wie möglich sein. Genau wie Funktionen.

Der einzige Unterschied besteht darin, dass die Größe bei Funktionen durch die Anzahl der Zeilen in dieser Funktion bestimmt wird, während sie bei Klassen durch die Anzahl der Verantwortlichkeiten in dieser Klasse bestimmt wird.

Normalerweise repräsentiert ein Klassenname die Art von Verantwortlichkeiten, die er möglicherweise besitzt, aber wenn der Name mehrdeutig oder zu allgemein ist, geben wir ihm höchstwahrscheinlich zu viel Verantwortung.

Dies führt uns zurück zum SRP (Single-Responsibility-Prinzip), das besagt, dass eine Klasse nur einen Grund – eine Verantwortung – haben sollte, sich zu ändern.

Tipp 10: Vermeiden Sie komplexe ternäre Ausdrücke
Vermeiden Sie die Verwendung übermäßig komplexer ternärer Ausdrücke. Bevorzugen Sie die Lesbarkeit gegenüber der Kürze, um den Code verständlicher zu machen.