WordPressin koodausstandardit [Opas]

Syy siihen, että meillä on lainkaan koodausstandardeja (ei vain WordPress), on luoda tuttu ympäristö ohjelmoijille projektin parissa. Erityisesti WordPress sisältää monenlaisia tuotteita. Ytimestä itsestään teemoihin ja laajennuksiin on paljon katsottavaa - ja paljon, jotta voisit sekoittaa.

Jos jokainen muotoilee koodinsa samalla tavalla, käyttää kommentteja, samaa dokumentointityyppiä ja niin edelleen, työskentely yhdessä tulee niin paljon helpommaksi, ja uuden projektin liittymiseen liittyvä oppimiskäyrä ei ole yhtä jyrkkä.

WordPressin yhteenkuuluvuuden tarvetta suurentaa se tila, jossa koodipohja on. WordPress ei noudata tiukkaa objektorientoitua lähestymistapaa eikä käytä MVC-kuviota. Hankkeilla, jotka noudattavat poikkeuksetta OOP- ja MVC-ohjeita (kuten Laravel), on johdonmukaisuus ja parhaat käytännöt “paistettu” rakenteensa vuoksi.

WordPress on valitettavasti kypsä spagettikoodausta varten tekee mitä haluat. Parhaita käytäntöjä on vaikea panna täytäntöön vain siksi, että huonoja koodeja käyttävät tuotteet voivat toimia yhtä hyvin (pinnalla).

Seuraamalla WordPressin koodausstandardeja voit oppia hieman WordPressin koodaus etosista, luoda lisää WordPress-yhteensopivia tuotteita. näytä, mitä yhteisöä pidät ja kumotat korkealaatuista koodia.

Lisää sivustosta Hongkiat.com:

10 pahinta painajaisia Web-kehittäjille
5 syytä, miksi CSS voisi olla kaikkien vaikein kieli
30 Yleisiä reaktioita Ohjelmoijilla on kun asiat menevät vikaan

Jotkut standardeihin liittyvät huomautukset

Standardit eivät määrittele oikein ja väärin. Saatat olla eri mieltä säännöstä, esim. Pidikkeitä tulisi aina käyttää, vaikka niitä ei tarvita. WordPress-koodausstandardien tarkoituksena ei ole päättää, olitko oikeassa tai väärässä, vaan päättää, miten se pitäisi tehdä WordPressissa.

Standardit eivät ole keskustelun kohteena. Standardien käyttö ei ole paikka, jossa kannattaa vastustaa sellaista syvennystyyliä, jota et pidä. Jos jokin on koodausstandardeissa, tee se näin. WordPress-kehittäjät rakastavat sinua siitä! Tämä tarkoittaa, että jos et hyväksy jotakin siellä, nosta ääntäsi ja anna ihmisten tietää. On aina mahdollista tehdä asioita paremmin, mutta sinun pitäisi vain muuttaa koodityyliäsi, jos standardit sallivat sen.

Johdonmukaisuus peräaukon pysyvyyden suhteen. Jos olet viimeisen 10%: n projektiisi ja olet juuri huomannut, että olet käyttänyt virheellistä luokittelukäytäntöä luokkiin, älä vaihda puoliväliin. Oman henkilökohtaisen mielipiteeni mukaan luen mieluummin jotain johdonmukaisesti väärää kuin jotain, joka on joskus oikea ja joskus ei. Voit aina kirjoittaa komentosarjan, jos haluat muuttaa asioita yhdellä kertaa, tai lukea koodisi loppuun.

Seuraavat standardit ovat vaikeita! Alustan asettaminen samalle riville kuin toiminto alla olevan rivin sijaan on melko helppoa, vaikka olet tottunut lyömään sisään ennen. Kuitenkin, kun sinun täytyy ajatella noin 100 pientä sääntöä, koko prosessi muuttuu hieman virhealttiiksi. Huolimatta vaikeista asenteistani seuraaviin standardeihin olen yhtä syyllinen kuin muutkin virheiden tekemisessä. Päivän lopussa väärä sisennys ei ole peruuttamaton synti. Kokeile parasta noudattaa kaikkia sääntöjä, opit kaiken ajoissa.

WordPress-koodausstandardit

Tällä hetkellä WordPressilla on neljä opasta, yksi kullekin käytetylle kielelle: PHP, HTML, Javascript ja CSS. Ne muodostavat osan laajempaa tietämystä, Core Contributor -käsikirjaa. Kaikkien kulkeminen vie jonkin aikaa, joten olen korostanut joitakin katkelmia niistä neljästä kielestä, joita usein näen ihmisten väärässä.

