Usando PHP CodeSniffer con WordPress Capire gli odori di codice

Spesso, il modo in cui scriviamo il codice dipende da come abbiamo iniziato con la programmazione.

Ad esempio, se qualcuno ha una formazione formale in informatica, è probabile che conoscano una varietà di principi che impediranno loro di scrivere codice di scarsa qualità. Questa non è una regola, ovviamente, ma un'osservazione. 

Allo stesso modo, coloro che entrano in programmazione da soli, al di fuori di un contesto formale, finiscono spesso per insegnare loro stessi e imparare da una varietà di risorse diverse. A volte, ciò può causare problemi con il tipo di codice scritto.

Per essere assolutamente chiari: non sto dicendo che un'educazione formale nel calcolo vince su qualcuno che insegna a se stesso, né viceversa. Alcuni fantastici programmatori sono quelli che sono istruiti; altri sono quelli che sono autodidatti. Ma l'unica cosa che hanno in comune l'una con l'altra è che non sono esenti dalla scrittura di odori di codice di volta in volta.

In questo articolo, daremo uno sguardo introduttivo agli odori del codice. Esamineremo cosa sono, come sono e come si manifestano spesso nel lavoro che facciamo. Useremo PHP per i nostri esempi.

Nella seconda parte di questa serie, daremo un'occhiata a come evitare di scrivere odori di codice. Nello specifico, utilizzeremo PHP, un paio di strumenti e WordPress come ambiente di scelta.

Ma prima, facciamo un'introduzione agli odori del codice.

Quali sono gli odori di codice?

A seconda del tipo di sviluppatore che chiedi, probabilmente otterrai una variazione sulla seguente definizione:

L'odore di codice, noto anche come cattivo odore, nel codice di programmazione del computer, si riferisce a qualsiasi sintomo nel codice sorgente di un programma che potrebbe indicare un problema più profondo. 

Questa definizione è direttamente da Wikipedia. Non è male, ma non è la mia opinione preferita sull'argomento. Invece, la mia definizione preferita proviene da un prolifico e popolare programmatore di nome Martin Fowler. In questo articolo puoi leggere tutta la sua interpretazione dell'odore di codice in questo articolo, ma l'ho riassunto nei seguenti punti:

1. "Un lungo metodo è un buon esempio di questo - basta guardare il codice e il mio naso si contrae se vedo più di una dozzina di linee di Java."
2. "Gli odori non sono intrinsecamente cattivi da soli - sono spesso un indicatore di un problema piuttosto che il problema stesso".
   
3. "Le classi di dati (classi con tutti i dati e nessun comportamento) sono buoni esempi."
   

Se non hai letto l'articolo, termina con questo:

Una delle cose belle degli odori è che è facile per le persone inesperte individuarle, anche se non ne sanno abbastanza per valutare se c'è un problema reale o correggerle. 

E penso che sia una dichiarazione fantastica perché significa che questo argomento è posizionato perfettamente per coloro che sono programmatori ma non sono sicuri da dove iniziare quando si tratta di identificare e indirizzare gli odori del codice.

In breve, l'esperienza non gioca un ruolo importante in questo. Certo, coloro che hanno maggiore esperienza probabilmente identificheranno più facilmente gli odori (perché ne hanno visti di più), ma gli sviluppatori meno esperti dovrebbero essere in grado di identificarli.

Avete esempi?

Naturalmente, quando si tratta di un argomento come gli odori di codice, è spesso più facile parlarne a un livello astratto che è effettivamente fare qualcosa su di loro. Ma questo non è pratico, né è applicabile al nostro lavoro quotidiano.

Detto questo, perché non dare un'occhiata ad alcuni esempi di odori di codice? Esamineremo perché sono problematici e quindi offriremo una soluzione su come rimuovere l'odore mediante il refactoring del codice.

Esempio 1: Cancella convenzioni di denominazione

