Utilizzo dei PSR (rispetto agli standard di codifica di WordPress)

A questo punto, non so quanti articoli ho scritto sull’importanza degli standard di codifica di WordPress (abbastanza per collegarli qui, qui e qui, immagino, che conta qualcosa).

Ma dopo aver fatto abbastanza progetti per i clienti e aver lavorato con sviluppatori che sono molto più intelligenti e familiari con gli strumenti avanzati di me, sono a un punto in cui sto decidendo di iniziare a utilizzare i PSR nello sviluppo di WordPress WordPress.

Oh il dramma, giusto?

Seriamente però. Ci sono ragioni per questo, e ci sono momenti in cui penso che gli standard di codifica di WordPress dovrebbero essere ancora utilizzati, ma sto diventando rapidamente più convinto che la costruzione di qualsiasi progetto moderno su WordPress dovrebbe utilizzare strumenti PHP più moderni (che io ‘ menzionerò brevemente più avanti).

Utilizzo dei PSR nello sviluppo di WordPress

Post come questo spesso introducono un dibattito o una risposta drammatica all’interno di WordPress che non è il mio intento né è qualcosa che penso sia nemmeno necessario. Ad essere onesto, conosco un buon numero di altri sviluppatori che l’ hanno fatto molto tempo fa, ne hanno parlato, sono andati avanti e hanno continuato ad avere successo sia nei loro affari che nei loro progetti di hobby.

Ma dato che ho parlato così tanto dell’uno contro l’altro, ho pensato che valesse la pena condividere la mia opinione sul motivo per cui sto optando per fare questo cambiamento ora e la logica dietro di esso.

1 Parità con la comunità PHP

Nell’ultimo anno o giù di lì, e solo negli ultimi mesi di quest’anno, mi sono abituato di più a:

• amici sviluppatori più esperti orientati a PHP che approvano strumenti che si aspettano che i PSR vengano adottati,
• l’uso di //@codingStandardsIgnoreStart e //@codingStandardsIgnoreEnd nel mio codice,
• set di regole personalizzate per i miei progetti in base agli ambienti in cui sono distribuiti,
• e altro ancora.

In definitiva, si tratta di voler mantenere la parità (o una parte di essa) con la più ampia comunità PHP in generale, scrivendo anche codice leggibile e basato su standard su WordPress. E mi piacerebbe anche utilizzare altri strumenti e versioni più recenti di strumenti esistenti (di cui parlerò più avanti in questo post).

2 Problemi con gli ambienti moderni

Al momento della stesura di questo post, PHP CodeSniffer (necessario per eseguire gli standard di codifica di WordPress) è alla versione 3.0.2. Tuttavia, ci sono problemi di compatibilità con PHPCS e con gli standard di codifica di WordPress. Nello specifico :

La nuova versione di PHP CodeSniffer ha alcune caratteristiche interessanti, ma introduce modifiche sostanziali che significano che gli standard di codifica di WordPress non sono compatibili.

Per essere chiari (ea causa della natura del software), è questione di tempo prima che venga risolto. Ma se stai lavorando su una base di codice e stai usando Composer e gli standard di codifica di WordPress, dovrai impostare esplicitamente la versione di PHP CodeSniffer piuttosto che qualunque sia la versione più recente attualmente.

Inoltre, ho riscontrato problemi con i clienti in cui la mia mancata adozione dei PSR nello sviluppo di WordPress ha comportato comportamenti strani durante la distribuzione del codice. Forse si potrebbe sostenere che dovrebbero adeguare l’ambiente, ma se stanno lavorando per avere gli strumenti più moderni a disposizione delle persone che li utilizzano, perché regredire?

3 Compatibilità con strumenti moderni

Infine, ci sono una serie di strumenti moderni che non sono stato in grado di utilizzare, per non parlare di imparare, a causa di ciò che è e ciò che non è supportato dalla natura del controllo delle versioni.

Ad esempio, stavamo utilizzando GrumPHP in un progetto recente che supporta una varietà di strumenti ma non siamo stati in grado di utilizzare, ad esempio, PHPMD a causa della mancanza di adozione dei PSR. Per quanto mi riguarda:

• Voglio migliorare continuamente le mie capacità di sviluppatore (e, in questo contesto, di sviluppatore PHP),
• la mancanza di supporto per strumenti più moderni mi mette in uno schema di mantenimento che altrimenti non sperimenterei,
• Voglio continuare a lavorare con WordPress ma farlo con un flusso di lavoro più moderno

E in questo momento, non utilizzare i PSR sta creando un divario tra ciò che sta facendo il resto della comunità PHP e ciò che sta facendo WordPress. Quindi mi piacerebbe andare avanti continuando a lavorare su progetti in aggiunta al software che mi piace ancora usare.

Che dire degli standard di codifica di WordPress

Quindi cosa significa questo sugli standard di codifica di WordPress e sui post precedenti? Niente. Per come la vedo io: gli standard di codifica di WordPress dovrebbero essere utilizzati ogni volta che lavori su WordPress Core o qualcosa che sarà strettamente integrato in esso.

Ma se stai lavorando su qualcosa che si trova sopra WordPress o qualcosa che utilizza WordPress come base e puoi utilizzare i PSR nello sviluppo di WordPress insieme a strumenti che possono aiutare ad aumentare la qualità della base di codice che stai costruendo.

Quindi, almeno per ora, questa è la prospettiva che adotterò. Non vedo l’ora di vedere come andrà a finire nei prossimi mesi. E, come per qualsiasi altra cosa che ho condiviso, condividerò gli aspetti di fare questo passaggio.