Dbanie o wysoką jakość kodu jest zalecane i szanowane już od dawna. Jednak dotyczy to w głównej mierze języków programowania. Kod HTML (i CSS) jak dotąd traktowane były – poza wąskim gronem zapaleńców – na ogół na zasadzie: „nieważne jak, byle działało”, a przynajmniej ja odnosiłem zawsze takie wrażenie. Jednak kod strony internetowej również można napisać solidnie, tak aby był łatwy w utrzymaniu i modyfikowaniu, albo całkowicie marnie.

Pierwsza bardzo ważna zasada jest bardzo prosta: selektorem CSS nie powinien być tag HTML – zarówno „goły” (np. h1, article, div), jak i nawet w połączeniu z klasą. Z bardzo prostego powodu – zdarza się, że element, który ma mieć dane style, może występować również jako inny tag HTML. Na przykład przycisk może być czasem elementem a, czasem elementem button, a czasem nawet innym. Podobnie czasami chcemy, aby cała mała sekcja, która normalnie jest elementem section, była tym razem odnośnikiem. Jeśli będziemy określać zasadę stylowania tylko po klasie, to z punktu widzenia CSS nic się nie zmieni, gdy zamiast w section zamkniemy tę sekcję w a. Gdybyśmy jednak w kodzie CSS uwzględnili też tag HTML, tworząc np. selektor section.my-section, to wtedy nie byłoby to takie proste i musielibyśmy oprócz zmiany kodu HTML i dodania tam odnośnika, zmieniać także kod CSS. Wynika z tego, że używanie tagów HTML w selektorach CSS jest kłopotliwe, obniża poziom abstrakcji, a także zmniejsza czytelność i czystość naszego kodu.

Jednak równocześnie ważne jest, by nie popadać w fanatyzm, stąd osobiście dopuszczam kilka wyjątków. Chodzi o linki i akapity w danym bloku tekstu, ponieważ są one niejako częściami tej treści, które pełnią konkretne funkcje, dla których zostały stworzone. Ponadto przemawia za tym także zdrowy rozsądek – linków i akapitów w bloku tekstu jest na tyle dużo, że nie ma powodu, aby każdemu z nich przypisywać dodatkową klasę (no chyba, że dany link ma mieć wygląd inny niż domyślny dla linku w tekście). Dopuszczam również stylowanie elementów listy za pośrednictwem zagnieżdżonego tagu HTML (np. .horizontal-list > li). Element li jest bardzo specyficzny i skonkretyzowany i nie powinien występować w innym kontekście niż lista, dlatego uważam, że nie ma powodu komplikować kodu kolejną klasą. Oprócz tego nie mam problemu z odnoszeniem się bezpośrednio po tagu do elementów html i body, bo zakładam, że zawsze są one tylko w jednym egzemplarzu.

Kolejny problem, jaki powoduje tworzenie selektorów zawierających tagi HTML, i do tego znacznie poważniejszy, jest taki, że często taki sam element HTML w danym kontekście powinien mieć odmienny wygląd niż w innym – bo przecież na stronie mamy bardzo wiele sekcji, nagłówków, tytułów, a co dopiero div'ów! Niedoświadczona osoba może próbować później wybrnąć z tego tworząc zagnieżdżone selektory CSS (np. section h2, albo section header h3). To natomiast powoduje kolejne problemy. Oprócz wymieniania wielu innych wad takiego rozwiązania, wystarczy przytoczyć jedną z bardziej ogólnych zasad pisania dobrego kodu (która nie dotyczy tylko pisania stron internetowych, jak zresztą wiele innych wymienionych w tym artykule). Otóż dobrze napisany kod powinien być możliwy do ponownego użycia, a do tego jak najbardziej uniwersalny i niezależny od innych elementów systemu. Oczywiście stosowanie zagnieżdżonych selektorów CSS to absolutnie uniemożliwia. Jeśli wygląd elementów zależy od ich położenia w hierarchii dokumentu, to stają się one całkowicie nieprzenośne i zależne od struktury aplikacji, a dodatkowo bardzo podatne na działanie kodu istniejącego już w systemie, w którym chcemy użyć naszego rozwiązania lub odwrotnie – powodujące efekty uboczne w projekcie, do którego miałyby być przeniesione.

