Sztuka pisania kodu, którego nie sposób przeczytać

Wyobraź sobie, że otwierasz plik z kodem źródłowym i zamiast zwykłych pętli i instrukcji warunkowych widzisz ASCII art w kształcie pociągu lub mapy świata. Uruchamiasz kompilację i ten „rysunek" nagle zamienia się w działający kalkulator lub silnik szachowy. To nie magia — to IOCCC, najstarszy konkurs w internecie na pisanie najbardziej zaciemnionego kodu w C.

Repozytorium zwycięzców to ogromne archiwum wszystkich prac, które wygrały Międzynarodowy Konkurs Zaciemnionego Kodu w C od 1984 roku. To nie tylko zbiór dziwnych plików, ale prawdziwa encyklopedia ciemnych zakątków standardu C i ludzkiej pomysłowości.

Skąd wziął się pomysł dręczenia kodu

Wszystko zaczęło się w marcu 1984 roku. Landon Curt Noll i Larry Bassel pracowali w National Semiconductor i próbowali naprawić błędy w starym kodzie powłoki Bourne'a oraz narzędzia finger. Kod był tak okropny, przepełniony makrami i pozbawiony struktury, że Landon zastanowił się: a co jeśli ludzie zaczęliby celowo pisać zły kod?

Tak narodził się konkurs z dwoma celami. Po pierwsze, aby pokazać przez kontrast, dlaczego czystość kodu ma znaczenie. Po drugie, aby przetestować granice kompilatorów i znajomość niuansów języka. Autorzy nazywają to „programowaniem satyrycznym".

Co można znaleźć w tym archiwum

Wewnątrz repozytorium foldery są zorganizowane według roku. Każdy zawiera pliki źródłowe programów, Makefile do kompilacji oraz pliki z wyjaśnieniami od sędziów.

Programy-łamigłówki

Wiele prac wygląda jak przypadkowy zbiór znaków. Patrzysz na kod i nie rozumiesz, co robi, dopóki go nie skompilujesz. Na przykład program może obliczać liczbę Pi, podczas gdy sam tekst źródłowy jest wizualnie sformatowany jako koło.

Wykorzystywanie makr do granic możliwości

Uczestnicy często używają preprocesora C w taki sposób, że całkowicie przepisuje on logikę programu przed kompilacją. To świetny sposób, aby dowiedzieć się, jak #define tak naprawdę działają i jak można je nadużywać.

Wykorzystywanie nieoczywistych reguł C

Archiwum jest pełne przykładów wykorzystujących priorytety operatorów, o których większość programistów nawet nie wie. Zmusza to do zagłębienia się w standard języka i zrozumienia, dlaczego a[i] jest tym samym co i[a] i jak ta wiedza pomaga ukryć logikę.

Jak studiować te arcydzieła

Samo otwieranie pliku w VS Code i próba jego przeczytania to zły pomysł. Najprawdopodobniej zobaczysz chaos jednoliterowych zmiennych i dziwnych stałych. Sędziowie konkursu sugerują własny algorytm badania.

Po pierwsze, powinieneś przepuścić kod przez preprocesor. Polecenie takie jak gcc -E prog.c usunie wszystkie komentarze i rozwinie makra. Staje się odrobinę jaśniejsze, ale niezbyt.

Następnym krokiem jest użycie narzędzi do formatowania (beautifierów). Ale uważaj: niektóre programy są napisane tak sprytnie, że formatowanie je po prostu crashuje lub łamie logikę, jeśli jest powiązana z makrami definiującymi strukturę bloków.

Najbardziej niezawodną metodą jest uruchomienie kodu. Każdy folder zawiera instrukcje, jakie argumenty podać i jakiego wyniku oczekiwać. Czasami program wymaga określonych flag kompilatora, które są podane w Makefile.

Jaka jest praktyczna korzyść dla zwykłego programisty

Może się wydawać, że po co patrzeć na kod, który łamie wszystkie zasady przyzwoitości? W rzeczywistości to świetna sala treningowa.

1. Głębokie zrozumienie języka. Analizując zwycięzców IOCCC, uczysz się o efektach ubocznych, regułach promocji typów i zarządzaniu pamięcią więcej niż z jakiegokolwiek podręcznika.
2. Debugowanie i refaktoryzacja. Jeśli potrafisz zrozumieć, jak działa program o rozmiarze 512 bajtów sformatowany jako logo Linuksa, to zwykły „legacy" kod w pracy będzie dla ciebie jak bajka dla dzieci.
3. Zrozumienie, jak działają kompilatory. Zobaczysz, jakie optymalizacje wykonują nowoczesne kompilatory i na których konstrukcjach się potykają.

Czy warto zajrzeć do tego repozytorium

Jeśli kochasz łamigłówki i chcesz przetestować swoją wiedzę o C do granic możliwości — zdecydowanie tak. To jak muzeum sztuki cyfrowej, gdzie eksponaty można (i należy) uruchamiać.

Po prostu nie próbuj kopiować tego stylu w swoich projektach zawodowych. Autorzy projektu sami ostrzegają: „Proszę, nie pisz kodu w tym stylu!". To repozytorium istnieje, aby pokazać ekstremum i nigdy nie zbliżać się do niego w prawdziwym życiu.

Najlepiej zacznij od wczesnych lat, na przykład 1984 lub 1985. Programy są tam wciąż stosunkowo krótkie i łatwiejsze do „dekompresji" w głowie. Im bliżej współczesności, tym bardziej wyrafinowane stają się techniki zaciemniania.