Kodavimo standartai „WordPress“ [vadovas]

Priežastis, kodėl mes vis dar turime kodavimo standartus (ne tik „WordPress“) sukurti pažįstamą programuotojų aplinką projektą. „WordPress“ ypač apima įvairius produktus. Nuo pačios pagrindinės iki temų ir įskiepių yra daug ką pažvelgti - ir daug ką sujungti.

Jei visi koduoja savo kodą tokiu pačiu būdu, naudoja komentarus, tą patį dokumentacijos stilių ir tt, dirbant kartu tampa daug lengviau, o prisijungimo prie naujo projekto mokymosi kreivė nebus tokia staiga.

Sanglaudos poreikį WordPress didina valstybė, kurioje yra kodo bazė. „WordPress“ nesilaiko griežto objekto orientuoto požiūrio ir nenaudoja MVC modelio. Projektai, kurie vadovaujasi OOP ir MVC gairėmis be išimties (pvz., Laravel), turi nuoseklumą ir geriausią praktiką “kepti” dėl jų struktūros.

Deja, „WordPress“ yra subrendęs spageti kodavimui daryti viską, ką norite. Geriausia praktika yra sunku įgyvendinti, nes produktai, kuriuose naudojamas blogas kodas, gali veikti taip pat gerai (ant paviršiaus).

Sekdami WordPress kodavimo standartus, galite šiek tiek sužinoti apie „WordPress“ kodavimo etosą, sukurti daugiau „WordPress“ suderinamų produktų. parodyti bendruomenei, su kuria jūs rūpinatės, ir sugalvoti aukštos kokybės kodą.

Daugiau apie „Hongkiat.com“:

• 10 blogiausių košmarų žiniatinklio kūrėjams
• 5 priežastys, kodėl CSS gali būti sunkiausia visų kalbų kalba
• 30 Bendros reakcijos Programuotojai turi kai viskas vyksta blogai

Kai kurios pastabos apie standartus

Standartai neapibrėžia teisingai ir neteisingai. Jūs galite nesutikti su taisyklėmis, pavyzdžiui, visada turėtų būti naudojamos petnešos, net jei jų nereikia. „WordPress“ kodavimo standartų tikslas nėra nuspręsti, ar esate teisus ar neteisingas, nuspręsti, kaip tai turėtų būti daroma „WordPress“.

Standartai nėra svarstomi. Standartų naudojimas yra ne vieta, kur galima pasipriešinti tam, kuris jums nepatinka. Jei kažkas yra kodavimo standartuose, tai atlikite taip. WordPress kūrėjai jus mylės! Beje, jei nesutinkate su kažkuo, pakelkite savo balsą ir leiskite žmonėms žinoti. Visada įmanoma geriau atlikti veiksmus, bet kodavimo stilių turėtumėte keisti tik tada, jei standartai tai leidžia.

Suderinamumas su analinio atsistatymo. Jei esate per paskutinius 10% savo projekto ir ką tik sužinojote, kad naudojote neteisingą pavadinimų paskyrimo klasę, nekeiskite viduryje. Mano nuomone, aš mieliau perskaityčiau kažką nuosekliai neteisingo nei kažkas, kas kartais yra teisinga ir kartais ne. Jūs visada galite parašyti scenarijų, kad pakeistumėte dalykus vienu metu, arba pabaigoje perskaitykite savo kodą.

Šie standartai yra sudėtingi! Tvirtai pritvirtinus tą pačią liniją, kaip ir toliau, eilutė yra gana paprasta, net jei esate pripratę prie pat pradžių. Tačiau, kai jums reikia galvoti apie 100 mažų taisyklių, visas procesas tampa šiek tiek klaidingas. Nepaisant mano griežtos pozicijos dėl šių standartų, aš taip pat kaltas kaip ir kiti dėl klaidų. Dienos pabaigoje neteisinga įdėjimas nėra neatšaukiama nuodėmė. Pabandykite geriausia laikytis visų taisyklių, viską sužinosite laiku.

WordPress kodavimo standartai

Šiuo metu „WordPress“ turi keturis vadovus, po vieną kiekvienai pagrindinei kalbai: PHP, HTML, Javascript ir CSS. Jie sudaro didesnės žinios, pagrindinio prisidedančiojo vadovo, dalį. Vykdant viską, reikės šiek tiek laiko, todėl išryškinau kai kurias iš keturių kalbų, kurias dažnai matau, kad žmonės klaidingai žiūri.

