Share
På dette punktet i serien har vi dekket mye bakken. Hittil har vi diskutert følgende emner:
Masse ting, ikke sant?
I denne spesielle artikkelen tenkte jeg at vi ville ta det litt lettere før vi hoppet inn i det siste emnet. Som sådan skal vi dekke to veldig enkle emner (som ofte enten ignoreres eller blir overkomplisert).
Spesielt skal vi snakke om den ternære operatøren, og vi skal snakke om Yoda forhold.
Når det gjelder å skrive WordPress-basert kode, sier kodningsstandardene strengt at vi først bør sikte på lesbarhet. Rett fra Codex:
Generelt er lesbarhet viktigere enn intelligens eller korthet.
Men det er litt nyanse til dette. Noen utviklere anser den ternære operatøren å være litt i strid med dette bestemte prinsippet, spesielt fordi det ennå er en annen måte å skrive en hvis / annet uttalelse, og hvis utvikleren ikke er kjent med å skrive eller lese den ternære operatøren, er det i strid med dette prinsippet.
Vi vil se nærmere på dette i et øyeblikk.
For det første, for de som ikke er kjent, er den ternære operatøren en forenklet måte å skrive en hvis / annet betinget utsagn. Det brukes vanligvis bare når betinget er den enkleste form og bare når det er en singel hvis og en singel ellers blokkere.
For eksempel, la oss si at vi har en betinget slik:
Accentsconagua
$ uses_gasoline = null; hvis ('hybrid' == $ car_type) $ uses_gasoline = false; ellers $ uses_gasoline = true; echo $ uses_gasoline; Jo, dette er litt av et godt eksempel, men du får poenget. Tross alt prøver jeg bare å demonstrere hvordan man konverterer en betinget som dette til et skjema som brukes av den ternære operatøren.
I samsvar med eksemplet ovenfor kan du gjøre følgende:
$ uses_gasoline = 'hybrid' == $ car_type? usann sannhet; ekko $ uses_gasoline;
Gir mening? En viktig ting å merke seg: Den ternære operatøren tester for ekte (i stedet for falsk, åpenbart).
For hva det er verdt, synes jeg dette å være mye som å lese en setning. Den første klausulen stiller et spørsmål (åpenbart punktert av et spørsmålstegn), med de to mulige svarene returnert basert på evalueringen av betingede.
Der er en advarsel for å sjekke for sant som alle er dokumentert i Codex:
Et unntak ville bruke
! tømme(), som testing for falsk her er generelt mer intuitivt.
Etter min erfaring har det vært den eneste tiden å bruke en negativ evaluering i betinget. Alle tider jeg har brukt med ternær operatør, har jeg funnet ut at testing for falsk ofte gjør ternær evalueringen vanskeligere å tyde på.
I tillegg har jeg funnet ut at det er best å gi en enkelt evaluering og kan være To evalueringer under svært enkle og klare forhold.
Annet enn det, det er hvordan du kan bruke den ternære operatøren i det daglige WordPress-arbeidet ditt
Hvis du fulgte tett sammen, vil du legge merke til at jeg gjorde noe som de fleste programmeringsspråk (eller til og med PHP-baserte plattformer utenfor WordPress) ikke regelmessig gjør:
Den betingede sammenligningen ble gjort ved å sammenligne verdien til variabelen; ikke den andre veien rundt.
Tradisjonelt ser vi noe slikt ut:
$ uses_gasoline = null; hvis ($ car_type == 'hybrid') $ uses_gasoline = false; ellers $ uses_gasoline = true; echo $ uses_gasoline;
Og den tilsvarende ternære operatøren ville se slik ut:
$ uses_gasoline = $ car_type == 'hybrid'? usann sannhet; ekko $ uses_gasoline;
Så hvis flertallet av programmeringsspråk og plattformer ikke bruk Yoda forhold, så hvorfor gjør WordPress?
I henhold til Codex:
I eksemplet ovenfor, hvis du utelater et likestilt skilt (innrøm det, skjer det selv til de mest erfarne av oss), får du en parse-feil, fordi du ikke kan tildele en konstant som
ekte. Hvis utsagnet var omvendt($ the_force = true), Oppdraget ville være helt gyldig, tilbake1, forårsaker at uttalelsen skal evalueres tilekte, og du kan jage den feilen en stund.
Etter min mening er dette en virkelig, veldig god forklaring for å utføre sammenligninger som dette spesielt innenfor dynamisk skrevet språk som PHP og JavaScript.
Uavhengig av om du er enig med denne tilnærmingen eller ikke, det er En del av standarden og deg er kommer til å se dette brukt gjennom WordPress kjerne, temaer, plugins, artikler og mer.
Til det formål anbefaler jeg sterkt å begynne å implementere i ditt eget arbeid.
Som nevnt i begynnelsen, ville dette innlegget bli mye enklere og grei enn noen av de andre materialene vi har dekket i serien så langt.
På dette punktet har vi bare ett hovedtema for å dekke: Database-spørringer.
Etter det skal vi gjennomgå alle emnene som vi har skissert gjennom denne serien for å oppsummere prinsippene vi har detaljert fra kodingsstandardene.
Men først, videre til Database Queries.
