Share
I denne serien tar vi et dypt dykk inn i WordPress Coding Standards - spesielt PHP-kodingsstandardene - for å evangelisere og forstå hvordan kvaliteten på WordPress-koden skal skrives.
Til tross for at dette er dokumentert i WordPress Developer Handbook, tror jeg det er noe å si for å forstå begrunnelsen bak Hvorfor Noen ting er slik de er.
Husk: Vårt overordnede mål er å sørge for at vi skriver kode som overholder kodingsstandardene, slik at vi sammen med andre utviklere lettere kan lese, forstå og vedlikeholde kode for temaer, plugins og applikasjoner som er bygget på toppen av WordPress.
I dette innlegget skal vi ta en titt på hvordan man håndterer navngivningskonvensjoner og funksjonsargumenter.
Før du spenderer tid på å utdype punktene som er angitt i kodingsstandardene, er det viktig å forstå hvilken rolle navngivningskonvensjoner spiller i skriftlig kode uansett hvilken plattform du arbeider med.
Til slutt skal navngivende konvensjoner - uavhengig av om de er for klasser, funksjoner, variabler, attributter eller argumenter - bidra til å forklare formålet de tjener.
Dermed mener jeg at klassenavn vanligvis skal være substantiver, funksjoner skal typisk være verb, og variabler, attributter og argumenter bør forklare formålet med at de tjener innenfor konteksten til klassen eller funksjonen de skal defineres i. Det handler om å gjøre koden så lesbar som mulig.
Akkurat som kodestandarder oppgir:
Ikke forkort variable navn unødvendigvis; la koden være entydig og selvdokumenterende.
Dette er en god tommelfingerregel uansett av hvilken del av koden den er du jobber på.
Når det gjelder å jobbe med WordPress, er det ikke sannsynlig at du møter klasser med mindre du gjør en av to ting:
Hvis du bare jobber med temaet, er du mer sannsynlig å jobbe med et sett med funksjoner - vi snakker om disse øyeblikkelig.
Men for de som jobber med plugins eller egne biblioteker, er det viktig å huske at klasser vanligvis bør være substantiver - de bør representere formålet med at de innkapsler, og de bør ideelt sett gjøre en ting og gjøre det bra.
For eksempel, hvis du har en klasse kalt Local_File_Operations da kan det være ansvarlig for å lese og skrive filer. Det bør ikke være ansvarlig for å lese og skrive filer, så vel som å si, hente fjernfiler.
I følge WordPress Coding Standards bør klassene følge følgende konvensjoner:
Enkel, rett?
Praktisk sett vil dette se ut som følgende:
Accentsconagua
klasse Local_File_Operations klasse Remote_File_Operations klassen HTTP_Request klasse SQL_Manager Å gjenta: Klasser skal også være substantiver og bør beskrive det enkelte formål de tjener.
Som nevnt tidligere, hvis klasser er substantiver som ideelt sett representerer en enkelt ide eller et enkelt formål, bør deres metoder være de handlingene de kan ta. Som sådan bør de være verb - de bør indikere hvilke tiltak som vil bli tatt når de blir kalt.
Videre skal argumentene de aksepterer også være med i navnet på funksjonen. For eksempel, hvis en funksjon er ansvarlig for å åpne en fil, bør parameteren være et filnavn. Siden målet vårt skal gjøre det så enkelt som mulig å lese kode, bør det lese noe som "har den lokale filbehandleren les filen som har følgende filnavn."
I kode kan dette se slik ut:
// Klasse definisjonsklasse Local_File_Manager offentlig funksjon open_file ($ filnavn) // Funksjon implementering // Hvordan vi ville bruke denne koden $ file_manager = new Local_File_Manager (); $ file_manager-> open_file ('foo.txt'); Selvfølgelig dekker dette fortsatt ikke hvordan Funksjoner skal skrives i sammenheng med WordPress-utvikling. Kodestandarden stat:
Bruk små bokstaver i variabel-, handling- og funksjonsnavn (aldri
Camelcase). Separate ord via underskrifter. Ikke forkort variable navn unødvendigvis; la koden være entydig og selvdokumenterende.
Den første delen av konvensjonen er lett nok til å forstå; Men jeg tror utviklere har en tendens til å ta snarveier når de er i stand. "Åh," tenker vi, "$ str gir mening her, og $ nummer fornuftig her. "
Selvfølgelig er det alltid verre - noen utviklere ty til å bruke enkeltpersoner for deres variabelnavn (som vanligvis bare er akseptabelt i looper.)
Akkurat som kodestandarder oppgir: Forkort ikke variable navn un-nødvendigvis. La koden være entydig og selvdokumenterende.
Nå er sannheten, kode kan bare være entydig til et punkt. Tross alt er det derfor kalt koden, ikke sant? Dette er grunnen til at jeg tror at kodekommentarer skal brukes liberalt.
Uansett, bunnlinjen er å redusere metodenavnene dine, unngå alle kamelhyller, skille mellomrom, og vær så spesifikke som mulig når du navngir variablene dine.
Variable navn faktisk er ikke mye forskjellig fra funksjonsnavn annet enn de representerer en enkelt verdi eller en referanse til en bestemt gjenstand. Navngivningskonvensjonene følger fortsatt hva du forventer:
En annen konvensjon som noen utviklere bruker, er det som er kjent som ungarsk notasjon, hvor er typen verdi variabelen lagrer prefixed foran variabelen.
For eksempel:
$ str_firstname $ i_tax eller $ num_tax $ arr_range Ærlig talt sier kodingsstandardene ingenting om dette. På den ene siden mener jeg at dette gir renere kode i det totale omfanget av kode, men det er mange utviklere som misliker ungarsk notasjon.
Siden kodingskonvensjonene ikke sier noe om dem, er jeg nølende med å anbefale dem som jeg vil være så nær standarder som mulig. Som sådan må jeg anbefale at det er best å følge kodningsstandardene.
I tråd med temaet om å gjøre vår kode så lesbar og selvdokumenterende som mulig, er det fornuftig at vi trekker dette gjennom kildekoden vår helt til filene som vi skal utarbeide vårt tema, plugin eller applikasjon.
I følge kodingsstandarder:
Filer skal benevnes beskrivende med små bokstaver. Hyphens skal skille ord.
I samsvar med vårt tidligere eksempel, la oss si at vi jobber med Local_File_Operations da vil filen bli navngitt klasse-local-fil-operations.php.
Lett nok.
Neste, hvis du jobber med et plugin som heter Instagram_Foo da skal filen navngis instagram-foo.php; Det er imidlertid verdt å merke seg at hvis du bruker noen avanserte metoder for å utvikle pluginene dine, for eksempel å holde plugin-klassen fil i sin egen fil og deretter laste den ved å bruke den en annen fil, så kan filstrukturen være:
klasse-instagram-foo.phpinstagram-foo.phpHvor instagram-foo.php er ansvarlig for å laste inn klasse-instagram-foo.php. Selvfølgelig er dette bare fornuftig hvis du bruker OOP når du skriver WordPress-pluginene dine.
Når det gjelder å overføre funksjonsargumenter, er det viktig å huske at hvis funksjonsnavn beskriver handlingene som blir tatt av klassen, bør argumentet representere hva funksjonen egentlig driver.
Fra kodingsstandardene:
Foretrekk strengverdier til bare
ekteogfalsknår du ringer funksjoner.
Siden boolske verdier kan være uklare når man overfører verdier til en funksjon, gjør det vanskelig å fastslå nøyaktig hva funksjonen gjør.
For eksempel, la oss bruke eksemplet ovenfor på en litt annen måte:
// Klassen definisjonsklasse Local_File_Manager offentlig funksjon manage_file ($ filnavn, sant) if (true) // Åpne filen ellers // Slett filen // Hvordan vi bruker denne koden $ file_manager = ny Local_File_Manager (); $ file_manager-> manage_file ('foo.txt', true); Er vanskeligere å forstå enn, si, noe slikt:
// Klassen definisjonsklasse Local_File_Manager offentlig funksjon open_file ($ filnavn) // åpne filen offentlig funksjon delete_file ($ filnavn) // slette filen // Hvordan vi ville bruke denne koden $ file_manager = new Local_File_Manager (); $ file_manager-> open_file ('foo.txt'); $ file_manager-> delete_file ('foo.txt'); På toppen av det, husk at argumenter blir overført til funksjoner, er fortsatt variabler i seg selv, slik at de er underlagt de variable navnekonvensjonene som vi har beskrevet ovenfor.
Vi har tatt et utvidet blikk på Naming Conventions og Function argumenter i kodningsstandardene. Forhåpentligvis har dette bidratt til å gi ikke bare en veiledning for hvordan du kan forbedre visse aspekter av WordPress-koden, men også å forklare begrunnelsen bak noen av praksisene.
I neste artikkel skal vi se på betydningen av enkle anførselstegn og doble anførselstegn i sammenheng med å arbeide med strenger i WordPress-utvikling.
Der er en forskjell i hvordan de tolkes av PHP, og det er forhold der du skal bruke den ene over den andre og vi vurderer det i neste artikkel.