PHP

„PHP“ yra pagrindinė „WordPress“ kalba ir yra gana laisvai įvesta kalba, kuri verčia reguliuoti.

Brace stiliai

Pradžios petnešos visada turi būti išdėstytos linijų pabaigoje. Susiję teiginiai turėtų būti pateikiami toje pačioje eilutėje kaip ir ankstesnė uždarymo sąvarža. Tai geriausiai įrodo kodo pavyzdys:

jei (sąlyga) // Kažkas elseif (sąlyga) // Kažkas kitur // Kažkas

Turtingas erdvės naudojimas

Aš nesu girgždinto kodo gerbėjas (turiu blogą regėjimą), todėl aš ypač norėčiau jį įgyvendinti. Uždėkite vietas po kableliais, ir abiejose pusėse logiška, palyginimas, eilutė ir priskyrimo operatoriai, po to jei, elseif, dėl, kiekvienam ir jungiklis pareiškimai ir pan.

Tai lengviau pasakyti, kur nereikėtų pridėti erdvių! Vienintelis laikas, kai neturėtumėte pridėti tarpų, yra kada tipų nustatymas arba nuorodų matricos.

Gana paini išimtis išimčiai yra masyvai, kuriuose masyvo raktas yra kintamasis, šiuo atveju naudokite erdvę. Šis pavyzdys turėtų tai padaryti aiškiai:

funkcija my_function ($ complete_array = null, $ key_1 = 4, $ key_2 = 'bar') if (null == $ complete_array) $ final_array = $ complete_array;  other $ key_1 = (sveikasis skaičius) $ key_1; $ final_array [0] = 'tai'; $ final_array [$ key_1] = 'yra'; $ final_array [$ key_2] = 'an'; $ final_array ['last'] = 'pavyzdys';  grąžinti $ final_array; 

Pavadinimo konvencijos

Tai gali būti sunku priprasti, ypač jei esate iš skirtingų aplinkų. Trumpai tariant:

• Kintamieji pavadinimai turėtų būti visų mažųjų raidžių, žodžiai, atskirti pabraukimais
• Klasės pavadinimai turėtų naudoti kapitalizuoti žodžiai atskirti pabraukimais. Akronimai turėtų būti visi didžiosios raidės
• Konstansai turėtų būti visi didieji, išryškinti pabraukimai
• Failų pavadinimai turėtų būti visų mažųjų raidžių, atskirti brūkšneliais

Yoda sąlygos

Kitaip tariant rašydami sąlygas, neleisite suprasti klaidų. Tai atrodo šiek tiek keista, bet tai yra geresnis kodas.

jei ('Daniel' === $ name) echo 'Rašyti straipsnį, kurį norėsite'; 

HTML

HTML neturi daug taisyklių, susijusių su juo, galėčiau sugalvoti gana daug, kad būtų dar labiau modulinė. Rašant HTML, turite žinoti tik penkias taisykles:

1. Jūsų kodas turi patvirtinti W3C tikrintuvą.
2. Savarankiškai uždaromos HTML žymos turi būti vienoje vietoje prieš priekinį brūkšnį (tai aš asmeniškai nekenčiu, bet tai yra W3C specifikacija, ne tik „WordPress“ naminių gyvūnėlių žvilgsnis)
3. Atributai ir žymos turi būti visos mažosios. Vienintelė išimtis yra tada, kai atributų vertės yra skirtos žmonėms vartoti, tokiu atveju jos turėtų būti įvestos natūraliai.
4. Visi atributai turi turėti vertę ir turi būti nurodyti (rašyti neteisingas)
5. Atskyrimas turėtų būti pasiektas naudojant skirtukus ir laikantis loginės struktūros.

CSS

CSS yra dar viena laisvai įvesta kalba, todėl čia taip pat reikia daug darbo. Vis dėlto standartai koduotojams yra gana paprasti.

Pasirinkėjai

Pasirinkėjai turėtų būti tokie pat kvalifikuoti, kaip būtina, būti žmogiški skaitymai, būti mažosiomis raidėmis su žodžiais, atskirtais brūkšneliais, ir atributų parinkėjai turėtų naudoti dvigubas kabutes. Štai glaustas pavyzdys:

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

Nekilnojamojo turto užsakymas

