Pożegnaj się ze złymi praktykami JavaScript

Nov 29 2022

Kiedy stawiamy pierwsze kroki w cudowny świat programowania, możemy na własne oczy przekonać się, co robi dla milionów ludzi. To dzięki programowaniu życie tak wielu osób staje się łatwiejsze, wystarczy nacisnąć kilka klawiszy na ich urządzeniach (to magia).

Programowanie to inny rodzaj supermocarstwa, ale jak powiedział wujek Ben swojemu siostrzeńcowi Peterowi Parkerowi: „Z wielką mocą wiąże się wielka odpowiedzialność”. W świecie programowania naszym największym obowiązkiem jest zapewnienie, aby kod, który piszemy, był zarówno łatwy do przetestowania, jak i utrzymywania przez długi czas.

Istnieje kilka drobnych praktyk w programowaniu, które mogą mieć ciągły negatywny wpływ na kod, który piszemy i produkt, który tworzymy jako wynik końcowy. Doświadczyłem tych problemów na własnej skórze. Ważne jest, aby dzielić się tym, czym one są i dlaczego należy ich unikać za wszelką cenę.

1. Używanie var zamiast let i const

Czas pożegnać się z używaniem var.

Powinieneś używać tylko let i const z następujących powodów:

● Zakres jest wyraźniejszy (między nawiasami klamrowymi).

● Nie tworzy obiektów globalnych.

● Oznacza błędy, jeśli ponownie je deklarujesz.

O ile nie używasz starszej przeglądarki, takiej jak ukochana IE11, w twoim najlepszym interesie jest puszczenie var. Let i const będą twoimi najlepszymi przyjaciółmi w przyszłości.

2. Wykorzystanie komentarzy do wyjaśnienia kodu

Komentarze są fundamentalną częścią podczas tworzenia oprogramowania, pomagają nam trochę lepiej zrozumieć czytany kod, ale nie możemy popełnić błędu wyjaśniania krok po kroku, co robi nasz kod, musimy stworzyć kod, który jest łatwy do czytać i komentarze powinny stanowić jedynie kontekst.

Oto kilka wskazówek i przypomnień, które pomogą Ci pisać komentarze do kodu jak profesjonalista:

● Unikaj redundancji w swoich komentarzach; nie pisz co robisz, pisz dlaczego to robisz.

● Opisowe nazwy zmiennych/funkcji/klas są lepsze niż opisowe komentarze.

● Podsumuj jak najwięcej; nie pisz akapitów, jeśli nie jest to absolutnie konieczne.

● Staraj się zawsze używać tego samego języka i stylu komentarzy.

● Z biegiem czasu komentarze zwykle nie są utrzymywane (zmodyfikowane) kod jest.

3. Używanie == zamiast ===

Pierwszą rzeczą do zrozumienia jest to, że chociaż wizualnie są bardzo podobne, robią różne rzeczy: pierwszy nazywa się zwykłym operatorem równości (==), a drugi operatorem ścisłej równości (===).

Zwykły operator równości (==) sprawdza tylko, czy operandy są podobne, co może powodować nieprzyjemne niespodzianki.

Operator ścisłej równości (===) zawsze sprawdza, czy operandy są różnych typów i wartości oraz czy są dokładnie takie same.

4. Zapominanie o użyciu opcjonalnego łączenia

Opcjonalny operator łańcuchowy (?) umożliwia odczytanie wartości właściwości znajdującej się głęboko w łańcuchu połączonych obiektów bez konieczności sprawdzania każdej referencji w łańcuchu.

Pomaga nam to uniknąć błędów podczas próby uzyskania dostępu do nieistniejącej właściwości. Jako przykład, powiedzmy, że mamy obiekt Pokémon, który zawiera informacje o tym Pokémonie.

Gdy chcemy uzyskać dostęp do właściwości, która nie jest zdefiniowana, tak jak w tym przykładzie, dostęp do właściwości „atak” JavaScript wygeneruje błąd, a nasza aplikacja ulegnie awarii. Podczas korzystania z opcjonalnego łączenia (?), Javascript poinformuje nas, że właściwość jest niezdefiniowana, ale nie wygeneruje żadnego błędu. Myślenie o tego typu błędach, które czasami są poza naszą kontrolą, na dłuższą metę robi dużą różnicę.

5. Nieużywanie magicznych strun i magicznych liczb

Magiczna liczba lub magiczne ciągi to liczby lub ciągi używane bezpośrednio w kodzie, które często nie mają jasnego kontekstu, ale mają cel. Najlepiej przypisać te wartości do stałych, ponieważ w przeciwnym razie mogą być trudne do zrozumienia i debugowania.

6. Niewłaściwa obsługa błędów wywołań API

Zawsze powinniśmy obsługiwać błędy za pomocą try/catch w naszym async/await.

Jeśli nie poradzimy sobie z błędami w naszych obietnicach, bardzo prawdopodobne jest, że nasza aplikacja eksploduje, a wierzcie mi, nie chcemy, aby tak się stało.

7. Używanie obiektu jako pojedynczego parametru

Deklarując funkcję, w której oczekuje się wielu wartości od obiektu, najlepiej jest użyć wielu parametrów wejściowych zamiast danych wejściowych pojedynczego obiektu. To pomaga nam w kilku rzeczach:

Po pierwsze, ułatwia czytanie naszego kodu, wiedząc od początku, jakich parametrów potrzebuje nasza funkcja.

Po drugie, ułatwia testowanie funkcji, a te dwie rzeczy razem pomagają utrzymać nasz produkt w miarę upływu czasu. Ponadto, jako plus, poprawia wydajność naszej aplikacji, ponieważ pozwala uniknąć zbierania śmieci lub tworzenia niepotrzebnych parametrów obiektów.

Kolejnym plusem jest to, że jeśli używasz TypeScript i masz kilka parametrów, łatwiej jest zdefiniować interfejs parametrów, aby skorzystać ze sprawdzania typów i autosugestii, co pozwala uniknąć błędów.

8. Zapominanie o sile skrótów

Wszyscy byliśmy w sytuacji, w której zastanawialiśmy się, czy zmienna istnieje lub czy zawiera jakąś wartość inną niż null lub niezdefiniowana. Z tego powodu często przeprowadzamy bardzo długie walidacje tego typu:

Skróty pomagają nam uniknąć tego problemu. W prostszy i bardziej elegancki sposób powyższy kod można zredukować do następującego:

Wniosek

Pisanie czystego kodu zawsze będzie naszym obowiązkiem. Z mojego doświadczenia jako programista nauczyłem się, że posiadanie łatwego w utrzymaniu i łatwego do odczytania kodu pozwoli Tobie i Twojemu zespołowi zaoszczędzić wiele godzin.

Pamiętaj, że więcej czasu spędzamy na czytaniu kodu niż na jego pisaniu. Mam nadzieję, że te małe wskazówki ułatwią Ci zadanie tworzenia magicznych i niesamowitych produktów.