Стандарти за кодиране за WordPress [Guide]

Причината, поради която въобще имаме стандарти за кодиране (не само за WordPress) е да създаване на позната среда за програмисти работа по проект. WordPress в частност обхваща голямо разнообразие от продукти. От самото ядро до теми и плъгини, има какво да се погледне - и много да се обърка.

Ако всеки форматира кода си по един и същи начин, използва коментари, същия стил на документиране и така нататък, съвместната работа става много по-лесна и кривата на обучение за присъединяване към нов проект няма да бъде толкова стръмен.

Необходимостта от сближаване в WordPress се увеличава от състоянието, в което е кодовата база. WordPress не следва строг обектно-ориентиран подход и не използва модел MVC. Проектите, които следват OOP и MVC насоките без изключение (като Laravel), имат последователност и най-добри практики “изпечен” поради тяхната структура.

WordPress за съжаление е узрял за кодиране на спагети, известен още като правиш каквото искаш. Най-добрите практики са трудни за прилагане, само защото продуктите с лош код могат да работят също така добре (на повърхността).

Следвайки WordPress кодиращите стандарти можете да научите малко за кодирането на WordPress, да създадете повече съвместими с WordPress продукти. покажете на общността, че ви е грижа, и вие препирате код с високо качество.

Повече на Hongkiat.com:

10-те най-лоши кошмари за уеб разработчици
5 причини, поради които CSS може да бъде най-трудният език за всички
30 Общи реакции Програмистите имат, когато нещата се объркат

Някои бележки по стандартите

Стандартите не определят правилно и неправилно. Може да не сте съгласни с някое правило, например винаги трябва да се използват скоби, дори ако не са необходими. Целта на стандартите за кодиране на WordPress не е да решавате дали сте прави или не, а да решите как трябва да се прави в WordPress.

Стандартите не са предмет на дебат. Използването на стандартите не е мястото да се противопоставим на стила на вдлъбнатината, който не ви харесва. Ако нещо е в стандартите за кодиране, направете го по този начин. WordPress разработчиците ще ви обичат за това! Това каза, ако не сте съгласни с нещо в нея, повдигнете гласа си и оставете хората да знаят. Винаги е възможно да правите неща по-добре, но трябва само да промените стила на кодиране, ако стандартите го позволяват.

Съвместимост с аналитичната ретентивност. Ако сте в последните 10% от проекта си и току-що сте открили, че използвате неправилни правила за именуване на класове, не превключвайте по средата. По мое лично мнение, бих предпочел да прочета нещо постоянно погрешно, отколкото нещо, което понякога е правилно, а понякога не. Винаги можете да напишете скрипт, за да промените нещата наведнъж, или да прочетете кода си в края.

Следните стандарти са трудни! Поставянето на скоба на същата линия като функцията вместо линията по-долу е доста лесно, дори ако сте свикнали да натискате Enter преди. Въпреки това, когато трябва да помислите за 100 малки правила, целият процес става малко податлив на грешки. Въпреки твърдата ми позиция по отношение на стандартите, аз съм виновна като всеки друг в правенето на грешки. В края на деня неправилното вмъкване не е неотменим грях. Опитайте се да следвате всички правила, ще научите всичко навреме.

Стандарти за кодиране в WordPress

В момента WordPress има четири ръководства, по един за всеки основен използван език: PHP, HTML, Javascript и CSS. Те съставляват част от по-голямо количество знания, наръчникът на основния сътрудник. Преминаването през всичко ще отнеме известно време, затова подчертах някои откъси от четирите езика, които често виждам, че хората грешат.

PHP

PHP е основният език на WordPress и е доста слабо типизиран език, което го прави зрял за регулиране.

Стилове на скоби

Началните скоби трябва винаги да се поставят в края на редовете. Свързаните оператори трябва да бъдат поставени на същата линия като предишната затваряща скоба. Това се демонстрира най-добре с пример за код:

ако (условие) // правим нещо elseif (условие) // правим нещо друго // правим нещо

Щедро използване на пространството

Аз не съм фен на смачкан код (имам лошо зрение), така че това е един, който особено искам да наложа. Поставете интервали след запетаи, и от двете страни на логичен, сравнение, низ и оператори на присвояване, след ако, ElseIf, за, за всеки и ключ изявления и т.н..

По-лесно е да се каже къде не трябва да се добавят пространства! Единственият път, когато не трябва да добавяте интервали, е кога стереотипа или рефериращи масиви.

По-скоро объркващо изключение от изключението са масивите, където масивът е променлива, в този случай използвайте интервал. Този пример трябва да направи това ясно:

функция my_function ($ complete_array = null, $ key_1 = 4, $ key_2 = 'bar') if (null == $ complete_array) $ final_array = $ complete_array;  else $ key_1 = (integer) $ key_1; $ final_array [0] = 'това'; $ final_array [$ key_1] = 'е'; $ final_array [$ key_2] = 'an'; $ final_array ['last'] = 'пример';  върнете $ final_array;

Конвенции за наименуване

Това може да е трудно да се свикне, особено ако идвате от различни среди. Накратко:

Имената на променливите би трябвало всички малки букви, думи, разделени с долни черти
Имената на класовете трябва да използвате главни думи разделени с долни черти. Съкращения трябва да бъде всичко Главна буква
константи би трябвало всички главни букви, издавани от подчертани
Имената на файловете би трябвало всички малки букви, разделени с тирета

