Osoby czytające tytuł tego artykułu i troszeczkę znające się na rzeczy mogę popukać się w głowę - jak to "czy potrzebny"? Przecież wiadomo, że potrzebny! Tak - faktycznie pytanie można by było sformułować inaczej, na przykład "jak bardzo jest potrzebny". Ale po kolei.

Kod oprogramowania można pisać na różne sposoby i jest to rzecz, która ewoluuje przez całą karierę programisty. Od najprostszych kontrukcji, na których koder uczy się w ogóle fachu, poprzez pisanie większych aplikacji w nieefektywny i nieustrukturyzowany sposób, aż do wręcz przesadzonych konstrukcji i znalezienia złotego środka. Jeśli mówimy nie tylko o tym, czy kod działa, ale także jak prezentuje się jego jakość, bierze się pod uwagę kilka czynników, które szczególnie zyskują na znaczeniu w obliczu pracy zespołowej. I być może nie uwierzycie, ale jednym z tych czynników jest... estetyka. Tak, jak interfejs użytkownika może być ładny lub brzydki, użyteczny lub nie, tak kod może być napisany ładnie lub brzydko.

I na tym się dzisiaj skupimy, gdyż w przeciwieństwie do wielu dziedzin życia, estetyka kodu źródłowego może być opisana standardem. Oczywiście, nie tylko ona gra rolę w tym, czy uznamy kod za dobry jakościowo - bardzo ważne, a w konsekwencji dużo ważniejsze jest architektura, w tym projekt klas i podatność na rozszerzenie. Jest to temat bardzo, bardzo szeroki, jednak od czegoś trzeba zacząć, najlepiej prostego. Stąd zapraszam na rozważania o urodzie linijek składających się na źródła oprogramowania.

Czym jest standard kodowania?

Jest to dokument lub zbiór wskazówek z omówieniem zasad pisania poszczególnych instrukcji kodu w danym języku programowania lub technologii. Przy czym rozumiem, że nadal można to rozumieć dwojako i na różnym poziomie szczegółowości. Dlatego, bazując na przykładach, można powiedzieć, że standard kodu może określać choćby:

• w jakim miejscu stawia się klamrę otwierającą ciało metody czy klasy,
• jakie odstępy stosować zarówno przy zagnieżdżaniu kodu, jak i podczas pisania instrukcji,
• jakimi zasadami kierować się przy nazywaniu klas lub metod,
• jaka jest kolejność metod i pól w klasach.

Te zasady określają zatem zarówno estetykę kodu, jak i zasady nazewnictwa. Jednak głównym celem nie jest to, aby "bebechy" oprogramowania prezentowały się pięknie i historycy sztucy w przyszłości zachwycali się bogactwem smaczków. Przede wszystkim przyczyną ustalenia wspólnego standardu kodu jest potrzeba unifikacji kodu pisanego przez różnych programistów. Wspominałem o tym, że coraz szerzej zakrojona praca zespołowa wymaga dodatkowych ustaleń i porządku. Wyobraźcie sobie bowiem jeden program implementowany przez trzy osoby, z których każda pisze w zupełnie inny sposób - jeden stawia klamry tak, drugi metody rozpoczyna wielką literą, a trzeci nie używa tabulatorów do odstępów, tylko spacji. Powstaje chaos, który nie tylko brzydko wygląda, ale przede wszystkim nie pozwala szybko zorientować się w programie i poznać szczegółów implementacji. Sami zresztą możemy tego doświadczyć, próbując czytać obcy amatorski kod lub nawet samego siebie sprzed kilku lat, kiedy to doświadczenie było mniejsze. W przypadku nazewnictwa mówimy o dodatkowym aspekcie, którym jest idea samodokumentującego się kodu. Jest to osobny temat, ale kluczowe jest to, że bez żadnych reguł, każdy programista pod kątem "słowotwórstwa" będzie znacząco odbiegał od innych (na zasadzie "przecież ja rozumiem, co tutaj jest napisane, inni też się domyślą"). Oczywiście, nie da się tego ustandaryzować całkowicie, ale cenne jest wskazanie, kiedy stosujemy notację PascalCase, a kiedy camelCase, kebab-case czy snake_case, jakich przedrostków (i czy w ogóle) używamy itd.

