Rozwiązując takie zadania, warto nauczyć się dokładnie patrzeć na strukturę kodu. Funkcja fun1 przyjmuje tablicę intów i sumuje jej elementy. Tu pętla for przechodzi po wszystkich sześciu indeksach – od 0 do 5. Gdy podmienisz na liczby z zadania: 3, 4, 2, 4, 10 oraz 0 – po prostu dodajesz te wartości do siebie. Suma wychodzi 23. Czyli wynik funkcji to właśnie 23. To taki bardzo typowy przykład sumowania elementów tablicy – nie tylko na lekcjach, ale praktycznie wszędzie, np. jak liczysz sumę zamówień w sklepie internetowym albo punkty gracza w grze. Jeśli chodzi o dobre praktyki w C++, to warto wiedzieć, że lepiej przekazywać tablicę z dodatkowym parametrem długości, żeby nie robić magicznych liczb jak to '6' w pętli – można się wtedy łatwo pomylić przy zmianie rozmiaru. Moim zdaniem dobrze jest od razu przyswoić sobie nawyk wykorzystywania std::vector zamiast „gołych” tablic, bo są bezpieczniejsze i elastyczniejsze. To już taki krok w stronę kodu produkcyjnego. Ale podsumowując – jeśli widzisz tak napisany kod, to zawsze patrz, ile razy pętla się wykona i jakie są wartości w tablicy. Tylko tyle i aż tyle. W praktyce ta umiejętność przekłada się na szybkie debugowanie i pisanie niezawodnych programów.
W tego typu zadaniach bardzo łatwo popełnić błąd w ocenie działania pętli oraz sumowania wartości w tablicy. Często pojawia się przekonanie, że funkcja może zwracać zero, bo ostatni element tablicy to 0 – ale trzeba pamiętać, że funkcja sumuje wszystkie elementy i zero po prostu nie wpływa na całą sumę, więc wynik się nie wyzeruje. Bywa też, że sugerujemy się pierwszą liczbą z tablicy albo jakąś wyróżniającą się, na przykład 10, myśląc, że to ona jest odpowiedzią – ale to nie ma uzasadnienia w kodzie. W pętli for wyraźnie jest napisane i < 6, czyli przeglądamy sześć elementów. Każdy z nich jest dodawany do zmiennej wynik. Kod nie ma żadnych warunków ani instrukcji przerwania, więc nie można zatrzymać się „na” jakiejś wartości, ani zignorować jakiejkolwiek liczby. Niektóre osoby mogą też popełnić błąd i dodać tylko część elementów albo pomylić kolejność, przez co suma wychodzi 10, 20 lub inna, ale przy mechanicznej analizie kodu to niemożliwe. Odpowiedź 20 pojawia się czasem, kiedy ktoś przez przypadek nie zliczy ostatniego zera, a z kolei 10 to typowy skrót myślowy – może wynikający z szybkiego rzutu oka na największą liczbę w tablicy, jednak suma elementów to nie to samo, co ich maksimum. Z mojego doświadczenia wynika, że bardzo wielu uczniów nie przywiązuje wagi do sumowania wszystkich elementów, zwłaszcza jak pojawia się zero – a przecież matematyka jest tu bezlitosna. W programowaniu sumujesz wszystko jak leci, jeśli nie ma warunku czy filtru. Takie drobne nawyki, jak dokładne śledzenie każdej iteracji pętli, potem procentują podczas bardziej złożonych zadań na egzaminach czy w prawdziwych projektach. Pamiętaj: jeśli kod nie sprawdza warunków, to wykonuje dokładnie to, co jest napisane – nic mniej, nic więcej. Warto się tego trzymać.