Dobre nawyki programisty – lepiej mieć, niż nie mieć

Po co programiście potrzebne są dobre nawyki? Aby ułatwić sobie życie!
“Dobre nawyki” (programisty) to często używany slogan, którym często posługują się autorzy poradników. Również w naszej branży mają one niebagatelne znaczenie. Podstawowa różnica między początkującym a profesjonalnym programistą tkwi właśnie w ich przyzwyczajeniach. Nowicjusz poznaje zasady i nabywa umiejętności. Zawodowiec zna i stosuje je odruchowo. Jak to wygląda w świecie programistów? Ten artykuł przybliża kilka nawyków dobrego developera.

Dobre nawyki programisty – 1: Trzymaj się założeń

Na początek: konwencje. To pojęcie fundamentalne, nie tylko w branży IT. Przykłady z różnych dziedzin to choćby układ pism urzędowych, sposób adresacji kopert czy średnice śrub. Niektóre nawet mogą ratować ludzkie życie, jak np. procedura mycia rąk przez chirurgów.

Konwencje programistyczne to ustalone sposoby pisania kodu. Ale nie chodzi o składnię języków – to konieczność: nawiasy trzeba zamykać, a pętli while nie można tak po prostu nazwać when. Mnóstwo jest natomiast zasad “niekoniecznych”, których przestrzeganie jest po prostu korzystne. Są to albo zalecenia przypisane do konkretnego języka, albo wewnętrzne ustalenia w danej firmie. Poniżej opisujemy kilka najpowszechniejszych przykładów.

Dobre nawyki programisty – 2: Nazewnictwo

O tym słyszy się już od pierwszych lekcji: nazwy powinny być znaczące. W jaki sposób to osiągnąć – to już trudniejsza sprawa. Kilka ogólnych zaleceń to:

• Unikaj niespecyficznych nazw typu a, b, c, x, func, variable. Powinny one faktycznie reprezentować to, czemu są przypisane.
• Funkcje powinno się nazywać, używając czasowników. Z założenia mają one wykonywać określone czynności, a czasowniki służą właśnie do przedstawiania tychże. Przykłady: sort, evaluate, create, replace, build.
• Nazwy zmiennych (obiektów) oraz klas to rzeczowniki. Reprezentują one coś namacalnego lub jakieś pojęcie, jak choćby age, person, time, range
• Nazwy plików (modułów) powinny identyfikować zawartość. Często w językach obiektowych zaleca się, aby w pliku znajdowała się tylko jedna klasa. Wtedy nazywa się je tak samo. Ułatwia to nawigację w systemie plików.
• Gdy w nazwie jest wiele słów, warto trzymać się jednej konwencji ich łączenia. Najczęściej stosuje się jeden z tych trzech: lowerCamelCase, UpperCamelCase, snake_case.

Niestety, łatwo jest nabrać złych nawyków. Przykłady w internecie i w książkach często zawierają nazwy typu classA, func1, X, Y, method1. Może to u początkujących stworzyć mylne wrażenie, że taka nomenklatura jest lepsza, skoro używają go fachowcy. Tymczasem w codziennej pracy zaleca się przestrzegać powyższych konwencji!

Dobre nawyki programisty – 3: Formatowanie

Doświadczeni developerzy mogą imponować młodszym kolegom szczególną umiejętnością: wystarczy rzut oka, a już rozumieją, za co odpowiada dany fragment kodu. Jak oni to robią? To nieraz kwestia przestrzegania konkretnego formatowania. Choć szczegóły są kwestią sporną, co do jednego jest zgodność: grunt to porządek. Na przykład:

