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

17

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 ...

Gordon Gustafson
źródło
2
Nie powiedziałbym, że jest „o wiele łatwiejsze do wycinania i wklejania”. To tylko trochę łatwiejsze.
Kugel,
1
Tak długo, jak utrzymujesz małe i uporządkowane bloki kodu, tokeny naprawdę nie powinny mieć znaczenia ... tak przy okazji, kochaj tag „Holy-War”, lol
Scott
„Niektóre edytory tekstu wyświetlają białe znaki inaczej.”: ?? „obecnie bardziej popularny”. Popularność często nie jest związana z jakością pomysłu.
Giorgio,
Uwielbiam składnię białych znaków i uwielbiałem kodować w CoffeeScript i Haskell (tak, wiem, że jest trudny). Zakodowałem wiele w JavaScript i C i po prostu nie mogę wrócić do}. Jednak najlepiej
użyć
Myślę, że trudniej jest dostrzec błędy, jeśli musisz polegać tylko na białych znakach. Na przykład: stackoverflow.com/questions/21205836/ ... Jedyną różnicą między kodem OP a odpowiedzią jest dodatkowa przestrzeń. Posiadanie} do rozgraniczenia, który kod znajduje się w pętli for, a który nie, jest o wiele wyraźniejsze.
AncientElevator9

Odpowiedzi:

15

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.

Jason Baker
źródło
6
Nawiasem mówiąc: cooking.stackexchange.com
Jon Purdy
Ponadto coś, co jest dla niektórych pro, może być dla innych oszustwem.
Larry Coleman
Doskonały punkt Osobiście uważam, że współpracują ze sobą i dopóki nie dojdzie do wyraźnego spokoju, nie będę narzekał (dużo).
Michael K
8
Nie zgadzam się z twoją analogią. Istnieją dość obiektywne powody, by sądzić, że składnia zależna od białych znaków ogranicza wydajność programisty, nawet u programistów, którzy go uwielbiają. To trochę jak powiedzenie, że ludzie po prostu nie lubią smaku cyjanku - wszyscy „logizują” się, gdy mówią, że jest trujący. Nie. Nieważne, jak bardzo to kochasz, wciąż cię zabije.
Timwi
4
PS Słowo, którego naprawdę szukasz, jest racjonalne . Ponadto wszyscy mają tendencję do racjonalizacji, nie tylko programiści.
Timwi
11

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.)

Timwi
źródło
8
Wcięcie w Pythonie nie wymaga naprawy, ponieważ nie ulega uszkodzeniu (bez zauważenia przez kogoś!). Niemożliwe jest także napisanie Purify (programu, który pomaga wykrywać wycieki pamięci) dla C #, nie oznacza to, że zarządzanie pamięcią C ++ jest lepsze.
dbkk,
2
@Dean: Dlaczego tak wielu ludzi uważa, że ​​potrzebuje Resharpera do wszystkiego? To, co opisujesz, jest już w Visual Studio bez Resharpera.
Timwi
2
@dbkk: Twoje wcięcie zostanie przerwane, gdy tylko dodasz iflinię w dowolnym miejscu. Następnie musisz ręcznie naprawić wcięcie.
Timwi
2
prawdopodobnie nie pracowałeś w zespole, w którym wcięcia były leniwe, niespójne itp., a naprawianie go było odradzane, ponieważ uniemożliwia różnice w kodzie.
Kevin
2
@Kevin: Zgadza się, nie mam i szczerze mówiąc, nie chciałbym. Nalegałbym na naprawienie tego wszystkiego za jednym razem, co powoduje tylko jedną nieczytelną różnicę, która wpływa tylko na nieznaczne białe znaki i naprawia wszystkie przyszłe różnice. Wszystko inne przyniosłoby efekt przeciwny do zamierzonego i szkodliwy dla projektu.
Timwi
3

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.

Dominique McDonnell
źródło
3

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).

Inaimathi
źródło
Wyrażenia wieloliniowe są obsługiwane w Pythonie - wystarczy umieścić \ na końcu linii.
dbkk,
8
Szczerze mówiąc, brak wielowierszowych lambd jest ograniczeniem Pythona, a nie białych znaków w ogóle. W moim języku oddzielonym spacjami, jeśli wprowadzisz lambda i pojawi się blok z wcięciem, blok zostanie użyty jako ciało lambda.
Uwaga dla siebie - wymyśl imię
@ Uwaga - Ok, tak, uczciwe. Python to jedyny język rozdzielany spacjami, z którym mam jakiekolwiek doświadczenie. @dbkk, więc mówisz, że lambda n: a = n \\na.sort() \\na[0:3] to nie zwróci błędu składniowego? Sztuczka `\ 'pozwala rozłożyć lambda jednowierszowy na wiele linii, ale nadal nie otrzymujesz więcej niż jednej rzeczywistej linii.
Inaimathi,
Haskell, CoffeeScript używają białych znaków, ale nie mają ograniczenia linii lambda w jednym wierszu.
aoeu256
3

{} 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.

użytkownik470365
źródło
1
Uważasz, że dobrze rozumiesz nadmiarowość. Zastanawiam się nad odzyskiwaniem parserów dla kompilatorów (po bardzo ciekawych próbach Clanga wydania Fix-It dla kodu) i naprawdę pomaga tutaj to, że jest nadmiarowość. Dlatego uważam, że żadna redundancja, choć świetna w idealnym świecie, nie jest w rzeczywistości szkodliwa dla programowania w świecie rzeczywistym. Kiedy zwykle zbędne źródła informacji się nie zgadzają, może się zdarzyć, że popełniono literówkę / błąd; bez redundancji ten potencjalny błąd pozostaje niewykryty! To powiedziawszy, wolę żadnych aparatów ortodontycznych;)
Matthieu M.
„Hałas” to słowo, którego Erik Meijer użył w swoich filmach Haskell.
user16764
Co się stanie, jeśli usuniesz blok i zapomnisz usunąć} lub {omyłkowo skasować, gdy robisz coś przeciwnego? Redundancja jest sprzeczna z DRY IMO.
aoeu256
2

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 "     ".
Andy Canfield
źródło
9
Jeśli używasz wielostronicowych wyrażeń warunkowych, masz inne problemy. Po prostu nie rób tego. W rzeczywistości nawet przy nawiasach klamrowych kod staje się nieczytelnym bałaganem. Jest to właściwie kolejna zaleta wcięć białych znaków: zapobiega pisaniu tak okropnego kodu.
Konrad Rudolph
1
Poważnie, warunkowe wiele stron ?
Winston Ewert,
2

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ęć.

Petruza
źródło
Podoba mi się ta składnia, ponieważ jest to dobry kompromis i pozwala uniknąć nawiasów klamrowych. Ale jest to kosztowne dla instrukcji jednowierszowych, gdzie np. W C możemy całkowicie odstawić nawiasy klamrowe :(
Jo So
zamiast zagnieżdżać, jeśli ... elif możesz spróbować użyć słowników i / lub kontynuować, wrócić, zagnieżdżone funkcje ...
aoeu256
@ aoeu256 zupełnie nie ma sensu pytanie i moja odpowiedź też.
Petruza