16.01.20194 min

Redakcja Bulldogjob

Grzeszki w kodach programistów

Poznaj grzeszki w kodowaniu, do których przyznali się programiści.

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"

<p>Loading...</p>

Powiązane artykuły

Dziel się wiedzą ze 160 tysiącami naszych czytelników

Zostań autorem Readme

Ubezpieczeniowy Fundusz Gwarancyjny

Specjalista ds. testów

medium

Znamy widełki

Kontrakt B2BUmowa o pracę

Warszawa

Ważna do 27.02.2022

Dobrze
JIRASoapUIOracle Database
Początkujący
FitNesseJMeter

Sii Polska

DevOps Engineer

medium

17 000 - 24 000 PLN

Kontrakt B2B

Warszawa

Ważna do 27.02.2022

Dobrze
AWSGCPGitHub
Bardzo dobrze
Linux

Accenture Polska

Agile Project Manager

medium

Brak widełek

Kontrakt B2BUmowa o pracę

Warszawa

Praca zdalna 100%

Ważna do 27.02.2022

Bardzo dobrze
Agile Methodologies (Scrum, Kanban, Kaizen)
Dobrze
Team-building & people management
Początkujący
cloud fundamentals

DB Schenker Technology Center Warsaw

Business Analyst

medium

Brak widełek

Kontrakt B2BUmowa o pracę

Warszawa

Ważna do 27.02.2022

Accenture Polska

PHP/Magento Developer

medium

Brak widełek

Kontrakt B2BUmowa o pracę

Praca zdalna 100%

Ważna do 27.02.2022

Bardzo dobrze
PHPGIT
Dobrze
Magento 2SOAP/REST HTML/CSS
Początkujący
JSONJavaScript jQuery

T-Mobile Polska S. A.

Inżynier Sieciowy

medium

Brak widełek

Kontrakt B2B

Warszawa

Ważna do 27.02.2022

Asseco Poland S.A.

Młodszy Analityk Finansowy

junior

Brak widełek

Umowa o pracę

Rzeszów

Ważna do 27.02.2022

Netguru

Junior iOS Developer

junior

4 200 - 6 000 PLN

Kontrakt B2BUmowa o pracę

Praca zdalna 100%

Ważna do 27.02.2022

Dobrze
iOS

7N

Data Engineer

medium

15 100 - 18 100 PLN

Kontrakt B2B

Praca zdalna 100%

Ważna do 27.02.2022

Dobrze
MS SQLETLSpark

7N

Senior Business Analyst

senior

16 800 - 21 800 PLN

Kontrakt B2B

Praca zdalna 100%

Ważna do 27.02.2022