Share
Hvis du bare går med i serien, har vi diskutert emnet kode lukter, hvordan du refactor dem, og verktøy som er tilgjengelige for å hjelpe oss å automatisere noen av monotonyen som følger med, spesielt innen PHP programmering.
Hvis du ikke har lest de to første artiklene i serien, anbefaler jeg det som de dekker noen forutsetninger vi har på plass før du går videre med resten av artikkelen.
Artikklene er:
Kort sagt, artiklene ovenfor vil introdusere begrepet kode lukter, som vi har definert som følgende:
[A] kode lukt, også kjent som en dårlig lukt, i programmeringskode, refererer til ethvert symptom i kildekoden til et program som muligens indikerer et dypere problem.
Og jeg vil gå deg gjennom trinnene som trengs for å installere PHP CodeSniffer på maskinen din.
Men hvis du har gjort det så langt, antar jeg at du er en WordPress-utvikler, og du er interessert i å få PHP CodeSniffer konfigurert slik at det kan snuse ut eventuelle problemer i koden din som det gjelder WordPress Coding Standards.
Det er bra! Fordi i resten av denne artikkelen, er det akkurat det vi skal dekke.
Dette burde være en veldig kort liste. Hvis du har fulgt med serien opp til dette punktet, må du ha:
Alt dette er dekket i detalj gjennom de forrige artiklene i serien, men hvis du har kommet så langt og er komfortabel med kommandolinjen, så bør dette være en cinch i forhold til det vi har gjort så langt.
Med alt det sagt, la oss komme i gang.
Finn først reglene for WordPress Coding Standards på GitHub. De er enkle å finne.
Du kan lese alt om prosjektets detaljer fra prosjektsiden, men det viktigste jeg vil dele er som følger:
Dette prosjektet er en samling av PHP_CodeSniffer regler (sniffs) for å validere kode utviklet for WordPress. Det sikrer kodekvalitet og overholdelse av kodingskonvensjoner, spesielt de offisielle WordPress-kodningsstandardene.
Jeg vil gjerne ta hensyn til uttrykket som dette refererer til "offisielle WordPress Coding Standards." Merk at disse reglene er basert på WordPress Coding Standards. Det vil si, du kan ikke offisielt referere dem.
Hvis du ønsker å finne en måte å se gjennom reglene som WordPress definerer, sjekk ut denne artikkelen i Codex. Det er lett å følge, lett å lese, men mye å huske. Heldigvis har vi regelen sett koblet over.
Det viktige å merke seg er at selv om du ikke er kjent med reglene, vil CodeSniffer finne problemene med koden din og vil varsle deg om hva du trenger å fikse. Selv om du ikke trenger å lese Codex-artikkelen, kan det noen ganger hjelpe til med å identifisere hva som trengs basert på feilene eller advarslene som snifferen genererer.
Forutsatt at du har riktig installert PHP CodeSniffer, la oss legge til WordPress-reglene til programvaren. For denne opplæringen skal jeg gjøre alt via kommandolinjen for å være så plattformig agnostisk som mulig. Jeg gir noen ord om IDEer og regler på slutten av serien.
Åpne terminalen din og naviger til hvor du har din kopi av PHP CodeSniffer installert. Hvis du har fulgt sammen med denne serien av opplæringsprogrammer, husker du sannsynligvis at vi har en composer.json fil som vil trekke dette inn for oss. Hvis ikke, husk å lage composer.json i roten til prosjektet ditt og legg til dette i filen:
"krever": "squizlabs / php_codesniffer": "2. *"
Når du er ferdig, løp $ komponent oppdatering fra terminalen din, og du har alt du trenger for å komme i gang. For å bekrefte installasjonen, kjør følgende kommando:
$ leverandør / bin / phpcs - versjon
Og du bør se noe som følgende utgang:
PHP_CodeSniffer versjon 2.6.0 (stabil) av Squiz (http://www.squiz.net)
Perfekt. Deretter la vi installere WordPress-reglene. Siden vi bruker Composer (og vil fortsette å gjøre det), er dette veldig enkelt å gjøre.
Kjør følgende kommando fra rotkatalogen av prosjektet ditt:
komponent create-project wp-coding-standards / wpcs: dev-master -no-dev
Merk at du kan bli bedt om følgende spørsmål:
Vil du fjerne den eksisterende VCS-historien (.git, .svn ...)? [Y, n]?
Hvis du vet hva du gjør, så vær så snill å gå videre og velg 'n'; ellers vil du være i orden å trykke 'y'.
Nå som PHP CodeSniffer er installert, og WordPress-reglene er installert, må vi sørge for at PHP CodeSniffer er klar over vår nye regelsett. For å gjøre dette må vi skrive inn følgende kommando i kommandolinjen.
Fra roten til prosjektkatalogen din, skriv inn følgende kommando:
$ leverandør / bin / phpcs --config-set installed_paths wpcs
For å bekrefte at de nye reglene er lagt til, kan vi spørre PHP CodeSniffer for å rapportere til oss de settene regler som den har tilgjengelig for øyeblikket. I terminalen skriver du inn følgende kommando:
$ leverandør / bin / phpcs -i
Og du bør se følgende utgang (eller noe veldig lignende):
De installerte kodingsstandardene er MySource, PEAR, PHPCS, PSR1, PSR2, Squiz, Zend, WordPress, WordPress-Core, WordPress-Docs, WordPress-Extra og WordPress-VIP
Legg merke til i linjen ovenfor at vi har flere sett med regler angående WordPress. Ganske pent, ikke sant? Selvfølgelig, la oss se hvordan dette stabler opp når vi kjører regelen sett mot en plugin som Hei Dolly.
Forutsatt at du jobber ut av en katalog som inneholder et WordPress-plugin, kan du hoppe over følgende trinn. Hvis du derimot gjør det ikke ha en kopi av et WordPress-skript, en fil, et tema eller et plugin som er installert i prosjektkatalogen, fortsett og kopi en til prosjektkatalogen nå.
Som nevnt, vil vi teste Hei Dolly plugg inn.
For å kjøre PHP CodeSniffer med WordPress-reglene mot filene i plugin-katalogen, skriv inn følgende kommando i Terminal:
$ leverandør / bin / phpcs --standard = WordPress hello-dolly
Dette vil resultere i produksjon som skal svare til det du ser her:
FIL: /Users/tommcfarlin/Desktop/tutsplus_demo/hello-dolly/hello.php -------------------------------- -------------------------------------- Funnet 14 feil som påvirker 14 linjer ------ -------------------------------------------------- -------------- 2 | FEIL | Mangler kort beskrivelse i doc kommentar 5 | FEIL | Det må være nøyaktig en tom linje etter filen | | kommentar 6 | FEIL | Tom linje nødvendig før blokkkommentar 15 | FEIL | Du må bruke "/ **" stilkommentarer for en funksjon | | kommentar 46 | FEIL | Inline kommentarer må slutte i fullstopp, utrop | | merker eller spørsmålstegn 49 | FEIL | Inline kommentarer må slutte i fullstopp, utrop | | merker eller spørsmålstegn 53 | FEIL | Inline kommentarer må slutte i fullstopp, utrop | | merker eller spørsmålstegn 54 | FEIL | Du må bruke "/ **" stilkommentarer for en funksjon | | kommentar 56 | FEIL | Forventet neste ting å være en escaping-funksjon (se | | Codex for 'Data validering'), ikke '"$ valgt
"59 | FEIL | Inline kommentarer må slutte i fullstopp, utropstegn | | merker eller spørsmålstegn 62 | FEIL | Inline kommentarer må slutte i fullstopp, utropstegn | | merker eller spørsmålstegn 63 | FEIL | Du må bruk "/ **" stil kommentarer til en funksjon | | kommentar 64 | FEIL | Inline kommentarer må slutte i fullstopp, utropstegn | | merker eller spørsmålstegn 67 | FEIL | Forventet neste ting å være en rømmende funksjon (se | | Codex for 'Data Validation'), ikke '"| | ' ----------------------------------------------------------------------
Selvfølgelig kan noen av disse tingene endres avhengig av når du leser denne opplæringen.
Feilene bør være ganske tydelige med hensyn til hva som må løses:
Merk at selv om dette er feil eller advarsler, vil koden åpenbart fortsatt fungere. Men la oss trekke dette gjennom ende til slutt og se hvordan det er å fikse et plugin, uten tvil den mest populære siden det kommer med hver installasjon av WordPress, og se forskjellene i kvaliteten på koden.
Merk pluginet, før vi begynner å jobbe med det, inneholder følgende kildekode:
Accentsconagua
Hei, Dolly øverst til høyre på admin-skjermbildet på hver side. Forfatter: Matt Mullenweg Versjon: 1.6 Forfatter URI: http://ma.tt/ * / function hello_dolly_get_lyric () / ** Dette er teksten til Hello Dolly * / $ lyrics = "Hei, Dolly Well, hei, Dolly It's så hyggelig å ha deg tilbake der du hører Du ser deg, Dolly, jeg kan fortelle, Dolly Du er fortsatt lyser, du er fortsatt kråkig. Du er fortsatt god. Vi føler at rommet er swayin. Mens bandets playin "En av dine gamle favorittsanger fra vei tilbake når Så, ta henne inn i båndet, fellas Finn henne et tomt skudd, fellas Dolly'll aldri gå bort igjen Hei, Dolly Nå, hei Dolly Det er så hyggelig å få deg tilbake der du tilhører Du ser ut, hov, Dolly, jeg kan fortelle, Dolly Du er fortsatt glød, du er fortsatt krånn. Du er fortsatt god. Vi føler at rommet er swayin. Mens bandet spiller 'En av dine gamle favoritt sanger fra vei tilbake når Golly, ge, fellas Finn henne et ledig kne, fellas Dolly'll aldri gå bort Dolly'll aldri gå bort Dolly'll aldri gå bort igjen "; // Her deler vi det i linjer $ lyrics = explode ("\ n", $ lyrics); // Og velg deretter en linjeskift wptexturize ($ lyrics [mt_rand (0, count ($ lyrics) - 1)]); // Dette ekko bare den valgte linjen, vi plasserer den senere funksjonen hello_dolly () $ selected = hello_dolly_get_lyric (); ekko "$ valgt
"; // Nå setter vi den funksjonen opp for å utføre når admin_notices-handlingen heter add_action ('admin_notices', 'hallo_dolly'); // Vi trenger litt CSS for å plassere avsnittet funksjonen dolly_css () // Dette sørger for at at posisjoneringen også er bra for høyre til venstre språk $ x = is_rtl ()? 'left': 'right'; ekko " "; add_action ('admin_head', 'dolly_css');?> Det bør være relativt enkelt å følge da det bare bruker noen få grunnleggende PHP-funksjoner, og Matt har gjort en god jobb med å kommentere koden.
Men gitt de 14 feilene som CodeSniffer fant, la oss refactor plugin. Med tanke på feilene de presenterte og hva de forventer å se, la oss ta opp hver av dem.
Når det er gjort, må pluginet se ut som følgende:
Hei, Dolly øverst til høyre på admin-skjermbildet på hver side. * Forfatter: Matt Mullenweg * Versjon: 1.6 * Forfatter URI: http://ma.tt/ * / / ** * Definerer teksten for 'Hello Dolly'. * * @return string En tilfeldig linje fra tekstene til sangen. * / funksjon hello_dolly_get_lyric () / ** Dette er teksten til Hello Dolly * / $ lyrics = "Hei, Dolly Well, hei, Dolly. Det er så hyggelig å ha deg tilbake der du hører. Du er kvelende, Dolly I kan du fortelle, Dolly Du er fortsatt glød, du er fortsatt kråken. Du er fortsatt god. Vi føler at rommet er swayin. Mens bandet er playin 'En av dine gamle favorittsanger fra veien tilbake når Så, ta henne inn , fellas Finn henne et tomt skudd, fellas Dolly'll aldri gå bort igjen Hei, Dolly Nå, hei Dolly Det er så hyggelig å ha deg tilbake der du hører Du ser ut, hovner, Dolly, jeg kan fortelle, Dolly Du er Fortsatt glowin ', du er fortsatt kråkig. Du er fortsatt god. Vi føler at rommet er swayin. Mens bandets spill er "En av dine gamle favorittsanger fra veien tilbake når Golly, ge, fellas. Finn henne et ledig kne, fellas Dolly'll aldri gå bort Dolly'll aldri gå vekk Dolly'll aldri gå bort igjen "; // Her deler vi det i linjer. $ lyrics = explode ("\ n", $ lyrics); // Og velg deretter en linje. returnere wptexturize ($ lyrics [mt_rand (0, count ($ lyrics) - 1)]); add_action ('admin_notices', 'hello_dolly'); / ** * Dette ekko bare den valgte linjen, vi plasserer den senere. Denne funksjonen er * satt opp til å utføres når admin_notices-handlingen kalles. * / funksjon hello_dolly () $ selected = hello_dolly_get_lyric (); ekko "$ valgt
"; // WPCS: XSS OK. Add_action ('admin_head', 'dolly_css'); / ** * Legg til noen CSS for å plassere avsnittet. * / Funksjon dolly_css () / ** * Dette sørger for at posisjoneringen er også bra for høyre til venstre språk. * / $ x = is_rtl ()? 'left': 'right'; ekko " "; // WPCS: XSS OK. Legg merke til at plugin fortsetter å fungere og koden er litt renere. Til slutt, la oss bekrefte at dette passerer PHP CodeSniffer-testen. La oss kjøre koden som vi brukte ovenfor, for å først vurdere pluggen.
$ leverandør / bin / phpcs --standard = WordPress hello-dolly
Og utgangen som vi ser:
Skyhopper5: tutsplus_demo tommcfarlin $
Nøyaktig: Det skal ikke være noe utgang. I stedet bør det være en retur til standard kommandoprompt.
Utmerket. Pluggen har blitt tatt opp til standard. Det er derfor å ha en kode sniffer er så verdifull: Det finner feilene i koden din basert på reglene du definerer og deretter rapporterer eventuelle feil som kan eksistere.
I siste instans sikrer dette at du slipper den høyeste kvalitetskoden til et produksjonsnivå. Nå betyr dette ikke at du bør unngå enhetstesting eller andre typer testing, og det betyr heller ikke at det finnes feil. Det betyr bare at koden din er opp til en høy standard.
Og med det konkluderer vi serien om bruk av PHP CodeSniffer. Husk at gjennom hele serien har vi dekket ideen om kode lukter, hvordan å refactor dem, og hvilke verktøy er tilgjengelige for oss når de jobber med PHP applikasjoner.
I denne artikkelen så vi hvordan vi kan bruke et gitt sett med regler for WordPress Coding Standards for å evaluere vår kode mens du jobber med et nytt eller et eksisterende prosjekt. Merk at noen IDEer støtter muligheten til å utføre reglene mens du skriver kode.
Selv om det er utenfor omfanget av denne bestemte opplæringen, kan du finne ressurser til dette på forskjellige steder over hele nettet. Bare søk etter IDE etter navn, fastslå støtten til PHP CodeSniffer, og sørg for å installere WordPress-reglene som vi har beskrevet i denne opplæringen.
Hvis du likte denne artikkelen eller denne serien, kan du være interessert i å sjekke ut andre ting jeg har skrevet både på min profilside eller på bloggen min. Du kan også følge meg på Twitter på @tommcfarlin hvor jeg ofte snakker om og deler ulike programvareutviklingspraksis i sammenheng med WordPress.
Med det sagt, ikke nøl med å legge igjen noen spørsmål eller kommentarer i feedet nedenfor, og jeg vil sikte på å svare på hver av dem.
