() translation by (you can also view the original English article)
Se voi state completando la serie di articoli, in cui abbiamo discusso l'argomento del code smells, come fare il loro refactor, e degli strumenti che sono disponibili per aiutarci ad automatizzare alcune ricorsive che ci vengono in aiuto, soprattutto con la programmazione in PHP.
Se non avete letto i primi due articoli di questa serie, lo consiglio in quanto coprono alcuni prerequisiti necessari prima di andare avanti con il resto di questo articolo
Gli articoli sono:
- Usare PHP CodeSniffer con WordPress: Capire Code Smells
- Usare Php CodeSniffer con WordPress: Installare e Usare PHP CodeSniffer
In breve, gli articoli sopra introducono il concetto del code smell, che andiamo definendo come segue:
[A] code smell, anche conosciuto come bad smell, nel codice di programmazione informatica, si riferisce a qualsiasi sintomo nel codice sorgente di un programma che potrebbe indicare un problema più profondo.
Vi guiderò attraverso i passi necessari per installare PHP CodeSniffer nelle vostre macchine.
Se siete arrivati sino a questo punto, si presume che siate sviluppatori WordPress, e che siate interessati a configurare PHP CodeSniffer in modo tale da poter fiutare eventuali problemi nel codice in relazione alla WordPress Coding Standards.
Bene! Perchè nel resto del capitolo andremo a scoprire proprio questo.
Prerequisiti
Questa dovrebbe essere una lista molto breve. Se avete seguito la serie di articoli fino a questo punto, voi dovreste avere:
- una versione di PHP ( preferibilmente 5.6.10 o sucessiva)
- PHP CodeSniffer
- Composer
Tutto questo è spiegato in dettaglio nel corso dei precedenti articoli della serie, ma se siete arrivati fino a questo punto e avete dimestichezza con la linea di comando , allora questo dovrebbe essere un gioco da ragazzi in confronto a quello che abbiamo fatto finora .
Detto tutto ciò, cominciamo.
Le regole di WordPress per PHP CodeSniffer
Primo , individuare il WordPress Coding Standards rules su GitHub . Sono facili da trovare