• • Jedna instrukcja na linijkę. Popularne języki umożliwiają umieszczenie wielu wyrażeń w jednej linii, np. rozdzielając je średnikami. Jednak w 90% przypadków zmniejsza to czytelność.
  • Formatowanie bloków. Bloki kodu zawsze są jakoś ograniczone, np. nawiasami klamrowymi. Obok nich bardzo ważne jest używanie wcięć, czyli tabulatorów. Otwarcie bloku można umieścić w poprzedniej linii lub w nowej:

    fun1(){
           instrukcje
    }
    fun2()
    {
           instrukcje
    }
    

  • Długość linii. Przed laty ograniczeniem była szerokość monitora lub liczba znaków akceptowana przez terminale. Obecnie zdroworozsądkowo ogranicza się to do ok. 100-150 znaków.
  • Stopień zagnieżdżenia. Nie należy umieszczać bloku w bloku kilka razy, np:

    if (warunek){
      if(warunek){
        while(warunek){
          if(warunek){
            instrukcje
          }
        }
      }
    }
    

Taki kod może łatwo rozrosnąć się do bardzo nieczytelnej postaci, więc liczbę poziomów ogranicza się np. do 3.

• Odstępy. We właściwych miejscach warto postawić “enter” – zazwyczaj zaraz poniżej definicji funkcji lub klasy.

Dobre nawyki programisty – 4: Objętość kodu

Nie chodzi tu o to, żeby pisać koniecznie mniej niż jakieś sztywne założenie. Rozwijane programy z czasem rozrastają się, więc trzeba je inteligentnie dzielić. Konkretne sposoby zależą od użytego języka, ale mają cechę wspólną: analizowany przez programistę kod musi mu się “mieścić w głowie”. Trudno uważać się za geniusza, który dokładnie pamięta setki linii. Lepiej wyodrębnić zawczasu fragment, który może stać się osobną funkcją lub klasą. Wtedy można mieć przed oczami mniej tekstu jednocześnie, co po prostu poprawia czytelność. Istnieją zalecenia, aby funkcje były krótsze niż pięć linijek! Co więcej, aby nie były one zbyt skomplikowane, powinny przyjmować niewiele argumentów, np. do trzech.

Dobre nawyki programisty – 5: Komentarze

Nawykiem powinno być unikanie komentowania. Idealny kod w ogóle tego nie wymaga, gdyż sam w sobie jest przejrzysty i czytelny. Istnieją jednak dobre powody, aby miejscami użyć pewnych adnotacji:

• Wymogi prawne. Zdarza się, iż przed opublikowaniem należy w nagłówku każdego pliku umieścić informację o autorze i licencji, na której można go używać.
• Objaśnienia. Kiedy dany fragment może wzbudzać wątpliwości, dobrze jest zwięźle go opisać dla czytelności. Na przykład argumenty funkcji czasem muszą mieć odpowiedni format. Nieraz świadczy to jednak o tym, że autor nie miał czasu lub ochoty napisać kodu czytelniej.
• Ostrzeżenia. Czasami dana funkcjonalność jest przestarzała lub jej zastosowanie jest ryzykowne (np. zajmuje dużo czasu). Wtedy komentarz może uprzedzić, że lepiej użyć funkcji szybszej albo nowszej. Ktoś mógł też wyjątkowo skorzystać z odradzanych zazwyczaj konstrukcji – wtedy warto poinformować o swoich zamiarach, aby nikt nic nieopatrznie nie zepsuł.
• Dodatkowe narzędzia. Istnieją programy (nieraz wbudowane w środowiska programistyczne), które potrzebują specjalnych komentarzy do działania. Np. automatyczne generatory dokumentacji mogą pobierać opis danej klasy.

Dobre nawyki programisty – 6: Pisz testy

