Početna » WordPress » Standardi kodiranja za WordPress [Vodič]

    Standardi kodiranja za WordPress [Vodič]

    Razlog zbog kojeg uopće imamo standarde kodiranja (ne samo za WordPress) jest stvoriti poznato okruženje za programere rad na projektu. WordPress posebno obuhvaća široku paletu proizvoda. Od same jezgre do tema i dodataka, ima puno toga za pogledati - i mnogo toga o čemu se treba miješati.

    Ako svatko formatira svoj kod na isti način, koristi komentare, isti stil dokumentacije i tako dalje, zajednički rad postaje mnogo lakši, a krivulja učenja pridruživanja novom projektu neće biti tako strma.

    Potreba za kohezijom u WordPressu je uvećana stanjem u kojem je baza koda. WordPress ne slijedi strogi objektno orijentirani pristup i ne koristi MVC uzorak. Projekti koji slijede OOP i MVC smjernice bez iznimke (kao Laravel) imaju dosljednost i najbolje prakse “pečena” zbog njihove strukture.

    WordPress je, nažalost, zrela za špagete kodiranje radiš što god želiš. Najbolja praksa je teško provoditi samo zato što proizvodi koji koriste loš kod mogu raditi jednako dobro (na površini).

    Slijedeći WordPress standarde kodiranja možete naučiti nešto o kodiranju etosa WordPressa, stvoriti više WordPress kompatibilnih proizvoda. pokažite zajednici da vam je stalo i prepirete visoku kvalitetu koda.

    Više na Hongkiat.com:

    • 10 najgorih noćnih mora za web programere
    • 5 razloga zašto CSS može biti najteži jezik od svih
    • 30 Uobičajene reakcije Programeri imaju kad stvari krenu pogrešno

    Neke napomene o standardima

    Standardi ne definiraju ispravno i pogrešno. Možda se ne slažete s pravilom, npr. Zagradama uvijek treba koristiti, čak i ako nisu potrebne. Svrha WordPress standarda kodiranja nije da odlučite jeste li u pravu ili u krivu, to je da odlučite kako to treba učiniti u WordPressu.

    Standardi nisu za raspravu. Korištenje standarda nije mjesto na kojem se možete suprotstaviti stilu uvlačenja koje vam se ne sviđa. Ako je nešto u standardima kodiranja, onda to napravite na taj način. WordPress programeri će vas voljeti za to! To je rekao, ako se ne slažete s nečim tamo, podignite svoj glas i obavijestite ljude. Uvijek je moguće raditi stvari bolje, ali samo trebate promijeniti svoj stil kodiranja ako standardi to dopuštaju.

    Dosljednost tijekom analnog zadržavanja. Ako ste u posljednjih 10% svog projekta, a upravo ste otkrili da koristite neispravne konvencije imenovanja za razrede, nemojte se mijenjati ni na pola puta. Po mom osobnom mišljenju, radije bih pročitao nešto dosljedno netočno od nečega što je ponekad točno, a ponekad ne. Uvijek možete napisati skriptu za promjenu stvari u jednom pokretu ili čitanje koda na kraju.

    Slijedeći standardi su teški! Postavljanje zagrada na istu liniju kao funkcija umjesto linije ispod je prilično lako, čak i ako ste prije navikli na tipku Enter. Međutim, kada trebate razmisliti o 100 malih pravila, cijeli proces postaje malo sklon pogreškama. Unatoč mom čvrstom stavu o sljedećim standardima, kriv sam kao i svatko na pogreškama. Na kraju dana, pogrešno uvlačenje nije neopoziv grijeh. Pokušajte najbolje slijediti sva pravila, naučit ćete sve na vrijeme.

    Standardi kodiranja za WordPress

    Trenutno WordPress ima četiri vodiča, jedan za svaki glavni jezik koji se koristi: PHP, HTML, Javascript i CSS. Oni čine dio većeg skupa znanja, Priručnika za temeljne suradnike. Prolazak kroz sve bi potrajao pa sam istaknuo neke isječke s četiri jezika koje često vidim kako ljudi griješe.

    PHP

    PHP je glavni jezik WordPressa i prilično labav tip koji ga čini zrelim za regulaciju.

    Stilovi podupirača

    Početni zagradama uvijek treba postaviti na kraju redaka. Srodne naredbe trebaju biti smještene na istoj liniji kao i prethodna zaključna zagrada. To se najbolje pokazuje primjerom koda:

    if (condition) // Do Something elseif (uvjet) // Do Something else // Do Something

    Velikodušna uporaba prostora

    Nisam obožavatelj zgnječenog koda (imam loš vid) tako da ovo posebno volim provoditi. Stavite razmake nakon zarezi, i na obje strane logičan, usporedba, niz i operatora dodjele, nakon ako, elseif, za, za svakoga i prekidač izjave i tako dalje.

    Lakše je reći gdje ne bi trebalo dodavati prostore! Jedini put kada ne biste trebali dodavati razmake je kada typecasting ili referenciranje nizova.

    Veoma zbunjujuća iznimka od iznimke su polja gdje je ključ matrice je varijabla, u tom slučaju koristite razmaknicu. Ovaj primjer bi trebao biti jasan:

    funkcija my_function ($ complete_array = null, $ key_1 = 4, $ key_2 = 'bar') if (null == $ complete_array) $ final_array = $ complete_array;  else $ key_1 = (cijeli broj) $ key_1; $ final_array [0] = 'ovo'; $ final_array [$ key_1] = 'je'; $ final_array [$ key_2] = 'an'; $ final_array ['last'] = 'primjer';  povratak $ final_array; 

    Konvencije imenovanja

    Na ovo se može teško naviknuti, pogotovo ako dolazite iz različitih okruženja. U suštini:

    • Imena varijabli trebalo bi sva mala slova, riječi odvojene s podcrtanjima
    • Imena klasa treba koristiti kapitalizirane riječi razdvojene donjom crtom. kratice bi trebao biti sve velikim slovima
    • konstante trebalo bi sva velika slova, izgovorene podcrtanjima
    • Imena datoteka trebalo bi sva mala slova, odvojiti s crticama

    Uvjeti Yoda

    Uvjeti pisanja obrnuto nego što ste navikli spriječit će pogreške pri raščlanjivanju. Izgleda pomalo čudno, ali je bolji kod.

    if ('Daniel' === $ name) echo 'Napišite članak koji želite'; 

    HTML

    HTML nema toliko pravila povezanih s njim, mogao bih smisliti puno toga da bi stvari bile modularne. Postoji samo pet pravila koja morate znati prilikom pisanja HTML-a:

    1. Vaš kôd mora potvrditi valjanost W3C validatora.
    2. Samozatvarajuće HTML oznake moraju imati točno jedan razmak prije kose crte (ovo osobno mrzim, ali to je W3C specifikacija, ne samo WordPress kućni ljubimac)
    3. Atributi i oznake moraju biti mala. Jedina iznimka je kada su vrijednosti atributa namijenjene za ljudsku potrošnju, u kojem slučaju ih treba upisivati ​​prirodno.
    4. Svi atributi moraju imati vrijednost i moraju se navoditi (pisati nije ispravno)
    5. Uvlačenje se mora postići pomoću kartica i treba slijediti logičku strukturu.

    CSS

    CSS je još jedan labavo otipkani jezik, tako da i ovdje ima dosta posla. Usprkos tome, standardi se lako primjenjuju koderi.

    selektora

    Selektori bi trebali biti kvalificirani koliko je potrebno, čitljivi u ljudskom smislu, svi s malim slovima, riječi odvojene crtama, a selektori atributa trebali bi koristiti dvostruke navodnike. Evo kratkog primjera:

    input [type = "text"], ulaz [type = "password"], .name-field background: # f1f1f1; 

    Narudžba imovine

    Standardi prepoznaju potrebu za nekim osobnim prostorom jer ne propisuju poseban redoslijed za CSS pravila. Sto oni čini recimo da treba slijediti semantičku strukturu ima smisla. Grupirajte svojstva prema njihovim odnosima ili ih grupirajte po abecedi, samo ih ne ispisuj slučajno.

    Najveći uzrok slučajnosti je “oh također moram dodati marginu” i zatim nastavite s dodavanjem na dno. Uzmite dodatnih .3 sekundi i dodajte pravilo na logično mjesto.

    • Prikaz
    • namještanje
    • Model kutije
    • Boje i tipografija
    • drugo
    .profil-modal (prikaz: blok; Položaj: na; lijevo: 100piks; vrh: 90px; pozadina: # ff9900; boja: #fff; 

    Formatiranje vrijednosti

    Ovo je mjesto na kojem mrzim osobito vidjeti nedosljednosti. Ako ne slijedite smjernice, to je još bolje nego ponekad vidjeti prostor ispred vrijednosti; ponekad koristeći stenografiju, ponekad ne; ponekad koriste jedinice na vrijednosti 0, ponekad ne, itd.

    Formatiranje vrijednosti je prilično složeno, ali to prirodno dolazi s nekom praksom. Pogledajte točan vodič u Kodeksu za oblikovanje vaših vrijednosti.

    Javascript

    U mom iskustvu Javascript je najviše skloni ići posvuda. Dok mnogi programeri znaju znatnu količinu Javascript-a, učili su ga postupno, kao naknadno razmišljanje o HTML-u, CSS-u i PHP-u. Kada tek počinjete raditi s novim jezikom, napravite puno više pogrešaka i ako te pogreške ne uzrokuju fatalne pogreške, one mogu postati ukorijenjene u vama.

    U mnogim slučajevima standardi se odnose na granicu ili stanje linije “ako linija nije preduga”. To se odnosi na jQuery Style Guide koji nameće a Ograničenje od 100 znakova na retke. Vodič za WordPress temelji se na vodiču jQuery, tako da je dobra ideja i to pročitati.

    zarezom

    Ovo je najjednostavnije pravilo, ali je ono koje se često previđa. Nikada, nikad, ne izostavite točku-zarez samo zato što vaš kôd radi bez nje. To je samo traljavo.

    uvlačenje

    Kartice se uvijek trebaju koristiti za uvlačenje. Također biste trebali uvlačiti sadržaj zatvaranja čak i ako je sadržaj cijele datoteke sadržan u jednom. Nisam siguran zašto me je gnjavila vrhunska zatvaranja čak i prije nego što sam pročitala standarde.

    Breaking lines

    Prilikom razbijanja dugih nizova uvijek prekinite liniju nakon operatora, ne ostavljajte varijablu da visi. Na prvi pogled je očito da je linija prekinuta i da niste zaboravili točku-zarez.

    Također, ako je uvjet dugačak, podijelite ga na više redaka i dodajte dodatnu karticu prije nje. Ovo izgleda vrlo čudno za moje oči, ali razdvajanje koje dodaje između stanja i tijela je vrlo vidljivo.

    if (firstCondition () && secondCondition () && thirdCondition ()) var html = 'Ovaj redak se sastoji od riječi' + n + ', pa ih treba razvrstati nakon' + 'operatora'; 

    Ponavljanje jQuery

    Prema standardima jQuery iteracija (JQuery.each ()) koristiti samo na jQuery objektima. Trebali biste koristiti osnovni za, za / u, dok petlje u Javascriptu za ponavljanje nad drugim zbirkama.

    Zaključak

    Ima puno toga za primijetiti i pratiti i ne postoji način da se sve to može primijeniti u jednom pokretu. Trebate uzeti svoj kod što je moguće bliže standardima i raditi na njihovom praćenju točno.

    Po mom mišljenju dosljednost je najvažnije pravilo. Bolje je dosljedno raditi nešto pogrešno nego prebaciti na pola puta. To je osobito istinito kod postupaka oblikovanja jer oni ne utječu na funkcionalnost vašeg koda i - u većini slučajeva - može se kasnije naknadno promijeniti.

    Mrzite li element standarda kodiranja, mislite li da bi trebalo dodati nešto? Javite nam u komentarima!