Potete leggere tutti i dettagli del progetto dalla pagina del progetto, ma la cosa più importante che vorrei condividere è la seguente :
Questo progetto è una collezione di regole PHP_CodeSniffer (sniff) per convalidare il codice sviluppato per WordPress Questo assicura la qualità del codice e l'aderenza alle convenzioni di codifica, specialmente con l'ufficiale WordPress Coding Standards
Mi piacerebbe portare la vostra attenzione alla frase che fa riferimento al " ufficiale WordPress Coding Standards ". Si noti che queste regole si basano sui WordPress Coding Standards. Ciò significa, che non potete non riferivi ad esse.
Se state cercando un modo per vedere la definizione delle regole di WordPress, controllate questo articolo del Codex Sono semplici da seguire, facili da leggere, ma c'è molto da memorizzare. Per fortuna, abbiamo il set di regole nel link sopra.
La cosa importante da notare è che se non avete familiarità con le regole, il CodeSniffer troverà il problema nel vostro codice e vi notificherà cosa dovrete risolvere. Anche se non c'è bisogno di leggere l'articolo sul Codex, a volte può aiutare a identificare ciò che è necessario in base ai errori o avvisi generati dallo sniffer.
Installare WordPress Rules
Supponendo di aver correttamente installato PHP CodeSniffer, aggiungiamo le regole di WordPress per il software. Per questo tutorial, andrò a fare ogni cosa via linea di comando così da essere il più indipendente possibile dalla piattaforma. Offrirò qualche parola riguardo IDEs e regole alla fine delle serie.
Aprite il vostro Terminal e navigate dove avete installato la vostra copia di CodeSniffer. Se avete seguito fin qui questa serie di tutorials, è probabile che voi abbiate un richiamo al file composer.json che farà questo per noi. Se così non è, ricordate di creare composer.json nella root del vostro progetto e di aggiungere nel file:
1 |
{
|
2 |
"require": { |
3 |
"squizlabs/php_codesniffer": "2.*" |
4 |
}
|
5 |
}
|
Una volta fatto, avviate $ composer update dal vostro Terminale avrete tutto quello che serve per andare avanti. Per verificare l'installazione, avviate il seguente comando:
1 |
$ vendor/bin/phpcs --version |
Dovreste vedere qualcosa di simile al seguente output:
1 |
PHP_CodeSniffer version 2.6.0 (stable) by Squiz (https://www.squiz.net) |
Perfetto. Successivamente, andiamo ad installare le regole di WordPress. Dal momento che stiamo usando Composer (e continueremo a farlo), questo è molto facile da fare.
Avviate il seguente comando all'interno della directory principale del vostro progetto:
1 |
composer create-project wp-coding-standards/wpcs:dev-master --no-dev
|
Si noti che è possibile che venga mostrata la seguente domanda:
1 |
Do you want to remove the existing VCS (.git, .svn..) history? [Y,n]? |
Se sapete cosa state facendo, sentitevi liberi di andare avanti e selezionate 'n'; altrimenti andrà bene battere 'y'.
2. Aggiungere le regole per PHP CodeSniffer
Ora che PHP CodeSniffer è installato, e le regole di WordPress sono installate, abbiamo bisogno di fare in modo che PHP Code Sniffer sia a conoscenza del nostro nuovo set di regole. Per fare questo, dobbiamo battere il seguente comando nella riga di comando.
Nella root della directory del vostro progetto, inserite il seguente comando:
1 |
$ vendor/bin/phpcs --config-set installed_paths wpcs |
Per verificare che le nuove regole siano state aggiunte, possiamo chiedere a PHP CodeSniffer di mostrarci i set di regole che attualmente ha disponibili. Nel terminal, inserire il seguente comando:
1 |
$ vendor/bin/phpcs -i |
Si dovrebbe vedere il seguente output (o qualcosa di molto simile):
1 |
The installed coding standards are MySource, PEAR, PHPCS, PSR1, PSR2, Squiz, Zend, WordPress, WordPress-Core, WordPress-Docs, WordPress-Extra and WordPress-VIP |
Si noti nella riga sopra che abbiamo diverse serie di regole riguadanti WordPress. Piuttosto pulito, non è vero? Naturalmente, vediamo come questo aumenta quando si esegue il set di regole verso un plugin come Hello Dolly.
3. Avviare PHP CodeSniffer verso WordPress Projects
Supponendo che si stia lavorando su una directory che include un plugin per WordPress, allora si può saltare il passo successivo. Se, d'altra parte, non avete una copia di uno script di WordPress, file, tema o plugin installato nella directory del progetto, andare avanti e copiare uno sopra alla directory del progetto in questo momento.
Come già detto, andremo a testare il plugin Hello Dolly.



Per eseguire PHP CodeSniffer con le regole di WordPress verso i file nella directory dei plugin, immettere il seguente comando nel terminale:
1 |
$ vendor/bin/phpcs --standard=WordPress hello-dolly |
Questo si tradurrà in output che deve corrispondere a quello che vedete qui:
1 |
FILE: /Users/tommcfarlin/Desktop/tutsplus_demo/hello-dolly/hello.php |
2 |
----------------------------------------------------------------------
|
3 |
FOUND 14 ERRORS AFFECTING 14 LINES |
4 |
----------------------------------------------------------------------
|
5 |
2 | ERROR | Missing short description in doc comment
|
6 |
5 | ERROR | There must be exactly one blank line after the file |
7 |
| | comment |
8 |
6 | ERROR | Empty line required before block comment |
9 |
15 | ERROR | You must use "/**" style comments for a function |
10 |
| | comment |
11 |
46 | ERROR | Inline comments must end in full-stops, exclamation
|
12 |
| | marks, or question marks |
13 |
49 | ERROR | Inline comments must end in full-stops, exclamation
|
14 |
| | marks, or question marks |
15 |
53 | ERROR | Inline comments must end in full-stops, exclamation
|
16 |
| | marks, or question marks |
17 |
54 | ERROR | You must use "/**" style comments for a function |
18 |
| | comment |
19 |
56 | ERROR | Expected next thing to be an escaping function (see |
20 |
| | Codex for 'Data Validation'), not '"<p |
21 |
| | id='dolly'>$chosen</p>"' |
22 |
59 | ERROR | Inline comments must end in full-stops, exclamation
|
23 |
| | marks, or question marks |
24 |
62 | ERROR | Inline comments must end in full-stops, exclamation
|
25 |
| | marks, or question marks |
26 |
63 | ERROR | You must use "/**" style comments for a function |
27 |
| | comment |
28 |
64 | ERROR | Inline comments must end in full-stops, exclamation
|
29 |
| | marks, or question marks |
30 |
67 | ERROR | Expected next thing to be an escaping function (see |
31 |
| | Codex for 'Data Validation'), not '" |
32 |
| | '
|
33 |
----------------------------------------------------------------------
|
Naturalmente, alcune di queste cose potrà essere diversa a seconda di quando starete leggendo questo tutorial.
Gli errori dovrebbero essere abbastanza chiari per quanto riguarda ciò che deve essere risolto:
- La prima colonna indica la riga in cui esiste il problema.
- La seconda colonna determina se c'è un errore o un avviso.
- La terza colonna spiega il problema e che cosa è previsto dal codice.
Si noti che anche se si tratta di errori o avvisi, il codice ovviamente funzionerà ancora. Ma vediamo attraverso l'end-to-end cosa vuol dire sistemare un plugin, senza dubbio il più popolare, dato che si trova con ogni installazione di WordPress, ed esaminiamo le differenze nella qualità del codice.
4. Refactoring Hello Dolly
Notate il plugin, prima di cominciare lavoro su esso, include il codice sorgente riportato di seguito:
1 |
<?php
|
2 |
/**
|
3 |
* @package Hello_Dolly
|
4 |
* @version 1.6
|
5 |
*/
|
6 |
/*
|
7 |
Plugin Name: Hello Dolly
|
8 |
Plugin URI: https://wordpress.org/plugins/hello-dolly/
|
9 |
Description: This is not just a plugin, it symbolizes the hope and enthusiasm of an entire generation summed up in two words sung most famously by Louis Armstrong: Hello, Dolly. When activated you will randomly see a lyric from <cite>Hello, Dolly</cite> in the upper right of your admin screen on every page.
|
10 |
Author: Matt Mullenweg
|
11 |
Version: 1.6
|
12 |
Author URI: http://ma.tt/
|
13 |
*/
|
14 |
|
15 |
function hello_dolly_get_lyric() { |
16 |
/** These are the lyrics to Hello Dolly */
|
17 |
$lyrics = "Hello, Dolly |
18 |
Well, hello, Dolly
|
19 |
It's so nice to have you back where you belong
|
20 |
You're lookin' swell, Dolly
|
21 |
I can tell, Dolly
|
22 |
You're still glowin', you're still crowin'
|
23 |
You're still goin' strong
|
24 |
We feel the room swayin'
|
25 |
While the band's playin'
|
26 |
One of your old favourite songs from way back when
|
27 |
So, take her wrap, fellas
|
28 |
Find her an empty lap, fellas
|
29 |
Dolly'll never go away again
|
30 |
Hello, Dolly
|
31 |
Well, hello, Dolly
|
32 |
It's so nice to have you back where you belong
|
33 |
You're lookin' swell, Dolly
|
34 |
I can tell, Dolly
|
35 |
You're still glowin', you're still crowin'
|
36 |
You're still goin' strong
|
37 |
We feel the room swayin'
|
38 |
While the band's playin'
|
39 |
One of your old favourite songs from way back when
|
40 |
Golly, gee, fellas
|
41 |
Find her a vacant knee, fellas
|
42 |
Dolly'll never go away
|
43 |
Dolly'll never go away
|
44 |
Dolly'll never go away again"; |
45 |
|
46 |
// Here we split it into lines
|
47 |
$lyrics = explode( "\n", $lyrics ); |
48 |
|
49 |
// And then randomly choose a line
|
50 |
return wptexturize( $lyrics[ mt_rand( 0, count( $lyrics ) - 1 ) ] ); |
51 |
}
|
52 |
|
53 |
// This just echoes the chosen line, we'll position it later
|
54 |
function hello_dolly() { |
55 |
$chosen = hello_dolly_get_lyric(); |
56 |
echo "<p id='dolly'>$chosen</p>"; |
57 |
}
|
58 |
|
59 |
// Now we set that function up to execute when the admin_notices action is called
|
60 |
add_action( 'admin_notices', 'hello_dolly' ); |
61 |
|
62 |
// We need some CSS to position the paragraph
|
63 |
function dolly_css() { |
64 |
// This makes sure that the positioning is also good for right-to-left languages
|
65 |
$x = is_rtl() ? 'left' : 'right'; |
66 |
|
67 |
echo " |
68 |
<style type='text/css'>
|
69 |
#dolly {
|
70 |
float: $x; |
71 |
padding-$x: 15px; |
72 |
padding-top: 5px;
|
73 |
margin: 0;
|
74 |
font-size: 11px;
|
75 |
}
|
76 |
</style>
|
77 |
"; |
78 |
}
|
79 |
|
80 |
add_action( 'admin_head', 'dolly_css' ); |
81 |
|
82 |
?>
|
Dovrebbe essere relativamente facile da seguire in quanto si usano solo poche caratteristiche di PHP id base e Matt ha fatto un buon lavoro di commento del codice.
Ma dato i 14 errori che il CodeSniffer ha trovato, andiamo a fare il refactoring del plugin. Prendendo in considerazione gli errori che si sono presentati e che cosa ci si aspetta di vedere, andiamo affrontare ciascuno di essi.
Una volta fatto, il plugin dovrebbe essere simile al seguente:
1 |
<?php
|
2 |
/**
|
3 |
* This is a plugin that symbolizes the hope and enthusiasm of an entire
|
4 |
* generation summed up in two words sung most famously by Louis Armstrong.
|
5 |
*
|
6 |
* @package Hello_Dolly
|
7 |
* @version 1.6
|
8 |
*
|
9 |
* @wordpress-plugin
|
10 |
* Plugin Name: Hello Dolly
|
11 |
* Plugin URI: https://wordpress.org/plugins/hello-dolly/
|
12 |
* Description: This is not just a plugin, it symbolizes the hope and enthusiasm of an entire generation summed up in two words sung most famously by Louis Armstrong: Hello, Dolly. When activated you will randomly see a lyric from <cite>Hello, Dolly</cite> in the upper right of your admin screen on every page.
|
13 |
* Author: Matt Mullenweg
|
14 |
* Version: 1.6
|
15 |
* Author URI: http://ma.tt/
|
16 |
*/
|
17 |
|
18 |
/**
|
19 |
* Defines the lyrics for 'Hello Dolly'.
|
20 |
*
|
21 |
* @return string A random line of from the lyrics to the song.
|
22 |
*/
|
23 |
function hello_dolly_get_lyric() { |
24 |
/** These are the lyrics to Hello Dolly */
|
25 |
$lyrics = "Hello, Dolly |
26 |
Well, hello, Dolly
|
27 |
It's so nice to have you back where you belong
|
28 |
You're lookin' swell, Dolly
|
29 |
I can tell, Dolly
|
30 |
You're still glowin', you're still crowin'
|
31 |
You're still goin' strong
|
32 |
We feel the room swayin'
|
33 |
While the band's playin'
|
34 |
One of your old favourite songs from way back when
|
35 |
So, take her wrap, fellas
|
36 |
Find her an empty lap, fellas
|
37 |
Dolly'll never go away again
|
38 |
Hello, Dolly
|
39 |
Well, hello, Dolly
|
40 |
It's so nice to have you back where you belong
|
41 |
You're lookin' swell, Dolly
|
42 |
I can tell, Dolly
|
43 |
You're still glowin', you're still crowin'
|
44 |
You're still goin' strong
|
45 |
We feel the room swayin'
|
46 |
While the band's playin'
|
47 |
One of your old favourite songs from way back when
|
48 |
Golly, gee, fellas
|
49 |
Find her a vacant knee, fellas
|
50 |
Dolly'll never go away
|
51 |
Dolly'll never go away
|
52 |
Dolly'll never go away again"; |
53 |
|
54 |
// Here we split it into lines.
|
55 |
$lyrics = explode( "\n", $lyrics ); |
56 |
|
57 |
// And then randomly choose a line.
|
58 |
return wptexturize( $lyrics[ mt_rand( 0, count( $lyrics ) - 1 ) ] ); |
59 |
}
|
60 |
|
61 |
add_action( 'admin_notices', 'hello_dolly' ); |
62 |
/**
|
63 |
* This just echoes the chosen line, we'll position it later. This function is
|
64 |
* set up to execute when the admin_notices action is called.
|
65 |
*/
|
66 |
function hello_dolly() { |
67 |
|
68 |
$chosen = hello_dolly_get_lyric(); |
69 |
echo "<p id='dolly'>$chosen</p>"; // WPCS: XSS OK. |
70 |
|
71 |
}
|
72 |
|
73 |
add_action( 'admin_head', 'dolly_css' ); |
74 |
/**
|
75 |
* Add some CSS to position the paragraph.
|
76 |
*/
|
77 |
function dolly_css() { |
78 |
|
79 |
/**
|
80 |
*This makes sure that the positioning is also good for right-to-left languages.
|
81 |
*/
|
82 |
$x = is_rtl() ? 'left' : 'right'; |
83 |
echo "<style type='text/css'> #dolly { float: $x; padding-$x: 15px; padding-top: 5px; margin: 0; font-size: 11px; } </style> "; // WPCS: XSS OK. |
84 |
|
85 |
}
|
Si noti che il plugin continua a lavorare e il codice è un po' più pulito. Infine, andiamo a verificare che passi il test di CodeSniffer di PHP. Andiamo ad eseguire nuovamente il codice che abbiamo usato in precedenza per valutare inizialmente il plugin.
1 |
$ vendor/bin/phpcs --standard=WordPress hello-dolly |
E l'output che vediamo:
1 |
Skyhopper5:tutsplus_demo tommcfarlin$
|
Esattamente: non ci dovrebbe essere alcun output. Invece, dovrebbe essere un ritorno al prompt dei comandi standard.
Eccellente. Il plugin è stato portato allo standard. Ecco perché avere uno code sniffer è così prezioso: trova gli errori nel codice in base alle regole definite e quindi segnala gli eventuali errori che possono esistere.
In definitiva, questo assicura che voi rilascerete la massima qualità di codice scritta in un sito a livello di produzione. Ora, questo non significa che si potrebbe evitare unit testing o altri tipi di test, né significa che i bug non esistano. Significa solo che il vostro codice è ad un alto livello.
Conclusione
E con questo, concludiamo la serie sull'utilizzo di PHP CodeSniffer. Ricordo che durante la serie, abbiamo trattato l'argomento del code smell, come effettuare il refactoring di essi, e quali strumenti sono disponibili quando si lavora con applicazioni PHP.
In questo articolo, abbiamo visto come possiamo usare un set di regole per gli standard di codifica di WordPress fornito per valutare il nostro codice mentre si lavora su un progetto nuovo o esistente. Si noti che alcuni IDEs supportano la possibilità di eseguire le regole durante la scrittura di codice.
Anche se ciò è oltre lo scopo di questo tutorial, potrete trovare le risorse per questo in tutto il web. Cerca semplicemente il vostro IDE per nome, determinate il suo supporto per PHP CodeSniffer e quindi assicurarsi di installare le regole di WordPress come noi abbiamo descritto in dettaglio in questo tutorial.
Se vi è piaciuto questo articolo o questa serie di articoli, potreste essere interessati a verificare altre cose che ho scritto sia sulla mia pagina di profilo che sul mio blog. Potete anche seguirmi su Twitter @tommcfarlin dove spesso si parla e condividono le varie procedure di sviluppo software all'interno di WordPress.
Detto questo, non esitate a lasciare qualsiasi domanda o commento nel feed sotto ed io risponderò a ciascuno di essi.