10 błędów początkujących Frontend Developerów część 1

błędy frontend deweloperów

W programowaniu od samego początku warto dbać o dobre praktyki. Jednak czasami w trakcie nauki można przeoczyć lub zbagatelizować pewne kwestie. Stąd u początkujących Frontend Developerów pojawiają się błędy w kodzie. Razem z Mariuszem Bugajskim, autorem bloga blog.bugajsky.pl i zwycięzcą konkursu Daj się Poznać 2017, zdecydowaliśmy się napisać serię postów o tej tematyce, aby pomóc w eliminacji takich błędów.

Pamiętaj:

  1. Unikaj nadużywania id
  2. Unikaj nadawania stylów elementom w HTML
  3. Nie ładuj wszystkich skryptów w sekcji head dokumentu
  4. Nadawaj nazwy w języku angielskim
  5. Zmieniaj nazwy klasy/id/funkcji we wszystkich miejscach gdzie są używane
  6. Uważaj na ścieżki do plików
  7. Pamiętaj o semantyce
  8. Strzeż się literówek
  9. Pamiętaj o initial-scale=1 w meta tagu viewport
  10. Unikaj niepotrzebnego zagnieżdżania i nadużywania tagów div
  11. Bonus 😉

Poniżej znajdziesz wyjaśnienie do każdego z tych podpunktów.

1. Unikaj nadużywania id

Nie wszystkie elementy w Twoim kodzie HTML muszą mieć id. Nadanie id powinno być przemyślane i mieć swój konkretny cel. Jeśli nie zamierzasz stylować danego elementu używając id, bądź manipulować nim poprzez użycie JavaScript, nie jest ono potrzebne. Pamiętaj również, że id jest unikatowe – tylko jeden element na stronie może mieć dane id.

Można np. używać pseudoselektorów (tj. first-child), które umożliwiają wybieranie elementów bez nadawania im klasy czy id.

See the Pen Good example of naming by SowaProgramuje (@sowaProgramuje) on CodePen.

Tutaj stylujemy bezpośrednie dzieci elementu o klasie .menu oraz korzystamy z pseudoselektora, dzięki któremu nie musimy stylować elementu przez id.

2. Unikaj nadawania stylów elementom w HTML

Pamiętaj, że HTML jest językiem do opisywania struktury, dlatego unikaj dodawania stylów na poszczególnych elementach za pomocą atrybutu <style> (style inline). Najlepiej zapisywać style w jednej regule w CSS.

Dlaczego należy tak robić?

Ponieważ jest to antypattern, czyli łamanie podstawowych założeń. W razie jakiś problemów z kodem będzie Ci dużo łatwiej go debugować, jeśli style będą tylko w CSSie. Nie będziesz musieć przeszukiwać dwóch różnych plików lub co gorsza nadpisywać kodu. To prowadzi do bałaganu, a tego każdy Frotend Developer powinien unikać jak ognia.

Czasami bywa tak, że manipulujemy kodem używając do tego JavaScript. Na przykład po kliknięciu na button zmieni on kolor z czerwonego na niebieski. W tym przypadku najlepiej jest nadać elementowi klasę, która będzie nadawała mu dane styl.

Używając jQuery i metody .css() nadajemy atrybut w HTML

See the Pen Change button color jQuery by SowaProgramuje (@sowaProgramuje) on CodePen.

Używając metody .addClass() nie dodajemy stylów inline tylko klasę

See the Pen NgYeXR by SowaProgramuje (@sowaProgramuje) on CodePen.

3. Nie ładuj wszystkich skryptów w sekcji head dokumentu

Jeśli nie potrzebujesz, aby kod JavaScript był ładowany w sekcji head, należy umieścić go przed tagiem zamykającym body. Wynika to z tego, że skrypty ładują się synchronicznie, czyli jeśli masz przykładowo 5 różnych skryptów które ładujesz w sekcji head to muszą się one w całości pobrać zanim w ogóle dojdzie do budowania DOM, co znacznie opóźni ładowanie strony internetowej. Dlatego jeśli nie potrzebujesz, aby skrypt odpalił się przed załadowaniem DOM umieszczaj go przed </body>.

4. Nadawaj nazwy w języku angielskim

