Jakie są zalety i wady języka używającego białych znaków vs. {} w celu wskazania zakresu? [Zamknięte]

Wygląda na to, że istnieje konflikt dotyczący tego, czy lepiej używać białych znaków lub tokenów, takich jak nawiasy, w celu wskazania zakresu. Widziałem wiele pochwał rozwiązania Pythona dla niespójnego problemu wcięcia, ale wielu się nie zgadza:

Każdy język, który ma białe znaki jako tokeny, musi umrzeć.

opublikował później tę samą odpowiedź:

Byłem swego rodzaju anty-białymi znakami, dopóki go nie wypróbowałem. Prawdopodobnie pomogło mi to, że mój osobisty układ białych znaków odpowiada prawie wszystkim tym, z czego korzysta każdy w python-land. Być może dlatego, że jestem trochę minimalistyczny, ale jeśli i tak będziesz wciskał, po co zawracać sobie głowę {}?

Widzę jasne argumenty dla każdej strony:

za pomocą białych znaków:

• pomaga zmniejszyć niespójne wcięcia w kodzie
• czyści ekran, zastępując widoczne tokeny spacją, aby spełniał ten sam cel

za pomocą tokenów:

• znacznie łatwiej wyciąć i wkleić kod na różnych poziomach (nie musisz naprawiać wcięcia)
• bardziej konsekwentny. Niektóre edytory tekstu wyświetlają białe znaki inaczej.
• obecnie bardziej popularny.

Czy brakuje mi punktów? Który wolisz? Jakieś słowa mądrości po dłuższej pracy z jednym lub drugim?

PS. Nienawidzę tego, gdy języki nie używają tego samego tokena dla każdej struktury kontroli. VB jest naprawdę denerwujący swoimi End Ifi End Whileoświadczeniami, większość innych języków po prostu używa {} do wszystkiego. Ale może to temat na inne pytanie ...

Myślę, że wielu z nas programistów (łącznie ze mną) ma tendencję do „logizacji” każdej decyzji. W porządku, ale nie każde pytanie ma logiczną odpowiedź. Na przykład wątpię, aby szefowie kuchni zadawali pytania na temat przepełnienia szefa kuchni (jeśli coś takiego istnieje), prosząc o wady i zalety szarlotki vs. To pytanie, które lubisz bardziej.

Mając to na uwadze, myślę, że najprostszą odpowiedzią jest powiedzenie „Niektórzy lubią aparaty ortodontyczne, niektórzy lubią spacje” i zostawmy to w tym miejscu.

Ryzykując, że zabrzmi jak kompletny fanboy, myślę, że każdy, kto twierdzi, że białe znaki „pomagają zmniejszyć niespójne wcięcia w kodzie”, nigdy nie używał programu Visual Studio. Za pomocą jednego polecenia (myślę, że domyślnym skrótem jest Ctrl + K, D), wszystkie wcięcia są natychmiast spójne¹. Co więcej, podczas wklejania kodu wcięcie jest natychmiast korygowane bez konieczności robienia czegokolwiek, i to samo dotyczy pisania nowego kodu lub zawijania czegoś w podobnym lub podobnym miejscu, co sprawia, że ​​bardzo trudno jest przypadkowo pomyśleć, że instrukcja jest nadal pod kiedy nie jest.if lub innym bloku (ponowne formatowanie zachodzi podczas }pisania). Ponadto naciśnięcie klawisza Enter po zakończeniu instrukcji zawsze ustawia kursor na poprawnym poziomie wcięcia dla następnej instrukcji, nawet jeśli poprzednia instrukcja była wcięta dalej z powoduifif

Punkt staram się zrobić to nie , że Visual Studio jest wielki. Chodzi mi o to, że IDE może zautomatyzować naprawianie wcięć (i inne problemy z formatowaniem), ale tylko wtedy, gdy znaczenie programu nie zależy od jego formatowania. Daje to programiście większą możliwość skupienia się na rzeczywistym zadaniu programistycznym. Składnia taka jak Pythona przynosi efekt przeciwny do zamierzonego: nie można napisać IDE, które może „naprawić” wcięcie kodu Pythona, ponieważ samo wcięcie określa niektóre semantyki.