Wspomniałem o tym przed chwilą, więc już śpieszę z wyjaśnieniem i rozwijam myśl. Jest to szczególnie widoczne w przypadku tytułów h1-h6. Chodzi o to, że „ważniejszy” (będący wyżej w hierarchii) nagłówek nie zawsze musi być wizualnie większy i lepiej widoczny. Nieraz można spotkać nagłówki sekcyj złożone z dwóch tytułów – małego, który jednak precyzyjnie określa zawartość rozdziału, oraz większego i dłuższego, który w barwny sposób opisuje, o czym możemy później przeczytać. Oczywiście to ten pierwszy jest semantycznie ważniejszy i powinien być wyżej w hierarchii jako np. h2, a ten drugi zawarty w h3.

Myślę, że największy wpływ na wytworzenie się zasad dobrego kodu HTML miało opracowanie metodyki BEM. Wielu osobom wydaje się, że jest to tylko konwencja kodowania, ale kryje się za tym o wiele więcej. Liczne dobre zasady pisania kodu stron internetowych można oczywiście stosować bez korzystania z koncepcji BEM, jeśli ktoś się uprze, jednak uważam, że ta metodyka to krok milowy w historii pisania dobrego kodu HTML i sama w sobie bardzo porządkuje kod.

Głównym założeniem metodyki BEM jest dzielenie strony na niezależne od siebie moduły/obiekty, które dzięki swej niezależności można efektywnie wykorzystywać (z małymi modyfikacjami) w wielu miejscach na stronie, a nawet w wielu projektach. Sprawia to, że nasz kod jest bardziej uniwersalny i na odpowiednim poziomie abstrakcji.

Bardzo ważna jest zasada mówiąca o tym, że obiekty rozpoznajemy tylko i wyłącznie po klasie. Tag nie ma znaczenia, liczy się tylko klasa. Jest to bardzo istotne, gdyż taki sam wygląd możemy chcieć nadać obiektom, które „pod maską” będą innymi elementami HTML. Np. przycisk może być czasami linkiem (a), a czasami… przyciskiem (button). Wszystkie nazwy zapisujemy małymi literami, wyrazy oddzielając myślnikami.

1. Blok (block) – jest to niezależny obiekt na stronie internetowej, który może występować samodzielnie w wielu różnych miejscach nie będąc zależnym bezpośrednio od innych obiektów. Może to być na przykład: przycisk, pole formularza, formularz, artykuł, sekcja, nagłówek.

   Klasę bloku tworzymy po prostu poprzez podanie jego nazwy. Np. button, section-title, section-header, article, quote, form, form-field.

2. Element – część bloku nie mogąca występować samodzielnie poza blokiem – jest z nim nierozerwalnie związana i odeń zależna, np. nagłówek artykułu, element listy, podpis zdjęcia.

   Klasę elementu tworzymy przez dodanie nazwy elementu do nazwy bloku łącząc je podwójnym podkreśleniem, np. article__header, list__item, picture__caption, button__icon-container.

   Bardzo istotne jest – a wielu młodych front-end developerów o tym zapomina, albo nie zdaje sobie z tego sprawy – to, że elementy w bloku mogą mieć tylko jeden poziom zagłębienia. To oznacza, że nie może istnieć element elementu, który niektórzy próbują zapisywać np. w taki sposób: person-showcase__details_name. Takie coś nie może istnieć. Taka reguła nie ma za zadanie utrudniać pisania kodu programiście, ale przeciwnie – wymuszać pisanie kodu wysokiej jakości.

   Ktoś być może zapyta: „Ale dlaczego? Przecież czasem może zdarzyć się sytuacja, że coś takiego będzie potrzebne!” Otóż ośmielę się powiedzieć, że jeśli ktoś uważa, że powinien stworzyc taki „podelement”, to najprawdopodobniej źle przemyślał strukturę bloku, a przede wszystkim nie zaprojektował go na odpowiednim poziomie abstrakcji (o czym niżej). Prawdę mówiąc nawet ciężko było mi wymyślić taki przykład, bo cokolwiek nie wymyśliłem, wydawało mi się kompletnie bez sensu i nie wiedziałem, czy będzie to dobrym przykładem. Dlatego powyżej posiłkowałem się kodem, jaki napisał pewien młody developer podczas wdrażania projektu, który miałem okazję koordynować.

