Pewnie podczas nauki programowania zastanawialiście się, jak to jest, że niektórzy piszą dobry kod, a innym wcale to nie wychodzi. A może nawet nie wiedzieliście do końca, czym jest dobry kod. A więc jak jest z tym tak naprawdę?
Pisz dużo
Po pierwsze: żeby pisać dobry kod, trzeba najpierw pisać kod. To stwierdzenie może wydać się mało śmiesznym żartem, ale wcale nim nie jest – najprostsze rozwiązania czasem są najlepsze. Żeby wyrobić w sobie umiejętności pro-kodera, trzeba ćwiczyć. I to całkiem sporo ćwiczyć – dwa programy po 100 linii nie wystarczą. Gdy człowiek czuje się już w miarę pewnie z kodem źródłowym, warto skupić się na poprawianiu pojedynczych rzeczy. Być może tę funkcję da się zapisać krócej, a ten if jest tutaj niepotrzebny. W tamtym pliku można nieco przeorganizować kod, a ten powtarzający się fragment można wyrzucić do osobnej funkcji. Dobre nawyki przyjdą z czasem.
Pisz czytelnie
Jak jesteśmy już przy pisaniu kodu, to warto pamiętać, że kod powinien dać się potem przeczytać. I nie, to że akurat ten malutki programik jest tylko dla was i nikt nigdy go nie zobaczy to nie jest dobra wymówka. Te małe programiki wpływają na dalsze podejście do tworzenia kodu! Nie chcecie chyba za każdym razem przepisywać kodu na bardziej czytelny gdy tylko okaże się, że ktoś chce skorzystać z tego, co napisaliście.
Jak zapewnić tę czytelność? Po pierwsze: nazwy. Zmiennych, stałych, funkcji, klas. Każda nazwa powinna być znacząca, no chyba że ma marginalne znaczenie. Jednoliterowe nazwy mogą się nadawać do zmiennych tymczasowych, takich jak np. zmienne pętli, ale tylko i wyłącznie wtedy. Nazwy powinny odzwierciedlać zastosowanie – zmienna przechowująca indeks tablicy może nazywać się „index”, a funkcja dodająca do siebie dwie liczby – „add”. Trudno się nie zgodzić, że są to o wiele czytelniejsze nazwy niż np. „foo” czy „asdf”.
Używaj jednego języka
Warto też zauważyć pewną konwencję – profesjonalnych programistów poznaje się po tym, że ich kod jest w języku angielskim. I jasne, jeśli angielski jest dla was jeszcze trochę zbyt trudny, nazwy po polsku są w pełni zrozumiałe. Ale gdy tylko nieco oswoicie się z programowaniem, spróbujcie tłumaczyć nazwy (choćby i używając Google Translate). I nigdy, przenigdy nie mieszajcie kilku języków – twory w stylu „sprawdz_client_ID” nie świadczą zbyt dobrze o programiście.
Kolejną ważną kwestią jest testowanie kodu. Bo co komu po ładnie napisanym programie, który nie działa? Zwracajcie uwagę na skrajne przypadki, myślcie o możliwości wpisania błędnych danych i starajcie się przewidzieć wszystko. I jak najszybciej przyzwyczajcie się do pisania własnych testów – to naprawdę bardzo dobra praktyka. I pozwala wyłapać bardzo wiele błędów.
Ucz się od mistrzów
Jeśli piszecie w języku obiektowym, zainteresujcie się wzorcami projektowymi. Pomocne są też ogólnie znane zasady SOLID, GRASP, DRY i KISS (jeśli o nich nie słyszeliście, to jest dobry moment, by wygooglować). Jest masa książek na temat pisania dobrego kodu, godnymi polecenia są „Pragmatyczny programista. Od czeladnika do mistrza” A. Hunt, D. Thomas, „Czysty kod. Podręcznik dobrego programisty” R. C. Martin czy „Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku” E. Gamma, R. Helm, R. Johnson, J. M. Vlissides. Te trzy pozycje są na tyle przystępnie napisane, że mogą przydać się nawet początkującym.
Poprawiaj błędy
Ostatnim aspektem drogi do idealnego kodu jest ciągłe ocenianie własnej pracy. W pracy zawodowej wasz kod zawsze będzie poddawany kontroli i ocenie, ale czemu rezygnować z tego podczas nauki? Jeśli nie znacie nikogo, kto mógłby spojrzeć na wasz dotychczasowy kod i rzetelnie powiedzieć, co można jeszcze poprawić, spróbujcie zrobić to sami. I nie powtarzajcie w kółko błędów, tylko starajcie się je stopniowo naprawiać. To wszystko jest w stanie pomóc wam osiągnąć mistrzostwo w programowaniu.
[su_button url=”https://roboblog.eu/2016/05/27/dobrykod-komentarze-sa-zle/” desc=”Czy komentarze są złe?”]Następna część[/su_button]