Czym grozi brak standardu kodowania?

Poniekąd wskazaliśmy to sobie w poprzednim akapicie - brak standardu oznacza, że każdy pisze kod "po swojemu", pełny wiary w dobrą wolę i to, że wszyscy rozumieją pisany tekst tak, jak on(a). Aby było jasne, to oczywiście - pełna zgodność w zespole i podobny styl można wypracować bez żadnych standardów. Może się też okazać, że wszyscy członkowie zespołu tworzą kod w jednakowy sposób, naturalnie się dostosowując. Jednak jest to szczególnie szczęśliwy zbieg okoliczności, zakładający też równy poziom doświadczenia całego składu. Natomiast tak, jak o umowach mówi się, że są "na trudne czasy", tak to samo można powiedzieć o standardzie kodu.

Nie jest niczym złym, że w zespole są różne style pisania, o ile te odmienności nie są znaczące i zrozumiałe tylko dla wybranego programisty. Natomiast dość prosto można znaleźć słuszne powody, dla których styl powinien być jednak zunifikowany. Jeśli tak nie jest, to możemy doprowadzić do:

• dłuższego czasu potrzebnego na zrozumienie takiego kodu i skorzystania z niego,
• dłuższych przeglądów kodu, co zaburza pracę nad nową funkcjonalnością,
• nieporozumień i złego użycia wzajemnej pracy lub wręcz duplikowania jej (np. poprzez napisanie kodu, który już jest w programie, ale w innym module i pod inną nazwą),
• problemów ze scaleniem kodu i zgłaszaniem konfliktów, które tak naprawdę nie istnieją (np. problemy z białymi znakami),
• dłuższym czasem wprowadzenia i zadomowienia się nowych programistów, którzy dopiero zaczęli pracować w danym projekcie.

W dalszej perspektywie problemy z unifikowaniem pracy mogą doprowadzić do złego oprogramowania, którego w dodatku stworzenie zabierze więcej czasu niż zakładano. Ale to nie wszystko - w skrajnych przypadkach dochodzą konflikty w zespole, konieczność spotkań wyrównujących lub pisanie dodatkowej dokumentacji, komentarzy w kodzie i przede wszystkim frustracja.

Kiedy warto i jak stworzyć standard kodowania?

Oczywiście, standardy kodowania spotyka się w środowiskach, gdzie odbywa się praca zespołowa. Dotyczy to przede wszystkim firm zajmujących się oprogramowaniem, ale też np. społeczności, które wspólnie opracowują kod konkretnego software'u. Mam tutaj na myśli zwłaszcza grupy utrzymujące projekty opensource'owe, gdzie przypadkowość dostarczanego kodu może być jeszcze większa, chyba że jest to trzymane w ryzach przez coś w rodzaju "komitetu". Wątpliwe jest z kolei, czy osobny standard kodowania jest potrzebny indywidualnym programistom (np. freelancerom pracującym samodzielnie) oraz grupom, które współpracują ze sobą przez krótki okres nad projektami uczelnianymi czy szkolnymi. Natomiast to nie oznacza, że w tych przypadkach można robić, co się chce - warto trzymać się standardów, ale zewnętrznych, o których jeszcze sobie wspomnimy.