Условия на Йода

Условията за писане в обратната посока, отколкото сте свикнали, ще попречат на грешките при анализа. Изглежда малко странно, но е по-добър код.

if ('Daniel' === $ name) echo 'Напишете статия, която искате';

HTML

HTML няма много правила, свързани с него, можех да измисля доста неща, за да направя нещата по-модулни. Има само пет правила, които трябва да знаете, когато пишете HTML:

Вашият код трябва да бъде валидиран спрямо валидатора на W3C.
Самозатварящите се HTML тагове трябва да имат точно едно място преди наклонената черта (това е лично мразя, но това е W3C спецификация, а не просто WordPress домашен любимец)
Атрибутите и маркерите трябва да са с малки букви. Единственото изключение е, когато стойностите на атрибутите са предназначени за консумация от човека, в който случай те трябва да се въвеждат по естествен път.
Всички атрибути трябва да имат стойност и трябва да бъдат цитирани (писане не е правилно)
Вдлъбнатината трябва да бъде постигната с помощта на раздели и следва логическа структура.

CSS

CSS е друг слабо типизиран език, затова и тук има много работа. Дори и така, стандартите са доста лесни за програмистите.

селектори

Селекторите трябва да са толкова квалифицирани, колкото е необходимо, да са четливи, да бъдат с малки букви, с думи, разделени с тирета, а селекторите на атрибути да използват двойни кавички. Ето кратък пример:

input [type = "text"], въвеждане [type = "password"], .name-field background: # f1f1f1;

Поръчка за собственост

Стандартите признават необходимостта от някакво лично пространство, тъй като не предписват конкретна поръчка за правилата на CSS. Какво те правя да кажем, че трябва да следвате една семантична структура, която има смисъл. Групирайте свойствата по техните връзки или ги групирайте по азбучен ред, просто не ги записвайте случайно.

Най-голямата причина за случайността е “О, аз също трябва да добавите марж” и след това продължете да го добавите на дъното. Вземете допълнителните .3 секунди и добавете правилото в логичното място.

показ
позициониране
Модел на кутията
Цветове и типография
друг

.профил-модален (дисплей: блок; позиции: абсолютен; лява: 100px; отгоре: 90px; фон: # ff9900; цвят: #fff;

Форматиране на стойност

Това е едно място, в което особено мразя да виждам несъответствия. Ако не следвате указанията, това все още е по-добре, отколкото понякога да виждате пространство преди стойността; понякога използвайки стенография, понякога не; понякога използвайки единици на 0 стойности, понякога не и т.н..

Форматирането на стойността е доста сложно, но това естествено идва с някаква практика. Обърнете внимание на точното ръководство в Codex за форматиране на вашите стойности.

Javascript

В моя опит Javascript е най-предразположен към навсякъде. Докато много разработчици знаят значителна част от Javascript, той е усвоен постепенно, като мисъл за HTML, CSS и PHP. Когато започваш с нов език, правиш много повече грешки и ако тези грешки не предизвикват фатални грешки, те могат да станат вкоренени във вас.

В много случаи стандартите се отнасят до лимит или състояние “ако дадена линия не е твърде дълга”. Това се отнася за jQuery Style Guide, който налага a Лимит от 100 знака по линиите. Ръководството на WordPress се основава на ръководството jQuery, така че е добра идея да се даде същото и на четене.

точка и запетая

Това е най-простото правило, но често се пренебрегва. Никога, никога, не пропускайте точка и запетая само защото кодът ви ще работи без него. Това е просто небрежно.

редовете

За отстъпване винаги трябва да се използват раздели. Също така трябва да отстъпите съдържанието на затварянето, дори ако съдържанието на целия файл се съдържа в едно. Не съм сигурна защо, но безпроблемно затваряне на най-високо ниво ме подслушваше още преди да прочета стандартите.

Прекъсващи линии

Когато прекъсвате дългите низове, винаги прекъсвайте линията след оператор, не оставяйте променлива да виси. На пръв поглед става очевидно, че линията е счупена и не сте забравили запетая.

Също така, ако условието е дълго, разбийте го на няколко реда и добавете допълнителен раздел преди него. Това изглежда много странно за очите ми, но разделянето, което добавя между състоянието и тялото, е много видимо.

if (firstCondition () && secondCondition () && thirdCondition ()) var html = 'Този ред се състои от' + n + 'думи, така че трябва да бъде разбит след' + 'оператор';

jQuery итерация

Според стандартите jQuery итерация (JQuery.each ()) трябва да се използва само на обекти jQuery. Трябва да използвате basic за, за / в, докато цикли в Javascript за повторение над други колекции.

заключение

Има много какво да се отбележи и да следите и няма начин някой да приложи всичко това наведнъж. Трябва да вземете кода колкото се може по-близо до стандартите и да работите точно по тях.

По мое мнение последователността е най-важното правило. По-добре е последователно да правите нещо неправилно, отколкото да превключвате по средата. Това е особено вярно при форматирането, тъй като те не засягат функционалността на кода и - в по-голямата си част - може лесно да бъде променен на партиди по-късно.

Мразиш ли елемент от стандартите за кодиране, мислиш ли, че трябва да се добави нещо? Кажете ни в коментарите!