Peruskoodausstandardit PSR-1:n kautta

Eilen puhuin lyhyesti PSR:n käytön perusteista WordPressin koodausstandardeihin verrattuna ja molempien milloin ja miksi. Mutta se ei tarkoita, etteikö se olisi ilman sekaannuksia, varsinkin jos olet vasta aloittamassa niistä, eikö niin?

Tällä tarkoitan: Oletetaan, että olet työskennellyt WordPress-koodausstandardien kanssa vuosia (koska voin samaistua), ja nyt on noudatettava näitä uusia sääntöjä ja ohjeita. Mutta se ei ole kuin pelkkä välilyöntien muuttaminen ja tiedostojen uudelleennimeäminen.

On muitakin huomioitavia kohtia, ja jokainen on hahmoteltu numeroina, aivan kirjaimellisesti (PSR-1, PSR-2 ja niin edelleen), kuinka jonkin pitäisi toimia.

Mitä ongelmia saatamme kohdata WordPress-kehittäjinä, kun kyse on vain PSR-1:ssä kuvatuista peruskoodausstandardeista?

Koodauksen perusstandardit (ja sivuvaikutukset)

Minulla ei ole aikomusta käydä läpi jokaista dokumenttia ja toistaa sitä, mitä voimme jo oppia lukemalla ne, mutta mielestäni on sanottavaa, että otamme jotain, mitä monet meistä tekevät tai kokevat, ja katsomme, kuinka tämä voi muuttua sisällä. WordPressin kontekstissa.

Otetaan peruskoodausstandardin (tai PSR-1 :n) sivuvaikutukset esimerkiksi:

Tiedoston PITÄÄ ilmoittaa uusia symboleja (luokat, funktiot, vakiot jne.) eikä aiheuta muita sivuvaikutuksia, tai sen PITÄÄ suorittaa logiikkaa sivuvaikutuksineen, mutta EI SIDÄ tehdä molempia.

Ilmaus "sivuvaikutukset" tarkoittaa logiikan suorittamista, joka ei liity suoraan luokkien, funktioiden, vakioiden jne. ilmoittamiseen, pelkästään tiedoston sisällyttämisestä.

Henkilökohtaisesti pidän toista lausetta avaimena koodimme sivuvaikutusten ymmärtämiseen ja välttämiseen niin paljon kuin mahdollista. Toisin sanoen kaiken, mitä luokkamme tekevät, tulee olla itsenäistä tai olla yhtenäistä jonkin kanssa, joka on saatettu jollain tavalla injektoitua.

Siitä huolimatta sivuvaikutuksen tuovan koodin löytäminen ja sen puhdistaminen ei saisi olla liian vaikeaa. Itse asiassa käytän itseäni esimerkkinä.

Katso tämä tietty koodinpätkä :

Tämä koodi on suoraan Toggle Admin Noticesista. Myönnettäköön, se on yksinkertainen, ja arkisto näyttää huomautuksen sen muuttamisesta. Se osoittaa kuitenkin pointin, eikö?

Mikä on ratkaisu? Tämä tulee Autoloadingin muodossa (joka on myös katettu PSR-4 :ssä ). Entä jos tekisin sen uudelleen, joten se seurasi PSR-1:tä kunnolla? Sitten yksi tapa palauttaa se voi näyttää tältä :

Onko tämä loistava esimerkki? Luultavasti ei. Mutta siinä on muutakin kuin tiedostojen lisääminen. Näiden tiedostojen mukaan lukien tämä yksittäinen tiedosto tuo esiin erilaisia ​​sivuvaikutuksia.

Tämä tarkoittaa, että tämä yksi tiedosto yksin on vastuussa paljon enemmän kuin vain noista neljästä koodirivistä. Ajattele sitä niin, että se sisältää kaiken, mitä muut tiedostot toteuttavat. Siinä vaiheessa se muuttuu monimutkaisemmaksi.

Joten ota tämä idea ja siirrä se paljon laajempaan järjestelmään, niin näet kuinka ja miksi tämä olisi ongelmallista.

Tietysti on olemassa myös vaihtoehtoisia tapoja. Ja tämä on vain yksi esimerkki. Myös itsetuhoista. Tarkoituksena ei ole niinkään osoittaa lopullinen tapa tehdä tämä, vaan alkaa kylvää ajatuksia siitä, miten suunnittelemme, suunnittelemme, rakennamme ja sisällytämme luokkia.

Entä näkymät?

Mitä tulee lisäosien kirjoittamiseen, käsittelen osittain sitä, mitä käyttäjät näkevät näkyminä. Mutta tässä näyttää olevan saalis: Tiedostojen sisällyttämistä pidetään huonona käytäntönä, koska se tuo mukanaan sivuvaikutuksia.

Emme siis halua tuottaa luokillamme logiikkaa, vaan haluamme myös erottaa esityksen liikelogiikasta.

Mitä meidän tulee tehdä?

Kierre… on, että aiomme käyttää olio-ohjelmointia tehdäksemme sen. Suunnittelemme luokan, joka luo HTML:n PHP-mallin avulla.

Joku muu on käsitellyt tätä perusteellisesti, ja suosittelen lämpimästi kyseisen postauksen lukemista sivuvaikutusten huomioimiseksi, niiden välttämiseksi ja kiinteiden käytäntöjen sisällyttämiseksi mahdollisimman paljon.

…Ja omaisuus ja niihin liittyvät tiedostot?

Tiedän: Ajatus sivuvaikutuksista luopumisesta (puhumattakaan niiden tunnistamisesta) voi olla aluksi outo, varsinkin kun ajattelee tiettyjä asioita, joita olemme tehneet niin kauan.

Ja se voi herättää kysymyksiä, kuten: Onko JavaScript- tai CSS-tiedostojen sisällyttäminen väärin? Tämä on varmaankin toisen postauksen aihe. Muista kuitenkin, että siihen liittyy suoraan API-ydintoimintoja, ja ne voivat olla osa luokkaa, joka on tiukasti vastuussa siitä.

Jos luokan tarkoitus on tehdä juuri se ja vain se ja se käyttää API-funktioita tehdäkseen sen, sanoisin, että se on todennäköisesti kunnossa.

Mutta poikkean siitä toistaiseksi (ja ehkä se on kommenttien aihe tai taas toinen viesti).

Pidä sen sijaan luokkasi kevyinä ja määrätietoisina. Heidän tulisi toimia kuten PSR-1- tiloissa ja välttää tekemästä asioita, kuten "[julistaa] uusia luokkia, funktioita, vakioita jne." ja "[suorittaa] logiikkaa sivuvaikutuksineen."