Share
In questa serie, stiamo approfondendo gli standard di codifica di WordPress, in particolare gli standard di codifica PHP, per evangelizzare e capire come deve essere scritto il codice WordPress di qualità.
Nonostante questo sia documentato nel manuale dello sviluppatore WordPress, penso che ci sia qualcosa da dire per capire la logica alla base perché alcune cose sono come sono.
Ricorda: il nostro obiettivo finale è quello di assicurarci che stiamo scrivendo un codice conforme agli standard di codifica in modo che noi, insieme ad altri sviluppatori, siamo in grado di leggere, comprendere e mantenere più facilmente il codice per temi, plug-in e applicazioni create in cima a WordPress.
In questo post, daremo un'occhiata a come gestire le convenzioni di denominazione e gli argomenti delle funzioni.
Prima di dedicare del tempo a elaborare i punti delineati negli standard di codifica, è importante capire il ruolo che le convenzioni di denominazione giocano nella scrittura del codice indipendentemente dalla piattaforma con cui stai lavorando.
In definitiva, le convenzioni di denominazione, indipendentemente dal fatto che siano per classi, funzioni, variabili, attributi o argomenti, dovrebbero aiutare a spiegare lo scopo che servono.
Con ciò intendo che i nomi di classe dovrebbero essere tipicamente sostantivi, le funzioni dovrebbero essere tipicamente verbi e le variabili, gli attributi e gli argomenti dovrebbero spiegare lo scopo che servono all'interno del contesto della classe o della funzione in cui devono essere definiti. Si tratta di rendere il codice il più leggibile possibile.
Proprio come lo stato di codifica afferma:
Non abbreviare i nomi delle variabili non necessariamente; lascia che il codice sia inequivocabile e auto-documentante.
Questa è una buona regola empirica senza riguardo di quale parte del codice è su cui stai lavorando.
Quando si tratta di lavorare con WordPress, non è probabile che si incontrino le classi a meno che non si stia facendo una delle due cose:
Se stai semplicemente lavorando sul tema, è più probabile che tu stia lavorando con una serie di funzioni - ne parleremo brevemente.
Ma per coloro che stanno lavorando con i plugin o le loro librerie, è importante ricordare che le classi dovrebbero essere tipicamente sostantivi - dovrebbero rappresentare lo scopo che incapsulano e dovrebbero idealmente fare una cosa e farlo bene.
Ad esempio, se hai una classe chiamata Local_File_Operations quindi potrebbe essere responsabile per la lettura e la scrittura di file. Non dovrebbe essere responsabile per la lettura e la scrittura di file e, ad esempio, il recupero di file remoti.
Secondo gli standard di codifica di WordPress, le lezioni dovrebbero seguire le seguenti convenzioni:
Semplice, giusto?
In pratica, questo sarebbe il seguente:
Accentsconagua
class Local_File_Operations class Remote_File_Operations classe HTTP_Request class SQL_Manager Per ripetere: le classi dovrebbero anche essere nomi e dovrebbero descrivere il singolo scopo che servono.
Come accennato in precedenza, se le classi sono nomi che rappresentano idealmente una singola idea o un unico scopo, i loro metodi dovrebbero essere le azioni che sono in grado di intraprendere. In quanto tali, dovrebbero essere i verbi - dovrebbero indicare quale azione verrà intrapresa ogni volta che vengono chiamati.
Inoltre, gli argomenti accettati accettano anche il nome della funzione. Ad esempio, se una funzione è responsabile dell'apertura di un file, il suo parametro dovrebbe essere un nome di file. Dato che il nostro obiettivo dovrebbe rendere il più semplice possibile la lettura del codice, allora dovrebbe leggere qualcosa del tipo "chiedi al file manager locale di leggere il file con il seguente nome di file".
Nel codice, questo può assomigliare a questo:
// La classe di definizione classe Local_File_Manager public function open_file ($ filename) // Implementazione funzione // Come useremmo questo codice $ file_manager = new Local_File_Manager (); $ file_manager-> open_file ('foo.txt'); Naturalmente, questo non copre ancora Come le funzioni dovrebbero essere scritte nel contesto dello sviluppo di WordPress. Gli standard di codifica indicano:
Usa lettere minuscole nei nomi di variabili, azioni e funzioni (mai
camelCase). Separare le parole tramite underscore. Non abbreviare i nomi delle variabili non necessariamente; lascia che il codice sia inequivocabile e auto-documentante.
La prima parte della convenzione è abbastanza facile da capire; tuttavia, penso che gli sviluppatori abbiano la propensione a prendere scorciatoie quando sono in grado. "Ah", pensiamo, "$ str ha senso qui, e numero di $ ha senso qui. "
Naturalmente, ci sono sempre peggio: alcuni sviluppatori ricorrono all'uso di singoli caratteri per i loro nomi variabili (che generalmente è accettabile solo nei loop).
Proprio come lo stato di codifica afferma: Non abbreviare i nomi delle variabili non-necessariamente. Lascia che il codice sia inequivocabile e auto-documentante.
Ora, la verità è che il codice non può essere inequivocabile fino a un certo punto. Dopotutto, è per questo che si chiama codice, giusto? Questo è il motivo per cui penso che i commenti sul codice dovrebbero essere usati liberamente.
In ogni caso, la linea di fondo è quella di minare i nomi dei metodi, evitare tutto il corpo del cammello, separare per spaziatura ed essere il più specifico possibile quando si nominano le variabili.
I nomi delle variabili in realtà non sono molto diversi dai nomi delle funzioni tranne che rappresentano un singolo valore o un riferimento a un particolare oggetto. Le convenzioni di denominazione seguono ancora ciò che ti aspetteresti:
Un'altra convenzione utilizzata da alcuni sviluppatori è quella nota come Notazione ungherese, ovvero il luogo in cui il tipo di valore memorizzato dalla variabile viene anteposto davanti alla variabile.
Per esempio:
$ str_firstname $ i_tax o $ num_tax $ arr_range Onestamente, gli standard di codifica non dicono nulla al riguardo. Da un lato, penso che questo faccia per un codice più pulito nell'ambito globale del codice, ma ci sono molti sviluppatori che non amano la notazione ungherese.
Dal momento che le convenzioni sulla codifica non dicono nulla su di loro, sono riluttante a raccomandarle perché voglio rimanere il più vicino possibile agli standard. Come tale, devo raccomandare che è meglio seguire gli standard di codifica.
In linea con il tema di rendere il nostro codice leggibile e autodocumentato il più possibile, ha senso passare questo attraverso il nostro codice sorgente fino ai file che andremo a costituire il nostro tema, plugin o applicazione.
Secondo gli standard di codifica:
I file dovrebbero essere nominati in modo descrittivo utilizzando lettere minuscole. I trattini dovrebbero separare le parole.
Nel mantenere coerente con il nostro esempio precedente, diciamo che stiamo lavorando Local_File_Operations allora il file verrebbe nominato class-file-locale-operations.php.
Abbastanza facile.
Successivamente, se stai lavorando su un plugin chiamato Instagram_Foo allora il file dovrebbe essere nominato instagram-foo.php; tuttavia, vale la pena notare che se si utilizzano alcuni metodi avanzati per lo sviluppo di plug-in come mantenere il file di classe del plug-in nel proprio file e quindi caricarlo utilizzando un altro file, la struttura del file potrebbe essere:
class-instagram-foo.phpinstagram-foo.phpDove instagram-foo.php è responsabile del caricamento del class-instagram-foo.php. Ovviamente, questo ha senso solo se stai usando OOP quando scrivi i tuoi plugin WordPress.
Quando si tratta di passare argomenti di funzione, è importante ricordare che se i nomi di funzione descrivono le azioni che vengono intraprese dalla classe, allora l'argomento dovrebbe rappresentare su ciò che la funzione sta effettivamente operando.
Dagli standard di codifica:
Preferisci valori di stringa a solo
veroefalsoquando si chiamano funzioni.
Poiché i valori booleani possono non essere chiari quando si passano valori in una funzione, è difficile determinare esattamente cosa sta facendo la funzione.
Ad esempio, utilizziamo l'esempio sopra in modo leggermente diverso:
// La classe di definizione classe Local_File_Manager public function manage_file ($ filename, true) if (true) // Apri il file else // Elimina il file // Come usiamo questo codice $ file_manager = new Local_File_Manager (); $ file_manager-> manage_file ('foo.txt', true); È più difficile capire di, diciamo, qualcosa del genere:
// La classe di definizione classe Local_File_Manager public function open_file ($ filename) // apre il file public function delete_file ($ filename) // elimina il file // Come usiamo questo codice $ file_manager = new Local_File_Manager (); $ file_manager-> open_file ('foo.txt'); $ file_manager-> delete_file ('foo.txt'); Oltre a ciò, ricorda che gli argomenti passati alle funzioni sono ancora variabili di per sé e quindi sono soggetti alle convenzioni di denominazione delle variabili che abbiamo dettagliato sopra.
Abbiamo preso in considerazione le convenzioni di denominazione e gli argomenti delle funzioni negli standard di codifica. Speriamo che questo abbia contribuito a fornire non solo una guida su come migliorare alcuni aspetti del tuo codice WordPress, ma anche per spiegare la logica dietro alcune delle pratiche.
Nel prossimo articolo, daremo un'occhiata al significato delle virgolette singole e doppie nel contesto del lavoro con le stringhe nello sviluppo di WordPress.
Là è una differenza nel modo in cui sono interpretati da PHP e ci sono delle condizioni in cui dovresti usarne uno sull'altro e lo esamineremo nel prossimo articolo.
