Стандарди кодирања за ВордПресс [Водич]

Разлог због којег уопште имамо стандарде кодирања (не само за ВордПресс) је створите познато окружење за програмере радећи на пројекту. ВордПресс посебно обухвата широк спектар производа. Од самог језгра до тема и додатака, има много тога да се погледа - и много тога о чему се може мешати.

Ако сви форматирају свој код на исти начин, користи коментаре, исти стил документације и тако даље, заједнички рад постаје много лакши, а кривуља учења придруживања новом пројекту неће бити тако стрма.

Потреба за кохезијом у ВордПресс-у је увећана за стање у којем је база кода. ВордПресс не прати строги објектно оријентисани приступ и не користи МВЦ образац. Пројекти који слиједе ООП и МВЦ смјернице без изузетка (као Ларавел) имају досљедност и најбоље праксе “печено у” због њихове структуре.

ВордПресс је нажалост зрела за шпагетско кодирање радите шта год желите. Најбоље праксе се тешко примењују само зато што производи који користе лош код могу да функционишу једнако добро (на површини).

Пратећи ВордПресс стандарде кодирања можете научити нешто о етосу кодирања ВордПресса, креирати више ВордПресс компатибилних производа. покажите заједници да вам је стало, а ви испољавате висок квалитет.

Више на Хонгкиат.цом:

• 10 најгорих ноћних мора за веб програмере
• 5 разлога зашто би ЦСС могао бити најтежи језик свих
• 30 Заједничке реакције Програмери имају кад ствари крену погрешно

Неке напомене о стандардима

Стандарди не дефинишу исправно и погрешно. Можда се не слажете са правилом, нпр. Заградама треба увек користити, чак и ако нису потребне. Сврха ВордПресс стандарда кодирања није да одлучите да ли сте у праву или у криву, већ да одлучите како се то ради у ВордПресс-у.

Стандарди нису за дебату. Употреба стандарда није место да се заузмете против стила увлачења који вам се не допада. Ако је нешто у стандардима за кодирање онда то урадите на тај начин. ВордПресс програмери ће вас волети због тога! То је рекао, ако се не слажете са нечим тамо, подигните свој глас и пустите људе да знају. Увек је могуће радити ствари боље, али само требате промијенити свој стил кодирања ако стандарди то допуштају.

Конзистентност у аналној ретензивности. Ако сте у последњих 10% вашег пројекта и тек сте открили да сте користили погрешну конвенцију именовања за класе, немојте се пребацивати на пола пута. По мом личном мишљењу, радије бих прочитао нешто што је стално нетачно, него нешто што је понекад тачно, а понекад не. Увек можете написати скрипту да бисте променили ствари у једном покрету или прочитали код на крају.

Праћење стандарда је тешко! Постављање заграда на исту линију као функција умјесто линије испод је прилично лако, чак и ако сте навикли да прије притиснете типку Ентер. Међутим, када требате размислити о 100 малих правила, цијели процес постаје мало склон погрешкама. Упркос мом чврстом ставу о следећим стандардима, крив сам као и било ко други у прављењу грешака. На крају дана, погрешно увлачење није неопозив грех. Трудите се да пратите сва правила, све ћете научити на време.

ВордПресс Цодинг Стандардс

Тренутно ВордПресс има четири водича, по један за сваки главни језик: ПХП, ХТМЛ, Јавасцрипт и ЦСС. Они чине дио већег низа знања, Приручника за основне доприносе. Пролазак кроз све би потрајао па сам истакао неке исјечке са четири језика које често видим да људи погрешно схватају.

ПХП

ПХП је главни језик ВордПресса и прилично лабав тип који га чини зрелим за регулацију.

Браце Стилес

Почетни заграду треба увек поставити на крају редова. Сродне наредбе треба да буду постављене на исту линију као и претходна закључна заграда. Ово се најбоље демонстрира примјером кода:

иф (цондитион) // До Сометхинг елсеиф (цондитион) // До Сометхинг елсе // До Сометхинг

Великодушна употреба простора

Нисам љубитељ згњеченог кода (имам лош вид) тако да ово посебно волим да спроводим. Стави размаке после зарезе, и са обе стране логичан, поређење, низ и оператори доделе, после ако, елсеиф, за, за сваки и прекидач изјаве и тако даље.

Лакше је рећи гдје се простори не смију додавати! Једини пут када не би требало да додајете размаке јесте када типецастинг или референцирање низова.

Веома збуњујући изузетак од изузетка су поља где је арраи кеи је променљива, у овом случају, користите размак. Овај пример треба да буде јасан:

фунцтион ми_фунцтион ($ цомплете_арраи = нулл, $ кеи_1 = 4, $ кеи_2 = 'бар') иф (нулл == $ цомплете_арраи) $ финал_арраи = $ цомплете_арраи;  елсе $ кеи_1 = (интегер) $ кеи_1; $ финал_арраи [0] = 'ово'; $ финал_арраи [$ кеи_1] = 'је'; $ финал_арраи [$ кеи_2] = 'ан'; $ финал_арраи ['ласт'] = 'пример';  ретурн $ финал_арраи; 

Именовања конвенције

На ово се може тешко навићи, поготово ако долазите из различитих окружења. Укратко:

• Имена променљивих требало би сва мала слова, речи раздвојене подвлацењем
• Имена класа треба користити капитализоване речи раздвојене доњом цртом. Ацронимс би требало да буде све велика слова
• Константе требало би алл велика слова, подметнут подвучењем
• Имена датотека требало би сва мала слова, раздвојен цртама

