Kod ci wszystko wytłumaczy
2011-10-27 22:12(…) są dwa style pisania – pierwszy to: “popatrzcie jaki ja jestem mądry” – a drugi to: “popatrzcie jakie to proste”.
Jerzy Grębosz, Symfonia C++
Autor tego stwierdzenia miał na myśli przede wszystkim pisanie technicznej prozy, a więc wszelkiego rodzaju artykułów, książek, kursów i tutoriali (i blogów? ;]). Po namyśle stwierdzam jednak, że równie dobrze nadaje się ono i do poezji – czyli kodu. Podobnie bowiem przedstawia się kwestia wyższości drugiego stylu nad pierwszym, w większości przypadków.
“Większość” nie oznacza aczkolwiek “wszystkich”. Czasami górę biorą na przykład kwestie wydajnościowe, które niekiedy uzasadniają wyprodukowanie kodu wyglądającego jak przemyślnie zaszyfrowane zaklęcie. Klasycznym przykładem jest procedura szybkiego obliczania 
, wyciągnięta wprost ze źródeł Quake‘a III:
- float InvSqrt (float x){
- float xhalf = 0.5f*x;
- int i = *(int*)&x;
- i = 0x5f3759df - (i>>1);
- x = *(float*)&i;
- x = x*(1.5f - xhalf*x*x);
- return x;
- }
Funkcja ta (której autorstwo niesłusznie przypisuje się czasem Johnowi Carmackowi) doskonale pokazuje, jak ważna jest czytelność i zrozumiałość kodu. Robi to w najlepszy możliwy sposób, tj. nie posiadając żadnej z tych dwóch cech :) W zamian oferuje znacznie ważniejszą w swoim zastosowaniu jakość – czyli wydajność.
Obliczanie odwrotności pierwiastka kwadratowego to jedna z najczęściej używanych operacji w grafice 3D – zawiera ją np. każda normalizacja wektora. Sensowne jest więc jak największe zoptymalizowanie tej funkcji. Będzie ona przecież wywoływana setki czy tysiące razy podczas renderowania pojedynczej klatki.
W sumie daje to kilkadziesiąt tysięcy wywołań na sekundę, a to dość unikatowa perspektywa jeśli chodzi o wartościowanie szybkości, czytelności, elastyczności – i tak dalej. I właśnie dlatego wspominam o niej jako o oczywistym wyjątku. Parafrazując popularną ostatnio proporcję: w 99% przypadków podobny kompromis nie będzie musiał dotyczyć nawet 1% kodu :)
O wiele bardziej typową sytuacją jest bowiem zdecydowana wyższość klarowności, czystości i zrozumiałości. To jest właśnie ów drugi styl: “zobaczcie jakie to proste”. Bierze on pod uwagę oczywisty w gruncie rzeczy fakt, iż głównym odbiorcą kodu jest człowiek, a nie komputer. Jeśli przyszły czytelnik potrafi z łatwością zrozumieć intencje autora – bo są one wyrażone przejrzyście i jednoznacznie – to niemal równie łatwo przyjdzie mu modyfikacja, rozszerzanie i poprawianie programu. Nie wspominając już nawet o tym, że program, który daje się łatwo “wytłumaczyć” samym kodem z definicji nie może być zanadto skomplikowany. Syntaktyczna prostota przekłada się więc na semantyczną, która z kolei dobrze koreluje z innymi pożądanymi właściwościami – jak choćby niezawodnością.
Author: Xion, posted under Programming, Thoughts »
-
Tomasz Dąbrowski:
October 27th, 2011 o 23:21Ten przykładowy kod jest akurat trywialnie prosty, podobnie jak każda inna funkcja która nie odwołuje się do niczego poza swoimi argumentami.
Dla mnie skomplikowany kod to taki który ma dziesiątki poziomów zagnieżdżenia zanim zrobi coś praktycznego. Co z tego że funkcje są proste skoro callstack ma 30 linijek i po drodze maca 50 różnych plików?
No i co do tłumaczenia kodu to jest jeszcze nieśmiertelne
return x; // returns x
:D
-
maku:
October 27th, 2011 o 23:58Zazwyczaj, kod piszemy raz, a czytamy kilka/kilkadziesiąt razy. Pracując w grupie grono czytelników kodu może być/ jest większe. Warto poświęcić więcej czasu na napisanie czytelnego kodu (ewentualnie na komentarz przy _optymalnym_, ale nie czytelnym kodzie).
-
Krzysztof Szumny - noisy:
October 28th, 2011 o 16:37przytoczony kod nie obrazuje tak naprawdę istoty problemu. Funkcja jest krótka a jej nazwa mówi wszystko co o niej chcemy wiedzieć. Z takiej funkcji się po prostu korzysta a nie debaguje ją. Nawet jeżeli padło by podejrzenie, że coś z nią jest nie tak, to do przeanalizowania jej działania wymagana jest wiedza tylko z matematyki i podstawy aretmetyki binarnej.
Schody zaczynają się gdzie indziej. Gdyby funkcja nazywałaby się bardziej bezosobowo np. “prepareArgument” a w dodatku tak naprawdę konstruowałaby binarnie (wg specyfikacji) jakiś fragment pliku (zip/png/mp3), to nagle by się okazało… że to wszystko kupy się nie trzyma.
Wszyscy jesteśmy programistami, ale oprogramowujemy bardzo często rzeczy, z którymi nie mieliśmy styczności. Pół biedy, jeżeli coś robimy wg. specyfikacji (specyfikacji pliku, dostarczonej przez klienta), gorzej gdy jakiś inny pracownik wymyślił sobie “bardzo sprytny” zoptymalizowany algorytm do komunikacji między urządzeniami/serwerami/modułami… niestety zapomniał gdzieś spisać lub zaktualizować sposobu jego działania.
Recent posts
