Prawidłowa odpowiedź dobrze oddaje jedną z kluczowych zasad programowania strukturalnego: jeśli w programie pojawiają się powtarzające się sekwencje instrukcji, należy je wydzielać do osobnych procedur i funkcji. Chodzi o to, żeby kod był podzielony na logiczne bloki, które coś konkretnego robią i można je wielokrotnie wywoływać. Z mojego doświadczenia to właśnie ten nawyk najmocniej odróżnia „klepanie kodu” od świadomego programowania. Programowanie strukturalne opiera się na trzech podstawowych strukturach sterujących: sekwencji, selekcji (if, switch) i iteracji (pętle). Z tych klocków buduje się całe algorytmy, bez potrzeby używania chaotycznych skoków typu goto. Funkcje i procedury są naturalnym rozszerzeniem tej idei: pozwalają zamknąć fragment algorytmu w jednym miejscu, nadać mu nazwę i parametry. W praktyce, gdy masz np. fragment kodu liczący średnią z tablicy, walidujący formularz lub generujący fragment HTML, nie powtarzasz go w dziesięciu miejscach, tylko robisz funkcję, np. validateForm(), calculateAverage(), renderMenu(). To podejście daje kilka konkretnych korzyści: po pierwsze, kod jest krótszy i czytelniejszy, bo zamiast ściany instrukcji widzisz wywołania dobrze nazwanych funkcji. Po drugie, łatwiej się go testuje i debugguje, bo możesz sprawdzać działanie pojedynczych procedur. Po trzecie, zmiany w logice wprowadzasz w jednym miejscu – mniejsze ryzyko, że coś przeoczysz. W praktyce wszystkie współczesne języki używane w web devie (C, PHP, JavaScript, Python i inne) promują takie podejście jako absolutny standard. Moim zdaniem, jeśli ktoś potrafi z każdego większego problemu „wyciągnąć” sensowne funkcje i procedury, to ma już bardzo solidny fundament pod dalszą naukę programowania, także obiektowego.
W tym pytaniu łatwo wpaść w kilka typowych pułapek myślowych dotyczących stylów programowania. Programowanie strukturalne często myli się z innymi paradygmatami, szczególnie z programowaniem obiektowym albo z bardzo starym, „spaghetti kodem” opartym na instrukcjach skoku. W efekcie pojawiają się błędne skojarzenia, że skoro jest jakiś „styl programowania”, to pewnie czegoś kategorycznie zabrania, albo że sprowadza się do modnych pojęć jak obiekty czy klasy. Jednym z takich nieporozumień jest przekonanie, że w programowaniu strukturalnym nie wolno używać instrukcji warunkowych if. Jest dokładnie odwrotnie. Instrukcje warunkowe są jednym z trzech filarów programowania strukturalnego, obok sekwencji i pętli. To właśnie dzięki nim można budować czytelne rozgałęzienia logiki programu, zamiast skakać po kodzie goto. Gdy ktoś myśli, że „strukturalne” oznacza „bez if”, to zwykle wynika to z pomieszania pojęć albo z jakiegoś źle zapamiętanego hasła z teorii. Kolejna myląca sprawa to obiekty z polami i metodami. To już jest domena programowania obiektowego, które pojawiło się później i rozwinęło idee programowania strukturalnego, ale ich nie zastąpiło. W podejściu stricte strukturalnym skupiamy się na funkcjach, procedurach i danych, a nie na łączeniu ich w klasy i obiekty. Oczywiście w praktyce, w językach takich jak PHP czy JavaScript, często mieszamy te paradygmaty, ale sama możliwość tworzenia obiektów nie jest zasadą programowania strukturalnego. Dość zdradliwa jest też pokusa, żeby intensywnie korzystać z instrukcji skoku goto. Historycznie wiele języków je miało i programiści budowali z nich całe przepływy sterowania, co prowadziło do tzw. spaghetti code – kodu trudnego do śledzenia i utrzymania. Programowanie strukturalne właśnie z tym walczy: zamiast skakać w losowe miejsca pliku, używamy pętli, instrukcji warunkowych oraz dobrze wydzielonych procedur i funkcji. Jeżeli ktoś uważa goto za „skrócenie drogi”, to zwykle kończy z kodem, którego nikt nie chce potem dotykać. Sedno sprawy jest takie, że podstawowe dobre praktyki – unikanie goto, świadome używanie if i pętli, wydzielanie powtarzających się fragmentów do funkcji – to fundament, na którym buduje się dalsze, bardziej zaawansowane style programowania. Zrozumienie, dlaczego pozostałe odpowiedzi są sprzeczne z tym podejściem, pomaga lepiej ogarnąć, skąd wzięły się współczesne standardy jakości kodu i czemu tak mocno kładzie się nacisk na czytelność oraz utrzymywalność programu.