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

Avocode – co to jest i czy warto korzystać?

Ostatnio spotkałam się ze sporym problemem. Designer mojego klienta dostarczył mi pliki, które zaprojektował w Sketchu, czyli aplikacji do projektowania graficznego na Macu. Przekopałam internet w celu znalezieniu sposobu na otworzenie tych plików graficznych na Ubuntu bądź na Windowsie. Generalnie było ciężko, dlatego znalazłam inne rozwiązanie – zdecydowałam się wypróbować Avocode.

Avocode jest zarówno aplikacją desktopową jak i webową. Pozwala na otwieranie plików zarówno w formacie PSD jak i tych stworzonych w Sketchu. Program ten jest dostępny na Maca, Windowsa i Linuxa.

avocode-screen
Avocode – widok głowny
avocode-screen
W górnym menu dostępne jest kilka narzędzi: Hand, Select, Measure, Color, Slice, Note

 

Dlaczego Avocode jest fajnym narzędziem?

Pozwala na eksportowanie warstw lub elementów (pojedynczo lub kilka na raz.) Mamy możliwość eksportu w formatach: SVG, PNG, JPG oraz WEBP.   Elementy zapisane w SVG możemy od razu skalować 2x, 3x lub 4x razy.

avocode-screen
Eksportowanie elementu w różnych formatach

 

Generuje gotowe kawałki kodu: CSS, Less, Sass, SCSS, Stylus, Swift, Android, CSS w JS i React Native. Mamy gotowe informacje min. na temat wysokości, szerokości elementu, czcionki i jej rozmiaru, kolorów; wszystko od razu z odpowiednimi jednostkami.  Wystarczy skopiować jednym kliknięciem i wkleić do swojego edytora.

avocode-screen
Kawałek kodu opisujący button w CSS
avocode-screen
Ten sam button opisany w innym języku

 

Umożliwia tworzenie zespołów i dzielenie się projektami graficznymi. Komunikacja jest ułatwiona dzięki możliwości dodawania komentarzy.

avocode-screen
Dodawanie komentarzy

 

Avocode umożliwia proste kopiowanie tekstu od razu jako element HTML bądź eksportowanie go jako JPG lub PNG. Wystarczy jedno kliknięcie i tekst jest gotowy do wklejenia do naszego edytora.

avocode-screen
Kopiowanie tekstu

 

Pozwala na definiowanie zmiennych – kolorów, czcionek, gradientów, rozmiarów i odległości. W ten sposób kopiowany kod z Avocode będzie od razu uwzględniał  i kopiował nasze zmienne. Jeszcze tego nie testowałam, ale wydaje się to ciekawa opcja.

Dodatkowo, podaje dokładne wymiary oraz położenie elementu. Wystarczy wybrać narzędzie Measure w górnym menu, najechać kursorem na dany element i dostajemy o nim pełen zestaw informacji, zarówno w odniesieniu do granic warstwy jak i innych elementów położonych na tej warstwie. W ten sposób Avocode pomaga w ustalaniu marginesów i paddingów.

avocode-screen

 

Avocode ma sporo zaawansowanych ustawień, które pozwalają dostosować to narzędzie do naszych potrzeb.

avocode-screen
W zaawansowanych ustawieniach możemy np. domyślny format kolorów
avocode-screen
W zaawansowanych ustawieniach możemy np. zmieniać domyślne jednostki

 

Dopiero zaczynam korzystać z tego narzędzia, ale uważam, że jest bardzo cenne, ułatwia i usprawnia kodowanie. Sama aplikacja jest dość intuicyjna, całkiem przyjemna w użytkowaniu. Nie jest idealna, ale ciągle jest usprawniana i dodawane są nowe funkcjonalności. Narzędzie jest płatne (po 14 dniowym trialu), można płacić miesięczną subskrypcję, którą można anulować w każdej chwili, bądź skorzystać ze zniżki na plan roczny.

