Share
I den første artikkelen i denne serien definerte vi kode lukter og så på noen få eksempler på hva de er og hvordan vi kan refactor dem, slik at kvaliteten på koden er forbedret. Minnes:
[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.
Til slutt arbeider vi for å implementere WordPress-spesifikke kode sniffing regler, men før vi gjør det er det viktig å gjøre deg kjent med PHP CodeSniffer.
I denne artikkelen skal vi se på hva PHP CodeSniffer er, hvordan du installerer det, hvordan du kjører det mot et eksempelskript, og hvordan du refactor skriver scriptet. Da ser vi på hvordan vi skal gå videre til WordPress-spesifikk kode.
Hvis du har et lokalt utviklingsmiljø satt opp, så flott; Hvis ikke, det er greit. Jeg gir noen koblinger som får deg til å løpe raskt.
Med det sagt, la oss komme i gang.
Før du går i gang, er det viktig at du har en slags lokalt utviklingsmiljø, selv om dette bare inneholder en kopi av PHP-tolken.
Merk at hvis du kjører en variant av Linux eller OS X, er det en sjanse for at du allerede har PHP installert. Hvis du gjør det, trenger du ikke å bekymre deg for noe annet i denne delen. For å finne ut om du har PHP installert, kjør følgende kommando på kommandolinjen:
$ php -v
Du bør se noe som følger (selv om produksjonen din kan være forskjellig basert på versjonen av PHP du har valgt å kjøre):
PHP 5.6.10 (cli) (bygget: 6. juli 2015 14:28:54) Copyright (c) 1997-2015 PHP-gruppen Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
Hvis du er mer avansert og har flere kopier av prosjektet installert, kan du kjøre:
$ som php
Og du bør se noe slikt:
/Applications/MAMP/bin/php/php5.6.10/bin/php
Selv om produksjonen din vil variere basert på hvor din kopi av PHP er installert.
Selv om denne serien er rettet primært mot nybegynnere, kan det være noen av dere som er komfortable med å laste ned en kopi av PHP og installere den på systemet ditt. Hvis dette er deg, ta en kopi av PHP fra prosjektets hjemmeside, installer den, og gå tilbake til denne opplæringen.
Hvis det derimot er nytt for deg, kan du velge å bruke en av installatørene for operativsystemet på PHP-hjemmesiden som er koblet over eller en av de angitte verktøyene nedenfor..
Alle disse pakkene har egne installatører og installerer PHP, MySQL og Apache. Som tidligere nevnt, er vi først og fremst opptatt av å ha en kopi av PHP tilgjengelig på vårt system.
Når disse er installert, kan du prøve å kjøre kommandoene nevnt i første del av denne delen (eller systemets ekvivalent), og du bør se lignende utdata.
Hvis du ikke gjør det, må du sannsynligvis legge til banen til PHP til dine miljøvariabler. Dette er utenfor omfanget av denne opplæringen, så vennligst se dokumentasjonen for versjonen av prosjektet du installerte.
Med PHP nå installert, er vi klare til å komme i gang med å fange og rydde opp våre kode lukter.
Du finner den offisielle PHP CodeSniffer-programvaren på GitHub.
Fra prosjektets dokumentasjon:
PHP_CodeSniffer er et sett med to PHP-skript; hovedphpcsskript som tilkaster PHP, JavaScript og CSS-filer for å oppdage brudd på en definert kodingsstandard, og et sekundphpcbfSkript for automatisk korrigering av kodende standardbrudd. PHP_CodeSniffer er et viktig utviklingsverktøy som sikrer at koden forblir ren og konsistent.
Hvis du aldri har sett noe slikt før, høres det veldig fint ut, ikke sant? Jeg mener, det er et verktøy som er ment å bidra til at et visst kvalitetsnivå finnes i koden din!
Selv om prosjektet nevner språk som CSS og JavaScript, er vi fokusert på PHP i denne serien. Dette betyr ikke at det ikke er viktig å sjekke kvaliteten på de aktuelle språkfilene i prosjektene dine.
Så godt som det høres, reiser det fremdeles spørsmålene: Hvordan installerer vi programvaren, og hvordan begynner vi å sjekke vår kode?
La oss svare på begge disse spørsmålene nå.
Hvis du skulle utføre et Google-søk for hvordan du installerer PHP CodeSniffer, vil du sannsynligvis ende opp med en rekke resultater, hvorav mange vil inkludere å bruke noe som heter Pear.
Pære var en gang de facto-pakkedistribusjonssystemet for PHP-biblioteker, og selv om mange pakker fortsatt er tilgjengelige gjennom programvaren, blir den også pensjonert fra andre populære pakker (for eksempel PHPUnit).
Av denne grunn anbefaler jeg ofte å bruke andre metoder for installasjon når de er tilgjengelige. Dette inkluderer bruk av verktøy som Composer, som er uten tvil den mest populære dependence management software for PHP.
Hvis du aldri har brukt Composer før, ikke bekymre deg. Jeg gir alle trinnene du trenger for å få PHP CodeSniffer oppe og kjører på maskinen din med Composer og med minimal arbeid. Hvis du er interessert i å lære mer, har vi ganske mange opplæringsprogrammer om hvordan du bruker Komponist, så vær så snill å sjekke dem ut.
Før vi installerer PHP CodeSniffer, må vi faktisk installere Komponist. Heldigvis er det veldig enkelt å gjøre det når du har PHP oppe og kjører på din lokale maskin.
For å installere Komponist, kan du laste ned denne filen og deretter utføre følgende kommando på kommandolinjen, uansett hvor du lastet ned komponentinstallatøren:
$ php composer-setup.php --install-dir = bin - filnavn = komponist
Et notat fra installasjonsinstruksen til komponisten:
Du kan installere Komponist til en bestemt katalog ved å bruke--install-diralternativ og i tillegg (re) navnet det også med--filnavnalternativ.
For mer informasjon, vennligst henvis til nedlastingsanvisningene eller se hele prosjektet på GitHub.
Når den er installert, kan du nå bruke Komponist til å installere tredjepartsavhengigheter, for eksempel PHP CodeSniffer, i prosjektene dine. Legg merke til hvor du har installert din kopi av Komponist, skjønt. Du må referere til det når du kjører det, siden vi skal kjøre det fra kommandolinjen.
Uansett, la oss gå videre og opprette en katalog der vi skal kjøre våre PHP-skript. Selv om vi ikke vil ha noe i denne katalogen ennå, må vi opprette en fil som heter composer.json.
Jeg skal ringe til katalogen min tutsplus-demo, og jeg vil inkludere min Composer-fil i den katalogen for å komme i gang.
Når du har laget filen, legger du følgende kode i JSON-filen:
"krever": "squizlabs / php_codesniffer": "2. *"
Kort sagt, dette forteller Komponist å installere PHP CodeSniffer når du utfører riktig kommando. Legg merke til at krever direktivet gjør følgende:
Lister pakker som kreves av denne pakken. Pakken vil ikke bli installert med mindre disse kravene er oppfylt.
Du kan lese mer om Composer-skjemaet i dokumentasjonen.
Når Komponist er installert og når du har din composer.json filen ser ut som koden ovenfor, er det på tide å faktisk installere PHP CodeSniffer. Fra kommandolinjen, utsted følgende kommando:
$ komponent oppdatering
Merk at dette er basert på ideen Composer er tilgjengelig offentlig på systemet. Hvis ikke, kan du kjøre den ved å skrive hele banen til den installerte filen, eller du kan legge den til dine miljøvariabler og deretter starte terminalsesjonen for å laste om variablene.
Når Composer er ferdig med å jobbe, bør du se noe slikt:
Og din tutsplus-kode katalogen skal nå se slik ut:
Legg merke til at du har en leverandørkatalog. Dette betyr at Composer installert riktig PHP CodeSniffer. På dette tidspunktet er vi klare til å evaluere vår PHP-kode.
La oss først ta et eksempelskript. Den vi skal se på, finnes i dette svaret på Stack Overflow.
Lag en fil i din tutsplus-demo katalog og navn den sample.php. Kontroller at filen inneholder følgende innhold:
Lagre arbeidet ditt. Deretter kan vi kjøre PHP CodeSniffer fra kommandolinjen og få den til å evaluere koden i skriptet ovenfor ved hjelp av standard sett med regler.
Fra din terminal, skriv inn følgende kommando:
$ leverandør / bin / phpcs sample.php
Dette skal generere utdata som inneholder følgende:
Skyhopper5: tutsplus-demo tommcfarlin $ leverandør / bin / phpcs sample.php FIL: /Users/tommcfarlin/Desktop/tutsplus-demo/sample.php ------------------- -------------------------------------------------- - Funnet 4 feil som påvirker 4 linjer ------------------------------------------- --------------------------- 2 | FEIL | [] Manglende fil doc kommentare 5 | FEIL | [x] Ingen plass funnet etter komma i funksjonsanrop 7 | FEIL | [] Forventet "hvis (...) \ n"; funnet "hvis (...) \ n" 9 | FEIL | [] Forventet "hvis (...) \ n"; funnet "hvis (...) \ n" ---------------------------------------- ------------------------------ PHPCBF CAN FIX DE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY ----------- -------------------------------------------------- --------- Tid: 46ms; Minne: 3,5Mb Skyhopper5: tutsplus-demo tommcfarlin $
Legg merke til at det fant fire feil. Den første kolonnen forteller deg hvilken linje feilen er på, den andre kolonnen angir at det er en feil (i motsetning til en advarsel), og resten forteller deg hva det forventet å se versus det det egentlig så.
Så la oss rydde opp filen basert på disse feilene. Generelt må vi gjøre følgende:
Accentsconagua
hvis uttalelser i skriptet.Sluttresultatet ville se slik ut:
* @license http://opensource.org/licenses/gpl-license.php GNU Public License * @link http://is.gd/dq0DhO * @since 1.0.0 * / $ target_dir = "opplastinger /"; $ target_file = $ target_dir. basename ($ _ FILES [ "fileToUpload"] [ "navn"]); $ uploadOk = 1; $ imageFileType = stiinfo ($ target_file, PATHINFO_EXTENSION); // Sjekk om bildefil er et faktisk bilde eller falsk bilde hvis (isset ($ _ POST ["submit"])) $ check = getimagesize ($ _ FILES ["fileToUpload"] ["tmp_name"]); hvis ($ sjekk! == false) echo "Filen er et bilde -". $ sjekk ["mime"]. ""; $ uploadOk = 1; else echo "Filen er ikke et bilde."; $ uploadOk = 0; ?>
Kjør deretter skriptet igjen, og du bør ikke få noen utdata. Det vil si at du bør bli presentert med standard kommandoprompt. Noen ganger betyr dette at noe er ødelagt, men i dette tilfellet betyr det at alt går som forventet
Ikke dårlig, ikke sant?
Forestill deg nå hva dette kan gjøre for større kodebaser og skript som du jobber med på daglig basis.
Like viktig som det er å evaluere vår kode, for å unngå kode lukter, og å sikte på høyeste kvalitet, er verktøy som PHP CodeSniffer ikke ment å bli brukt som krykker. Det betyr at vi ikke har unnskyldning for å skrive dårlig kode fordi et annet verktøy vil fange det.
Fordi det ikke alltid vil gjøre det.
I stedet er dette ment som et annet pass av sorter. Det vil si at det er ment å fange ting som vi kanskje savner når du skriver kode første, andre eller niende gang. Den fine tingen om dette programmet er at du kan laste forskjellige regler til PHP CodeSniffer, avhengig av miljø, rammeverk eller bibliotek du jobber med..
Og det er akkurat det vi skal gjøre med WordPress i neste artikkel.
Når det gjelder innledende materiale, har vi dekket en del grunnlag i denne opplæringen. Det vil si at vi har sett på å sette opp et grunnleggende utviklingsmiljø på vår lokale maskin som inkluderer PHP.
Deretter har vi tatt en titt på Komponist og hvordan den skal installeres på vårt system. Vi har skrevet vår første Composer-fil for å hente avhengigheter, nemlig PHP CodeSniffer, og vi har til og med vurdert og korrigert resultater som ble gitt til oss av programvaren.
Hvis du primært er en PHP-utvikler, håper jeg de to første artiklene i serien har vært nyttig, men hvis du er en WordPress-utvikler, så har vi litt mer til å dekke.
I den endelige artikkelen i serien, skal vi gjøre oppmerksomheten vår til WordPress. Fordi det har sitt eget sett med kodingsstandarder, skal vi se på hvordan du laster disse reglene inn i PHP CodeSniffer, og deretter vurderer plugins, tema kode og så videre for å få en ide om hvordan du bruker dette i vår dag- Dagens arbeid i våre WordPress-prosjekter.
Før vi går videre til neste artikkel, vurder koden ovenfor og sørg for at du har PHP og PHP CodeSniffer installert, og at du er kjent med hvordan det fungerer, siden vi skal binde alt dette sammen.
Til slutt kan du se gjennom alle mine kurs og opplæringsprogrammer på min profilside, og du kan følge meg på bloggen min og / eller Twitter på @tommcfarlin hvor jeg snakker om ulike programvareutviklingspraksis, spesielt i sammenheng med WordPress.
Ikke nøl med å legge igjen noen spørsmål eller kommentarer i feedet under, og jeg vil sikte på å svare på hver av dem.
