Kod powinien być na tyle elegancki, aby bez żenady pójść z nim na przyjęcie.

Ostatnimi czasy wpada mi do głowy wiele pomysłów na ciekawe wpisy do bloga, ale niestety akurat mam teraz sporo nauki i wiele różnych projektów do zrobienia. Tak więc postanowiłem dzisiaj dodać tylko taki lekki wpis na temat elegancji kodu, zakończony ciekawymi cytatami związanymi z programowaniem.

Czasami zdarza mi się oglądać kod, który nie wygląda jakby był pisany przez stado małp z problemami alkoholowymi. Kod, który jest uporządkowany, przejrzysty i którego analiza przychodzi z łatwością, a przy tym nie jest rozlazły. Taki kod zdecydowanie świadczy pozytywnie o programiście, który go napisał.


Aby pisać piękny kod należy się cały czas pilnować, rozwijać i przede wszystkim myśleć. Istnieje wielu ludzi których programy powstają w myśl zasady "pragmatycznego programowania". Oznacza to, że najważniejsza jest skuteczność i funkcjonalność kodu, a nie trzymanie się dokumentacji, sztywnych konwencji i zasad języka. Innymi słowy "najważniejsze, że działa". Bez wątpienia program, który działa jest zdecydowanie fajniejszy od tego, który pozbawiony jest takiego "ficzera". Niemniej jednak dla samego siebie, a już z całą pewnością dla ludzi, z którymi wspólnie tworzysz oprogramowanie lepiej by było aby Twój kod, oprócz tego, że działa, był również elegancki. Nie oznacza to, że należy restrykcyjnie trzymać się dokumentacji i miliona zasad dobrego programowania i popadać w kolejną skrajność, tylko tak jak to w życiu często bywa, należy postarać się znaleźć złoty środek i harmonię między funkcjonalnością, a estetyką.

Aby zobrazować o co mi chodzi podam pewien przykład. Mamy do czynienia z programistą P1, level: ortodoksyjny pragmatyzm. Taka osoba, dla wszystkich pól każdej klasy wpisze modyfikator 'public' (w języku, który posiada tego typu modyfikatory dostępu), bo tak łatwiej, albo właściwie to nie wpisze żadnego, ponieważ domyślnie jest 'public', więc tak będzie szybciej. O ile przy malutkich, osobistych projektach takie podejście może nie prowadzić do żadnych negatywnych skutków, to przy większych projektach tworzonych w zespole, wcześniej czy później okaże się to piłowaniem gałęzi na której się siedzi.
Odwrotnie zachowa się programista P2, level: człowiek-dokumentacja, który każdemu polu każdej klasy nada modyfikator 'privet'. Niby konwencje programowania obiektowego mówią, że klasa powinna być czarną skrzynką z udostępnionymi metodami, a ukrytymi atrybutami, czyli powinno się zastosować enkapsulacje. Jednak jaki jest sens nadawać modyfikator 'privat' pojedynczej zmiennej, dla której nie potrzebujemy walidacji danych, a chcielibyśmy móc pobierać i ustawiać jej wartość? Wówczas, gdy nadamy takiej zmiennej dostęp typu 'private', będziemy musieli jeszcze dopisać gettery i settery, niepotrzebnie wydłużając i zaciemniając kod.

Tak więc sztywne przestrzeganie ani jednej, ani drugiej zasady pisania oprogramowania nie prowadzi do tworzenia pięknego kodu. Należy więc nad każdą, pojedynczą linijką pomyśleć, czy na pewno jest ona potrzebna i jakie konsekwencje przyniesie jej wpisanie. W moim odczuciu elegancki kod to taki, który jest możliwie najkrótszy, najprostszy, funkcjonalny, wydajny, a przy tym CZYTELNY i prosty w modyfikacji.

Zdaję sobie sprawę, że pisanie takiego kodu wymaga nauki, wprawy, doświadczenia i ciągłego doskonalenia się, no ale chyba nikt nie oczekuje dobrych rezultatów, bez dobrego przygotowania.

Na zakończenie parę interesujących cytatów, które udało mi się znaleść:

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies."

"Istnieją dwie drogi projektowania oprogramowania: Jedna to stworzyć je tak proste, że oczywiście nie będzie zawierać żadnych niedoskonałości, druga to stworzyć je tak skomplikowane, że nie będzie zawierać żadnych oczywistych niedoskonałości."

- C.A.R Hoare

"Programs must be written for people to read, and only incidentally for machines to execute."

"Programy powinny być pisane dla ludzi do czytania i tylko przypadkowo do wykonywania przez maszyny."

-Hal Abelson

"Measuring programming progress by lines of code is like measuring aircraft building progress by weight"

"Mierzenie postępu w programie za pomocą ilości linii kodu jest jak mierzenie postępu w budowaniu myśliwca za pomocą jego wagi."

- Bill Gates

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

"Debugowanie kodu jest dwa razy trudniejsze niż jego pisanie. Dlatego, jeżeli napiszesz kod tak zmyślnie jak to tylko możliwe, to z definicji nie jesteś na tyle mądry by go debugować."

- Brian W. Kernighan

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.”

"Zawsze programuj tak, jakby osoba, która potem będzie utrzymywać Twój kod była brutalnym psychopatą, który wie gdzie mieszkasz"

- Martin Golding

"One of my most productive days was throwing away 1000 lines of code."

"Jednym z moich najbardziej produktywnych dni było wywalenie 1000 linii kodu."

- Ken Thompson

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

"Byle głupiec potrafi napisac kod zrozumiały dla komputera. Dobrzy programiści piszą kod zrozumiały dla ludzi."

- Martin Fowler

"The best code is no code at All"

"Najlepszy kod to brak kodu w ogóle"

- Jeff Atwood