Das Invent mit Python Blog

Das Zen von Python von Tim Peters sind 20 Richtlinien für das Design der Python-Sprache. Ihr Python-Code muss nicht unbedingt diesen Richtlinien folgen, aber sie sind gut zu beachten. Das Zen von Python ist ein Osterei oder versteckter Witz, der erscheint, wenn Sie laufen import this:

>>> import thisThe Zen of Python, by Tim PetersBeautiful is better than ugly.Explicit is better than implicit.Simple is better than complex.Complex is better than complicated.Flat is better than nested.Sparse is better than dense.Readability counts.Special cases aren't special enough to break the rules.Although practicality beats purity.Errors should never pass silently.Unless explicitly silenced.In the face of ambiguity, refuse the temptation to guess.There should be one-- and preferably only one --obvious way to do it.Although that way may not be obvious at first unless you're Dutch.Now is better than never.Although never is often better than *right* now.If the implementation is hard to explain, it's a bad idea.If the implementation is easy to explain, it may be a good idea.Namespaces are one honking great idea -- let's do more of those!

HINWEIS: Mysteriös, nur 19 der Richtlinien sind aufgeschrieben. Guido van Rosum soll gesagt haben, dass der fehlende 20. Aphorismus „ein bizarrer Tim Peters-Witz“ sei.“

Am Ende sind diese Richtlinien Meinungen, die für oder gegen argumentiert werden können. Wie alle guten Moralkodizes widersprechen sie sich manchmal, um die größte Flexibilität zu bieten. Hier ist meine eigene Interpretation dieser Aphorismen:

Schön ist besser als hässlich.

Programmierer schreiben Code oft schnell und ohne Rücksicht auf die Lesbarkeit. Während Code nicht lesbar sein muss, muss der Code der Python-Sprache selbst durchdacht, konsistent und benutzerfreundlich sein. Natürlich muss nicht jedes Skript schön sein, und Schönheit ist subjektiv, aber ein Großteil der Popularität von Python ist darauf zurückzuführen, dass es so einfach ist, damit zu arbeiten.

Explizit ist besser als implizit.

„Dieser Aphorismus ist selbsterklärend“, das wäre eine schreckliche Erklärung für jeden Aphorismus. Ebenso ist es besser, wenn Code ausführlich und explizit ist. Sie sollten es vermeiden, die Funktionalität des Codes hinter obskuren Sprachfunktionen zu verbergen, die Vertrautheit erfordern, um vollständig verstanden zu werden.

Einfach ist besser als komplex. Komplex ist besser als kompliziert.

Diese beiden Aphorismen erinnern uns daran, dass alles mit einfachen oder komplexen Techniken gebaut werden kann. Bei einem einfachen Problem, wie dem Bau eines Vogelhauses, ist eine einfache Lösung besser. Der Bau eines Dieselzugmotors ist dagegen ein komplexes Problem, das komplexe Techniken erfordert. Selbst wenn Sie technisch einen Dieselzugmotor mit Vogelhäuschentechniken herstellen könnten, würden Sie wahrscheinlich eine komplizierte Rube Goldberg-Anordnung von Vogelhäuschenteilen erhalten, die keine ideale Lösung wäre. Bevorzugen Sie Einfachheit gegenüber Komplexität, aber kennen Sie die Grenzen der Einfachheit.

Flach ist besser als verschachtelt.

Programmierer lieben es, Dinge in Kategorien zu organisieren, insbesondere Kategorien, die Unterkategorien enthalten, die andere Unterkategorien enthalten. Diese Hierarchien fügen oft nicht so viel Organisation hinzu, wie sie Bürokratie hinzufügen. Es ist in Ordnung, Code in nur einem Modul oder einer Klasse der obersten Schicht zu haben, anstatt ihn auf mehrere Submodule oder Unterklassen aufzuteilen. Wenn Sie Pakete und Module erstellen, die Code wie import spam.eggs.bacon.ham.foo.bar , machen Sie Ihren Code zu kompliziert.

Spärlich ist besser als dicht.

