PSR-Duh!

I en tidligere leksjon her på Nettuts + lærer du om PSR; Denne artikkelen beskriver imidlertid ikke prosessen med å integrere den kodende stilen i prosjektene dine. La oss fikse det!

Merk: Denne artikkelen antar at du har lest PSR-Huh ?, og forstå hva PSR refererer til. La oss begynne med den første standarden: PSR-0.

PSR-0 - Autoloading Standard

PHPCS-pluginet er det mest nyttige verktøyet jeg har brukt.

Tidligere har vi inkludert PHP-filer på en av to måter:

• Bruk en gigantisk blokk med inkludere uttalelser øverst på hver fil.
• Liste alle inneholder i en enkelt fil og inkluderer den samme filen i prosjektet.

Det er fordeler og ulemper for begge disse tilnærmingene, men jeg tror vi kan alle være enige om at ingen av dem er optimale eller moderne løsninger. PHP5 introduserte begrepet autoloading-filer basert på klassenavnene deres; så, PSR-0 tar sikte på å holde filnavnene konsekvente.

Navnegrupper har ingenting å gjøre med filnavn eller autolading; Du kan teknisk deklarere forskjellige navneområder i samme fil. For eksempel er følgende kode helt gyldig.

  
Det er to Hallo klasser i denne enkeltfilen, men de ligger innenfor forskjellige navneområder. De to siste linjene i denne koden befinner seg i Hallo() klasser på deres respektive navneområder. De første utgangene "Nettuts +", mens den andre ekkoet "Gabriel." Navnegrupper lar deg skille mellom to klasser med samme navn, akkurat som du kanskje er vant til med mapper på skrivebordet. PSR-0-standarden utnytter bare fordelene med navneområder, noe som gjør det enkelt å autoload klassene dine. Ved å navngi filene dine, kan du opprette en funksjon som automatisk finner de nødvendige filene.
 
For å være PSR-1-kompatibel må du også følge PSR-0.
 
Husk å lese hele standarden, men for å oppsummere:
 
 
Hver klasse må være navngitt med prosjektets navn (eller skaperen).
 
Underscores i klassens navn skal konverteres til katalog separatorer.
 
Filene må ha .php forlengelse.
 
 
For eksempel, en klassen referanse til:
 
 \ Nettuts \ Database \ SQL_Postgres
 
hvis følgende PSR-0 skal oversettes til denne banen:
 
 ./Nettuts/Database/SQL/Postgres.php
 
Hvordan kan vi implementere denne funksjonaliteten? Den mest åpenbare løsningen er å bruke Komponist, som leveres med en PSR-0-kompatibel autoloader. Hvis du bruker Komponist i prosjektene dine (og du burde), så velg autoloader, i stedet for å skrive din egen.
 
En PSR-0-kompatibel laster lar deg spesifisere en grunnbane, informere lasteren hvilken katalog som skal sees inn først. For å komme i gang, opprett en enkel composer.json fil som inneholder følgende JSON:
 
 "autoload": "psr-0": "Nettuts": "./", "Gmanricks": "leverandør /"
 
Denne JSON-filen forteller Komponist at vi vil bruke PSR-0-standarden til å autoload alle Nettuts-namespaced-filer med gjeldende katalog (rotmappen) som grunnveien. Vi ønsker også å autoload alle klasser med Gmanricks navneområde, i forhold til selger mappe (f.eks. ./ Leverandør / Gmanricks / Classname).
 
Skriv nå "komponent installasjon"å generere autoload-klassene, eller"komponist dump-autoload"på senere endringer for å regenerere autoload-klassene. Ikke glem å kreve autoloader et sted tidlig i prosjektet ditt.
 
  
Komponist er det beste alternativet, men det kan være scenarier når du vil ha en liten, enkel autoloader. PHP-FIG gir en sample autoloader som du kan bruke:
 
 funksjon __autoload ($ className) $ className = ltrim ($ className, '\\'); $ fileName = "; $ namespace ="; hvis ($ lastNsPos = strrpos ($ className, '\\')) $ namespace = substr ($ className, 0, $ lastNsPos); $ className = substr ($ className, $ lastNsPos + 1); $ fileName = str_replace ('\\', DIRECTORY_SEPARATOR, $ namespace). DIRECTORY_SEPARATOR;  $ fileName. = str_replace ('_', DIRECTORY_SEPARATOR, $ className). 'Php'; krever $ fileName; 
 
