Standard di codifica di base tramite PSR-1

Ieri ho parlato brevemente di una logica per l’utilizzo dei PSR rispetto agli standard di codifica di WordPress e del quando e del perché di entrambi. Ma questo non significa che non sia privo di punti di confusione soprattutto se stai appena iniziando con loro, giusto?

Con questo, intendo: supponiamo che tu abbia lavorato con gli standard di codifica di WordPress per anni (perché posso relazionarmi) e ora c’è questo insieme completamente nuovo di regole e linee guida da seguire. Ma non è come una semplice questione di modificare alcuni spazi bianchi e rinominare i file.

Ci sono altri punti da seguire, e ognuno è delineato in un numero, letteralmente (PSR-1, PSR-2 e così via), di come dovrebbe funzionare qualcosa.

Quindi, quando si tratta solo degli standard di codifica di base come delineato in PSR-1, quali sono alcune aree problematiche che potremmo incontrare come sviluppatori di WordPress?

Standard di codifica di base (ed effetti collaterali)

Non ho intenzione di esaminare ciascuno dei documenti e ricostruire ciò che possiamo già imparare semplicemente leggendoli, ma penso che ci sia qualcosa da dire per prendere qualcosa che molti di noi fanno o sperimentano e vedere come questo potrebbe cambiare all’interno il contesto di WordPress.

Prendi gli effetti collaterali dallo standard di codifica di base (o PSR-1 ), ad esempio:

Un file DOVREBBE dichiarare nuovi simboli (classi, funzioni, costanti, ecc.) e non causare altri effetti collaterali, oppure DOVREBBE eseguire la logica con effetti collaterali, ma NON DOVREBBE fare entrambi.

La frase "effetti collaterali" indica l’esecuzione di una logica non direttamente correlata alla dichiarazione di classi, funzioni, costanti, ecc., semplicemente dall’inclusione del file.

Personalmente, trovo la seconda frase la chiave per comprendere ed evitare il più possibile gli effetti collaterali nel nostro codice. Cioè, tutto ciò che fanno le nostre classi dovrebbe essere autonomo o essere coeso con qualcosa che potrebbe essere stato iniettato in qualche modo.

Indipendentemente da ciò, trovare codice che introduce un effetto collaterale e ripulirlo non dovrebbe essere troppo difficile. In effetti, userò me stesso come esempio.

Guarda questo particolare pezzo di codice :

Questo codice proviene direttamente da Toggle Admin Notice. Certo, è semplice e il repository mostra una nota su come cambiarlo. Dimostra comunque il punto, giusto?

Qual è la soluzione? Questo si presenta sotto forma di Autoloading (che è anche trattato in PSR-4 ). E se dovessi rifattorizzarlo, in modo che seguisse correttamente PSR-1? Quindi un modo per refactoring potrebbe essere simile a questo :

È un ottimo esempio? Probabilmente no. Ma c’è di più oltre a includere solo i file. Includere quei file significa che questo singolo file introduce una varietà di effetti collaterali.

Ciò significa che solo questo file è responsabile di fare molto di più di quelle quattro righe di codice. Pensalo come incorporare tutto ciò che implementano altri file. Diventa più complesso a quel punto.

Quindi prendi quell’idea e spostala in un sistema molto più ampio e puoi vedere come e perché questo sarebbe problematico.

Naturalmente, ci sono anche modi alternativi. E questo è solo un esempio. Anche autoironico. Il punto non è tanto mostrare un modo definitivo per farlo, ma iniziare a seminare pensieri su come progettiamo, pianifichiamo, costruiamo e incorporiamo le classi.

E per quanto riguarda le visualizzazioni?

Quando si tratta di scrivere plug-in, sono parziale nel trattare ciò che gli utenti vedranno come visualizzazioni. Ma sembra esserci un problema qui: è considerata una cattiva pratica includere file poiché introduce effetti collaterali.

Quindi non vogliamo produrre logica nelle nostre classi, ma vogliamo anche separare la presentazione dalla logica aziendale.

Cosa dobbiamo fare?

Il colpo di scena… è che useremo la programmazione orientata agli oggetti per farlo. Progetteremo una classe che genera HTML utilizzando il modello PHP.

Questo è stato trattato in modo approfondito da qualcun altro e consiglio vivamente di leggere quel particolare post per prendere l’idea degli effetti collaterali, evitarli e incorporare pratiche solide il più possibile.

…E asset e file correlati?

Lo so: l’idea di allontanarsi dagli effetti collaterali (per non parlare di identificarli) può essere strana all’inizio, specialmente se si pensa a certe cose che abbiamo fatto per così tanto tempo.

E potrebbe sollevare domande come: includere file JavaScript o file CSS è sbagliato? Questo è probabilmente un argomento per un altro post. Ricorda, tuttavia, che ci sono funzioni API di base direttamente correlate a ciò e potrebbero far parte di una classe strettamente responsabile di farlo.

Se lo scopo di una classe è quello di fare esattamente questo e solo quello e utilizza le funzioni API per farlo, direi che probabilmente va bene.

Ma per ora divago su questo (e forse è un argomento per i commenti o, ancora, un altro post).

Invece, mantieni le tue lezioni snelle e propositive. Dovrebbero fare come afferma PSR-1 ed evitare di fare cose come "[dichiarare] nuove classi, funzioni, costanti, ecc." e "[esecuzione] logica con effetti collaterali".