avocode-pricing
Ceny w miesięcznym rozliczeniu

 

Mam nadzieję, że ten artykuł był pomocny. Daj znać czy korzystałeś/korzystałaś z tego narzędzia. A może znasz jakieś inne, ciekawe i konkurencyjne? Jeśli masz jakieś pytania zostaw komentarz! 🙂 

Konferencja UX oczami developera – czyli Ciemna Strona UX #3

Dzisiaj miałam okazję uczestniczyć w konferencji organizowanej przez ITberries pod tytułem „Break the Rules! – Ciemna Strona UX #3”. Było to ciekawe doświadczenie, ponieważ mogłam słuchać prelekcji i patrzeć przez pryzmat Frontend Developera. W sumie było 12 prelekcji, pod tym linkiem możesz zobaczyć agendę oraz dowiedzieć się więcej o prelegentach. Zebrałam 10 wniosków, które udało mi się zapisać w postaci notatki wizualnej (ang. sketchnote).

1. Badania i burze mózgów przynoszą nowe pomysły i pozwalają na doskonalenie produktów

Badania UX-owe (UX – User Experience) pomagają w dostosowaniu produktu do potrzeb użytkownika. Ich przeprowadzanie oraz analizowanie może prowadzić do odkrywania nowych problemów i potrzeb. W rzeczywistości firmy rzadko dysponują budżetem na takie badania.

2. Moderator może pomóc zespołowi osiągnąć więcej w krótkim czasie

Moderator – tutaj jako osoba zewnętrzna, która przychodzi do firmy na kilka godzin, bądź dni i wchodzi w interakcje z pracownikami firmy (często z różnych działów) i pomaga im w rozwoju / znalezieniu rozwiązań na problemy i ustaleniu konkretnych działań.

3. Praca z personami pozwala na więcej empatii

„Persony to swoisty archetyp użytkownika danego produktu przedstawiony w postaci perswazyjnego, „uczłowieczonego” opisu cech, umiejętności, potrzeb, celów (zarówno życiowych jak i realizowanych przy użyciu produktu). Zadaniem tych modeli jest przybliżenie zespołowi pracującemu nad projektem różnych typów użytkowników, tak, aby ułatwić podjęcie decyzji związanych z koncepcją, funkcjonalnościami projektu oraz grafiką.”

źródło: http://uxbite.com/2010/08/tworzenie-person/

Poznawanie i pracowanie z personami pozwala na przybliżenie potencjalnego użytkownika produktu czy usługi. Zamiast abstrakcyjnych użytkowników mamy do czynienia z profilami osób, co pozwala twórcom na więcej empatii.

4. Machine learning może być przyszłością projektowania oraz ulepszania produktów

Sztuczna inteligencja rozwija się z niebywałą prędkością, jest w stanie tworzyć muzykę, pomagać w rozpoznawaniu chorób. Również zagadnienie self-driving cars jest bardzo fascynujące. Jaka będzie przyszłość projektowania i developmentu w erze maszyn? Przekonany się za pewne w przeciągu dekady.

5. Testujmy i ulepszajmy MVP (minimum value product)

Dzięki testowaniu MVP możemy w szybki sposób zweryfikować czy pomysł produktu / usługi jest trafny, a dzięki analizie będziemy mogli sprecyzować oczekiwania użytkowników i wyjść im na przeciw z skrojonymi na miarę rozwiązaniami.

6. Istotne jest projektowanie badań – najlepiej w interdyscyplinarnym teamie

Projektowanie badań jest samo w sobie ciekawym zagadnieniem. Tutaj również możemy starać się aby UX był jak najlepszy. Nie dość, że trzeba dbać o jasno sformułowane pytania, odpowiednie pola do odpowiedzi, to możemy również użyć kreatywności aby zaangażować osobę, która bierze udział w badaniu.

7. Obserwowanie użytkownika podczas badań może zaburzać wyniki