W programowaniu bardzo duży nacisk stawia się na uniwersalność kodu. Stąd nadawanie nazw klas, funkcji itd. w innym języku niż angielski może przysporzyć problemy. Wyobraź sobie co by było, gdybyś trafił / trafiła do projektu, w którym nazwy pisane są w języku Swahili. Mogłoby być dość ciężko ze zrozumieniem co w danym kodzie się dzieje. Dlatego pamiętaj, używaj języka angielskiego, obecnie jest to standard w tej branży i tego się trzymajmy. 😉 Więcej o nadawaniu nazw pisałam tutaj.

5. Zmieniaj nazwy klasy/id/funkcji we wszystkich miejscach gdzie są używane

Twój kod nie działa, a chwilę wcześniej zmieniłeś / zmieniłaś klasę bądź id jakiegoś elementu lub nazwę funkcji? Istnieje spore prawdopodobieństwo, że nazwa nie została uaktualniona wszystkich miejscach, w których jest używana. Jeśli chcesz zmienić nazwę – użyj wyszukiwania we wszystkich plikach i zastąp konkretną nazwę.

6. Uważaj na ścieżki do plików

Nie wyświetla się jakaś grafika w Twoim projekcie? A może nie ładują Ci się style? Pierwsza rzecz jaką należy sprawdzić w takiej sytuacji to ścieżka do pliku, którą podałeś/podałaś. Sprawdź też czy nie zrobiłeś literówki w nazwie pliku lub folderu, oraz czy rozszerzenie pliku się zgadza np.: pułapką jest .jpg oraz .jpeg.

<img src=”heroimage.jpg”> – w przypadku, gdy plik heroimage.jpg znajduje się w tym samym folderze co dany plik HTML

<img src=”folderName/heroimage.jpg”> – w przypadku, gdy heroimage.jpg w podfolderze folderu, w którym jest plik HTML

<img src=”/folderName/heroimage.jpg”> – w przypadku, gdy heroimage.jpg jest w rootcie

<img src=”../heroimage.jpg”>w przypadku, gdy heroimage.jpg poziom wyżej (gdy musisz się cofnąć)

7. Pamiętaj o semantyce

Semantyka to dostosowanie tagów w htmlu do tego czym są dane elementy na stronie tj. jeśli chcesz zrobić listę używaj tagu <ul> bądź <ol> a nie <p>.

To nie jest semantyczny kod:

See the Pen Non semantic code by SowaProgramuje (@sowaProgramuje) on CodePen.

To jest semantyczny kod:

See the Pen Example of semantic code by SowaProgramuje (@sowaProgramuje) on CodePen.

To nie zawsze jest takie oczywiste np.: jeśli tworzymy menu to również używajmy listy, a nie divów i paragrafów. Tak samo jeśli chcemy opisać input to używaj tagu <label> a nie <p>, ponieważ <label> jest stworzony właśnie do tego.

Nie nadużywaj tagu <h1>, jest zarezerwowany dla najważniejszych treści na stronie np. : tytuł artykułu.

8. Strzeż się literówek

Literówki to kolejny powód dla którego Twój kod może nie działać. Zanim poprosisz o pomoc starszego programistę upewnij się, że dobrze przepisałeś nazwę klasy, funkcji czy jakiegoś atrybutu. Mi osobiście kilka razy zdarzyło się zamiast src=” ” napisać scr=” ” i potem się bardzo dziwiłam, że zdjęcie się nie ładowało.

Jak uniknąć literówek?

  • Korzystaj z wtyczek do edytorów, które automatycznie podpowiadają konkretne własności, wartości, nazwy metod i funkcji.
  • Kopiuj nazwy klas, id – w ten sposób unikniesz niepożądanych problemów

9. Pamiętaj o initial-scale=1 w meta tagu viewport

Twoja strona nie jest responsywna pomimo, że dodałeś media queries? Upewnij się, że w sekcji head dokumentu masz meta tag:

<meta name=”viewport”, content=”initial-scale=1.0”, content=”width=device-width” >

Dlaczego jest to potrzebne?

To powoduje, że strona skaluję się do takiej szerokości jakiej jest dane urządzenie, na którym wyświetlana jest strona.

