Standardy kodowania dla WordPressa [Przewodnik]

Powodem, dla którego mamy standardy kodowania w ogóle (nie tylko dla WordPressa) jest stworzyć znajome środowisko dla programistów praca nad projektem. WordPress w szczególności obejmuje szeroką gamę produktów. Od samego rdzenia do motywów i wtyczek, jest wiele rzeczy do obejrzenia - i wiele do zrobienia.

Jeśli wszyscy formatują swój kod w ten sam sposób, używają komentarzy, tego samego stylu dokumentacji i tak dalej, współpraca staje się o wiele łatwiejsza, a krzywa uczenia się dołączenia do nowego projektu nie będzie tak stroma.

Potrzeba spójności w WordPressie jest zwiększona przez stan, w którym znajduje się podstawa kodu. WordPress nie stosuje podejścia ściśle zorientowanego obiektowo i nie używa wzorca MVC. Projekty zgodne z wytycznymi OOP i MVC bez wyjątku (jak Laravel) mają spójność i najlepsze praktyki “pieczone w” ze względu na ich strukturę.

WordPress jest niestety dojrzały do kodowania spaghetti, aka robić co chcesz. Najlepsze praktyki są trudne do egzekwowania po prostu dlatego, że produkty wykorzystujące zły kod mogą działać równie dobrze (na powierzchni).

Postępując zgodnie ze standardami kodowania WordPress możesz dowiedzieć się trochę o etosie kodowania WordPressa, stworzyć więcej produktów zgodnych z WordPress. pokaż społeczności, którą ci zależy, i walcz z kodem wysokiej jakości.

Więcej na stronie Hongkiat.com:

10 najgorszych koszmarów dla programistów internetowych
5 powodów, dla których CSS może być najtrudniejszym językiem dla wszystkich
30 Wspólne reakcje Programiści mają problemy z poprawnością

Kilka uwag na temat standardów

Normy nie definiują dobra i zła. Możesz nie zgadzać się z regułą, na przykład zawsze używaj nawiasów klamrowych, nawet jeśli nie są one potrzebne. Celem standardów kodowania WordPress nie jest decydowanie, czy masz rację, czy nie. Decyduje, jak to zrobić w WordPressie.

Standardy nie nadają się do debaty. Korzystanie ze standardów nie jest miejscem, w którym można przeciwstawić się stylowi wcięć, którego nie lubisz. Jeśli coś jest w standardach kodowania, zrób to w ten sposób. Programiści WordPress pokochają Cię za to! Powiedziawszy to, jeśli nie zgadzasz się z czymś, podnieś swój głos i daj znać ludziom. Zawsze można robić rzeczy lepiej, ale styl kodowania należy zmieniać tylko wtedy, gdy pozwalają na to standardy.

Spójność nad zatrzymaniem odbytu. Jeśli jesteś w ostatnich 10% swojego projektu i właśnie odkryłeś, że używasz niepoprawnej konwencji nazewnictwa dla klas, nie przełączaj się w połowie drogi. W mojej osobistej opinii wolałbym czytać coś konsekwentnie niepoprawnego niż coś, co czasami jest poprawne, a czasem nie. Zawsze możesz napisać skrypt, aby zmienić rzeczy za jednym zamachem, lub przeczytać kod na końcu.

Przestrzeganie standardów jest trudne! Umieszczenie klamry na tej samej linii co funkcja zamiast linii poniżej jest całkiem łatwe, nawet jeśli przyzwyczaiłeś się wcześniej do uderzenia. Jednakże, gdy trzeba pomyśleć o 100 małych regułach, cały proces staje się nieco podatny na błędy. Pomimo mojego trudnego stanowiska w sprawie przestrzegania standardów jestem tak samo winny jak każdy inny w popełnianiu błędów. Pod koniec dnia nieprawidłowe wcięcia nie są nieodwołalnym grzechem. Postaraj się przestrzegać wszystkich zasad, dowiesz się wszystkiego na czas.

Standardy kodowania WordPress

Obecnie WordPress ma cztery przewodniki, po jednym dla każdego używanego języka: PHP, HTML, Javascript i CSS. Stanowią one część większego zasobu wiedzy, podręcznika Core Contributor Handbook. Przejście przez wszystko zajęłoby trochę czasu, więc podkreśliłem kilka fragmentów z czterech języków, które często widzę, jak ludzie się mylą.