Det er viktig å merke seg at denne lasteren forsøker å laste alle klasser ved hjelp av PSR-standarden i gjeldende katalog.
 
Nå som vi er vellykket autoloading klasser, la oss gå videre til neste standard: den grunnleggende kodningsstandarden.
 
 
PSR-1 - Den grunnleggende kodningsstandarden
 
PSR-1 definerer generelle retningslinjer for koding, som kan deles i to deler.
 
Naming Conventions
 
Navnegrupper lar deg skille mellom to klasser med samme navn.
 
Som med hvilket som helst programmeringsspråk, etterfølgende navngivningskonvensjoner, gjør koden din lettere å lese og vedlikeholde. Her er noen regler å følge:
 
 
Klassenavn bruker PascalCase.
 
Metode navn skal være i Camelcase.
 
Konstanter krever alle store bokstaver, skiller hvert ord med et understreke (f.eks. CONSTANT_VARIABLE).
 
 
Kodekonvensjoner:
 
Det er mer til det enn navngivende konvensjoner; Følg også disse retningslinjene:
 
 
Bruk bare  eller  i koden din. Ikke lukk PHP i en klasse.
 
Filer skal enten deklarere symboler eller bruke dem.
 
Filene må være i UTF-8-format uten BOM for PHP-kode
 
 
De fleste av disse er selvforklarende, men midtkonvensjonen er litt forvirrende. Det forutsetter i hovedsak at enhver deklarasjon, det være seg funksjoner, klasser osv., Skal skilles i egne filer. Dette fremmer ikke bare gode metoder som kode-gjenbruk og separasjon, men det holder koden ren og ren.
 
Det er verdt å nevne at hver PSR-standard bygger på den forrige PSR-standarden. Som sådan, for å være PSR-1-kompatibel, må du også følge PSR-0. Ved å følge disse to standardene, vil koden din bli riktig navngitt og autoloaded. Det er egentlig ingen grunn til ikke å følge dem.
 
Ja, noen utviklere klager på PSR og foretrekker å følge andre konvensjoner, men ved å følge denne standarden kan du dele kode med alle uten å bekymre deg for konsistensen. Når det er sagt, tvinger ingen hånden din her. Det er bare en anbefalt retningslinje.
 
Den neste standarden, PSR-2, dykker inn i detaljene for hvordan du skal strukturere koden din.
 
 
PSR-2 - Advanced Coding Standard
 
PSR-2 dykker inn i detaljene for hvordan du skal strukturere koden din.
 
Deretter kommer vi til den ene standarden som PHP-utviklere sliter med mest. Faktisk er det grunnen til at jeg valgte å skrive denne artikkelen.
 
PSR-2 definerer mange regler, hvorav mange er oppført nedenfor:
 
 
Fire mellomrom skal brukes i stedet for faner.
 
Den ideelle linjelengden skal være under 80 tegn, men en myk grense på 120 tegn skal pålegges på alle linjer.
 
Det skal være en tom linje under namespace og bruk erklæringer.
 
En metode eller klasse åpningsbøyle må være på egen linje.
 
En metode eller klasse 'lukkebøyle må gå på linjen umiddelbart etter kroppen.
 
Alle egenskaper og metoder krever et synlighetsnivå.
 
'abstrakt'/'endelig'søkeord skal vises før synligheten mens'statisk'går etter.
 
Kontroll struktur søkeord må følges av ett mellomrom.
 
En kontrollerklæring åpningsbrakett skal vises på samme linje som uttalelsen.
 
 
 
 Husk å se hele spesifikasjonen for en fullstendig oversikt. 
 
 