3. Modyfikator (modifier) – stan bloku lub elementu, który zmienia niektóre cechy, np. zablokowany przycisk, większy wariant tytułu, inny rodzaj lub wariant kolorystyczny przycisku czy specjalne zachowanie elementu np. obrócony wariant ikony.

   Klasę modyfikatora tworzymy przez dodanie nazwy modyfikatora do klasy bloku lub elementu za podwojonym znakiem myślnika. Np. section-title--large, button--disabled, button--secondary, button--stroke, icon-arrow--right. Co ważne, klasę taką dodajemy do już istniejącej, a zatem w przypadku jednego modyfikatora (a może ich być dowolna liczba) element będzie posiadał dwie klasy (o ile nie zawiera innych pobocznych klas) – jedną określającą go i drugą przypisującą mu dany modyfikator. Np. <button class=”button button--secondary”>(…)</button>.

Obiekty powinny być zaprojektowane w taki sposób, aby można było łączyć ze sobą różne modyfikatory i żeby jedne nie nadpisywały drugich (chyba, że użycie dwóch modyfikatorów na raz jest nielogiczne, bo użycie jednego wyklucza użycie drugiego, np. dwa warianty kolorystyczne). Np. przycisk mógłby posiadać wariant stroke i dwa warianty kolorystyczne – domyślny oraz primary. Powinien on mieć zatem określony wygląd dla samotnego modyfikatora stroke (można powiedzieć, że z kolorem domyślnym) oraz w połączeniu z modyfikatorem primary.

Właściwie to wszystko, co należy wiedzieć o metodyce BEM. Są to proste zasady, które już same w sobie porządkują kod, jednak to mimo wszystko tylko gramatyka. Chciałbym teraz zaprezentować istotne cechy dobrego kodu, jakie udało mi się wyróżnić podczas pracy jako front-end developer. Dla uważnego czytelnika z doświadczeniem w programowaniu prawdopodobnie niektóre zasady mogą się okazać znajome. Nic dziwnego, bo część z nich jest analogiczna do zasad dobrego kodu obiektowego, jednak niektóre są charakterystyczne tylko dla HTMLa.

Bloki powinny być możliwie małe (w sensie liczności rodzajów elementów) i realizować jedno zadanie. Jeśli blok jest zbyt obszerny, to znak, że być może powinien zostać rozdzielony na kilka mniejszych. Jeśli jakaś część bloku mogłaby istnieć samodzielnie poza blokiem, to również oznacza, że najprawdopodobniej powinna zostać wydzielona do nowego niezależnego bloku.

Na rysunku 2 ukazano projekt wpisu na blogu. Natomiast na listingu 1 widać przykładową implementację z zachowaniem metodyki BEM, jednak bez zachowania innych zasad pisania dobrego kodu.

Projekt posta zakodowano zgodnie z zasadami metodyki BEM, jednak samo podążanie za „gramatyką” metodyki nie wystarcza. Kod ten pozostawia wiele do życzenia. Zgodnie z tym, co powiedzieliśmy przed chwilą, część elementów zdecydowanie nie musi być związana tylko z wpisem na blogu. Takie obiekty jak tytuł, data, lista kategorii czy wreszcie treść mogą jak najbardziej istnieć samodzielnie i w innym kontekście, stąd powinny być niezależnymi blokami, a nie elementami bloku post. Na Listingu 2 przedstawiono udoskonalony kod z Listingu 1.

