Będziesz miłował kod swój

Przynoszę wam tedy jedno i najważniejsze przykazanie:

Dbaj o kod, nigdy nie wiesz, kiedy będziesz musiał do niego wrócić. Praca programisty polega na rozwijaniu oprogramowania, a nie na jego ciągłym przepisywaniu od zera.

Pisząc program, stosuję ścisłe zasady jego tworzenia. Są miejsca, gdzie czytelniej wyglądają instrukcje warunkowe, są miejsca, gdzie czytelniejsze są przełączniki wyboru. Niektóre zasady są niezmienne. Nie uznaję więcej niż jednego pustego wiersza z rzędu. Nie uznaję operatorów, które nie są poprzedzone spacją i po których spacja nie występuje. Po przecinku wymagam spacji. Klamra otwierająca blok zawsze jest wyrównana do lewej względem wyrażenia warunkowego, do którego jest przypisana. Klamra zamykająca znajduje się na tym samym poziomie wcięcia. Ściśle formatuję nawet zapytania SQL:

$query =
"
	SELECT foo.a, foo.b, baz.c
	FROM foobar AS foo
	INNER JOIN bazorg AS baz
	USING (d)
	WHERE foo.a > 3
	AND baz.c = 'a'
";

Nie twierdzę, że moje zasady są jedynie słuszne. Są spójne i gwarantują mi, że kod jest czytelny do tego stopnia, że mogę szukać interesujących mnie miejsc, przelatując wzrokiem po kodzie podczas ciągłego przewijania. Ma to kolosalne znaczenie przy systemie CMS, gdzie poszczególne moduły liczy się w tysiącach linii.

Niestety, mojego kolegi żadną siłą nie daje się zmusić do dbania o kod. Nie mówię o ścisłym przestrzeganiu moich reguł. Chodzi o utrzymanie jakiegokolwiek standardu. Nic nie szkodzi - jako, że regularnie robię przegląd kodu, każdą okazję wykorzystuję do jego czyszczenia. Łamię długie linie, dodaję spacje po przecinkach i dookoła operatorów, zamieniam indentację ze spacji na tabulatory i usuwam białe znaki z końców wierszy.

Przyświeca mi zasada wyznawana też przez jednostki S.W.A.T. - clean as you go.

Usuwam też brzydkie hacki, które dobrze działają. Wolę przepisać je w poprawny sposób i móc szybko dojść, co dany kawałek kodu robi. Próba zrozumienia czegoś, co przypomina relikty obcej cywilizacji - zwłaszcza, kiedy klient wisi na telefonie i dopytuje o termin zamknięcia poprawek - z pewnością nie należy do przyjemnych.

Ktoś pewnie nazwie to stratą czasu, ale dla mnie to jedyna metoda wspólnej pracy nad większą bazą kodu. Jeśli programista sam nie szanuje swojego kodu, to znaczy, że lekceważąco traktuje swoją pracę. Jeśli ktoś nie lubi swojej pracy, to po co ją wykonywać? Oczywiście, są projekty, które się dziedziczy po script kiddies i tam często zdarza się pisać kod wiele pozostawiający do życzenia, byle wpasował się w otoczenie i nie sugerował, że nad projektem pracował ktoś rozsądny, ale to historia na inną okazję.