Ludzie, który są świadomi, że biorą udział w badaniu mogą zachowywać się zupełnie inaczej niż w rzeczywistości. Przy organizacji testów wato o tym pamiętać.

8. Komputery mogą rozpoznawać emocje użytkownika w głosie – szansa na rozwój UX?

Komputery mają coraz większy wpływ na nasze życie, są one już w stanie rozpoznawać emocje na podstawie głosu bądź mimiki twarzy. Jest to szansa na rozwój UX, ponieważ znając emocje użytkownika, jako twórcy, projektanci i developerzy możemy na nie odpowiednio reagować.

9. Konflikt UX/UI vs Developer – umiejętność przyjmowania krytyki, umiejętność dawania konstruktywnego feedbacku, otwartość na inne rozwiązania oraz edukacja

W pracy osobiście spotkałam się z sytuacją, w której Designer kłócił się z Developerem. Każdy miał swoją rację i nie dopuszczał innego rozwiązania. Czasami warto się zastanowić dlaczego dana osoba tak myśli. Zastanowić czy moje rozwiązanie jest na pewno najlepsze? Szanujmy siebie nawzajem i uczmy się od siebie.

10. Developer ma wpływ na UX!

Developerzy mają ostateczny wpływ na wygląd i działanie stron / aplikacji / oprogramowania. Powinniśmy to brać pod uwagę podczas wdrażania funkcjonalności.

Serdecznie polecam branie udał w podobnych wydarzeniach. Zdecydowanie to poszerza horyzonty oraz  pozwala na zaczerpnięcie wiedzy z pokrewnych dziedzin, a w rezultacie lepsze zrozumienie innych ludzi.

Praca developera – najważniejsze pojęcia

praca developera

praca developera

Asana – uniwersalna aplikacja do zarządzania projektami.

branch – gałąź projektu. Wyróżniamy gałąź główną, deweloperską i gałęzie boczne. Gałąź deweloperska to tzw. develop w której znajduje się najbardziej aktualna wersja kodu. Gałąź boczna to taka na której rozwijana jest konkretna funkcjonalność. Gałęzi bocznych może być kilka. Tworzenie gałęzi pozwala na kontrolowanie wersji projektu, przykładowym narzędziem do tego jest GIT.

bug – błąd w kodzie

call – rozmowa z klientem odbywająca się przez komunikator tj. Skype, Google Hangouts

CLI – command-line interface – sposób komunikowania się użytkownika z programem za pomogą tekstowych poleceń wpisywanych do konsoli

code review – proces sprawdzania kodu przez innego programistę/programistkę,  zazwyczaj przed połączeniem kodu z głównym branchem deweloperskim

develop – gałąź deweloperska, w której znajduje się najbardziej aktualna wersja kodu

commit – zapis aktualnego stanu kodu w danym momencie

critical – najważniejszy task w danym momencie

feature – funkcjonalność w aplikacji / na stronie internetowej

GUI – Graphical User Interface – sposób komunikowania się użytkownika z programem za pomogą interfejsu graficznego.

JIRA – aplikacja do zarządzania projektami dedykowana dla software developmentu. Pomaga w organizacji pracy zespołu, usprawnia proces naprawiania bugów

JSON – JavaScript Object Notation – uniwersalny format przesyłania danych

master – główna gałąź projektu

merge – połączenie jednej gałęzi z drugą

repozytorium – miejsce w którym trzymane są wszystkie pliki związane z projektem oraz przetrzymywane są informacje na temat historii rozwoju projektu.  Pozwala to w łatwy sposób na śledzenie zmian w kodzie.

standup – spotkanie członków zespołu dotyczące danego projektu. Stundupy odbywają się codziennie, każdy członek zespołu określa co udało mu się zrobić dnia poprzedniego, jakie napotkał trudności oraz co zamierza zrobić danego dnia. Mogą się obywać w biurze bądź przez komunikator tj. Skype, Google Hangouts. Project Manager określa priorytety oraz przekazuje dodatkowe informacje ze strony klienta.