Pozostaje zatem pytanie, jak tworzyć taki standard. Wcześniej użyłem słowa "dokument" i rzeczywiście na myśl przychodzi konkretny plik tekstowy, w którym zostaną opisane i zawarte wszystkie reguły. W Wilda Software też kiedyś tak do tego podchodziliśmy, ale po latach zaczęliśmy mieć coraz więcej wątpliwości, czy to dobre postępowanie. Stworzenie odpowiedniego dokumentu jest pracochłonne i niekoniecznie spowoduje, że wszyscy łatwo odnajdą w nim to, co powinni. A trzeba przyznać, że standard kodu to nie książka z dobrą fabułą, którą się chłonie - ludzi niekoniecznie interesuje historia powstania poszczególnych reguł (chyba że w formie ciekawostek, które jeszcze mocniej pozwalają zapamiętać szczegóły), ale konkretne wytyczne, do których zaglądają w razie potrzeb i szybko je znajdują. Dlatego od pewnego czasu nasz standard jest tworzony w formie przykładów, kilku większych fragmentów kodu, który jest bezsensowny funkcjonalnie, ale pokazuje idealny kod pod względem stylistycznym. Mamy wrażenie, że napisanie wytycznych w takiej formie jest nie tylko szybsze, ale i łatwiej przyswajalne, gdyż można wzrokowo porównać poszczególne elementy z własnym kodem. Natomiast to każdy zespół musi wypracować sobie sam.

Niezależnie od tego, czy piszemy pełny tekst, czy przykład, bez dodatkowych opisów się nie obejdzie, szczególnie przy regułach nazewniczych. Tam, gdzie to możliwe, warto też krótko skomentować powody, dla których poszczególne wytyczne zostały wprowadzone. Z jednej strony dlatego, że szczególnie młodzi programiści lubią dopytywać "a dlaczego, a po co", gdy weryfikują swoją teoretyczną wiedzę z praktyką. Z drugiej - tak, jak pisałem, czasem pozwala to łatwiej zapamiętać pewne fragmenty. Przypomnijcie sobie, kiedy nauka historii była łatwiejsza - gdy opieraliśmy się na samych datach i suchych opisach czy gdy dowiadywaliśmy się różnych anegdot o bitwie pod Grunwaldem. Tutaj taką może być fakt, dlaczego polecamy ciało każdej pętli czy instrukcji warunkowej otaczać nawiasami klamrowymi, nawet, gdy to tylko jedna linijka - przypomnijmy sobie historię z błędem w SSL w kodzie Apple'a. To przy okazji dobry przykład, który pokazuje, że odpowiedni standard potrafi zaoszędzić różnych perypetii (nawet, jeśli opisywana sytuacja to po prostu zwykły, choć poważny błąd).

Warto również pamiętać o tym, że w różnych edytorach kodu istnieją mechanizmy, pozwalające do pewnego stopnia kontrolować pisanie zgodnie ze standardem. Są to zwykle pliki konfiguracyjne do wgrania lub konkretnie ustawienia. W pewnych przypadkach to również może być odpowiednia "dokumentacja" specyfiki pisania kodu w danym zespole.

Ostatnia rzecz warta uwagi w tej sekcji - jak już wcześniej zasugerowałem, standard kodu nie jest uniwersalny dla każdego języka programowania. Może być, ale zwykle nie jest, gdyż każda technologia wiąże się z pewnymi wewnętrznymi standardami, na których powinno się opierać ten swój, dostosowany do danego zespołu.

Jak ściśle trzymać się standardu?

To dobre pytanie. Oczywiście, narzuca się odpowiedź "w pełni" i przez pewien czas tak do tego podchodziliśmy w zespole podczas przeglądów kodu. Jednak, jak ze wszystkim w życiu, warto zachować umiar.

To nie jest tak, że osoba nietrzymająca się standardu jest od razu godna potępienia i ma spadać sobie do wulkanu (pozdrowienia dla Maćka i Tymona). Tak, jak pisałem, czasem różnice stylistycznie nie są na tyle duże, aby zostały negatywnie rozpatrzone. Z punktu widzenia harmonogramu projektu też nie ma sensu robić drobiazgowego przeglądu kodu tylko pod tym kątem - można przyjąć założenie, że uwagi dotyczące estetyki powinny raczej być od razu zauważalne lub stanowić wyraźne zagrożenie w dalszym rozwoju oprogramowania. Warto natomiast przykładać większą wagę do przeglądów programistów młodych, jeszcze nieukształtowanych, aby wyrobili sobie poprawne nawyki, niebędące kulą u nogi w dalszej współpracy.

