Dlaczego język powinien preferować wcięcia zamiast wyraźnych znaczników bloków?

Uczę się Haskell i szukałem narzędzia do automatycznego wcięcia. Nie wyglądałem dużo i nauczyłem się, że w Haskell (jak w Pythonie) wcięcie oznacza blok. W rezultacie zgaduję, że niemożliwe jest stworzenie narzędzia do automatycznego formatowania, tak silnego jak w innych językach z rodziny C, które używają wyraźnych znaczników, takich jak {} (nawiasy klamrowe) lub begin endsłowa kluczowe.

Nie przeszkadza mi język wymuszający wcięcie ze względu na czytelność, ale nie rozumiem korzyści wynikających zarówno z wymuszania wcięcia, jak i posiadania wyraźnego znacznika, aby zautomatyzowane narzędzia mogły zrozumieć, co należy do którego bloku.

Jeśli preferowane jest wcięcie oznaczające blok, aby kod wyglądał lepiej, to nadal nie rozumiem korzyści. Biorąc pod uwagę, że tabulatory i spacje są różnie reprezentowane w różnych edytorach i różnych czcionkach (na przykład czcionki mono-spacje wyglądają na bardziej uporządkowane), nie można oczekiwać, że programiści zaprezentują kod poprawnie. Narzędzie, które może uwzględnić bieżący edytor tekstu, byłoby bardziej odpowiednie do prawidłowego sformatowania kodu.

Dlaczego projektant języka miałby wybierać wcięcia zamiast wyraźnych znaczników bloków?

Guido Von Rossum

Z wywiadu z Guido Van Rossumem , który można zobaczyć w pełnym tekście na books.google.com (moje wyróżnienie ):

Wybór wcięcia dla grupowania nie był nową koncepcją w Pythonie; Odziedziczyłem to po ABC , ale zdarzało się to również w starszym języku occam. Nie wiem, czy autorzy ABC wpadli na pomysł od czasu do czasu, czy wymyślili go niezależnie, czy też był wspólny przodek. Oczywiście mogłem zdecydować się nie podążać za wskazówkami ABC, tak jak robiłem to w innych obszarach (np. ABC używał wielkich liter w słowach kluczowych i nazwach procedur, pomysł, którego nie kopiowałem), ale polubiłem tę funkcję dość nieco podczas korzystania z ABC, ponieważ wydawało się, że eliminuje on pewien rodzaj bezcelowej debaty powszechnej w tym czasie wśród użytkowników C, na temat tego, gdzie umieścić nawiasy klamrowe .

Von Rossum był mocno zainspirowany ABC i chociaż nie musiał kopiować wszystkiego, użycie wcięcia zostało zachowane, ponieważ może być korzystne w unikaniu wojen religijnych.

Byłem również świadomy, że czytelny kod i tak używa dobrowolnego wcięcia w celu wskazania grupowania, i natknąłem się na subtelne błędy w kodzie, w których wcięcie nie zgadzało się z grupowaniem składniowym za pomocą nawiasów klamrowych - programista i recenzenci przyjęli, że wcięcie pasuje do grupowania i dlatego nie zauważyłem błędu. Ponownie długa sesja debugowania udzieliła cennej lekcji.

Rossum był także świadkiem błędów spowodowanych niespójnością między grupowaniem a wcięciem i najwyraźniej poleganie na wcięciach jedynie w strukturze kodu byłoby bezpieczniejsze od błędów programowych ¹ .

Donald E. Knuth i Peter J. Landin

W cytowanym wywiadzie Guido wspomina pomysł Dona Knutha na użycie wcięcia. Jest to szczegółowo opisane w cytacie „Knuth Indentation Quote” , który cytuje programowanie strukturalne za pomocą instrukcji goto . Knuth odwołuje się także do następnych 700 języków programowania Petera Johna Landina (patrz sekcja Dyskusje na temat wcięć). Landin zaprojektował ISWIM, który wygląda jak pierwszy język z wcięciami zamiast bloków początkowych / końcowych. W tych dokumentach chodzi raczej o możliwość zastosowania wcięcia w programach do strukturyzacji, a nie o faktyczne argumenty przemawiające za tym.

_{1. Myślę, że jest to w rzeczywistości argument przemawiający za posiadaniem zarówno konstrukcji grupujących, jak i automatycznego formatowania, w celu wychwytywania i odzyskiwania po błędach programistycznych, które muszą się zdarzyć. Jeśli zepsujesz wcięcie w Pythonie, osoba debugująca Twój kod będzie musiała zgadnąć, co jest poprawne:}

