Podstawowe standardy kodowania za pośrednictwem PSR-1

Wczoraj omówiłem krótko o powodach używania PSR w porównaniu ze standardami kodowania WordPressa oraz o tym, kiedy i dlaczego. Ale to nie znaczy, że nie jest pozbawiony punktów zamieszania, zwłaszcza jeśli dopiero zaczynasz z nimi, prawda?

Mam na myśli to, że: powiedzmy, że pracujesz ze standardami kodowania WordPress od lat (ponieważ mogę się odnieść), a teraz jest cały nowy zestaw zasad i wytycznych, których należy przestrzegać. Ale to nie jest prosta sprawa zmiany jakiegoś odstępu i zmiany nazw plików.

Są jeszcze inne punkty do naśladowania, a każda z nich jest nakreślona, ​​całkiem dosłownie (PSR-1, PSR-2 itd.), jak coś powinno działać.

Więc jeśli chodzi tylko o podstawowe standardy kodowania opisane w PSR-1, na jakie problematyczne obszary możemy napotkać jako programiści WordPressa?

Podstawowe standardy kodowania (i skutki uboczne)

Nie planuję przejrzenia każdego z tych dokumentów i powtórzenia tego, czego możemy się już nauczyć, po prostu je czytając, ale myślę, że jest coś do powiedzenia, aby wziąć coś, czego wielu z nas albo robi lub doświadcza, i zobaczyć, jak to może się zmienić w ciągu kontekst WordPressa.

Weźmy efekty uboczne z podstawowego standardu kodowania (lub PSR-1 ), na przykład:

Plik POWINIEN deklarować nowe symbole (klasy, funkcje, stałe itp.) i nie powodować żadnych innych skutków ubocznych lub POWINIEN wykonywać logikę z efektami ubocznymi, ale NIE POWINIEN robić obu.

Wyrażenie „efekty uboczne" oznacza wykonanie logiki niezwiązanej bezpośrednio z deklarowaniem klas, funkcji, stałych itp., jedynie z dołączenia pliku.

Osobiście uważam, że druga fraza jest kluczem do zrozumienia i uniknięcia efektów ubocznych w naszym kodzie tak bardzo, jak to możliwe. Oznacza to, że wszystko, co robią nasze zajęcia, powinno być samowystarczalne lub spójne z czymś, co mogło zostać w jakiś sposób wstrzyknięte.

Niezależnie od tego, znalezienie kodu, który wprowadza efekt uboczny i wyczyszczenie go nie powinno być zbyt trudne. Właściwie użyję siebie jako przykładu.

Spójrz na ten konkretny fragment kodu :

Ten kod pochodzi bezpośrednio z Toggle Admin Notices. To prawda, jest to proste, a repozytorium pokazuje notatkę, jak to zmienić. To jednak pokazuje, o co chodzi, prawda?

Jakie jest rozwiązanie? Dzieje się to w formie automatycznego ładowania (które jest również omówione w PSR-4 ). Co z tego, jeśli miałbym go przerobić, aby prawidłowo podążał za PSR-1? Wtedy jeden ze sposobów refaktoryzacji może wyglądać tak :

Czy to świetny przykład? Prawdopodobnie nie. Ale to coś więcej niż tylko dołączanie plików. Włączenie tych plików powoduje, że ten pojedynczy plik wprowadza różne skutki uboczne.

Oznacza to, że ten jeden plik jest odpowiedzialny za dużo więcej niż tylko te cztery linijki kodu. Pomyśl o tym jako zawierającym wszystko, co implementują inne pliki. W tym momencie staje się bardziej złożona.

Więc weź ten pomysł i przenieś go do znacznie większego systemu, a zobaczysz, jak i dlaczego byłoby to problematyczne.

Oczywiście istnieją również alternatywne sposoby. A to tylko jeden przykład. A także autodeprecjonujące. Nie chodzi tu o pokazanie ostatecznego sposobu na zrobienie tego, ale o zasianie myśli o tym, jak projektujemy, planujemy, budujemy i włączamy klasy.

A co z widokami?

Jeśli chodzi o pisanie wtyczek, wolę traktować to, co użytkownicy zobaczą jako widoki. Ale wydaje się, że jest tu pewien haczyk: dołączanie plików jest uważane za kiepską praktykę, ponieważ powoduje to skutki uboczne.

Nie chcemy więc wyprowadzać logiki w naszych klasach, ale chcemy również oddzielić prezentację od logiki biznesowej.

Co mamy robić?

Skręt… polega na tym, że użyjemy do tego programowania obiektowego. Zaprojektujemy klasę generującą HTML przy użyciu szablonu PHP.

Zostało to dogłębnie omówione przez kogoś innego i bardzo polecam przeczytanie tego konkretnego postu, aby wziąć pod uwagę ideę skutków ubocznych, uniknąć ich i jak najwięcej zastosować solidne praktyki.

…A zasoby i powiązane pliki?

Wiem: pomysł odejścia od skutków ubocznych (nie mówiąc już o ich identyfikacji) może być początkowo dziwny, zwłaszcza gdy myślisz o pewnych rzeczach, które robiliśmy od tak dawna.

Może też rodzić pytania typu: Czy dołączanie plików JavaScript lub CSS jest niewłaściwe? To chyba temat na inny post. Pamiętaj jednak, że istnieją podstawowe funkcje API bezpośrednio z tym związane i mogą być częścią klasy ściśle odpowiedzialnej za to.

Jeśli celem klasy jest zrobienie dokładnie tego i tylko tego, a używa do tego funkcji API, to powiedziałbym, że prawdopodobnie jest w porządku.

Ale na razie dygresję w tej sprawie (a może to temat na komentarze lub kolejny post).

Zamiast tego utrzymuj lekcje szczupłe i celowe. Powinni postępować zgodnie ze stanami PSR-1 i unikać robienia takich rzeczy jak „[deklarowanie] nowych klas, funkcji, stałych itp.” oraz „[wykonywanie] logiki z efektami ubocznymi”.