Czym różni się podział wierszy w Pythonie od automatycznych średników JavaScript?

JavaScript ma funkcję o nazwie Automatyczne wstawianie średnika, w której w zasadzie jeśli parser napotka niepoprawny token, a ostatni token przed nim był łamaniem linii, wówczas parser wstawi średnik tam, gdzie jest podział linii. Umożliwia to w zasadzie pisanie całego kodu javascript bez średników, ale trzeba pamiętać o niektórych przypadkach krawędzi, głównie jeśli masz słowo kluczowe return, a następnie wartość, którą chcesz zwrócić w nowym wierszu.

function test(){
    // This will return 'undefined', because return is a valid statement
    // and  "john" is a valid statement on its own.
    return 
          "john"
}

Z powodu tych błędów istnieją dziesiątki artykułów o tytułach takich jak „Automatyczne wstawianie średnika jest złe”, „Zawsze używaj średników w JavaScript” itp.

Ale w Pythonie nikt nigdy nie używa średników i ma dokładnie takie same gotchas.

def test():
    # This will return 'undefined', because return is a valid statement
    # and  "john" is a valid statement on its own.
    return 
    "john"

Działa dokładnie tak samo, a jednak nikt nie boi się śmiertelnie zachowania Pythona.

Myślę, że przypadki, w których javascript zachowuje się źle, są na tyle mało, że powinieneś być w stanie łatwo ich uniknąć. Zwrot + wartość w nowej linii? Czy ludzie naprawdę tak często robią?

Jakieś opinie? Czy używasz średników w javascript i dlaczego?

Powodem jest to, że w Pythonie znaki nowej linii są jednoznacznym sposobem oddzielania linii kodu; jest to zgodne z projektem, a sposób, w jaki to działa, został dokładnie przemyślany. W rezultacie kod Pythona jest doskonale czytelny i jednoznaczny bez żadnych specjalnych znaczników końca instrukcji (oprócz nowej linii).

Z kolei JavaScript został zaprojektowany z myślą o składni podobnej do C, w której instrukcje zawsze kończą się średnikiem. Aby uczynić język bardziej odpornym na błędy, próbuje zgadnąć, gdzie powinny znaleźć się dodatkowe średniki, aby poprawić kod. Ponieważ zostało to w pewnym sensie dostosowane do składni podobnej do C, nie zawsze działa zgodnie z oczekiwaniami (czasami interpreter skryptu zgaduje źle) i może stworzyć dość sprzeczny z intuicją kod. \

Lub argumentowanie w kategoriach „jawne jest lepsze niż niejawne”: w Pythonie nowa linia jest już całkowicie jawna, podczas gdy w JavaScript jest niejednoznaczna, więc dodajesz średnik, aby była wyraźna.

Sądzę, że jest dość zasadnicza różnica w sposobie działania w Pythonie. Cytując z posta Einara Egilssona powiązanego z: „średnik nie jest sugerowany na końcu linii, jeśli pierwszy token kolejnej linii może zostać przeanalizowany jako część tej samej instrukcji”.

W Pythonie podział wiersza zawsze kończy instrukcję, z wyjątkiem pewnych dość oczywistych przypadków, takich jak wyrażenie w nawiasach okrągłych. Z drugiej strony, JavaScript spróbuje parsować jak najwięcej wierszy, jak to możliwe, przed zakończeniem instrukcji, potencjalnie prowadząc do takich rzeczy:

// Define a function and name it area.
area = function(r) {
    return r * r * 3.14159
}

// Fooled you! We're actually invoking it.
(14)

Często minimalizuję moje pliki JS w trybie produkcyjnym. Oznacza, usuwanie komentarzy i podziałów wierszy.

Bez użycia średników spowodowałoby to uszkodzenie mojego Javascript.

To nie działa tak jak opisano.

JavaScript ma funkcję o nazwie Automatyczne wstawianie średnika, w której w zasadzie jeśli parser napotka niepoprawny token, a ostatni token przed nim był łamaniem linii, wówczas parser wstawi średnik tam, gdzie jest podział linii.

To jest źle. Przykład:

return
  1 + 2;

1jest całkowicie poprawnym tokenem, ale parser nadal wstawi średnik bezpośrednio po nim return.

Jak widzisz, nawet nie możesz dokładnie powiedzieć, gdzie nastąpi średnik.

Problem z automatycznym wstawianiem jest dwojaki:

• Po pierwsze, ludzie mogą pominąć średnik, w którym automatyczne wstawianie nie może określić, czy należy wstawić.
• Również średnik może zostać wstawiony tam, gdzie nie jest przeznaczony, jak wyżej.

Oczywiście użycie średnika po każdej instrukcji pomaga tylko przy pierwszym źródle błędów.

W każdym razie, jak się już domyślacie, uważam, że automatyczne wstawianie średnika w składni podobnej do C jest złym pomysłem.

Podam jeden prosty powód:

JavaScript wygląda na „trochę java-ish” lub „trochę c-ish”. Oczywiście jest to język dynamiczny, więc wygląda inaczej ... ale spójrz prawdzie w oczy - są aparaty ortodontyczne. Języki z nawiasami klamrowymi zwykle mają średniki. Naturalne refleksy uruchamiają się i sprawiają, że palec uderza w klawisz średnika, zanim uderzysz Enter.

Przeciwnie, Python nawet na pierwszy rzut oka wygląda zupełnie inaczej. W związku z tym intuicyjnie tworzy się niewielka lub żadna analogia do „standardowych nudnych języków”, a kiedy wchodzi się w „tryb python”, brak średników staje się naturalny.

