Buone pratiche nella scrittura del codice in WordPress

Nel precedente articolo abbiamo introdotto alcuni concetti fondamentali della programmazione OO in WordPress. In questo articolo tratteremo invece delle convenzioni stilistiche per la scrittura del codice OO nel noto Blog engine.

Struttura dei file e delle directory

Sebbene WordPress consenta di fatto la scrittura del nostro intero codice nel file functions.php di un tema o nel file principale di un plugin, l'OOP prevede invece la creazione di una gerarchia di directory contenente i file delle nostre classi; tale gerarchia va sempre creata al di sotto della directory principale del tema o del plugin. Una buona pratica è quella di raggruppare insieme le classi che svolgono compiti analoghi. Ecco un esempio di questa gerarchia:

• /framework/
  • /shortcodes/
  • /post-types/
  • /widgets/
  • /theme-settings/

I nomi delle directory dovranno essere autoesplicativi nel senso che assegnare nomi abbreviati o quantomeno criptici alle directory renderà la manutenzione futura molto più difficile, inoltre, se avete intenzione di rivendere il vostro lavoro sul mercato, tenete presente che una struttura chiara delle directory vi eviterà spesso di dover rispondere alle classiche richieste di supporto del tipo "dove trovo il codice X?".
Per quanto riguarda invece i nomi delle classi, la pratica corrente è quella di creare un file PHP per ciascuna classe. Solitamente la struttura del nome di questi file è così composta:

PrefissoTemaOPluginNomeClasse.php

Come si può notare viene utilizzata la notazione camel-case. Il prefisso del tema o del plugin viene preposto al nome della classe allo scopo di creare sia un riferimento visivo alle classi sia un contesto di applicazione per esse. Se volete invece creare un framework da riutilizzare su più temi o plugin, allora il prefisso sarà quello del vostro framework.
Se utilizzate lo standard Zend, allora il nome della classe avrà come primo componente il nome della directory seguito dal nome della classe. Ciascuna parte del nome sarà separata da un underscore:

Prefisso_Directory_Nome_Classe.php

Una pratica comune in WordPress è quella di evitare che le classi interagiscano direttamente con i temi nel frontend, per questo motivo vengono create delle funzioni ad hoc che potranno essere usate nel frontend semplicemente richiamando i metodi delle classi.
Queste funzioni dovranno essere raggruppate in file specifici, come ad esempio frontend-funcs.php e quindi richiamate nel loop principale di WordPress.

Scrittura del codice

WordPress dispone di uno standard ben definito per la scrittura del codice PHP, questo standard, tuttavia, si applica per quegli sviluppatori che intendono contribuire al Core del CMS. Ad un'attenta lettura, come del resto accade anche per molti altri CMS, solo alcune di queste pratiche raccomandate trova un riscontro universale nell'ambito generale di PHP. Per esempio l'uso delle virgolette è una pratica condivisa, mentre l'uso dei tab al posto degli spazi non lo è.
Sicuramente una pratica molto utile è la spaziatura intorno alle parentesi tonde dei blocchi. Quindi:

foreach($foo as $bar) {
...
}

è sconsigliato, mentre:

foreach( $foo as $bar ) {
...
}

è consigliato, questo perché la spaziatura facilita la lettura e la comprensione del codice.
WordPress insiste molto sul fatto che le parti del nome di una funzione debbano essere separate da un underscore:

function my_function( $param1 = 'foo', $param2 = 'bar' ) { ...}

Lo stesso principio, secondo gli sviluppatori di WordPress, dovrebbe applicarsi anche ai nomi delle classi:

class Walker_Category extends Walker { [...] }

Tuttavia questa pratica non è universalmente accettata, quindi le seguenti alternative sono valide:

class PrefixMyClass {
//...
}

class Prefix_Dir_My_Class
{
// Zend
}

Per quanto riguarda i nomi dei metodi e delle proprietà si segue in genere la notazione camel-case, usando un underscore come prefisso per i metodi e le proprietà con visibilità protected o private:

class PrefixMyClass {
protected $_testProperty;
private function _sampleMethod() { }
}

Una pratica assolutamente sconsigliata è quella che riguarda l'uso dell'operatore di scope su metodi non statici. Anche se in PHP funziona ugualmente, tuttavia una pratica come:

class PrefixMyClass {
public function method() { }
}

PrefixMyClass::method();

è errata perché dovrebbe essere utilizzata solo se il metodo di cui sopra fosse stato dichiarato come static.
I nomi delle costanti, sia quelle definite in modo globale sia quelle definite in una classe, andrebbero sempre in lettere maiuscole, separate da un underscore:

class PrefixMyClass {
const MY_VALUE = 'OK';
}

Se i vostri file contengono soltanto codice PHP, allora potrete omettere il delimitatore PHP di chiusura, stando bene attenti che il vostro file non contenga spazi alla fine. Questa pratica ci permette di evitare il tristemente noto errore Headers already sent quando includiamo il nostro codice nel flusso di WordPress.

Conclusioni

In questo articolo abbiamo definito alcune semplici linee guida da seguire nella scrittura e nella gestione del nostro codice OO in WordPress, tali linee guida si riveleranno fondamentali quando dovremo affrontare progetti complessi. Nella prossima lezione presenteremo un'introduzione alla programmazione per oggetti nei plugin di WordPress