PHP

PHP jest głównym językiem WordPressa i jest dość luźnym językiem, który sprawia, że jest gotowy do regulacji.

Style brace

Klamry początkowe powinny być zawsze umieszczane na końcu linii. Powiązane instrukcje powinny być umieszczone w tej samej linii, co poprzedni nawias zamykający. Najlepiej ilustruje to przykład kodu:

if (warunek) // Zrób coś elseif (warunek) // Zrób coś else // Zrób coś

Hojne wykorzystanie przestrzeni

Nie jestem fanem zmiażdżonego kodu (mam zły wzrok), dlatego szczególnie lubię go egzekwować. Umieść spacje po przecinki, i po obu stronach logiczny, porównanie, strunowy i operatorzy przypisania, po Jeśli, elseif, dla, dla każdego i przełącznik oświadczenia i tak dalej.

Łatwiej powiedzieć, gdzie nie należy dodawać spacji! Jedyne czasy, w których nie należy dodawać spacji, to kiedy typowanie lub tablice odniesienia.

Dość mylącym wyjątkiem od wyjątku są tablice, w których klucz tablicy jest zmienną, w tym przypadku użyj spacji. Ten przykład powinien to wyjaśnić:

funkcja my_function ($ complete_array = null, $ key_1 = 4, $ key_2 = 'bar') if (null == $ array_array) $ final_array = $ complete_array;  else $ key_1 = (liczba całkowita) $ key_1; $ final_array [0] = 'this'; $ final_array [$ key_1] = 'is'; $ final_array [$ key_2] = 'an'; $ final_array ['last'] = 'example';  return $ final_array;

Konwencje nazewnictwa

To może być trudne do przyzwyczajenia, szczególnie jeśli pochodzisz z różnych środowisk. W skrócie:

Nazwy zmiennych powinno być wszystkie małe litery, słowa oddzielone podkreśleniami
Nazwy klas powinien użyć wielkie litery oddzielone podkreśleniami. Akronimy powinno być wszystko duże litery
Stałe powinno być wszystkie wielkie litery, podbitych przez podkreślenia
Nazwy plików powinno być wszystkie małe litery, oddzielone kreskami

Warunki Yoda

Zapisywanie warunków w inny sposób, niż jesteś przyzwyczajony, zapobiegnie błędom parsowania. Wygląda to trochę dziwnie, ale jest to lepszy kod.

if ('Daniel' === $ name) echo 'Napisz artykuł, który chcesz';

HTML

HTML nie ma wielu powiązanych z nim reguł, mógłbym wymyślić sporo, aby uczynić rzeczy bardziej modułowymi. Jest tylko pięć reguł, które musisz znać podczas pisania HTML:

Twój kod musi walidować się z walidatorem W3C.
Samozamykające się znaczniki HTML muszą mieć dokładnie jedną spację przed ukośnikiem (jest to ta, której osobiście nienawidzę, ale jest to specyfikacja W3C, a nie tylko zwierzak WordPressa)
Atrybuty i tagi muszą być małymi literami. Jedynym wyjątkiem jest sytuacja, gdy wartości atrybutów są przeznaczone do spożycia przez ludzi, w którym to przypadku powinny być wpisane w sposób naturalny.
Wszystkie atrybuty muszą mieć wartość i muszą być cytowane (pisanie nie jest poprawne)
Wcięcia powinny być uzyskiwane za pomocą zakładek i powinny być zgodne z logiczną strukturą.

CSS

CSS to kolejny luźno napisany język, więc jest tu również mnóstwo pracy. Mimo to standardy są dość łatwe dla programistów.

Selektory

Selektory powinny być tak kwalifikowane, jak to konieczne, być czytelne dla ludzi, wszystkie małe litery ze słowami oddzielonymi myślnikami, a selektory atrybutów powinny używać podwójnych cudzysłowów. Oto zwięzły przykład:

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

Zamówienie własności

Standardy uznają tutaj potrzebę osobistej przestrzeni, ponieważ nie zalecają określonej kolejności reguł CSS. Co oni robić powiedzmy, że powinieneś przestrzegać struktury semantycznej ma sens. Grupuj właściwości według ich relacji lub grupuj je alfabetycznie, po prostu nie wypisuj ich losowo.