Istnieje wiele dobrych powodów, aby nie używać wstawiania średników w JavaScript.

Przede wszystkim dlatego, że wstawienie średnika zgodnie z definicją w standardzie ECMAScript jest w niektórych przypadkach nieintuicyjne. @Svante wskazuje przypadek, w returnktórym użycie nowej linii spowoduje problemy.

Co mu się nie wspomina, że będzie to powodować problemy, jeśli jesteś przy użyciu średników jako dobrze, ponieważ wstawiania średnik dzieje, czy chcesz, czy nie.

Innym bardzo dobrym powodem, aby nie używać wstawiania średnika, jest kontrola wyjściowa. W wielu przypadkach JavaScript jest uruchamiany przez minifikator, zanim zostanie użyty w produkcji. Niektóre minizery potrafią obsłużyć automatyczne wstawianie średników, ale nie widzę powodu, aby polegać na tym, że działa idealnie

Dodatkowo w systemach zarządzania treścią wbudowany JavaScript może być automatycznie minimalizowany, a widziałem wiele przypadków, w których automatyczny minimalizator po prostu usuwa komentarze i przycina białe znaki (w tym znaki nowego wiersza) na początku i na końcu każdej linii.

Dla autorów, którzy nie mają wyboru, jakie narzędzia są wybierane, o wiele łatwiej jest po prostu trzymać się formatu, który działa w zdecydowanej większości przypadków.

Nieużywanie średnika jest przepisem na niepowodzenie przy minimalizacji plików JavaScript. Dlatego się boję.

W Javascripcie możesz napisać program, który byłby poprawny pod względem składniowym przy braku automatycznego wstawiania średnika, a ASI przekształci ten program w inny program poprawny pod względem składniowym (na przykład przekształca kod, który zwraca wartość na kod, który nic nie zwraca). W Pythonie nie ma analogicznego przypadku. W Pythonie każdy znak nowej linii, który może zakończyć instrukcję , zakończy instrukcję, chyba że zostanie poprzedzony znakiem odwrotnego ukośnika. Technicznie przypuszczam, że reguły Javascript są równie deterministyczne, ale nie wiem, czy można streścić reguły Javascript dotyczące kończących instrukcji w jednym zdaniu.

W większości przypadków ASI JavaScript obsługuje rzeczy zgodnie z oczekiwaniami. Jednym z przykładów ASI może nie zachowujących się w oczekiwany sposób:

var i = 0

(function() {
   // do something
})()

Będzie to interpretowane jako wywołanie funkcji 0za pomocą funkcji anonimowej, a następnie wykonanie wyniku. W takim przypadku prawdopodobnie chciałeś wykonać zadanie, a następnie natychmiast wykonać funkcję anonimową.

Dla kogoś, kto nie zna ASI, może to być bardzo mylące, gdy napotkasz takie problemy, dlatego zawsze zalecam programistom w moim zespole stosowanie średników.

(Nawiasem mówiąc: nie używam średników podczas pracy nad projektami osobistymi / pobocznymi, ponieważ wiem, że nikt inny nie musiałby utrzymywać kodu).

Podobnie jak ty, myślę, że to trochę paranoiczne. Zasady wstawiania średników są dobrze zdefiniowane w JavaScript, podobnie jak w Pythonie i CoffeeScript. Nikt nie śmieszy Python ani CoffeeScript średnikami, więc dlaczego JavaScript jest traktowany inaczej?

Myślę, że to nadmierna reakcja na nieszczęsny stan typowego kodu JavaScript sprzed około dziesięciu lat - JavaScript był postrzegany jako słaby, błędny, brzydki, nie-dobry język. To było zawstydzenie. Nie można napisać dobrego kodu w JavaScript!

Następnie ludzie przyszedł i próbował udowodnić, że mógłby napisać piękny, jasny kod w JavaScripcie. Reguła „ zawsze używaj średników” była częścią tej fali. I szczerze mówiąc, może to uczynić kilka sytuacji nieco jaśniejszymi.

Dlaczego JavaScript jest nadal traktowany inaczej?

Jest bezwładność. I nie należy zapominać, że ludzie, którzy cenią sobie wyraźnie skonstruowany kod, często wolą języki w stylu C. Ludzie, którzy doceniają niejawnie ustrukturyzowany kod, często przechodzą na języki inne niż C (jak CoffeeScript).

Używam ich w JavaScript wyłącznie dla zachowania spójności. Jeśli większość linii ma

Python ma je dla przypadków skrajnych, takich jak wiele instrukcji w jednym wierszu, javascript ma je, a ponieważ znajdziesz je regularnie używane, jestem zgodny z normą, w której są używane.

Nie mogę znaleźć zastosowania dla wielu instrukcji w tym samym wierszu i dlatego nie przewiduję używania średników.

Jeśli użyjesz czegoś takiego jak bundle-fu i menedżer zasobów dla swojej aplikacji sieciowej w szynach, to okropnie się zepsuje, jeśli nie napotka średnika na końcu tokena w javascript. Dobrym zwyczajem jest więc postawienie takiego.

Nie pamiętam, która dokładnie wersja IE, ale w niektórych przypadkach IE dosłownie popełni błąd, jeśli brakuje średnika. IIRC ma miejsce, gdy masz w zasięgu globalnym coś takiego:

var myFunc = function() {
  ...
}

Jeśli nie dodasz; po nawiasie zamykającym program faktycznie zawiedzie w niektórych wersjach IE. To, wraz z innymi powodami (w tym zaleceniem Crockforda, aby zawsze używać ich jawnie), skłoniło mnie do tego, aby zawsze używać ich wyraźnie w każdym przypadku.