Na portalu CSS-tricks jest artykuł na ten temat.

10. Unikaj niepotrzebnego zagnieżdżania, a także nadużywania tagów div

Struktura w HTML powinna być wykonana jak najmniejszą ilością elementów. Jeśli potrzeby dwie kolumny i w każdej paragraf to nie zagnieżdżaj ich w divy tylko nadaj im szerokość po 50%.  Tak samo jeśli chcesz aby np. span zajmował całą szerokość rodzica, to nie wrappuj go w diva tylko nadaj mu display block.

Przykład zbyt dużego i niepotrzebnego zagnieżdżenia:

See the Pen Divitis by SowaProgramuje (@sowaProgramuje) on CodePen.

Poprawny sposób:

See the Pen Paragraf by SowaProgramuje (@sowaProgramuje) on CodePen.

Rezultat jest ten sam, ale w przykładzie drugim mamy bardziej przejrzystą strukturę.  Trzymajmy się zasady KISS (Keep it simple Stupid)

Bonus! 🙂

11. Usuwaj martwy kod

Martwy kod (ang. dead code) to fragment kodu, który nic nie wnosi do naszego projektu: tj. kod który jest zakomentowany bądź np. funkcja, która nigdzie nie jest i nigdy nie zostanie wykorzystana. Jeśli jakiś fragment kodu nie jest potrzebny należy go usunąć. Najlepiej jest to zrobić podczas refactoringu.

Podsumowanie

Postaraj się aby dbanie o dobrą jakość kodu stało się Twoim nawykiem. To naprawdę nie kosztuje wiele, a robi ogromną różnicę.

Spodobał Ci się ten artykuł i chcesz dowiedzieć się więcej? Koniecznie odwiedź bloga Mariusza Bugajskiego, tam niebawem znajdziesz nasz kolejny wartościowy post z tej serii.

Masz jakieś pytania? Daj znać w komentarzu