Największą przyczyną losowości jest “och, ja też muszę dodać margines” a następnie, aby dodać go do dołu. Weź dodatkowe 0,3 sekundy i dodaj regułę w logicznym miejscu.

Pokaz
Pozycjonowanie
Model skrzynki
Kolory i typografia
Inny

.profile-modal display: block; pozycja: absolutna; left: 100px; top: 90px; tło: # ff9900; kolor: #fff;

Formatowanie wartości

To jest jedno miejsce, w którym szczególnie nienawidzę widzieć niespójności. Jeśli nie postępujesz zgodnie z wytycznymi, jest to wciąż lepsze niż czasami spacja przed wartością; czasami używając skrótów, czasami nie; czasami używa jednostek na wartości 0, czasami nie, itp.

Formatowanie wartości jest dość złożone, ale to przychodzi naturalnie z jakąś praktyką. Spójrz na dokładny przewodnik w Kodeksie do formatowania swoich wartości.

Javascript

Z mojego doświadczenia wynika, że JavaScript jest najbardziej podatny na przechodzenie wszędzie. Podczas gdy wielu deweloperów zna znaczną ilość Javascript, uczyło się to stopniowo, jako refleksja nad HTML, CSS i PHP. Kiedy dopiero zaczynasz z nowym językiem, popełniasz dużo więcej błędów i jeśli te błędy nie powodują fatalnych błędów, mogą zostać w tobie zakorzenione.

W wielu przypadkach normy odnoszą się do limitu linii lub stanu “jeśli linia nie jest zbyt długa”. Odnosi się to do przewodnika jQuery Style Guide, który nakłada a Limit 100 znaków na liniach. Przewodnik WordPress jest oparty na przewodniku jQuery, więc dobrym pomysłem jest również jego przeczytanie.

Średniki

Jest to najprostsza zasada, ale często pomijana. Nigdy, nigdy, pomiń średnik tylko dlatego, że twój kod będzie działał bez niego. To po prostu niedbałe.

Wcięcie

Karty powinny być zawsze używane do wcięć. Powinieneś także wcisnąć zawartość zamknięcia, nawet jeśli zawartość całego pliku jest zawarta w jednym. Nie jestem pewien, dlaczego, ale nieumiejętne zamknięcie najwyższego szczebla zawiodło mnie jeszcze zanim przeczytałem standardy.

Łamanie linii

Podczas łamania długich ciągów zawsze przerwij linię po operatorze, nie zostawiaj zmiennej zwisającej. To sprawia, że na pierwszy rzut oka staje się oczywiste, że linia jest uszkodzona i nie zapomniałeś o średniku.

Ponadto, jeśli warunek jest długi, podziel go na wiele linii i dodaj przed nim dodatkową kartę. Ten wygląda bardzo dziwnie w moich oczach, ale separacja, którą dodaje między stanem a ciałem, jest bardzo widoczna.

if (firstCondition () && secondCondition () && thirdCondition ()) var html = 'Ta linia składa się ze słów' + n + ', więc powinna być podzielona po' + 'operatora';

jQuery Iteracja

Zgodnie ze standardami iteracja jQuery (jQuery.each ()) powinien być używany tylko w obiektach jQuery. Powinieneś użyć podstawowego dla, dla w, podczas pętle w Javascript do iteracji nad innymi kolekcjami.

Wniosek

Jest wiele rzeczy do zapamiętania i śledzenia oraz nie ma możliwości, aby ktoś mógł zastosować to wszystko za jednym razem. Powinieneś zabrać swój kod jak najbliżej standardów i pracować dokładnie nad nimi.

W mojej opinii spójność jest najważniejszą zasadą. Lepiej jest konsekwentnie robić coś niepoprawnie niż zmieniać w połowie. Jest to szczególnie prawdziwe w przypadku praktyk formatowania, ponieważ nie wpływają one na funkcjonalność kodu i - w większości - można łatwo zmienić partię później.

Czy nienawidzisz elementu standardów kodowania, czy uważasz, że coś powinno zostać dodane? Daj nam znać w komentarzach!