Share
Om du bara går med i serien har vi diskuterat ämnet kodlukter, hur du refactor dem och verktyg som är tillgängliga för att hjälpa oss att automatisera en del monotoni som medför det, särskilt inom PHP-programmering.
Om du inte har läst de två första artiklarna i serien rekommenderar jag det eftersom de täcker några förutsättningar vi har på plats innan du går vidare med resten av artikeln.
Artiklarna är:
Kortfattat kommer artiklarna ovan att introducera begreppet kodluktar, som vi har definierat som följande:
[A] kodlukt, även känd som en dålig lukt, i datorprogrammeringskod, hänvisar till något symptom i källkoden för ett program som möjligen indikerar ett djupare problem.
Och jag kommer att gå igenom de steg som behövs för att installera PHP CodeSniffer på din maskin.
Men om du har gjort det så långt antar jag att du är en WordPress-utvecklare och du är intresserad av att få PHP CodeSniffer konfigurerad så att det kan snyta eventuella problem i din kod som det gäller WordPress-kodningsstandarderna.
Det är bra! För i resten av den här artikeln är det precis vad vi ska täcka.
Detta borde vara en mycket kort lista. Om du har följt med serien upp till denna punkt måste du ha:
Allt detta beskrivs i detalj i de tidigare artiklarna i serien, men om du har kommit så långt och är bekväm med kommandoraden så borde det vara en film i jämförelse med vad vi gjort hittills.
Med allt det sagt, låt oss börja.
Hitta först WordPress-kodningsstandardreglerna på GitHub. De är lätta att hitta.
Du kan läsa allt om projektets detaljer från projektsidan, men det viktigaste jag vill dela med är följande:
Detta projekt är en samling av PHP_CodeSniffer-regler (sniffs) för att validera kod utvecklad för WordPress. Det garanterar kodkvalitet och överensstämmelse med kodningskonventioner, särskilt de officiella WordPress-kodningsstandarderna.
Jag skulle vilja uppmärksamma frasen som hänvisar till "officiella WordPress-kodningsstandarder". Observera att dessa regler är baserade på WordPress-kodningsstandarderna. Det innebär att du inte kan referera dem officiellt.
Om du letar efter ett sätt att titta igenom de regler som WordPress definierar, kolla in den här artikeln i Codex. Det är lätt att följa, lätt att läsa, men mycket att komma ihåg. Tack och lov har vi regelbunden länk ovan.
Det viktiga att notera är att även om du inte känner till reglerna kommer CodeSniffer att hitta problemen med din kod och meddela dig vad du behöver fixa. Även om du inte behöver läsa Codexartikeln, kan det ibland hjälpa till att identifiera vad som behövs baserat på fel eller varningar som sniffer genererar.
Förutsatt att du har installerat PHP CodeSniffer korrekt, låt oss lägga till WordPress-reglerna till programvaran. För denna handledning ska jag göra allt via kommandoraden för att vara så plattformig agnostisk som möjligt. Jag kommer att erbjuda några ord om IDE och regler i slutet av serien.
Öppna din terminal och navigera till var du har din kopia av PHP CodeSniffer installerad. Om du har följt med den här serien av handledning, kommer du sannolikt att vi har en composer.json fil som kommer att dra in detta för oss. Om inte, kom ihåg att skapa composer.json i roten till ditt projekt och lägg till det här i filen:
"kräver": "squizlabs / php_codesniffer": "2. *"
När du är klar kör du $ komponentuppdatering från din terminal och du har allt du behöver för att komma igång. För att verifiera installationen, kör följande kommando:
$ leverantör / bin / phpcs - version
Och du borde se något som följande utdata:
PHP_CodeSniffer version 2.6.0 (stable) av Squiz (http://www.squiz.net)
Perfekt. Låt oss sedan installera WordPress-reglerna. Eftersom vi använder Composer (och fortsätter att göra det) är det här mycket enkelt att göra.
Kör följande kommando från rotkatalogen i ditt projekt:
kompositör skapa-projekt wp-kodning -standarder / wpcs: dev-master -no-dev
Observera att du kan bli tillfrågad med följande fråga:
Vill du ta bort den befintliga VCS-historiken (.git, .svn ...)? [Y, n]?
Om du vet vad du gör är du välkommen att fortsätta och välja 'n'; annars kommer du bra att träffa "y".
Nu när PHP CodeSniffer är installerat, och WordPress-reglerna är installerade, måste vi se till att PHP CodeSniffer är medveten om vår nya regelsats. För att göra detta måste vi ange följande kommando i kommandoraden.
Ange följande kommando från roten i din projektkatalog:
$ leverantör / bin / phpcs --config-set installed_paths wpcs
För att verifiera att de nya reglerna har lagts till kan vi fråga PHP CodeSniffer för att rapportera till oss de uppsättningar regler som den för närvarande har tillgänglig. I terminalen anger du följande kommando:
$ leverantör / bin / phpcs -i
Och du bör se följande utdata (eller något mycket liknande):
De installerade kodningsstandarderna är MySource, PEAR, PHPCS, PSR1, PSR2, Squiz, Zend, WordPress, WordPress-Core, WordPress-Docs, WordPress-Extra och WordPress-VIP
Observera i raden ovan att vi har flera uppsättningar regler om WordPress. Ganska snyggt eller inte? Självklart, låt oss se hur det här staplar upp när vi kör regelsætten mot ett plugin som Hej Dolly.
Om du antar att du arbetar i en katalog som innehåller ett WordPress-plugin, kan du hoppa över följande steg. Om du å andra sidan gör det inte ha en kopia av ett WordPress-skript, fil, tema eller plugin installerat i projektkatalogen, fortsätt och kopiera en över till din projektkatalog nu.
Som nämnts testar vi Hej Dolly plugin.
För att köra PHP CodeSniffer med WordPress-reglerna mot filerna i plugin-katalogen anger du följande kommando i Terminal:
$ leverantör / bin / phpcs - standard = WordPress Hello-Dolly
Detta kommer att resultera i produktionen som borde motsvara det du ser här:
FIL: /Users/tommcfarlin/Desktop/tutsplus_demo/hello-dolly/hello.php -------------------------------- -------------------------------------- FUND 14 FEL AVFEKTERER 14 LINER ------ -------------------------------------------------- -------------- 2 | FEL | Saknar kort beskrivning i doc kommentaren 5 | FEL | Det måste finnas exakt en blank linje efter filen | | kommentar 6 | FEL | Obligatorisk linje krävs före blockkommentar 15 | FEL | Du måste använda "/ **" stilkommentarer för en funktion | | kommentar 46 | FEL | Inline kommentarer måste sluta i fullstopp, utropstecken | | märken eller frågetecken 49 | FEL | Inline kommentarer måste sluta i fullstopp, utropstecken | | märken eller frågetecken 53 | FEL | Inline kommentarer måste sluta i fullstopp, utropstecken | | märken eller frågetecken 54 | FEL | Du måste använda "/ **" stilkommentarer för en funktion | | kommentar 56 | FEL | Förväntad nästa sak att vara en flyktig funktion (se | | Codex för "Data Validation"), inte ""$ valt
"59 | ERROR | Inline kommentarer måste sluta i fullstopp, utropstecken | | märken eller frågetecken 62 | ERROR | Inline-kommentarer måste sluta i fullstopp, utropstecken | | märken eller frågetecken 63 | FEL | Du måste använd "/ **" stil kommentarer för en funktion | | kommentar 64 | ERROR | Inline kommentarer måste sluta i fullstopp, utropstecken | | märken eller frågetecken 67 | ERROR | Förväntad nästa sak att vara en flyktig funktion (se | | Codex för "Data Validation"), inte "" | | ' ----------------------------------------------------------------------
Naturligtvis kan vissa av dessa saker förändras beroende på när du läser denna handledning.
Felen ska vara ganska tydliga när det gäller vad som behöver lösas:
Observera att även om det här är fel eller varningar, fungerar koden självklart fortfarande. Men låt oss dra det här genom slutet till slutet och se hur det är att fixa ett plugin, utan tvekan det mest populära eftersom det kommer med varje installation av WordPress och granska skillnaderna i kodens kvalitet.
Observera pluginet, innan vi börjar arbeta med det, innehåller följande källkod:
Accentsconagua
Hej, Dolly längst upp till höger på din administratörsskärm på varje sida. Författare: Matt Mullenweg Version: 1.6 Författare URI: http://ma.tt/ * / function hello_dolly_get_lyric () / ** Dessa är texterna till Hello Dolly * / $ lyrics = "Hej, Dolly Tja, hej, Dolly Det är så trevligt att få dig tillbaka där du hör hemma Du kan se dig, Dolly Jag kan berätta, Dolly Du är fortfarande glödin ', du är fortfarande krånglig' Du är fortfarande stark Vi känner rummet swayin 'Medan bandets playin "En av dina gamla favoritlåtar från vägen tillbaka när Så, ta henne ihop, fellas Hitta henne ett tomt varv, fellas Dolly kommer aldrig att gå igen Hallå Dolly Well hej Dolly Det är så trevligt att få dig tillbaka där Du hörs Du ser ut dig, Dolly Jag kan berätta, Dolly Du är fortfarande lysande, du är fortfarande krånglig. Du är fortfarande stark. Vi känner rummet swayin. Medan bandets spel är "En av era gamla favoritlåtar från väg tillbaka när Golly, ge, fellas Hitta henne ett ledigt knä, fellas Dolly'll aldrig gå bort Dolly'll aldrig gå bort Dolly'll aldrig gå bort igen "; // Här delar vi upp det i rader $ lyrics = explode ("\ n", $ lyrics); // och välj sedan slumpmässigt en linje retur wptexturize ($ lyrics [mt_rand (0, count ($ lyrics) - 1)]); // Detta härdar bara den valda linjen, vi placerar den senare funktionen hello_dolly () $ selected = hello_dolly_get_lyric (); eko "$ valt
"; // Nu ställer vi upp den här funktionen för att utföra när admin_notices-åtgärden heter add_action ('admin_notices', 'hallo_dolly'); // Vi behöver lite CSS för att placera punktfunktionen dolly_css () // Detta gör det säkert att positioneringen också är bra för höger till vänster språk $ x = is_rtl ()? 'left': 'right'; eko " "; add_action ('admin_head', 'dolly_css');?> Det ska vara relativt enkelt att följa eftersom det bara använder några grundläggande PHP-funktioner och Matt har gjort ett bra jobb att kommentera koden.
Men med tanke på de 14 fel som CodeSniffer hittade, låt oss refactor plugin. Med tanke på de fel som de presenterade och vad de förväntar oss att se, låt oss ta upp var och en av dem.
När en gång är klar ska pluggen se ut som följer:
Hej, Dolly längst upp till höger på din administratörsskärm på varje sida. * Författare: Matt Mullenweg * Version: 1.6 * Författare URI: http://ma.tt/ * / / ** * Definierar texterna för "Hello Dolly". * * @return sträng En slumpmässig linje från texterna till låten. * / funktion hello_dolly_get_lyric () / ** Det här är texterna till Hello Dolly * / $ lyrics = "Hej Dolly Well hej, Dolly Det är så trevligt att få dig tillbaka där du hör hemma Du ser ut dig, Dolly I kan säga, Dolly Du är fortfarande glödd, du är fortfarande krånglig. Du är fortfarande stark. Vi känner rummet swayin. Medan bandets playin "En av dina gamla favoritlåtar tillbaka när, Så, ta med henne , fellas Hitta henne ett tomt skott, älskling Dolly kommer aldrig att gå igen Hej Dolly Nå hej Dolly Det är så trevligt att få dig tillbaka där du hörs Du ser ut dig, Dolly Jag kan säga Dolly Du är du är fortfarande krånglig "Du är fortfarande stark Vi känner rummet swayin" Medan bandets playin "En av dina gamla favoritlåtar tillbaka när Golly, ge, fellas Hitta henne ett ledigt knä, fellas Dolly'll aldrig gå Dolly'll aldrig gå Dolly'll aldrig gå igen "; // Här delar vi det i linjer. $ lyrics = explodera ("\ n", $ lyrics); // och välj sedan slumpmässigt en rad. returnera wptexturize ($ lyrics [mt_rand (0, count ($ lyrics) - 1)]); add_action ("admin_notices", "hej_dolly"); / ** * Detta hämtar bara den valda linjen, vi placerar den senare. Den här funktionen är * konfigurerad att utföras när admin_notices-åtgärden heter. * / funktion hello_dolly () $ selected = hello_dolly_get_lyric (); eko "$ valt
"; // WPCS: XSS OK. Add_action ('admin_head', 'dolly_css'); / ** * Lägg till några CSS för att placera stycket. * / Function dolly_css () / ** * Detta säkerställer att positioneringen är också bra för språk till höger till vänster. * / $ x = is_rtl ()? 'left': 'right'; echo " "; // WPCS: XSS OK. Observera att plugin fortsätter att fungera och koden är lite renare. Till sist, låt oss verifiera att detta passerar PHP CodeSniffer-testet. Låt oss åter köra koden som vi använde ovan för att initialt utvärdera plugin.
$ leverantör / bin / phpcs - standard = WordPress Hello-Dolly
Och den produktion vi ser:
Skyhopper5: tutsplus_demo tommcfarlin $
Exakt: Det ska inte finnas någon produktion. Istället bör det vara en återgång till standardkommandotolken.
Excellent. Pluggen har tagits upp till standard. Det är därför att ha en kod sniffer är så värdefull: Det hittar fel i koden baserat på de regler du definierar och sedan rapporterar eventuella fel som kan finnas.
I sista hand säkerställer detta att du släpper ut den högsta kvalitetskoden till en produktionsnivå. Nu betyder det inte att du borde undvika enhetsprovning eller andra typer av test, och det betyder inte att det finns några fel. Det betyder bara att din kod är upp till en hög standard.
Och med det sluter vi serien om att använda PHP CodeSniffer. Minns att genom hela serien har vi tagit upp tanken på kodlukt, hur man refactor dem och vilka verktyg som finns tillgängliga för oss när vi arbetar med PHP-applikationer.
I den här artikeln såg vi hur vi kan använda en föreskriven uppsättning regler för WordPress-kodningsstandarderna för att utvärdera vår kod när du arbetar med ett nytt eller ett befintligt projekt. Observera att vissa IDE stödjer möjligheten att utföra reglerna medan du skriver kod.
Även om det ligger utanför omfattningen av den här handledningen kan du hitta resurser till detta på olika ställen över hela webben. Sök bara efter din IDE med namn, bestäm dess stöd för PHP CodeSniffer, och se till att installera WordPress-reglerna som vi har beskrivit i den här handledningen.
Om du haft den här artikeln eller den här serien kan du vara intresserad av att kolla på andra saker jag har skrivit både på min profilsida eller på min blogg. Du kan också följa mig på Twitter på @tommcfarlin där jag ofta pratar om och delar olika mjukvaruutvecklingsmetoder inom ramen för WordPress.
Med det sagt, tveka inte att lämna några frågor eller kommentarer i foderet nedan och jag ska sikta på att svara på var och en av dem.