Dodatkowo, nie należy zapominać, że standard nie musi być zacementowany - to naturalne, że wraz z rozwojem technologii, umiejętności programistów czy po prostu nowych doświadczeń, pewne wytyczne mogą ulegać zmianie. Dlatego nie zawsze odstępstwa od narzuconych reguł należy traktować jako błędy i wskazywać je niczym na sprawdzianie - dobrze jest od czasu do czasu spojrzeć na nie pod kątem tego, czy pewne zmiany w standardzie mogą w czymś pomóc zespołowi lub projektowi.

Standardowe standardy dla języka programowania

Wspomniałem wcześniej o tym, że swój standard należy opierać na zewnętrznych wytycznych, charakterystycznych dla danej technologii. Niektórzy pewnie powiedzą, że w ogóle powinno się opierać wyłącznie na światowych standardach, gdyż... są światowymi standardami. Bez względu na to, którą szkołę reprezentujemy, warto zapoznać się z tym, jakie są "oficjalne" wskazówki.

W przypadku języka PHP jest to PSR, czyli PHP Standards Recommendations, który jest nie jednym dokumentem, ale ich zbiorem z różnymi wytycznymi. W niektórych momentach widać, że jest mocno osadzony w swoich korzeniach związanych z językiem C/C++ i to są elementy, które dostosowaliśmy do swoich potrzeb w Wilda Software. Tym niemniej, tak, jak pisałem, warto zerknąć na takie propozycje uznawane za ogólnie obowiązujące.

Nie zawsze dla jednego języka istnieje jeden zestaw oficjalnych wytycznych. Java jest tak popularnym i "korporacyjnym" językiem programowania, że stała się obiektem zainteresowania różnych firm, takich jak Google czy Oracle, z których każdy utworzył swój standard (choć ten ostatni ma już swoje lata, a nawet wieki). W sieci można znaleźć też standardy opracowane np. przez Uniwersytet Hawajski i wiele innych instytucji.

Nie inaczej jest z każdym innym językiem - Pythonem, JavaScriptem i kolejnymi. Niekoniecznie należy trzymać się ich w pełni, natomiast warto wiedzieć, że będąc jak najbliżej "bazy", jednocześnie będziemy bliżej globalnych standardów.

W Internecie możemy szukać informacji o tym zagadnieniu pod terminami coding standards czy też coding guidelines.

Czy tylko kodowanie potrzebuje standardu?

Najczęściej mówi się o standardzie kodu, ale to nie jest jedyna kwestia, która powinna być uregulowana, co zresztą widać po powyższych odnośnikach do światowych standardów. W Wilda Software funkcjonuje też np. standard tworzenia schematów bazodanowych, który być może jest nawet ważniejszy z uwagi na to, iż modyfikacja schematu powoduje często więcej zamieszania niż refaktoryzacja kodu. Poza tym umiejętność szybkiego odnalezienia się w dużych relacyjnych bazach i zapytaniach do nich jest równie cenna jak umiejętność poruszania się po kodzie.

Innym przykładem są wytyczne tworzenia dokumentacji, choć w tym przypadku warto pamiętać, iż każdy dokument może wymagać specyficznego podejścia ze względu na opisywany projekt bądź odbiorców. Tym niemniej, nie zaszkodzi wypracować sobie choćby wspólnego szablonu dokumentu, np. dotyczącego tworzenia wymagań czy architektury oprogramowania.

Wreszcie, bywają również nie tyle standardy, co procedury postępowania w różnych przypadkach, zarówno technicznych (wdrażanie nowej wersji na serwer), organizacyjnych (procedura przyjęcia nowej osoby w zespole) czy biznesowych (wytyczne dot. korespondencji z klientem).

Podsumowanie

Standardy kodowania to ciekawy temat, choć w gruncie rzeczy prosty - ma zapobiec "rozjeżdżaniu się" kodu pisanego przez różne osoby i tym samym ułatwiać tworzenie oprogramowania. Natomiast ten obszar łączy się też z tworzeniem dokumentacji kodu, co jest znacznie szerszym zagadnieniem. Należy jednak od czego zacząć i małymi kroczkami polepszać swój wasztat, gdyż standardy również temu służą.

Pozdrawiam i dziękuję - Jakub Rojek.