Pytanie dotyczy dobrych praktyk poprawiających czytelność kodu, czyli takich, które ułatwiają szybkie zrozumienie programu przez inną osobę (lub przez autora po czasie). Czytelność wpływa bezpośrednio na utrzymanie aplikacji, szybkość poprawiania błędów i jakość pracy zespołowej.
Poprawna jest odpowiedź: "Kod powinien być napisany bez wcięć i zbędnych enterów." W kontekście czytelności taki zapis jest niekorzystny, ponieważ wcięcia oraz sensownie użyte puste linie pełnią rolę "struktury wizualnej". Dzięki nim łatwiej rozpoznać bloki (np. warunki, pętle, funkcje), zasięg instrukcji i zależności między fragmentami kodu. Usunięcie wcięć i łamań linii zwykle pogarsza możliwość szybkiego skanowania kodu.
Pozostałe zasady są typowymi praktykami zwiększającymi czytelność:
- "Nazwy zmiennych powinny odzwierciedlać ich zadanie." Dobre nazwy zmniejszają konieczność zgadywania znaczenia danych i ograniczają liczbę komentarzy wyjaśniających oczywiste rzeczy. Skróty i nazwy przypadkowe zwiększają ryzyko błędnej interpretacji.
- "W każdej linii kodu powinna występować tylko jedna instrukcja." Taki zapis ułatwia analizę, debugowanie i pracę z systemami kontroli wersji (diff). Złożone linie z wieloma instrukcjami są trudniejsze do czytania i łatwiej w nich przeoczyć błąd.
- "Należy wprowadzać komentarze w trudniejszych częściach kodu." Komentarze mają największą wartość tam, gdzie intencja nie wynika wprost z samego kodu. Pomagają wyjaśnić "dlaczego" coś zrobiono, a nie tylko "co" robi instrukcja.
Wskazówka egzaminacyjna: gdy pytanie brzmi "która zasada nie wpłynie korzystnie", szukaj odpowiedzi, która usuwa lub osłabia elementy porządkujące kod (formatowanie, jasność intencji). W praktyce zespołowej czytelność jest zwykle wspierana przez spójny styl, narzędzia formatowania i code review.
