Share
In dieser Serie beschäftigen wir uns eingehend mit den WordPress-Codierstandards - insbesondere den PHP-Codierstandards -, um zu verstehen, wie qualitativ hochwertiger WordPress-Code geschrieben werden soll.
Trotz der Tatsache, dass dies im WordPress-Entwicklerhandbuch dokumentiert ist, ist meiner Meinung nach etwas zu sagen, um die Gründe dafür zu verstehen Warum Manche Dinge sind so, wie sie sind.
Denken Sie daran: Unser oberstes Ziel ist es sicherzustellen, dass wir Code schreiben, der den Codierungsstandards entspricht, sodass wir zusammen mit anderen Entwicklern Code für Designs, Plugins und erstellte Anwendungen leichter lesen, verstehen und verwalten können auf WordPress.
In diesem Beitrag werden wir uns mit dem Umgang mit Namenskonventionen und Funktionsargumenten befassen.
Bevor Sie sich näher mit den Punkten befassen, die in den Codierungsstandards beschrieben werden, ist es wichtig zu verstehen, welche Rolle Namenskonventionen beim Schreiben von Code spielen, unabhängig von der Plattform, mit der Sie arbeiten.
Letztendlich sollten Namenskonventionen - unabhängig davon, ob sie Klassen, Funktionen, Variablen, Attribute oder Argumente betreffen - dazu beitragen, den Zweck zu erläutern, dem sie dienen.
Damit meine ich, dass Klassennamen normalerweise Substantive sein sollten, Funktionen sollten normalerweise Verben sein, und Variablen, Attribute und Argumente sollten den Zweck erläutern, den sie im Kontext der Klasse oder Funktion erfüllen, in der sie definiert werden sollen. Es geht darum, den Code so lesbar wie möglich zu machen.
Genauso wie die Kodierungsstandards besagen:
Abkürzen Sie Variablennamen nicht unbedingt ab. Lassen Sie den Code eindeutig und selbstdokumentierend sein.
Dies ist eine gute Faustregel ungeachtet von welchem Teil des Codes es ist, an dem Sie arbeiten.
Wenn Sie mit WordPress arbeiten, stoßen Sie wahrscheinlich nicht auf Klassen, es sei denn, Sie haben eine der folgenden zwei Möglichkeiten:
Wenn Sie nur an dem Thema arbeiten, arbeiten Sie wahrscheinlich mit einer Reihe von Funktionen - wir sprechen kurz darüber.
Aber für diejenigen, die mit Plugins oder ihren eigenen Bibliotheken arbeiten, ist es wichtig zu bedenken, dass Klassen normalerweise Nomen sein sollten - sie sollten den Zweck darstellen, den sie einkapseln, und im Idealfall sollten sie eine Sache tun und es gut machen.
Zum Beispiel, wenn Sie eine Klasse aufgerufen haben Local_File_Operations Dann kann es für das Lesen und Schreiben von Dateien verantwortlich sein. Es sollte nicht dafür verantwortlich sein, Dateien zu lesen und zu schreiben sowie entfernte Dateien abzurufen.
Gemäß den WordPress-Codierungsstandards sollten Klassen den folgenden Konventionen folgen:
Einfach, richtig?
In der Praxis würde dies wie folgt aussehen:
Accentsconagua
Klasse Local_File_Operations Klasse Remote_File_Operations Klasse HTTP_Request Klasse SQL_Manager Um es noch einmal zu wiederholen: Klassen sollten auch Substantive sein und sollten den einzelnen Zweck beschreiben, dem sie dienen.
Wenn Klassen Nomen sind, die idealerweise eine einzelne Idee oder einen einzigen Zweck darstellen, sollten ihre Methoden die Aktionen sein, die sie ausführen können. Als solche sollten sie Verben sein - sie sollten angeben, welche Aktion bei jedem Aufruf ausgeführt wird.
Darüber hinaus sollten die Argumente, die sie akzeptieren, auch den Namen der Funktion berücksichtigen. Wenn zum Beispiel eine Funktion für das Öffnen einer Datei verantwortlich ist, sollte ihr Parameter ein Dateiname sein. Da unser Ziel das Lesen von Code so einfach wie möglich machen soll, sollte es so etwas lesen wie "den lokalen Dateimanager die Datei mit dem folgenden Dateinamen lesen lassen".
Im Code kann dies ungefähr so aussehen:
// Die Klassendefinitionsklasse Local_File_Manager public function open_file ($ filename) // Funktionsimplementierung // Wie würden wir diesen Code verwenden $ file_manager = new Local_File_Manager (); $ file_manager-> open_file ('foo.txt'); Natürlich wird dies immer noch nicht abgedeckt Wie Funktionen sollten im Kontext der WordPress-Entwicklung geschrieben werden. Die Kodierungsstandards besagen:
Verwenden Sie in Variablen-, Aktions- und Funktionsnamen Kleinbuchstaben (niemals
camelCase). Wörter durch Unterstriche trennen. Abkürzen Sie Variablennamen nicht unbedingt ab. Lassen Sie den Code eindeutig und selbstdokumentierend sein.
Der erste Teil der Konvention ist leicht genug zu verstehen. Ich denke jedoch, dass Entwickler die Neigung haben, Abkürzungen zu nehmen, wenn sie dazu in der Lage sind. "Ah" denken wir "$ str macht hier Sinn und $ number machen hier Sinn. "
Natürlich gibt es immer noch Schlimmeres - einige Entwickler verwenden Einzelzeichen für ihre Variablennamen (was im Allgemeinen nur innerhalb von Schleifen zulässig ist).
Genauso wie die Kodierungsstandards besagen: Abkürzen Sie keine Variablennamen unnötigerweise. Lassen Sie den Code eindeutig und selbstdokumentierend sein.
Die Wahrheit ist, dass Code nur bis zu einem Punkt eindeutig sein kann. Deshalb heißt es deshalb Code, richtig? Deshalb denke ich, dass Code-Kommentare großzügig verwendet werden sollten.
In jedem Fall sollten Sie die Methodennamen in Kleinbuchstaben schreiben, alle Kamelhüllen vermeiden, durch Abstand voneinander trennen und bei der Benennung Ihrer Variablen so genau wie möglich sein.
Variablennamen unterscheiden sich tatsächlich nicht sehr von anderen Funktionsnamen, als dass sie einen einzelnen Wert oder eine Referenz auf ein bestimmtes Objekt darstellen. Die Namenskonventionen folgen weiterhin dem, was Sie erwarten würden:
Eine andere Konvention, die einige Entwickler verwenden, ist die sogenannte Ungarische Notation, bei der dem Wert, den die Variable speichert, der Variablen vorangestellt wird.
Zum Beispiel:
$ str_firstname $ i_tax oder $ num_tax $ arr_range Ehrlich gesagt, die Kodierungsstandards sagen dazu nichts aus. Auf der einen Seite denke ich, dass dies im Code-Code insgesamt zu sauberem Code führt, aber es gibt viele Entwickler, die ungarische Notation nicht mögen.
Da die Kodierungskonventionen nichts über sie aussagen, zögere ich, sie zu empfehlen, da ich so nahe wie möglich an den Standards bleiben möchte. Daher muss ich empfehlen, dass Sie sich am besten an die Kodierungsstandards halten.
Im Einklang mit dem Thema, unseren Code so lesbar und selbstdokumentierend wie möglich zu machen, ist es sinnvoll, diesen Code durch den Quellcode bis hin zu den Dateien zu ziehen, aus denen wir unser Theme, Plugin oder Anwendung.
Gemäß den Kodierungsstandards:
Dateien sollten beschreibend mit Kleinbuchstaben benannt werden. Bindestriche sollten Wörter trennen.
Um unserem vorherigen Beispiel zu entsprechen, nehmen wir an, wir arbeiten mit Local_File_Operations dann würde die Datei benannt werden class-local-file-operations.php.
Leicht genug.
Als nächstes, wenn Sie an einem Plugin arbeiten, genannt Instagram_Foo dann sollte die Datei benannt werden instagram-foo.php; Es ist jedoch erwähnenswert, dass, wenn Sie fortgeschrittene Methoden zur Entwicklung Ihrer Plugins verwenden, z. B. die Plugin-Klassendatei in einer eigenen Datei verbleiben und sie dann mit einer anderen Datei laden, die folgende Dateistruktur gilt:
class-instagram-foo.phpinstagram-foo.phpWoher instagram-foo.php ist verantwortlich für das Laden der class-instagram-foo.php. Das macht natürlich nur Sinn, wenn Sie OOP verwenden, wenn Sie Ihre WordPress-Plugins schreiben.
Beim Übergeben von Funktionsargumenten ist zu beachten, dass wenn Funktionsnamen die Aktionen beschreiben, die von der Klasse ausgeführt werden, das Argument die Funktion der Funktion darstellen soll.
Aus den Kodierungsstandards:
String-Werte gegenüber einfach vorziehen
wahrundfalschbeim Aufruf von Funktionen.
Da boolesche Werte beim Übergeben von Werten an eine Funktion unklar sein können, ist es schwierig, genau zu ermitteln, was die Funktion tut.
Zum Beispiel verwenden wir das obige Beispiel etwas anders:
// Die Klassendefinitionsklasse Local_File_Manager öffentliche Funktion manage_file ($ dateiname, true) if (true) // Datei öffnen else // Datei löschen // Wie würden wir diesen Code verwenden $ file_manager = new Local_File_Manager (); $ file_manager-> manage_file ('foo.txt', true); Ist schwieriger zu verstehen als etwa so etwas:
// Die Klassendefinitionsklasse Local_File_Manager öffentliche Funktion open_file ($ dateiname) // Datei öffnen öffentliche Funktion delete_file ($ Dateiname) // Datei löschen // Wie würden wir diesen Code verwenden $ file_manager = new Local_File_Manager (); $ file_manager-> open_file ('foo.txt'); $ file_manager-> delete_file ('foo.txt'); Denken Sie außerdem daran, dass Argumente, die an Funktionen übergeben werden, immer noch an und für sich Variablen sind. Daher unterliegen sie den oben genannten Variablennamenkonventionen.
Wir haben uns ausführlich mit Benennungskonventionen und Funktionsargumenten in den Codierungsstandards beschäftigt. Ich hoffe, dies hat geholfen, nicht nur einen Leitfaden für die Verbesserung bestimmter Aspekte Ihres WordPress-Codes zu bieten, sondern auch, um die Gründe für einige Praktiken zu erläutern.
Im nächsten Artikel werden wir die Bedeutung von einfachen Anführungszeichen und doppelten Anführungszeichen im Zusammenhang mit der Arbeit mit Strings in der WordPress-Entwicklung betrachten.
Dort ist Ein Unterschied, wie sie von PHP interpretiert werden, und es gibt Bedingungen, unter denen Sie eine über der anderen verwenden sollten. Wir werden das im nächsten Artikel besprechen.