PSR-2 er like viktig som PSR-1 (og PSR-0). Den har til hensikt å gjøre kode enkel å lese og vedlikeholde. Men som de sier, "Djevelen er i detaljene."Det er mange detaljer å huske, noe som kan være vanskelig hvis programmeringsvanene dine avviger fra hva standarden definerer. Heldigvis, hvis du er om bord, er det verktøy som hjelper deg å holde fast i PSR-0, PSR-1 og PSR-2. Kanskje det beste verktøyet er Sublime Text-plugin, PHPCS.
 
 
PHPCS - PHP Code Sniffer
 
PHPCS-pluginet er det mest nyttige verktøyet jeg har brukt, når det gjelder å få kode i form. Det lar deg ikke bare sikre at koden din følger PSR-standardene, men det bruker også PHPs linter for å sjekke om syntaksfeil. Dette er en flott tidsbesparende Du trenger ikke lenger å bekymre deg for syntaksfeil når du taster koden din i nettleseren.
 
Installer pakken via Sublime Package Control (det kalles Phpcs), eller alternativt med Git, ved hjelp av følgende kommandoer:
 
 cd ~ / Bibliotek / Application \ Support / Sublime \ Tekst \ 2 / Pakker / git klon git: //github.com/benmatselby/sublime-phpcs.git Phpcs
 
Dette installerer pluginet, men du trenger noen avhengigheter før du kan konfigurere PHPCS. Igjen, den enkleste måten å installere dem på er med Komponist. Bla gjennom til en katalog av ditt valg og opprett en composer.json fil med følgende JSON:
 
 "navn": "Nettutvikler PHPCS Demo", "krever": "squizlabs / php_codesniffer": "*", "fabpot / php-cs-fixer": "*", "phpmd / phpmd": "*" 
 
Dette installerer de tre avhengighetene i gjeldende mappe. Åpne et terminalvindu til installasjonsstedet ditt og skriv inn komponent installasjon, og det vil laste ned de nødvendige pakkene.
 
Nå kan du konfigurere pluginet i Sublime Text. Naviger til 'Preferences'> 'Package Settings'> 'PHP Code Sniffer'> 'Innstillinger - Bruker'.
  
Pluggen trenger å vite hvor de tre avhengighetene er, samt standarden som vi vil at vår kode skal overholde:
 
 "standard": "PSR2", "-n": "", "phpcs_executable_path": "DEPENDENCY_PATH / leverandør / bin / phpcs", "phpmd_executable_path": "DEPENDENCY_PATH / leverandør / bin / phpmd "," php_cs_fixer_executable_path ":" DEPENDENCY_PATH / leverandør / bin / php-cs-fixer "
 
Disse innstillingene informerer PHPCS som vi vil ha til PSR2-standarden og gi hver avhengighets sti. Ikke glem å bytte ut DEPENDENCY_PATH med den faktiske banen din.
 
Start på nytt Sublime, og kodesnifferen vil skanne koden din når du lagrer PHP-filene dine.
  
Høyreklikk i redigereren vil også vise flere nye alternativer, for eksempel å slette feilmerker og forsøke å fikse de ikke-standardiserte problemene. Men vurderer at poenget med denne artikkelen er å få deg vant til standarden, foreslår jeg manuelt å fikse koden din og unngå automatisk fixer trekk.
 
 
Konklusjon
 
PSR-standardene ble opprettet slik at koden enkelt kunne gjenbrukes fra prosjekt til prosjekt, uten å ofre på kodeform konsistens. Mens de kan føle seg overveldende i begynnelsen, kan du bruke ideene og verktøyene fra denne artikkelen for å hjelpe deg med overgangen.
 
Å gjenta en siste gang: Ingen tvinger deg til å endre måten du kodes i PHP. Det er rett og slett en guide, opprinnelig ment for rammeinteroperabilitet. Når det er sagt, på Nettuts +, anser vi det som en god praksis å følge. Gjør nå ditt eget sinn! Hvis du har spørsmål, la oss høre dem nedenfor!



		
			
	   
	




Kode