taski – pojedyncze zadania wyznaczone przez np. Project Managera, Tech Leada, Testera. Powinny one znaleźć się w aplikacji do zarządania projektem tj. Trello, Asana, Jira. Mogą polegać na stworzeniu konkretnej funkcjonalności, naprawieniu konkretnego buga. Idealnie taski powinny być małe, najlepiej aby czas przeznaczony na ich sfinalizowanie nie przekraczał kilku godzin. W Scrumie maksymalny czas jaki może być przypisany do jednego taska to 2 dni. Jeśli na etapie planningu okazuje się, że dana rzecz ma zając więcej niż dwa dni, to koniecznie trzeba ją podzielić na więcej niż jeden task.

Trello – uniwersalna aplikacja do zarządzania projektami.

Jeśli masz jakieś uwagi lub propozycje pojęć – proszę napisz w komentarzu, postaram się uzupełnić posta.

Słownik początkującego Frontend Developera

słownik frontend developera

słownik frontend developera

Tu powstaje słowniczek początkującego Frontend Developera. Podzielony jest on na kilka sekcji: pojęcia, technologie oraz narzędzia developerskie.

Pojęcia

BEM – Block Element Modifier – konwencja, która określa sposób nazywania CSS-owych klas, który pomaga w wprowadzeniu jednolitości w kodzie.

DRY – Don’t repeat yourself – konwencja, która zakłada, że w programowaniu powinniśmy unikać powtarzania kodu, który wykonuje takie samo zadanie. Najlepszym przykładem jest tworzenie re-używalnych funkcji. Pozwala to na optymalizację, zredukowanie ilości kodu oraz zwiększenie jego czytelności.

RWD – Responsive Web Design – konwencja, która zakłada, że układ strony powinien dostosowywać się do wielkości oraz orientacji ekranu użytkownika. Znaną biblioteką ułatwiającą kodowanie RWD jest Bootstrap.

Technologie

AJAX – Asynchronous JavaScript And XML – sposób komunikacji przeglądarki z serwerem, gdzie wysyłane zapytania są asynchroniczne, czyli nie musimy czekać aż przyjdzie odpowiedź z jednego zapytania, żeby wykonało się drugie. Przykładem użycia AJAXa jest dynamicznie ładujący się kontent na stronie.

ECMAScript 6, ES6 – jest najnowszą ustandaryzowaną wersją JavaScript z 2015 roku. Wprowadza ona dodatkowe funkcjonalności, skróty, słowa kluczowe oraz inne ulepszenia. Obecnie jeszcze nie wszystkie przeglądarki wspierają ES6, dlatego aby używać ES6 należy użyć kompilatora (np. Babel), który skompiluje nasz kod do ES5.

Sass – Syntactically Awesome Style Sheets – prepocesor języka CSS. Wprowadza większe możliwości niż CSS tj. zmienne, zagdzieżdżanie selekorów, mixiny.

Narzędzia developerskie

Babel – kompilator, który pozwala na używanie ECMAScript 6 i kompilowanie kodu do ECMAScript 5.

Webpack – module bundler, który dzięki szeregowi dodatkowych pluginów i loaderów może służyć do wielu do podstawowych tasków np. do kompilacji ES6 do ES5 (przy pomocy Babel loader), czy Sass do CSS. Dzięki dodatkowemu pluginowi Webpack DevServer dostajemy w prosty konfiguracji serwer deweloperski.

To nie jest ostateczna wersja posta, będzie on dalej aktualizowany. Jeśli masz jakieś propozycje pojęć, które powinny się znaleźć w słowniczku proszę napisz w komentarzu, postaram się uzupełnić.

Nazewnictwo w programowaniu – 20 cennych wskazówek