Uno dei codici più facili da individuare è quando un programmatore ha scelto di utilizzare nomi di variabili poco chiari. Cioè, nel contesto del codice, non è chiaro a cosa debba rappresentare una determinata variabile.

Certo, ci sono momenti in cui questo è accettabile (come usare un io in un per ciclo continuo). Ma con un metodo più lungo, non è esattamente la stessa cosa per ciclo continuo). 

Per esempio:

Dato abbastanza tempo, saremmo probabilmente in grado di capire cosa stia facendo. Innanzitutto, è un metodo relativamente semplice. Secondo, saremo in grado di leggere le variabili, i blocchi e ritorno valore per ottenere un'idea migliore di ciò che sta accadendo.
Ma se stiamo cercando di scrivere un codice pulito che sia più facile da capire quando ci riferiamo ad esso o un altro programmatore lavora con esso, allora l'uso di convenzioni di denominazione chiare aiuta sempre. E il codice precedente non utilizza convenzioni di denominazione chiare.
Invece, facciamo un refactoring in modo che assomigli a questo:
Molto più facile da capire, non è vero??
Si noti che l'algoritmo stesso non è cambiato, ma il nome della funzione e i nomi delle variabili hanno. Questo ha fatto quello molto di una differenza nella lettura di questo codice. Se ti viene chiesto che cosa dovrebbe fare questo codice, possiamo facilmente dire qualcosa del tipo:
Restituisce una matrice di elementi contrassegnati come veri da una serie predefinita di elementi.
Per quanto possibile, evita di usare nomi di variabili generiche e usa qualunque sia l'opzione più chiara per te e per i tuoi colleghi.
Esempio 2: Rimani SECCO
Nella programmazione, saresti costretto a trovare uno sviluppatore che non avesse mai sentito parlare di KISS o DRY (sai, "non ripeterti"). Nonostante ciò, spesso fare ripetici. 
Questo è indicativo del fatto che il tentativo di aderire ai principi di DRY è diverso in base ai diversi tipi di programmatori. E va bene! Non esiste un unico modo per dimostrare come aderire a questo principio.
Ma poiché ci sono molti modi per farlo, possiamo fornire un esempio di come non dovrebbe apparire e come dovrebbe essere.
Supponiamo per gli scopi del seguente esempio che abbiamo una funzione chiamata save_post e accetta due argomenti: un post ID e una stringa che rappresenta il titolo del post. Un odore di codice sarebbe simile a questo:
Ma perché scrivere manualmente una chiamata a save_post tre volte? Invece, impostiamo un array associativo, lo iteriamo e quindi chiamiamo il metodo una volta per iterazione.
 "Hello World!", 2 => "Goodbye World!", 3 => "Cos'è questo nuovo mondo?",]; foreach ($ post as $ post_id => $ post_title) save_post ($ post_id, $ post_title); 
Anche se chiamare il metodo una volta è bello, il metodo potrebbe essere reso ancora più flessibile accettando l'array di post come argomento e lasciando per ciascuno loop intatto, anche se questo non è proprio il punto di questo esempio.
Se ti ritrovi a fare lo stesso metodo di chiamare più volte in una funzione ma con parametri diversi, potresti avere un odore di codice. E se lo fai, quindi cercare modi per refactoring in modo che si sta chiamando il metodo solo una volta. 
Dopotutto, non vuoi ripetere te stesso.
Esempio 3: elenchi di parametri lunghi
Una delle cose più comuni che continuiamo a vedere nella programmazione, indipendentemente dalla lingua, è quando una funzione accetta un numero elevato di parametri. 
Diversi programmatori avranno opinioni su quale sia il numero ideale di parametri che una funzione dovrebbe accettare, ma io tendo a pensare tre (dare o prendere due, forse) è un buon numero.
Per prima cosa, diamo un'occhiata a quale funzione avrà una lunga lista di parametri. Probabilmente non ci sono sorprese nel codice seguente, e potresti avere a che fare con qualcosa di simile in uno dei tuoi progetti attuali:
Nota nell'esempio precedente non ci occupiamo dell'implementazione della funzione. Invece, siamo preoccupati di quanti parametri richiede. Sono molte informazioni da inviare e farà chiamare il metodo quello molto più brutto, pure.
Non colpisce neanche sul tema della verifica e della convalida. Ma sto divagando su questo.
Come si può ripulire questo? Personalmente, sono un fan della creazione di classi per rappresentare raccolte di informazioni come questa. Per questo particolare esempio, potremmo avere una classe che presenta le informazioni di contatto di una persona. Inoltre, quella persona potrebbe essere associata a un numero di carta di credito. 
I dettagli di questo potrebbero essere applicati utilizzando la logica aziendale altrove nell'applicazione, ma l'astrazione sarebbe simile a questa:
Questo refactoring, anche se piccolo, è il più grande che abbiamo fatto in questo particolare articolo. Si noti che abbiamo fatto le seguenti cose:
 
