Einführung in die Python-Code-Schreibspezifikationen

Einführung in die Python-Code-Schreibspezifikationen

Programmierspezifikationen, auch Codierungskonventionen genannt, beziehen sich auf die bei der Softwareentwicklung befolgten Normen und Richtlinien. Dabei handelt es sich um eine Reihe von Vorschriften und Richtlinien, die darauf abzielen, den Schreibstil, das Format und die Benennungsgewohnheiten von Code zu standardisieren und zu vereinheitlichen. Das Schreiben von Code, der der Spezifikation entspricht, verbessert die Lesbarkeit, Wartbarkeit und Skalierbarkeit. Bei Programmierspezifikationen handelt es sich nicht um starre Regeln, sondern um eine Art Leitnormen und Richtlinien.

Die Programmierspezifikation kann in der frühen Phase des Projekts klar definiert und durch Teamkonsens und Codeüberprüfung sichergestellt werden, dass sich jeder Entwickler daran hält, sodass der Codestil einheitlich ist und das gegenseitige Verständnis und die Änderung des Codes einfacher sind Es ist leicht zu verstehen, zu warten und zusammenzuarbeiten. Durch die Einhaltung von Programmierkonventionen können Sie die Lesbarkeit, Wartbarkeit, Sicherheit und Leistung des Codes verbessern und die Effizienz der Teamarbeit steigern.

Die Python-Programmierspezifikation sollte PEP 8 folgen. PEP ist die Abkürzung für Python Enhancement Proposal und wird normalerweise als „Python Enhancement Proposal“ übersetzt. Jedes PEP ist ein technisches Dokument für die Python-Community, um die Entwicklung von Python in eine bessere Richtung zu lenken. Enhancement Proposal No. 8 ist ein Code-Styleguide für die Python-Sprache: PEP 8 – Style Guide for Python Code | peps.python.org

Chinesische Übersetzung https://www.cnblogs.com/bymo/p/9567140.html#_label2_0

Hier sind einige wichtige Punkte aus der PEP8-Spezifikation:

1. Verwenden Sie 4 Leerzeichen zum Einrücken und vermeiden Sie die Verwendung von Tabulatoren ( Tabulatoren ), da verschiedene Editoren die Breite von Tabulatoren möglicherweise unterschiedlich interpretieren.

2. Versuchen Sie, 79 Zeichen pro Codezeile nicht zu überschreiten.

3. Die Definitionen von Funktionen und Klassen der obersten Ebene werden durch zwei Leerzeilen davor und danach getrennt, und die Methodendefinitionen in der Klasse werden durch eine Leerzeile getrennt.

4. Fügen Sie Leerzeichen vor und nach Operatoren hinzu, z. B. Zuweisung, Vergleich, logische Operation usw.

5. Variablennamen und Funktionsnamen sollten in Kleinbuchstaben geschrieben werden, Wörter müssen durch Unterstriche getrennt werden, und Variablennamen sollten ebenfalls in Kleinbuchstaben geschrieben werden, z. B. my_variable.

6. Konstantennamen sollten ausschließlich in Großbuchstaben geschrieben werden, wobei die Wörter durch Unterstriche getrennt werden, z. B. WEEK_OF_MONTH.

7. Der Klassenname wird in Kamelschrift (Pascal-Benennung) benannt, d. h. der erste Buchstabe jedes Wortes wird großgeschrieben und nicht durch Unterstriche getrennt, wie z. B. SpringBoot.

8. Verwenden Sie in den Kommentaren Englisch, die Kommentare sollten klar und deutlich sein, schreiben Sie keine nutzlosen Kommentare.

9. Vermeiden Sie Variablennamen mit nur einem Zeichen, außer für Zähler oder Iteratoren.

10. Verwenden Sie Leerzeichen, um Parameter und Parameterlisten zu trennen, aber setzen Sie keine Leerzeichen zwischen dem Funktionsnamen und der öffnenden Klammer.

11. Verwenden Sie in Ihrem Code wann immer möglich einfache Anführungszeichen anstelle von doppelten Anführungszeichen, es sei denn, die Zeichenfolge enthält einfache Anführungszeichen.

12. Beim Importieren von Modulen sollten Standardbibliotheksmodule vor anderen Modulen platziert werden und jedes Modul sollte durch eine Leerzeile getrennt werden. Jede Importmodulanweisung sollte in einer eigenen Zeile stehen.

13. Verwenden Sie für Module, Klassen und Funktionen Dokumentationszeichenfolgen (docstring), um Beschreibungen ihrer Funktionen, Parameter, Rückgabewerte usw. bereitzustellen. Docstrings sollten unterhalb der Definition platziert und in dreifache Anführungszeichen gesetzt werden.

Supongo que te gusta

Origin blog.csdn.net/cnds123/article/details/131952000
Recomendado
Clasificación