Grzeszki w kodach programistów

Programiści nie są kryształowi. Większość ma sporo na swoim programistycznym sumieniu. Chcieliśmy dowiedzieć się więcej na ten temat i dlatego w zorganizowanym przez nas konkursie zadaliśmy Wam pytanie: Jakie są/były Twoje największe grzeszki w kodzie?. Do wygrania było 5 egzemplarzy książki “Czysty kod. Podręcznik dobrego programisty” autorstwa Roberta C. Martina od Helion Szkolenia. Konkurs został rozstrzygnięty na Facebooku, a my podsumowujemy Wasze odpowiedzi.

Jedna z osób zapytała: ,,Kto poświęci reputacje dla książki?" Okazało się, że znalazło się ponad 70 śmiałków, którym bardzo dziękujemy.

Kamil:

,,Nazwy zmiennych i metod angielsko - polskie, używanie statycznych metod i zmiennych, zmienne globalne, zostawianie starego zakomentowanego kodu, jedna klasa robiąca wszystko, metody przyjmujące po 10 argumentów, brak spacji przy wszelakich operatorach - złe formatowanie kodu, wszystkie publiczne pola, zwracanie null, brak niezależności metod, magiczne liczby. Więcej grzechów nie pamiętam…"

Kamil wyliczył tutaj całą litanię i to nie dlatego, że jest/był jakimś wyjątkowo złym programistą. W zasadzie wszystkie błędy, które wymienił wyglądają na takie, które popełnia się, bo tak jest wygodniej. Dopiero przy próbie modyfikacji, zmiany zachowania, szczególnie po dłuższym czasie, te błędy dają się we znaki.

W podobnym tonie napisał swoją wypowiedź Wiktor:

,,Pisanie nazw zmiennych i klas "pol-engliszem" to już klasyka w moim wykonaniu :D Wstawianie e.printStackTrace() w bloku Catch z automatu, bo jak głosi legenda "...kiedyś zjawi się nieznajomy koder i obsłuży ten wyjątek ?‍♂️ " Kilometry zakomentowanego kodu, tak na wszelki wypadek. Tworzenie zmiennych "temp" oraz "test" oczywiście tylko na chwilę.. tylko dla testów.. Oraz wszechobecny bałagan w kodzie bo kto by tam te wszystkie spacje wstawiał :D"

U Wiktora widać większą ostrożność, typową dla uczącego się developera, który jednak nie chce zawalić. Wie/wiedział, że należy coś z wyjątkiem zrobić, jednak jeszcze nie do końca wiedział jak go poprawnie obsłużyć. Wyrazem (zbędnej) ostrożności jest też zostawianie zakomentowanego kodu.

Fajną wpadką podzieliła się Ania:

,,Nadanie elementowi 1px width/height żeby był niewidoczny dla użytkownika, ponieważ jego usunięcie powodowało rozjazd strony? koniecznie w towarzystwie !important"

I tu nawet nie dziwimy się za mocno. Rozwiązywanie problemów z CSS, szczególnie po długich godzinach pracy bywa ciężkie, szczególnie, że właściwości jednego elementu mogą wpływać na położenie drugiego. Dlatego czasem !important wydaje się bardzo kuszącym skrótem (który zdaje się wykorzystywać więcej osób, bo znaleźliśmy jeszcze dwa komentarze mówiące o tej praktyce). Dużo ułatwia flexbox i grid. Tu idealnie pasuje komentarz z grzeszkiem Jakuba:

,,Ustawienie wszystko na stronach za pomocą float w 2018 roku zamiast używać flex"

Nie mogło też zabraknąć żarcików

Daniel wyznał, że jego grzeszkiem jest to, że:

,,piszę w PHP"

Najczęściej powtarzające się problemy

Było kilka grzeszków, które przewijały się w wielu odpowiedziach. Chyba najbardziej popularne było ustawianie zmiennych i wypisywanie różnych wiadomości debugowych, połączone z wysyłaniem tego na produkcję. Z takich bardziej przyzwoitych przykładów Dariusz używał jako debuggera console.log(‘siema’), Paweł pozostawił w kodzie zmienną var andrzej.

Jak wiadomo debuguje się najczęściej jak coś nie działa, więc poziom frustracji jest wysoki. Dlatego sporo było przykładów mniej cenzuralnych. Jedna z osób biorących udział w konkursie przeoczyła wulgarną nazwę zmiennej debugowej w zadaniu rekrutacyjnym. Pracodawca dopytał: ,,Jesteś pewny, że Twój kod jest gotowy do code review?"

Szczególnie popularnym wśród studentów rodzajem przewinienia jest hardkodowanie wyniku zadania. Przykłady, które przytoczyliście pokazują, że często może być to efektywny sposób na zdobycie zaliczenia. Jednak wyrzuty sumienia pozostają.

Kolejną kategorią są różnego rodzaju literówki. Joanna przytoczyła historię, kiedy przez różnicę w nazwie pola w bazie i nazwie parametru oraz brak walidacji konieczne było obdzwonienie wszystkich klientów, u których zabrakło kluczowej danej. Jedną z najbardziej irytujących literówek jest napisanie = zamiast == w warunku if, czego doświadczyło zapewne bardzo wiele z Was.

Powtarzającym się motywem było przeładowanie odpowiedzialnością metod i klas. Niektórzy wspominali o metodach na kilkaset linii, łączeniu kilku różnych funkcji w ciele jednej metody (tu wygrał Daniel, który zdał sobie z tego sprawę i zmienił nazwę metody z FindById na FindByIdThenSortThenSendTo). Kilka osób mówiło też o tworzeniu tzw. God Objectu, który ma do wszystkiego dostęp i jest odpowiedzialny za zdecydowanie zbyt wiele funkcji.

Standardem jest też lenistwo. Polega ono zwykle na zostawieniu po sobie “TODO”. Bartosz poszedł nawet krok dalej:

,,coś zadziałało nie tak jak finalnie miało być, ale że się nie rzuca w oczy/wygląda ok to zostawało"

Grzeszków było znacznie więcej i czytając je można się oburzyć i powiedzieć: No ja to nigdy bym tak nie zrobił/a. Jednak rzeczywistość jest taka, że czasem każdy zaliczy wtopę. Właśnie dlatego mamy code review, narzędzia do formatowania, dobre praktyki czy metryki. Mamy więc nadzieję, że książka “Czysty kod. Podręcznik dobrego programisty” przyda się zwycięzcom konkursu, by robić coraz mniej błędów i pisać lepszy kod. Czasem, by nie pogarszać swojej reputacji, mogą też skorzystać ze sztuczki, którą podzielił się Robert:

,,Podpisuje slaby kod imieniem kolegi"