19 odpowiedzi do “10 błędów początkujących Frontend Developerów część 1”

    1. No właśnie nie do końca 🙂

      Tak jest wg specyfikacji i tak również korzystałem z tych tagów, ale okazało się że specyfikacja to jedno, a implementacja i życie to co innego.
      Okazuje się bowiem, że wiele tagów h1 na stronie i związany z tym mechanizm „outline” nie jest wspierany.

      Samo W3C to przyznało rok temu rekomendując używanie tagów h1-h6 „po staremu”:
      https://twitter.com/htmlwg/status/721694848911335424?ref_src=twsrc%5Etfw&ref_url=http%3A%2F%2Fadrianroselli.com%2F2013%2F12%2Fthe-truth-about-truth-about-multiple-h1.html

      https://lists.w3.org/Archives/Public/public-html/2016Apr/0032.html :
      „Given that this bug has been around, and not fixed in browsers, for many
      years, we are proposing to remove the suggestion, and return to the model
      where elements h1..h6 have a defined level of their own.”

      1. Widziałem materiał na kodu. je o labelach.. To dopiero mobilizacja 😉
        Aż chciało by się więcej takich porad 😉
        Pozdrawiam

    2. Cześć Paweł – Są różne powody nie używania wielokrotnie tagów H1 – główne to również SEO. Poszukaj jesli temat cię interesuje 😉

  1. > Jeśli nie zamierzasz stylować danego elementu używając id, bądź manipulować nim poprzez użycie JavaScript, nie jest ono potrzebne.

    Nie jest to do końca prawda. `[id]` często służy także do tworzenia punktów nawigacyjnych – wówczas powinno być w języku treści strony → http://tutorials.comandeer.pl/html5-blog.html#artykul-naglowki-jako-punkty-nawigacyjne

    Co do nienadawania klas: uważałbym z tą radą. Warto się zastanowić, czemu niemal wszystkie metodologie i konwencje nazewnicze dla CSS operują niemal wyłącznie na klasach. Problem z podejściem typu `.menu > li` jest takie, że wprowadzamy sobie niepłaską specyficzność, a tym samym: utrudniamy utrzymanie takiego CSS-a → https://csswizardry.com/2016/11/nesting-your-bem/#specificity

    Co do 3.: warto też sprawdzić atrybut `[defer]` i ładowanie skryptów jak najwyżej w `head` (przed stylami). Tak po prawdzie może wyjść wydajniej niż klasyczne umieszczenie skryptów na końcu `body` 😉

    PS polecam linkować do bardziej sprawdzonych źródeł niż W3Schools → https://forum.pasja-informatyki.pl/34559/w3schools-nie-szerzmy-falszywej-propagandy?show=34559#q34559 zwłaszcza, że nawet w tym artykule o ścieżkach są popisane głupoty, np. rada, żeby nie używać pełnych URL-ów w `[src]` zaboli nas w RSS-ach, a poza tym mieszane jest pojęcie URL-a z pojęciem ścieżki do pliku.

    1. Dzięki za komentarz i cenne uwagi. Co do id masz rację, zapomniałam o tym przypadku. Rada dotycząca klas nie była jasno przeze mnie wyjaśniona stąd pojawiły się nieporozumienia. Jasne, są takie atrybuty jak defer czy async, dobrze o tym wiedzieć. Generalnie, ładowanie skryptów to temat rzeka, można by tu poruszyć temat bundlowania, minifikacji, CDNów itd. Jest to dobry pomysł na osobny artykuł. Co do W3Schools faktycznie, mogłam znaleźć bardziej wiarygodne źródło, już usunęłam ten link. Jeszcze raz dzięki 🙂

  2. Bardzo podstawowe i niektóre oczywiste, ale też musisz zwrócić uwagę na nowe standardy, bo co do zagnieżdżeń to sam często stosuje żeby flexem przestylować i nadać odpowiedni layout, a o stylowaniu inline się zgodzę, że powinno się tego unikać, ALE co w przypadku reacta który wręcz „namawia” do użycia takiego stylowania, a jednak masa osób stoi za nim murem(oczywiście można też inaczej to robić, ale dużo rzeczy i tak sprowadza się do styli inline)

    1. Dzięki za komentarz. Co do Reacta, dobrze wiedzieć. Ja osobiście nie mogę się wypowiedzieć na ten temat, bo jeszcze nie miała okazji się go nauczyć.

    2. @Mati w przypadku Reacta mamy do czynienia tak naprawdę z niebezpiecznym trendem, który dąży do przesunięcia HTML-a i CSS-a bezpośrednio do JS-a. Z tego też powodu CSS staje się niczym innym, jak zwykłym obiektem JS. Niemniej w zależności od wybranej implementacji jest to różnie przerabiane na ostateczny kod i niekoniecznie skończymy ze stylami inline.

      PS czemu mój drugi komentarz nie został zaakceptowany?

  3. Użycie ID nie musi mieć nic wspólnego ze stylowaniem czy JavaScriptem. Element, który ma ID będzie w widoku przeglądarki gdy przejdzie się do strony z adresem gdzie to ID jest w URLu.

  4. Cytat:
    „Zmieniaj nazwy klasy/id/funkcji we wszystkich miejscach gdzie są używane”
    Dobre IDE posiada funkcję refactor, która zrobi to za Was.

    Cytat
    „Struktura w HTML powinna być wykonana jak najmniejszą ilością elementów”.

    W przypadku RWD dodatkowe kontenery są często niezbędne.

    1. Patro, masz rację. Dzięki, że o tym wspomniałeś, zdecydowanie warto używać różnych pluginów, które pomagają w minimalizowaniu błędów i przyspieszają pracę. Zwróć też uwagę, że np. w kursach online dla osób początkujących często nie ma takich udogodnień, co w sumie jest dobre ponieważ uczy myślenia, debugowania oraz dokładności. Co do RWD, tak zgadza się jak najbardziej.

  5. + za tematykę tego posta.
    Jednakże początkujący programista, przeglądając listingi 2. punktu i go kopiując (nie zaglądając w HTML-a), i próbując odpalić, nie będzie wiedział, czemu mu ten program nie działa -> brakuje jasnej informacji w treści posta, że są opisane metody jQuery, a nie JS.
    „Czasami bywa tak, że manipulujemy kodem używając do tego JavaScript. (…)
    Używając metody .css() nadajemy atrybut w HTML.”
    W vanilla JS zupełnie inaczej by się to zrobiło (w sensie kodu) 🙂

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *