Share
I denne serien har vi tatt et dypt dykk inn i WordPress Coding Standards for å få ordet ut om dem, forstå dem, og begynner å praktisere dem i vårt daglige arbeid.
Hvis du bare går med i serien, har vi hittil dekket følgende emner:
I denne artikkelen skal vi fortsette å bygge opp på innholdet i forrige artikkel: Spesielt skal vi ta en titt på brace-stil, vanlige uttrykk og nyanser av å jobbe med PHP-koder innenfor rammen av bygge WordPress-temaer, plugins og applikasjoner.
Gjennom hele denne serien er et av problemene vi har gjentatt om og om igjen, at kodingsstandardene bidrar til å gjøre koden mer lesbar, vedlikeholdsbar, og at de i siste instans skal få det til å se ut som en utvikler har skrevet koden.
Men en av de tingene vi ikke har snakket om, er hvorfor stil saker. Først, dette reiser spørsmålet: Hva er forskjellen mellom stil og kodingskonvensjoner?
Ærlig talt tror jeg at noen vil si at det ikke er noen forskjell - faktisk sier de at de er synonyme. Jeg er ikke nødvendigvis enig. Personlig, måten jeg alltid har sett på er at kodingsstandardene definere stilen til koden som blir skrevet. Kodningsstandarder er konvensjonene som vi stiler vår kode på.
Så med det sagt, la oss gjenoppta samtalen vår på kodingskonvensjoner ved å se på hvordan WordPress Coding Standards definerer bruken av braces.
Generelt sett er reglene enkle:
Disse prinsippene er ofte best demonstrert i kode. De to første er enkle:
// Single Line betingede eksempler hvis (condition1) do_work (); hvis (condition1) do_work (); ellers dont_do_work (); // Multiline conditionals hvis (condition1) do_work (); do_more_work (); annet dont_do_work (); seriously_be_lazy (); // Enkeltlinjeløkker (sant for do / mens, mens, for og foreach) mens (condition1) dont_stop_believing (); // Enkeltlinjeløkker (sant for do / mens, mens, for og foreach) mens (condition1) dont_stop_believing (); hold_on_to_that_feeling ();
Ingenting veldig komplisert, riktig?
Faktisk kan du se at jeg brukte metoder i blokkene ovenfor. Hvilket fører oss til vårt neste prinsipp: Hvis du har en altfor komplisert kropp på din betingede måte, vil det sannsynligvis bidra til å reflektere den betingede for lettere lesbarhet.
La oss ta en titt på et eksempel.
I dette eksemplet skal vi gjenta gjennom metadataene til den gjeldende brukeren, og hvis den nåværende brukerens metatast har substringen til "destroy:", sletter vi brukerens metatast.
Legg merke til i dette eksemplet at alt dette arbeidet gjøres i en betinget, i a for hver loop, og deretter i en annen betinget.
// Hvis betingelse1 er sant ... hvis (betingelse1) // ... får brukeren metadata for gjeldende bruker foreach (get_user_meta (wp_get_current_user () -> ID) som $ meta_key => $ meta_value) // Hvis brukeren har et ødelagt verdi sett, slett det. Dette betyr at de valgte ikke å slette en bruker. hvis (strstr ($ meta_key, 'destroy:')) delete_user_meta (wp_get_current_user () -> ID, $ meta_key);
Masse nestet kode, høyre?
Det er en rekke måter at dette kan refactored. Faktisk vil noen utviklere gå så langt som å ta hver blokk og trekke den inn i sin egen metode - det er ingenting galt med det heller.
Men for å demonstrere dette punktet, skal vi bare gi et nivå av abstraksjon: Vi skal ta sløyfen og det indre betinget, flytte det til en funksjon som aksepterer en bruker, og utfør deretter den opprinnelige handlingen.
// Hvis betingelse1 er sant ... hvis (betingelse1) process_user (wp_get_current_user ()); funksjon process_user ($ user) // Få brukeren å måle data for den nåværende brukeren foreach (get_user_meta ($ user-> ID) som $ meta_key => $ meta_value) // Hvis brukeren har en ødelagt verdi sett, slett det . Dette betyr at de valgte ikke å slette en bruker. hvis (strstr ($ meta_key, 'destroy:')) delete_user_meta ($ user-> ID, $ meta_key);
Som jeg sa, er dette et relativt enkelt eksempel, men poenget er fortsatt: Flytting av en stor blokk av en kode i sin egen, spesialiserte funksjon kan gå langt for å refactor den betingede slik at det er lettere å lese.
På dette punktet skal vi skifte gir litt og snakke kort om regulære uttrykk. Hvis du ikke er kjent med vanlige uttrykk, bare vet at de er kraftige måter å utføre tegn eller streng matching på. Du kan lese mye mer om dem på Wikipedia.
På et tidspunkt i WordPress-utviklingskarrieren kommer du sannsynligvis til å møte dem - enten i kjernekoden, koden for tema eller plugin, eller til og med at de trenger å utføre en handling i ditt eget prosjekt.
Heldigvis tilbyr PHP noen virkelig enkle, virkelig kraftige funksjoner for bruk av vanlige uttrykk i koden din; Det er imidlertid riktig og feilaktig bruk av dem når det gjelder å jobbe med dem i WordPress.
Her er de generelle reglene:
Accentsconagua
preg funksjoner som PHP tilbyr\ e bytte som tilbys av PHP - bruk preg_replace_callback i stedet.For de som er nysgjerrige, finnes det en rekke funksjoner som er tilgjengelige.
For eksempel anbefaler jeg å bli kjent med:
preg_replacepreg_matchpreg_match_allEndelig, preg_replace_callback er en måte å ringe til en funksjon når et vanlig uttrykk har funnet en kamp.
Åpenbart er reglene for vanlige uttrykk i WordPress enkle - det er mer et spørsmål om å kjenne funksjonene du har bør bruk og hva du ikke bør bruke, og hvordan du skal bruke dem i ditt daglige arbeid.
Den siste tingen å dekke i denne artikkelen er betydningen av hvordan du bruker PHP-koder i PHP-filene som utgjør prosjektet ditt. Heldigvis er det en veldig enkel tommelfingerregel for denne spesielle situasjonen:
Først og fremst betyr dette at du aldri skal åpne en fil eller en inline PHP-setning med eller med . Naturligvis bør alle inline PHP-setninger fortsatt avsluttes med ?> avsluttende tag.
Nå er dette neste emnet litt av en avvik fra kodningsstandardene, i hvert fall på tidspunktet for denne skrivingen, blir det en vanligere praksis å la den avsluttende koden av bunnen av filen hvis og bare hvis Den første linjen i filen er en åpning stikkord.
Spesielt er dette mer vanlig i sammenheng med plugins enn det er i temaer, og her er hvorfor: PHP er en måte hvor serverens sidekode kan legges inn i frontend-markup. Som sådan krever det både en åpningskode og lukkerkode slik at tolken vet hvordan man skal analysere koden.
Men hvis du skriver et plugin eller en applikasjonsfil som er 100% PHP, så er det ikke nødvendig å legge til en avslutende tag på slutten av filen. Parseren vil kunne oppdage det selv, og hvis du gjøre inkludere en terminerings-kode, så kan du potensielt ha hvite plass igjen på slutten av filen som kan forårsake alle slags problemer når det kommer tid for å aktivere plugin.
Så i tillegg til kodningsstandarden som er definert ovenfor, vil jeg også legge til:
Når vi går inn på den siste strekningen av WordPress Coding Standards, begynner vi å fokusere på mindre ting som ternære operatører og Yoda-forhold; Vi vil imidlertid også ta en titt på de fineste punktene for å utføre inline SQL-spørringer og de viktige reglene rundt det.
Hvis du ikke allerede har tatt opp på serien, er det nå en god tid å lese tilbake gjennom det vi har dekket så langt som det vil påvirke hvor vi er på vei med det neste settet av artikler.