Standartai pripažįsta, kad čia reikalinga tam tikra asmeninė erdvė, nes jie nenumato specialios tvarkos CSS taisyklėms. Ką jie daryti pasakyti, kad jūs turėtumėte sekti semantinę struktūrą logiška. Grupuokite savybes pagal savo santykius arba grupuokite juos abėcėlės tvarka, tiesiog neužrašykite jų atsitiktinai.

Didžiausia atsitiktinumo priežastis yra “taip pat turiu pridėti maržą” ir tada pridėkite jį prie apačios. Paimkite papildomas 0,3 sekundes ir pridėkite taisyklę loginėje vietoje.

• Ekranas
• Padėties nustatymas
• Dėžutės modelis
• Spalvos ir tipografija
• Kita

.profilio modalas ekranas: blokas; pozicija: absoliutus; kairėje: 100px; viršuje: 90px; fonas: # ff9900; spalva: #fff; 

Vertės formatavimas

Tai yra viena vieta, kur aš ypač nekenčiu prieštaravimų. Jei nesilaikysite gairių, tai dar geriau nei kartais matyti erdvę prieš vertę; kartais vartojant trumpąsias, kartais ne; kartais naudoja 0 vienetų, kartais ne, ir tt.

Vertės formatavimas yra gana sudėtingas, bet tai natūraliai ateina su tam tikra praktika. Pažvelkite į tikslius „Codex“ nurodymus, kaip formuoti savo vertybes.

„Javascript“

Mano patirtis Javascript yra labiausiai linkusi eiti visur. Nors daugelis kūrėjų žino nemažą „Javascript“ kiekį, jis buvo išmoko palaipsniui, kaip požiūris į HTML, CSS ir PHP. Kai tik pradėsite naują kalbą, darote daug daugiau klaidų ir jei šios klaidos nesukelia mirtinų klaidų, jie gali įsitraukti į jus.

Daugeliu atvejų standartai susiję su linijos riba arba būsena “jei linija nėra per ilga”. Tai reiškia „jQuery Style Guide“, kuris nustato a 100 simbolių apribojimas linijose. „WordPress“ vadovas yra pagrįstas „jQuery“ vadovu, taigi ir gera idėja taip pat skaityti.

Semikolonai

Tai yra paprasčiausia taisyklė, tačiau dažnai tai nepaisoma. Niekada niekada nepraleiskite kabliataškio, nes jūsų kodas veiks be jo. Tai tiesiog aplaidus.

Įtempimas

Skirtukai visada turi būti naudojami atkirpimui. Taip pat turėtumėte įvesti uždarymo turinį, net jei viso failo turinys yra viename. Aš nesu įsitikinęs, kodėl, bet neišardytas aukščiausio lygio uždarymas mane sugadino dar prieš perskaičius standartus.

Lūžimo linijos

Lūžant ilgas eilutes, visada nutraukite liniją po operatoriaus, nepalikite kintamo karkaso. Dėl to iš pirmo žvilgsnio akivaizdu, kad linija yra pažeista ir jūs neužmiršote semikolono.

Be to, jei sąlyga yra ilga, suskirstykite ją į kelias eilutes ir pridėkite papildomą skirtuką prieš jį. Tai atrodo labai keistai mano akims, tačiau atskyrimas, kurį jis prideda tarp būklės ir kūno, yra labai matomas.

jei (firstCondition () &&c secondCondition () && third-kondicionavimas ()) var html = 'Ši eilutė susideda iš „+ n +“ žodžių, todėl ji turėtų būti suskirstyta po „+“ operatoriaus; 

jQuery Iteracija

Pagal standartus jQuery iteracija (jQuery.each ()) turėtų būti naudojami tik „jQuery“ objektuose. Turėtumėte naudoti pagrindinį dėl, už / į, kol „Javascript“ kilpos, skirtos iteracijai per kitas kolekcijas.

Išvada

Yra daug pastabų ir sekti, ir nėra jokio būdo, kaip kažkas galėtų vienu metu taikyti visa tai. Turėtumėte naudoti savo kodą kuo arčiau standartų ir dirbti juos tiksliai.

Mano nuomone nuoseklumas yra svarbiausia taisyklė. Geriau nuosekliai daryti kažką neteisingai, nei persijungti į pusę. Tai ypač pasakytina apie formatavimo praktiką, nes jie neturi įtakos jūsų kodo funkcionalumui ir - daugiausia - vėliau gali būti lengvai pakeistas.

Ar nekenčiate kodavimo standartų elemento, ar manote, kad kažkas turėtų būti pridėta? Praneškite mums apie komentarus!