if (test(x)):
  foo(x)
  bar(x)

_{Czy barzawsze zadzwonię, czy tylko wtedy, gdy test się powiedzie?}

_{Konstrukcje grupujące dodają poziom redundancji, który pomaga wykryć błąd podczas automatycznego wcięcia kodu. W języku C równoważny kod może być automatycznie wcięty w następujący sposób:}

if (test(x))
  foo(x);
bar(x);

_{Jeśli chciałem barbyć na tym samym poziomie co foo, to automatyczne wcięcie oparte na strukturze kodu pozwala mi zobaczyć, że istnieje coś złego, co można naprawić, dodając nawiasy klamrowe wokół fooi bar.}

_{W Python: Myths about Indentation istnieje podobno zły przykład z C:}

/*  Warning:  bogus C code!  */

if (some condition)
        if (another condition)
                do_something(fancy);
else
        this_sucks(badluck);

_{Tak samo jak powyżej, w Emacsie podświetlam cały blok / funkcję, naciskam Tab, a następnie cały kod jest ponownie dodawany. Rozbieżność między ludzkimi wcięciami a strukturą kodu mówi mi, że coś jest nie tak (to i poprzedni komentarz!).}

_{Poza tym, kod pośredni, w którym wcięcie jest wyłączone w C, po prostu nie przechodzi przez gałąź master, wszystkie sprawdzenia stylu sprawiłyby, że GCC / Jenkins krzyczałby na mnie. Niedawno miałem problem podobny do opisanego powyżej w Pythonie, ze stwierdzeniem wyłączonym przez jeden poziom wcięcia. Czasami mam kod w C, który wykracza poza nawias zamykający, ale potem wciskam Tab i kod wcina się „niepoprawnie”: to kolejna szansa na zobaczenie błędu.}

Jest to bardzo subiektywne i jest przyczyną wielu wojen z płomieniami. Jednak:

Posiadanie symboli ograniczających bloki i wcięcia narusza zasadę DRY , ponieważ wyrażasz tę samą informację na dwa różne sposoby. Istnienie zautomatyzowanych narzędzi wcięcia jest symptomem naruszenia zasad DRY DRIVE: To, że możesz automatycznie wygenerować wcięcie, pokazuje, że jest to nadmiarowa informacja, a to oznacza, że ​​wcięcie i symbole mogą zsynchronizować się, co prowadzi do mylącego kodu.

Często zadawane pytania dotyczące projektowania i historii Pythona wyraźnie to stwierdzają:

Dlaczego Python używa wcięć do grupowania instrukcji?

Guido van Rossum uważa, że ​​użycie wcięcia do grupowania jest niezwykle eleganckie i ma duży wpływ na przejrzystość przeciętnego programu w języku Python. Większość ludzi uczy się pokochać tę funkcję po chwili.

Ponieważ nie ma nawiasów początkowych / końcowych, nie może być niezgodności między grupowaniem postrzeganym przez analizator składni a czytelnikiem.

Prawdą jest, że nie można utworzyć narzędzia automatycznego wcięcia dla Pythona, ale jest to dobra rzecz: oznacza to, że nie masz w składni redundancji, których potrzebujesz do automatycznego uzgadniania.

Tabulatory i spacje są uzasadnionym problemem w Pythonie i zaleca się, aby nigdy nie łączyć tabulatorów i spacji (w celu wcięcia) w tej samej bazie kodu.

Python odziedziczył znaczące wcięcie po (obecnie przestarzałym) języku poprzednika ABC. ABC jest jednym z niewielu języków programowania, które wykorzystały testy użyteczności do kierowania projektem. Tak więc, podczas gdy dyskusje na temat składni zwykle sprowadzają się do subiektywnych opinii i osobistych preferencji, wybór znacznego wcięcia ma w rzeczywistości solidniejsze podstawy.

Projektanci języków wybierają znaczące syntaktycznie białe spacje, ponieważ wierzą (lub przynajmniej sądzą, że ich potencjalni użytkownicy wierzą), że średniki i nawiasy klamrowe powodują hałas podczas czytania kodu, szkodząc produktywności. Innym częstym powodem jest to, że zły / niespójny styl kodowania szkodzi czytelności - wymuszając wspólny schemat wcięć, język ma lepszą czytelność ponad wszystko. Ten późniejszy powód jest mniej ważny, ponieważ automatyczne formatowanie IDE jest częstsze, ale nadal może mieć zastosowanie.