Иода Цондитионс

Услови писања обрнуто него што сте навикли спречавају грешке при анализи. Изгледа помало чудно али је бољи код.

иф ('Даниел' === $ наме) ецхо 'Напишите чланак који желите'; 

ХТМЛ

ХТМЛ нема толико правила везаних за то, могао бих смислити доста тога да би ствари биле модуларне. Постоји само пет правила која морате знати приликом писања ХТМЛ-а:

1. Ваш код мора проверити ваљаност В3Ц валидатора.
2. Самозатварајуће ХТМЛ ознаке морају имати тачно један размак прије косе црте (ово сам ја особно мрзим, али то је В3Ц спецификација, а не само ВордПресс кућни љубимац)
3. Атрибути и ознаке морају бити сва мала слова. Једини изузетак је када су вриједности атрибута намијењене за људску потрошњу, у ком случају би се требале уписивати природно.
4. Сви атрибути морају имати вриједност и морају бити цитирани (писање није тачно)
5. Удубљење треба да се постигне помоћу табова и треба да следи логичку структуру.

ЦСС

ЦСС је још један лабаво откуцани језик, тако да и овде има доста посла. Упркос томе, стандарди се лако примењују кодерима.

Селектори

Селектори би требало да буду квалификовани колико је потребно, да буду читљиви, да буду читљиви малим словима, а речи одвојене цртама, а селектори атрибута би требало да користе двоструке наводнике. Ево кратког примера:

инпут [типе = "тект"], инпут [типе = "пассворд"], .наме-фиелд бацкгроунд: # ф1ф1ф1; 

Проперти Ордер

Стандарди препознају потребу за неким личним простором, јер не прописују посебну наредбу за ЦСС правила. Оно што урадити рећи да треба да следите семантичку структуру има смисла. Групирајте својства према њиховим односима или их групирајте по абецедном реду, само их не исписуј случајно.

Највећи узрок случајности је “Ох, такође морам додати маргину” а затим наставите да је додате на дно. Узмите додатних .3 секунди и додајте правило на логично место.

• Приказ
• Позиционирање
• Бок модел
• Боје и типографија
• Друго

.профиле-модал дисплаи: блоцк; позиција: апсолутна; лево: 100пк; врх: 90пк; бацкгроунд: # фф9900; цолор: #ффф; 

Форматирање вредности

Ово је једно место где посебно мрзим да видим недоследности. Ако не слиједите смјернице, то је још боље него понекад видјети простор испред вриједности; понекад користе стенографију, понекад не; понекад користе јединице на вредности 0, понекад не, итд.

Форматирање вредности је прилично сложено, али то природно долази са неким праксама. Погледајте тачан водич у Кодексу за форматирање ваших вредности.

Јавасцрипт

По мом искуству, Јавасцрипт је најподложнији свуда. Док многи програмери знају знатну количину Јавасцрипт-а, он је постепено учен као ХТМЛ, ЦСС и ПХП. Када тек почињете са новим језиком, правите много више грешака и ако те грешке не изазивају фаталне грешке, оне могу постати укорењене у вама.

У многим случајевима стандарди се односе на границу линије или стање “ако линија није предуга”. Ово се односи на јКуери Стиле Гуиде који намеће а Ограничење од 100 знакова на линије. Водич за ВордПресс је заснован на ЈКуери водичу, тако да је добра идеја и то прочитати.

Семицолонс

Ово је најједноставније правило, али је оно које се често превиђа. Никада, никада, не изоставите тачку-зарез само зато што ће ваш код радити без њега. То је само траљаво.

Увлачење

Картице треба увек користити за увлачење. Такође треба да увлачите садржај затварања чак и ако је садржај целог фајла садржан у једном. Нисам сигуран зашто, али ме је неупадљиво затварање на највишем нивоу гњавило чак и пре него што сам прочитао стандарде.

Бреакинг линес

Приликом разбијања дугих низова, увек прекините линију након оператора, не остављајте променљиву да виси. На први поглед је очигледно да је линија прекинута и да нисте заборавили тачку-зарез.

Такође, ако је услов дугачак, подијелите га на више редова и додајте додатни табулатор. Ово изгледа веома чудно за моје очи, али раздвајање које додаје између стања и тијела је врло видљиво.

иф (фирстЦондитион () && сецондЦондитион () && тхирдЦондитион ()) вар хтмл = 'Ова линија се састоји од' + н + 'речи, тако да би требало да буде оборена након' + 'оператора'; 

јКуери Итератион

Према стандардима јКуери итерација (јКуери.еацх ()) треба користити само на јКуери објектима. Требало би да користите основни за, за / ин, док петље у Јавасцрипту за понављање над другим колекцијама.

Закључак

Има много тога да се запази и прати и не постоји начин да се све то примени у једном покрету. Требало би да код користите што ближе стандардима и да радите на њиховом праћењу.

По мом мишљењу конзистентност је најважније правило. Боље је доследно радити нешто погрешно него пребацити на пола пута. Ово је посебно тачно када се ради о праксама форматирања јер оне не утичу на функционалност вашег кода и - у већини случајева - може се касније лако променити.

Да ли мрзите елемент стандарда кодирања, да ли мислите да треба додати нешто? Јавите нам у коментарима!