PHP

PHP on WordPressin pääkieli ja se on melko löyhästi kirjoitettu kieli, joka tekee siitä kypsä sääntelyyn.

Brace-tyylit

Aloituskiinnikkeet tulisi aina sijoittaa viivojen loppuun. Liittyvät lausumat tulisi sijoittaa samalle linjalle kuin edellinen sulkeutuva pidike. Tämä näkyy parhaiten koodisimerkillä:

jos (ehto) // Tee jotain elseif (ehto) // Tee jotain muuta // Tee jotain

Antelias avaruuskäyttö

En ole puhaltanut koodattua koodia (minulla on huono näkö), joten tämä on erityisen haluan panna täytäntöön. Laita tilat jälkeen pilkut, ja molemmin puolin looginen, vertailu, jono ja toimeksiantajat, jälkeen jos, muuten jos, varten, jokaiselle ja vaihtaa lausunnot ja niin edelleen.

On helpompaa sanoa, missä tiloja ei pitäisi lisätä! Ainoat ajat, joita ei pitäisi lisätä, on milloin tyypittely tai viittausjärjestelmät.

Melko sekava poikkeus poikkeukseen on ryhmät, joissa array-näppäin on muuttuja, käytä tässä tapauksessa tilaa. Tässä esimerkissä pitäisi tehdä selväksi:

toiminto my_function ($ complete_array = null, $ key_1 = 4, $ key_2 = 'bar') if (null == $ complete_array) $ final_array = $ complete_array;  else $ key_1 = (kokonaisluku) $ key_1; $ final_array [0] = 'tämä'; $ final_array [$ key_1] = 'on'; $ final_array [$ key_2] = 'an'; $ final_array ['last'] = 'esimerkki';  palauta $ final_array;

Nimeämissopimukset

Tämä voi olla vaikea tottua, varsinkin jos tulet eri ympäristöistä. Pähkinänkuoressa:

Muuttujat pitäisi olla kaikki pienet kirjaimet, sanat, jotka on erotettu alaviivoilla
Luokan nimet pitäisi käyttää aktivoidut sanat erotetaan alaviivoilla. Lyhenteet pitäisi olla kaikki isoja
vakiot pitäisi olla kaikki isot kirjaimet, korostavat alaviivat
Tiedostonimet pitäisi olla kaikki pienet kirjaimet, erotettu viivoilla

Yoda-olosuhteet

Ehtojen kirjoittaminen toisin päin kuin olet tottunut estämään virheiden käsittely. Se näyttää hieman outolta, mutta se on parempi koodi.

jos ('Daniel' === $ nimi) echo 'Kirjoita artikkeli, jota haluat';

HTML

HTML: llä ei ole sitä monta sääntöä, jotka voisivat keksiä paljon, jotta asiat olisivat modulaarisia. HTML-koodia kirjoitettaessa on tiedettävä vain viisi sääntöä:

Koodisi on validoitava W3C-validointia vastaan.
Itse sulkevilla HTML-tunnisteilla on oltava täsmälleen yksi tila ennen eteenpäin vievää kauttaviivaa (tämä on henkilökohtaisesti vihaan, mutta se on W3C-määritys, ei vain WordPress-lemmikkieläinten peeve)
Ominaisuuksien ja tunnisteiden on oltava pieniä kirjaimia. Ainoa poikkeus on, kun attribuuttiarvot on tarkoitettu ihmisravinnoksi, jolloin ne olisi kirjoitettava luonnollisesti.
Kaikilla määritteillä on oltava arvo ja ne on mainittava (kirjoittaminen ei ole oikein)
Kohdistus tulee saavuttaa välilehdillä ja noudattaa loogista rakennetta.

CSS

CSS on toinen löyhästi kirjoitettu kieli, joten myös tässä on paljon työtä. Standardit kuitenkin menevät melko helposti koodereille.

valitsimet

Valitsijoiden tulisi olla tarpeellisen päteviä, inhimillisesti luettavia, kaikki pienet kirjaimet, joiden sanat on erotettu viivoilla, ja attribuutinvalitsijoiden tulisi käyttää kaksinkertaisia lainausmerkkejä. Tässä on lyhyt esimerkki:

input [type = "text"], syöttö [type = "password"], .name-kenttä tausta: # f1f1f1;

Kiinteistötila