Tak, jak zostało przed chwilą zaproponowane, wydzielono niektóre elementy do niezależnych bloków. I tak oto element post__date stał się blokiem date, element post__title zastąpiono obiektem simple-title, post__content zamieniono na text, a złożony (już sama jego złożoność powinna sugerować uniezależnienie go do osobnego bloku) element post__categories wydzielono do bloku categories z elementami categories__item.

Uczyniono tak, ponieważ tytuł sformatowany w ten sposób może pojawić się w wielu miejscach na stronie; nie musi (a nawet nie powinien) wyglądać w ten sposób li tylko tytuł posta. Wydzielenie go do osobnego bloku pozwala zachować spójność w obrębie całej strony internetowej. To samo dotyczy bloku tekstu czy listy kategorii, ale także daty. Bloków tekstu na stronie mamy bardzo dużo i, jeśli witryna jest dobrze zaprojektowana, w wielu miejscach tekst będzie wyglądał tak samo w różnych kontekstach. Nie ma więc powodu, by stylować go 20 razy tak samo dla elementów różnych bloków osobno. Dzięki temu oprócz ułatwienia sobie pracy zyskujemy znowu coś bardzo ważnego w dobrym projekcie – spójność i konsekwencję.

Kolejną ważną zasadą dobrego kodu jest wysoki poziom abstrakcji. Oznacza to mniej-więcej tyle, że nasze moduły, bloki, klasy powinny być tak ogólne, jak tylko pozwala na to projekt i zdrowy rozsądek. Dzięki temu nasz kod jest bardziej uniwersalny i możliwy do zastosowania w wielu kontekstach i sytuacjach. Nie piszemy go tylko po to, by użyc go raz w danym projekcie i później o nim zapomnieć. Z powodzeniem możemy zastosować go również w innych projektach. Zasada pojedynczej odpowiedzialności doskonale komponuje się z tą regułą i wymusza jej co najmniej szczątkowe stosowanie, ale zapewnienie odpowiedniego poziomu abstrakcji to coś więcej niż tylko pojedyncza odpowiedzialność.

Wróćmy jeszcze na chwilę do poprzedniego przykładu, ponieważ nie został on jeszcze wystarczająco skomentowany i zaprezentowany. Kod na Listingu 2 wygląda już całkiem dobrze, jednak pewnemu blokowi brakuje jeszcze – no właśnie! – odpowiedniego poziomu abstrakcji. Chodzi oczywiście o blok categories. Realizuje on co prawda tylko jedno zadanie i to na pewnym poziomie abstrakcji (jest listą kategorii), jednak zdecydowanie należałoby pójść o krok dalej (a przynajmniej w przypadku takiego projektu graficznego, jaki kodujemy) i maksymalnie go uogólnić. No bo przecież pozioma lista elementów oddzielanych od siebie małymi kropkami wcale nie musi być tylko listą kategorii, prawda? Możemy w ten sposób przedstawić obszary zainteresowań jakiejś osoby, a nawet składniki w przepisie kulinarnym. Aż prosi się, aby zaimplementować to jako np. bullet-list, inline-bullet-list czy też po prostu horizontal-list (czy coś w tym rodzaju, w zależności od tego jak dużo podobnych list mamy na stronie i jak długie nazwy klas lubimy).

Na Listingu 3 widać w końcu efekt naprawdę dobrej implementacji zaproponowanego projektu. Można z satysfakcją się przyjrzeć i powiedzieć: „Dobra robota!” :). Uważny czytelnik z pewnością dostrzeże również pewną ciekawą rzecz, że nasz post ostatecznie został tylko zarządcą układu, który ma w sobie niezależne elementy i jedynie układa je w odpowiedni sposób. Bardzo często dzieje się tak z „dużymi” bytami jak post, artykuł, nagłówek (top) lub stopka strony czy nawet górna belka strony lub boczne menu, a także blokami „biznesowymi” specyficznymi dla danej strony.

Można w tym momencie wyróżnić jeszcze dwie ważne zasady…