Creato a Informazioni sui contatti classe che ci consente di creare un'istanza di un oggetto che include tutte le informazioni di pagamento per una persona.
 
Creato a Informazioni sul pagamento classe che ci consente di mantenere il numero di carta di credito o di debito per una persona e altri dettagli associati a quel metodo di pagamento.
 
Creato a Ordine classe, collocato il inviare ordine funzione al suo interno, rinominato per inviare (dal inviare ordine sarebbe ridondante) e ha ridotto la sua lista di parametri a due valori: un'istanza di Informazioni sui contatti classe e il Informazioni sul pagamento classe).
 
Per essere chiari, questo esempio non gestisce la verifica dell'associazione tra informazioni di contatto e informazioni di pagamento, né mostra altre classi che potrebbero essere necessarie (ad esempio se il pagamento è fallito o meno per la transazione).
Ma non è questo il punto dell'esercizio.
Invece, stiamo osservando l'odore del codice di lunghi elenchi di parametri e come possiamo ridurli usando metodi pratici e più manutenibili a nostra disposizione.
Ogni volta che si scrive una funzione o si effettua una chiamata a una funzione che richiede un numero elevato di argomenti, cercare i modi per ridefinire tale funzione. Aumenterà la coesione del codice e diminuirà l'odore.
Conclusione
Ricorda, gli esempi che abbiamo visto sopra sono solo questo. L'elenco non è completo, ma si tratta di odori comuni che è probabile che si vedano nel codice con cui si lavora o addirittura si scrive codice. Sarò il primo ad ammettere di essere colpevole di questo.
Inoltre, ci sono molte, molte risorse che sono disponibili quando si tratta di identificare e correggere gli odori del codice. Fortunatamente abbiamo a nostra disposizione anche numerosi strumenti che ci aiuteranno a scoprirli automaticamente e a pulirli.
Ed è qui che siamo diretti. In particolare, useremo PHP CodeSniffer per aiutarci a evitare gli odori di codice nel nostro codice. Quindi, vedremo come incorporare le regole di WordPress in PHP CodeSniffer e collegarlo al nostro IDE di scelta.
Come accennato in precedenza in questo articolo, il prossimo articolo della serie si concentrerà maggiormente sugli odori di codice durante la scrittura del codice per WordPress. Daremo un'occhiata ad alcuni strumenti e risorse disponibili per assicurarci di evitare gli odori del codice e per assicurarci di scrivere codice più efficace.
Nel frattempo, studia gli esempi sopra e controlla le risorse che ho fornito in quanto luoghi ideali per imparare di più sugli odori e sul refactoring del codice da persone e luoghi che sono degni di nota nel nostro settore.
Ricorda, puoi prendere tutti i miei corsi e tutorial nella pagina del mio profilo, e puoi seguirmi sul mio blog e / o Twitter su @tommcfarlin dove parlo di varie pratiche di sviluppo del software e come possiamo impiegarle in WordPress.
Non esitare a lasciare qualsiasi domanda o commento nel feed qui sotto e cercherò di rispondere a ciascuno di essi.



		
			
	   
	




Codice