nazewnictwo w programowaniu

nazewnictwo w programowaniu

Czas na lekcję dobrych praktyk w programowaniu, dzisiaj będzie konkretnie o nazewnictwie. Post ten powstał na podstawie 2 rozdziału książki Roberta C. Martina “Czysty Kod” oraz moich własnych przemyśleń.

Nazewnictwo klas, funkcji, metod, zmiennych plików jest NIEZWYKLE ważne. To tak jak pisanie instrukcji obsługi, ale bez obrazków. Musimy dokładnie wyrazić o co nam chodzi. Warto poświęcić trochę więcej czasu na przemyślenie nazwy, to naprawdę pozwoli nam i innym programistom zaoszczędzić sporo czasu i nerwów.

  1. Nie bagatelizuj nazewnictwa.
  2. Postaw się w sytuacji programisty który będzie utrzymywał Twój kod. Wykrzesaj z siebie chociaż odrobinę empatii.
  3. Spójność to podstawa – warto przyjąć jedną konwencję i być konsekwentnym np. BEM
  4. KISS – Zasada Keep it Simple Stupid – czyli najprościej jak się da, bez zbędnych słów.
  5. Jeśli nazwa wymaga komentarza jest to zła nazwa.
  6. Nie używaj skrótów. Mogą one powodować nieporozumienia, ponieważ skróty często mają więcej niż jedno rozwinięcie.
  7. Uważaj na dwuznaczności słów, one też mają często więcej niż jedno znaczenie.
  8. Liczby też można nazywać! Nie każdy będzie wiedział skąd się wzięła i co robi cyfra “4” w Twoim kodzie. Będzie też łatwiej ją zlokalizować.
  9. Żarty, kolokwializmy, metafory – daruj sobie, jak wrócisz do kodu za dwa miesiące nie będziesz wiedział/a o co chodzi.
  10. Nie używaj jednoliterowych nazw. Są one trudne do wyszukania oraz nie wskazują na żaden kontekst. Wyjątek: jako zmienne lokalne w małych kawałkach kodu np. w liczniku pętli zmienna “i”.
  11. Nie mieszaj różnych języków! Polecam angielski, jest uniwersalny.
  12. Pamiętaj, że w niektórych czcionkach litery małe L i O łatwo pomylić z 1 i 0.
  13. Jeśli masz pomysł na lepszą nazwę, nie zastanawiaj się tylko ją zmień (ale nie w jednym miejscu – we wszystkich!).
  14. Unikaj nazw ze słowami jak “data”, “info”, “message” – sprecyzuj!
  15. Nazwy metod, funkcji to zwykle czasowniki (w stronie czynnej) lub wyrażenia czasownikowe. Czyli zwykle odpowiada na pytanie “co to robi”? Pomocne słowa: getSomething, setSomething, isSomething.
  16. Nazwy klas to zwykle rzeczowniki lub wyrażenia rzeczownikowe. Czyli zwykle odpowiada na pytanie “co to jest”?
  17. Jedno słowo na jedno abstrakcyjne pojęcie. Skąd będziesz wiedzieć jaka jest różnica pomiędzy: get, fetch albo retrieve?
  18. Jedno słowo na jedno zagadnienie. “Należy unikać używania tego samego słowa do dwóch celów”.
  19. Podczas code review zwracaj uwagę na nazewnictwo.
  20. Nie każdy element potrzebuje nazwy, jeśli jej nigdzie nie używasz nie zaśmiecaj nią kodu.
  21. Bonus: LITERÓWKI – bardzo na nie uważaj!

Zwracaj uwagę na nazewnictwo np. w popularnych bibliotekach. Zerknij na API jQuery i zobacz jakich oni nazw używają.  Po za tym ćwicz, ćwicz, ćwicz i proś innych o code review 

i pamiętaj:  

“Profesjonaliści piszą kod zrozumiały dla innych” Robert C. Martin