Programmierer möchten oft so viel Funktionalität wie möglich in so wenig Code wie möglich packen, z. B. Einzeiler wie den folgenden: print('\n'.join("%i bytes = %i bits which has %i possible values." % (j, j*8, 256**j-1) for j in (1 . While code like this may impress their friends, it'll infuriate their coworkers who have to try to understand it. Code that is spread out over multiple lines is often easier to read than dense one-liners.

Lesbarkeit zählt.

Während strcmp() offensichtlich die Funktion „String compare“ für jemanden bedeuten kann, der seit den 1970er Jahren in C programmiert, verfügen moderne Computer über genügend Speicher, um den vollständigen Funktionsnamen auszuschreiben. Lassen Sie keine Vokale aus Ihren Namen fallen oder schreiben Sie zu knappen Code. Code wird häufiger gelesen als geschrieben, daher ist expliziter, lesbarer Code wichtiger als knapper, undokumentierter Code.

Sonderfälle sind nicht speziell genug, um die Regeln zu brechen. Obwohl Praktikabilität Reinheit schlägt.

Diese beiden Aphorismen, die als Satz kommen, widersprechen sich. Die Programmierung ist voll von „Best Practices“, die Programmierer in ihrem Code anstreben sollten. Diese Praktiken für einen schnellen Hack zu umgehen, mag verlockend sein, kann aber zu einem Rattennest aus inkonsistentem, unlesbarem Code führen. Wenn Sie sich jedoch nach hinten beugen, um sich an Regeln zu halten, kann dies zu sehr abstraktem, unlesbarem Code führen. Der Versuch der Java-Programmiersprache, den gesamten Code an sein objektorientiertes Paradigma anzupassen, führt häufig zu viel Boilerplate-Code selbst für das kleinste Programm. Die Grenze zwischen diesen beiden Aphorismen zu gehen, wird mit der Erfahrung einfacher. Und mit der Zeit lernst du nicht nur die Regeln, sondern auch, wann du sie brechen musst.

Fehler sollten niemals unbemerkt passieren. Sofern nicht ausdrücklich Stillschweigen vereinbart.

Nur weil Programmierer Fehlermeldungen oft ignorieren, bedeutet das nicht, dass das Programm sie nicht mehr ausgeben sollte. Stille Fehler können auftreten, wenn Funktionen Fehlercodes oder None zurückgeben, anstatt Ausnahmen auszulösen. Diese beiden Aphorismen sagen uns, dass es besser ist, wenn ein Programm fail fast und abstürzt, als den Fehler zum Schweigen zu bringen und das Programm weiter auszuführen. Die Fehler, die später unvermeidlich auftreten, sind schwieriger zu debuggen, da sie weit von der ursprünglichen Ursache entfernt sind. Obwohl Sie immer die Fehler, die Ihre Programme verursachen, explizit ignorieren können, stellen Sie sicher, dass Sie die bewusste Entscheidung treffen.

Lehnen Sie angesichts der Mehrdeutigkeit die Versuchung ab, zu raten.

Computer haben den Menschen abergläubisch gemacht: Um die Dämonen in unseren Computern auszutreiben, führen wir das heilige Ritual durch, sie aus- und wieder einzuschalten. Angeblich wird dies jedes mysteriöse Problem beheben. Computer sind jedoch keine Magie. Wenn Ihr Code nicht funktioniert, gibt es einen Grund und nur sorgfältiges, kritisches Denken wird es lösen. Lehnen Sie die Versuchung ab, blind Lösungen auszuprobieren, bis etwas zu funktionieren scheint; Oft haben Sie das Problem nur maskiert, anstatt es zu lösen.

Es sollte einen — und vorzugsweise nur einen – offensichtlichen Weg geben, dies zu tun.

Dies ist eine Breitseite gegen das Motto der Programmiersprache Perl: „Es gibt mehr als einen Weg, dies zu tun!“ Es stellt sich heraus, dass es ein zweischneidiges Schwert ist, drei oder vier verschiedene Möglichkeiten zu haben, Code zu schreiben, der dasselbe tut: Sie haben Flexibilität beim Schreiben von Code, aber jetzt müssen Sie jede mögliche Art und Weise lernen, wie er hätte geschrieben werden können, um ihn zu lesen. Diese Flexibilität ist den 3x- oder 4x-Aufwand zum Erlernen einer Programmiersprache nicht wert.

Obwohl dieser Weg zunächst nicht offensichtlich ist, es sei denn, Sie sind Niederländer.

Diese Zeile ist ein Witz. Guido van Rossum, der Schöpfer und BDFL (Benevolent Dictator for Life) von Python, ist Niederländer. Nicht einmal dieser Aphorismus hinderte Python daran, drei verschiedene Arten der Formatierung von Zeichenfolgen zu integrieren.

Jetzt ist besser als nie. Obwohl nie ist oft besser als *right* now.

Diese beiden Aphorismen sagen uns, dass Code, der hängt oder sich in Endlosschleifen verfängt, offensichtlich schlimmer ist als Code, der dies nicht tut. Es ist jedoch mit ziemlicher Sicherheit besser, auf das Ende Ihres Programms zu warten, als es zu früh mit falschen Ergebnissen beenden zu lassen.

Wenn die Implementierung schwer zu erklären ist, ist es eine schlechte Idee. Wenn die Implementierung leicht zu erklären ist, kann es eine gute Idee sein.

Python ist bestrebt, die Arbeit des Programmierers zu erleichtern, anstatt den Computer unterzubringen, damit ein Programm schneller läuft. Und Programme müssen nicht nur für den Programmierer verständlich sein, der sie geschrieben hat, sondern auch für andere Programmierer, die den Code pflegen. Diese beiden Aphorismen erinnern uns daran, dass, wenn „Hochleistungscode“ so kompliziert ist, dass Programmierer ihn nicht verstehen und debuggen können, es sich um schlechten Code handelt. Aber leider, nur weil es einfach ist, den Code eines Programms jemand anderem zu erklären, bedeutet das nicht, dass es kein schlechter Code ist. Programmieren ist schwer.

Namespaces sind eine großartige Idee – lassen Sie uns mehr davon machen!

Namespaces (und auch globale und lokale Bereiche) sind der Schlüssel, um zu verhindern, dass Namen in einem Modul oder Bereich mit Namen in einem anderen in Konflikt stehen. Aber denken Sie auch daran, dass flach besser ist als verschachtelt: So großartig sie auch sind, Namespaces sollten nur erstellt werden, um Namenskonflikte zu vermeiden und keine unnötige Kategorisierung hinzuzufügen.

Wie alle Meinungen zum Programmieren können die, die ich hier geschrieben habe, dagegen argumentiert werden oder sind einfach irrelevant für Ihre Situation. Darüber zu streiten, wie Code geschrieben werden soll, ist selten so produktiv, wie Sie denken. (Es sei denn, Sie schreiben ein ganzes Buch voller Programmiermeinungen.)