Często spotykam się z pewną obawią niektórych webmasterów przed tworzeniem niewielkich bloków. Można-by odnieść wrażenie, że jeśli dany blok jest zbyt mały, wydaje im się to błędem i pakują go do innego bloku, który akurat mają pod ręką. Nie ma powodu tak robić! Ktoś porywczy mógłby wręcz powiedzieć, że im mniejszy blok, tym lepiej! Ja jednak nie lubię skrajności i wolę posłużyć się omówionymi już zasadami pojedynczej odpowiedzialności i niezależności modułów. Jeśli dany blok rzeczywiście realizuje swoje zadanie i nie jest zależny od innych elementów strony, to zdecydowanie wszystko jest jak należy i powinien być niezależnym blokiem, nawet jeśli nie ma żadnych elementów, tak jak np. wspomniany wcześniej simple-title czy date.

Szczególnymi przypadkami pojedynczej odpowiedzialności są (1) bloki realizujące funkcjonalność, albo (2) układające obiekty w obrębie dokumentu. Te drugie nie robią nic poza odpowiednim ułożeniem innych bloków (zarówno funkcjonalnych jak i innych kontenerów) i są raczej rzadko możliwe do ponownego użycia w innym projekcie, ponieważ układ elementów mimo wszystko na ogół jest dość specyficzny dla każdego projektu. Natomiast bloki funkcjonalne reprezentują konkretny wycinek rzeczywistości (przycisk, tytuł, nagłówek, notka biograficzna, cytat), który niesie za sobą jakąś treść lub możliwość działania dla użytkownika – pełni jakąś funkcję na stronie. Oczywiście blok funkcjonalny (moduł) może lokalnie w swoim obrębie zarządzać układem, jednak nie powinno to być jego główne zadanie. Powinien przede wszystkim odpowiadać za konkretny wygląd – kolory, rozmiary itp.

Poniżej możemy zobaczyć, że mamy zarządcę układu (icon-items), który jedynie rozmieszcza w odpowiedni sposób bloki, które ma w sobie, ale tak naprawdę nawet nie wie, czym są te obiekty. Jego intersuje tylko to, aby ułożyć je po trzy w rzędzie. Natomiast bloki, którymi zarządza (icon-item), z kolei nie wiedzą, jak są układane, i ich to zbytnio nie interesuje, bo mają one za zadanie przedstawić informacje w postaci bloku tekstu z ikoną i ewentualnie zająć odpowiednią szerokość. Idąd dalej, blok icon-item również nie wie, jaką ikonę do niego wsadzimy, albo jaki tytuł; on ma je tylko ułożyć w odpowiedni sposób, robiąc odstępy odpowiedniej wielkości i ewentualnie tworząc jakieś dodatkowe dekoracje (w tym przypadku akurat ich nie ma, ale ikona mogłaby np. być oddzielona od treści jakąś kreską czy czymś).

Wysokiej jakości kod oznacza mniejsze koszty utrzymania aplikacji i wprowadzania zmian. Korzystanie z założeń metodyki BEM znacznie podnosi jakość kodu HTML, jednak należy pamiętać, że BEM to nie tylko określony sposób zapisywania klas – to przede wszystkim filozofia dzielenia strony na niezależne moduły, które można wykorzystać w wielu projektach.

Należy również pamiętać, aby nasze komponenty spełniały zasadę pojedynczej odpowiedzialności i aby były na odpowiedniem poziomie abstrakcji. To z pewnością zaowocuje większą spójnością projektu i bezproblemowymi modyfikacjami, a także możliwością wykorzystania stworzonych modułów ponownie w kolejnych aplikacjach (zwłaszcza np. formularzy, przycisków, tytułów, itp.). Pomaga to również lepiej zorganizować pracę w zespole i uniknąć niespójności wśród części systemu tworzonych przez różne osoby. Oprócz tego zyskamy też większą satysfakcję i przyjemność z pisania czystego kodu, a dobre samopoczucie i wysokie morale są przecież również bardzo ważne.