Blok 1 to typowy przykład rekurencji, czyli sytuacji, gdy funkcja wywołuje samą siebie z innym argumentem (tutaj fn(a-1)). Takie podejście pojawia się w programowaniu bardzo często, szczególnie przy rozwiązywaniu problemów, gdzie rozwiązanie można rozbić na mniejsze, podobne zadania. W Bloku 1 mamy tzw. przypadek bazowy (if(a==1) return 1), czyli moment, w którym dalsza rekurencja się zatrzymuje – bez tego każdy program rekurencyjny skończyłby się przepełnieniem stosu i błędem. Moim zdaniem, dobrze rozumiana rekurencja to jedna z podstaw algorytmiki – spotyka się ją choćby przy obliczaniu silni, ciągu Fibonacciego czy w algorytmach przeszukiwania struktur drzewiastych, np. w operacjach na drzewach binarnych. W praktyce branżowej warto wiedzieć, że rekurencja bywa bardzo elegancka i skraca kod, ale trzeba ją stosować z głową – łatwo przekroczyć limity stosu przy zbyt głębokim wywołaniu albo zapomnieć o przypadku bazowym, przez co program nie kończy działania. W standardach wielu języków (np. C, Java) rekurencja jest narzędziem jak każde inne, ale zawsze powinna być projektowana z myślą o czytelności i efektywności rozwiązania. Często spotykam się z sytuacją, gdzie początkujący próbują wszystko rozwiązywać rekurencyjnie, a to nie zawsze jest optymalne – niektóre problemy lepiej rozwiązać iteracyjnie, choćby ze względu na wydajność. W tym konkretnym kodzie zastosowanie rekurencji jest klasyczne i poprawne, więc zdecydowanie jest to dobry wzór do nauki.
Wiele osób myli pojęcie rekurencji z prostym przetwarzaniem argumentów funkcji albo próbą wywołania innej funkcji. W przypadku Bloku 2 mamy tylko zwykłe odejmowanie i dodawanie – funkcja fn nie wywołuje samej siebie, więc nie występuje tu rekurencja. To jest bardzo częsty błąd, gdzie ktoś widzi podobieństwo w nazwach i strukturze, ale nie dostrzega istoty rekurencji, czyli tego samowywołania z innym argumentem. Blok 3 z kolei próbuje wywołać inną funkcję (fun zamiast fn), więc to również nie jest rekurencja, tylko – w najlepszym wypadku – jakaś forma współdziałania funkcji, ale nie spełnia definicji rekurencji. Częsty błąd to mylenie rekurencji z przekazywaniem sterowania do innych funkcji. Natomiast Blok 4 jest już najprostszym przypadkiem – nie wywołuje żadnej funkcji w środku, po prostu zawsze zwraca 2, poza przypadkiem bazowym. Brak tu jakiejkolwiek logiki rekurencyjnej. W praktyce programistycznej rekurencja to bardzo specyficzny wzorzec, gdzie kluczowe jest istnienie sprawdzalnego warunku zakończenia (tzw. przypadek bazowy) oraz wywołanie tej samej funkcji, ale z „mniejszym” lub „prostszym” przypadkiem. Bez tych elementów nie można mówić o poprawnej implementacji rekurencji. Osobiście zauważyłem, że wielu uczniów próbuje używać rekurencji do wszystkiego, nie rozumiejąc, że bez samowywołania i przypadku bazowego to po prostu nie działa tak, jak powinno. Branżowe standardy jasno wskazują, że rekurencja jest narzędziem do rozwiązywania problemów, które mają naturalną strukturę rekurencyjną – na przykład przetwarzanie struktur drzewiastych, rozwiązywanie łamigłówek typu wieże Hanoi, czy sortowanie szybkie (quick sort). Jeśli jednak funkcja nie wywołuje samej siebie, nie spełnia warunków rekurencji, nawet jeśli operuje na podobnych argumentach lub odwołuje się do innych funkcji.