To zajęcie zazwyczaj jest uważane za osobny zawód, jednak każdy programista też powinien pisać testy. Pomińmy tu dywagacje o przyczynach, sposobach, poziomach i metodykach tych praktyk – o tym pisano całe książki. Warto wspomnieć, że konkretne rodzaje testów są często surowo wymagane. Można ustalić procentowe minimum pokrycia testami (tzw. code coverage). Każdy profesjonalista rozumie, że dobrze jest przywyknąć do sprawdzania samego siebie, również w prywatnych projektach. Niekiedy odradza się pisanie testów dla własnych funkcjonalności i w zespole pisze się je dla siebie nawzajem. W ten sposób większa jest szansa, że będą one służyć spełnieniu wymagań projektowych, a nie tylko stwierdzać, że kod jakoś działa.

Dobre nawyki programisty – 7: Stosuj skróty klawiaturowe

To rada wręcz banalna, ale jakże przydatna. Regularne zapisywanie pracy przez odruchowe wciskanie ctrl+S niejednego uratowało przed sporą stratą czasu, gdy nagle komputer się zawiesi lub wysiądzie zasilanie. To oczywiście minimum, gdyż nawet proste edytory mogą mieć długą listę dostępnych skrótów. Których konkretnie kto używa – to już indywidualna kwestia, chodzi o ułatwienie i przyspieszenie pracy. Często korzysta się z: szybkiego wyszukiwania tekstu, usuwania lub przesuwania linijek, przeskakiwania między plikami, uruchamiania testów, debugowania.

Dobre nawyki prograisty – 8: Całuj i susz!

Akronimy KISS i DRY wyrażają pewne idee, a nie konkretne praktyki. Pierwszy znaczy Keep It Simple, Stupid! Po polsku BUZI – Bez Udziwnień Zapisu, Idioto. Chodzi o to, aby upraszczać jak to tylko możliwe. Proste rozwiązania są najłatwiejsze do późniejszego utrzymania czy modyfikacji. Można je szybko zrozumieć, bez mozolnej nauki danego systemu. W projektach IT liczy się efektywność, a nie gust lub estetyka – warto więc postawić na minimalizm. Tymczasem developerom czasami wydaje się, że złożone pomysły są skuteczniejsze. Czasem po prostu łatwiej jest im nie upraszczać, porządkować swojego kodu.
Drugi skrótowiec to Don’t Repeat Yourself – “nie powtarzaj się”. Najprościej tłumacząc, należy:

• Nie kopiować kodu. Nieraz kusi, aby powielić fragment, który już raz się sprawdził – czy nie najprościej użyć ctrl+C, ctrl+V? Wcale nie! Jeśli się tego nie kontroluje, po pewnym czasie może pojawić się mnóstwo kopii. A co będzie, gdy okaże się, że trzeba coś we wszystkich zmienić?
• Nie powtarzać czynności. Niejedną operację wykonuje się “ręcznie”, np. wpisując skomplikowaną komendę kompilacji w terminalu lub tworząc klasę/moduł zawsze według określonej formatki. Często można to zautomatyzować za pomocą skryptów. W dużych repozytoriach jest to wręcz niezbędne, aby nie tracić mnóstwa czasu na ciągłe kontrolowanie jakości bazy kodu, nad którą pracuje kilkadziesiąt osób naraz.

I na koniec…

…coś innego: rusz się, developerze! Pisanie i czytanie kodu to nie jest całe Twoje życie. Programowanie może być wciągające albo denerwujące, ale pamiętajmy, że jesteśmy tylko ludźmi. Nie bez powodu zasady BHP zalecają przerwy co godzinę podczas pracy z komputerem. Każdy, największy nawet entuzjasta branży IT bywa zmęczony. Codzienne drobne rytuały poprawiają koncentrację i humor: regularne picie wody mineralnej, zaparzenie dobrej kawy, przerwa na drugie śniadanie. Dobrze jest też zadbać o tzw. przestrzeń socjalną: miejsce, gdzie można pogadać z kolegą – nie tylko o pracy. Dzięki temu umysł jest w stanie oderwać się od główkowania. Przekonaj się, że czasem wystarczy kilka minut odpoczynku, aby rozwiązanie uporczywego problemu łatwiej przyszło do głowy!