¹ _{(Wiem, że istnieje szczególny przypadek, w którym VS odmawia sformatowania, a mianowicie literałów tablicowych obejmujących wiele wierszy, ale to nie ma znaczenia.)}

Osobiście uważam, że potrzebuję wprowadzić pustą linię, wprowadzając token na jej własnej linii, aby uświadomić sobie, że kod ma inny zakres.

Nienawidzę, gdy w Pythonie ludzie przechodzą:

if something
    do something
    do somethingelse

    cleanup
else
    do the other thing

będąc na terenie symbolicznym, nienawidzę, gdy ludzie kopiują i wklejają i nie usuwają wcięć ,

if something
{
I have been too lazy
      {
            to clean up
            }
what I pasted
}

lub nie używaj oddzielnej linii dla tokena .

if something {
    I find this confusing
}
else {
especially when combined with the previous 
do something
}

Mogę przeczytać wszystkie trzy, ale nie są takie, jak się spodziewam, i muszę poświęcić wysiłek, aby je przeanalizować, a jak mówi Joel, gdy rzeczy nie działają tak, jak się spodziewasz, to powoduje, że jesteś sfrustrowany.

Pro: O ile wiem, w świecie Pythona nie ma świętych wojen z wcięciami / nawiasami klamrowymi. Podjęcie tej decyzji w imieniu programistów prawdopodobnie zaoszczędziło trochę bólu.

Con: Funkcje anonimowe są ograniczone do jednej linii. Brzmi dobrze, ale często zdarza mi się pisać lambdaw Scheme wieloliniowe (głównie po to, by nakarmić maplub applydokładnie w jednym miejscu, więc nie ma sensu deklarować osobno).

{} dodaje redundancję. Zbyt dużo redundancji jest złe, zbyt mało jest złe. Ręczne wprowadzanie go jest złe, szczególnie. jeśli trudno go użyć.

Tak więc w czasach złego / braku IDE styl białych znaków może być nieco lepszy. Ale dzięki potężnemu IDE nawiasy klamrowe są lepsze.

Problem, który znalazłem w języku białych znaków, dotyczył wielostronicowych wyrażeń warunkowych. Dodanie wiersza na środku drugiej strony i wysunięcie się o jedną spację w środku całego bałaganu może drastycznie zmienić logikę kodu. I nawet jeśli czyjś kod jest „poprawny”, próba odczytania go jest straszną grą w zgadywanie. Po co „jeśli” to „jeszcze”? Mogę liczyć nawiasy klamrowe znacznie łatwiej niż niewidzialne puste znaki. A maszyny publikujące na tej stronie rozbijają je w jedno miejsce.

IMHO "{{{{{" is more reliable than "     ".

Nie sądzę, że to naprawdę kontra .
Pyterzy często krytykują programistów nawiasów klamrowych, jakby z łatwością naruszali wcięcia, ponieważ mogą.
W rzeczywistości zawsze korzystałem ze 100% spójnego wcięcia, nawet zanim poznałem Python i jego zasięg.

Faktem jest, że języki nawiasów klamrowych mogą również narzucać poprawne wcięcia w kompilatorze i mielibyśmy to, co najlepsze z obu światów. Widzieć? nie kontra w ogóle.

Pytoniści twierdzą, że nawiasy klamrowe są bezużyteczne, gdy wcięcie jest częścią składni, ale nie są, nawiasy klamrowe poprawiają czytelność. Próbowałem programować Python i jest to dla mnie bardzo interesujący język, ale czy próbowałeś mieć if-elifłańcuchy o więcej niż 2 lub 3 poziomach wcięcia? nie wyglądają już tak schludnie.

PS: Pisałem nawiasy klamrowe, ale w bardziej ogólny sposób mam na myśli tokeny separatora. Nawias otwierający można uznać za zbędny, ale język może wyglądać tak (w rzeczywistości jestem pewien, że istnieją takie języki, ale nie znam ich dobrze):

if condition:
    statement
    other_statement()
end

PS2: 2019, 4 lata po tej odpowiedzi. Nauczyłem się Pythona i całkowicie przyzwyczaiłem się do jego semantycznego wcięcia i wcale nie jest mi trudno go czytać. Zwłaszcza przy pomocy nowoczesnych IDE, które rysują pionowe kreski, aby pomóc w identyfikacji bloków wcięć.