Standardit tunnustavat tarpeen henkilökohtaiseen tilaan täällä, koska ne eivät määritä CSS-sääntöjen erityistä järjestystä. Mitä he tehdä sanoa, että sinun pitäisi seurata semanttista rakennetta käydä järkeen. Ryhmän ominaisuudet ryhmittelemällä tai ryhmittelemällä ne aakkosjärjestyksessä, älä vain kirjoita niitä satunnaisesti.

Suurin syy satunnaisuuteen on “oh minun on myös lisättävä marginaali” ja jatka sitten lisäämällä se pohjaan. Ota ylimääräiset 0,3 sekuntia ja lisää sääntö loogiseen paikkaan.

Näyttö
paikannus
Box-malli
Värit ja typografia
muut

.profiili-modaali näyttö: lohko; kanta: absoluuttinen; vasen: 100px; top: 90px; tausta: # ff9900; väri: #fff;

Arvon muotoilu

Tämä on yksi paikka, jossa en erityisesti halua nähdä epäjohdonmukaisuuksia. Jos et noudata ohjeita, se on vielä parempi kuin joskus nähdä tilaa ennen arvoa; joskus käyttämällä lyhytnäkymää, joskus ei; joskus käytetään yksiköitä 0 arvoon, joskus ei jne.

Arvon muotoilu on melko monimutkainen, mutta se tulee luonnollisesti jonkin verran käytännössä. Tutustu Codexin tarkkaan oppaaseen arvojen muotoiluun.

javascript

Kokemukseni mukaan Javascript on alttiimpi menemään kaikkialle. Vaikka monet kehittäjät tietävät huomattavan määrän Javascriptiä, sitä opittiin vähitellen HTML: n, CSS: n ja PHP: n jälkeen. Kun aloitat vain uuden kielen, teet paljon enemmän virheitä, ja jos nämä virheet eivät aiheuta kohtalokkaita virheitä, ne voivat juuttua sinuun.

Monissa tapauksissa standardit viittaavat linjarajaan tai tilaan “jos linja ei ole liian pitkä”. Tämä viittaa jQuery Style -oppaaseen, joka asettaa a 100 merkin raja linjoilla. WordPress-opas perustuu jQuery-oppaaseen, joten se on hyvä ajatus antaa myös luku.

puolipistettä

Tämä on yksinkertaisin sääntö, mutta se on usein huomiotta. Älä koskaan jätä puolipistettä vain siksi, että koodi toimii ilman sitä. Se on vain huolimaton.

sisennys

Välilehtiä tulisi aina käyttää sisennykseen. Sinun pitäisi myös sulkea sulkemisen sisältö, vaikka koko tiedoston sisältö olisi yksi. En ole varma, miksi ennaltaehkäisemätön ylemmän tason sulkeminen bugged minua jo ennen standardien lukemista.

Rikkoutuvat linjat

Kun katkaiset pitkät merkkijonot, katkaise rivi aina operaattorin jälkeen, älä jätä muuttujaa roikkumaan. Tämä tekee ensi silmäyksellä selväksi, että linja on rikki ja et ole juuri unohtanut puolipistettä.

Jos jokin ehto on pitkä, katkaise se useisiin riveihin ja lisää ylimääräinen välilehti sen eteen. Tämä tuntuu hyvin oudolta silmin, mutta erotus, jonka se lisää tilan ja kehon välillä, on hyvin näkyvissä.

jos (firstCondition () &&c secondCondition () &&clearition ()) var html = 'Tämä rivi koostuu' + n + '-sanoista, joten se on jaoteltava operaattorin' + 'jälkeen;

jQuery Iteration

Standardien mukaan jQuery iterointi (JQuery.each ()) tulisi käyttää vain jQuery-objekteissa. Sinun pitäisi käyttää perusasetuksia varten, ja / in, sillä aikaa silmukoita Javascriptissä iteroitumaan muihin kokoelmiin.

johtopäätös

On paljon huomionarvoista ja seurattavaa, eikä kukaan voi soveltaa tätä kaikkia yhdellä kertaa. Sinun pitäisi ottaa koodi niin lähelle kuin mahdollista standardeihin ja työskennellä seuraamalla niitä tarkasti.

Minun mielestäni johdonmukaisuus on tärkein sääntö. On parempi tehdä jotain väärin väärin kuin siirtyä puoliväliin. Tämä pätee erityisesti muotoilutapoihin, koska ne eivät vaikuta koodin toimivuuteen ja - useimmiten - voidaan helposti erottaa myöhemmin.

Inhoatko jotakin koodausstandardien elementtiä, luuletteko jotain pitäisi lisätä? Kerro meille kommenteistamme!