Pytanie Błąd JSLint: Przenieś wszystkie deklaracje "var" na górę funkcji


Strona JSLint zaktualizowana i nie mogę już sprawdzać skryptów JS. Dla mnie to ostrzeżenie nie jest krytyczne i nie chcę przejść przez tysiące linii, aby to naprawić, chcę znaleźć więcej krytycznych problemów.

Czy ktoś wie, jak wyłączyć ten błąd lub użyć starszej wersji JSLint?

AKTUALIZACJA

Przykład:

function doSomethingWithNodes(nodes){
  this.doSomething();

  for (var i = 0; i < nodes.length; ++i){
    this.doSomethingElse(nodes[i]);
  }

  doSomething(); // want to find this problem
}

Wyjście jslint.com:

Error:
Problem at line 4 character 8: Move all 'var' declarations to the top of the function.

for (var i = 0; i < nodes.length; ++i){

Problem at line 4 character 8: Stopping, unable to continue. (44% scanned).

Problem:

Posiadanie zmiennych na górze funkcji jest nowym wymogiem. Nie mogę użyć JSLINT do testowania kodu, ponieważ zatrzymuje skanowanie skryptu na tym błędzie.

Mam dużo kodu i nie chcę zagrażać temu ostrzeżeniu jako krytycznemu błędowi.

UPDATE 8/22/2011: znaleziono http://jshint.com, wygląda znacznie lepiej niż http://jslint.com/


76
2018-01-10 11:45


pochodzenie


Czy możesz sklasyfikować swoje pytanie. Czy w rzeczywistości pytasz o dwa pytania? - James Wiseman
Czy nadal się zatrzymuje po pierwszym błędzie, jeśli zostanie odznaczony Stop on first error? - david
@david Dla mnie, tak. - Paul Beusterien
ta strona zrobi lepszą pracę -> glat.info/jscheck - vsync
JSHint to dobry wybór. - Ben Roberts


Odpowiedzi:


Aktualizacja czerwiec 2017 r .: Z zastrzeżeniem obsługi (np. Jeśli nie używasz JavaScript w Internet Explorerze 10 lub niższym), powinieneś sprawdzić, jak używać pozwolić zamiast var.

Na przykład: for(let i=0; ...; i++)


Nie ma mowy, abym postawił var i; od for(var i=0; ...; i++) na szczycie moich funkcji. Zwłaszcza gdy Specyfikacja JavaScript ma to jako dopuszczalną składnię w for sekcja (12.6). Również jest to składnia Brendan Eich używa w swoich przykładach.

Ideą przeniesienia deklaracji na szczyt jest to, że ma ona dokładniej odzwierciedlać to, co dzieje się pod maską, jednak czyniąc to tylko odzwierciedli, a nie wpłynie.

Dla mnie jest to absurdalne oczekiwanie for iteracje. Tym bardziej, że JSLint przestaje przetwarzać, gdy go wykryje.

To, czy zmienne zadeklarowane u góry funkcji są bardziej czytelne, jest dyskusyjne. Ja osobiście wolę deklarować zmienne iteratora, gdy są używane. Nie obchodzi mnie, czy zmienna jest już wewnętrznie utworzona, ja ją tutaj inicjuję, więc jestem bezpieczny.

Twierdzę, że deklarowanie zmiennej iteracyjnej, w której są używane, zapewnia, że ​​nie są one przypadkowo globalne (jeśli przeniesiesz pętlę do innej funkcji, zmienna iteratora przesuwa się wraz z nią). Jest to o wiele łatwiejsze do utrzymania niż konieczność przechowywania deklaracji zmiennych u góry funkcji.

Na razie używam http://www.javascriptlint.com/online_lint.php ponieważ wydaje się skupiać na ważnych rzeczach.


149
2018-06-20 13:12



Sprawdź także JSHint, który został utworzony częściowo w odpowiedzi na rzeczy w JSLint w ten sposób. Zobacz tę dyskusję: stackoverflow.com/questions/6803305/... - Ben Roberts
Dzięki za wskazanie javascriptlint.com/online_lint.php. Używałem JSLinta, ale trudno jest przebrnąć przez całą bezsensowną bzdurę dotyczącą błędów, które nie są nawet błędami w JSLint.
Nie zgadzam się z tobą, ale ważne jest, aby zaznaczyć, że javascript ma tylko zakres funkcji. Nie ma zasięgu bloku w pętli for. Dlatego nawet jeśli zmienna i jest zdefiniowany w for(var i=0; i<10; i+=1) będzie dostępny dla całej funkcji i zostanie podniesiony do góry przy inicjalizacji. JSLint jest poprawny pod względem składni, ale w tym przypadku przez konwencję nikt nie koduje w ten sposób. - mastaBlasta
NVM, masz całkowitą rację. Próbowałem sprawdzić, co by się stało, gdybyś miał dwie pętle w funkcji for(var i=0; i<5; i+=1), jeśli kompilator rzuciłby a variable already defined ostrzeżenie, ale tak się nie stało! Nawet w trybie ścisłym ponowne zadeklarowanie zmiennej nie spowodowało ostrzeżeń ani błędów. Więc tak, JSLint się myli. - mastaBlasta
@Zon: lub po prostu użyj i znowu jak każdy rozsądny deweloper. Nie ma znaczenia, gdzie deklarujesz var i, ponowne użycie jest dozwolone niezależnie. - Lee Kowalkowski


Kompilator Google Closure faktycznie nie potrafi poprawnie wykryć typu zmiennej pętli dla pętli for ... in, chyba że jest zadeklarowany jak dla (var i in ...) i żadna adnotacja nie rozwiązuje tego problemu, więc deklaracja nie może zostać przeniesiona na szczyt.


7
2018-06-30 15:18



Naprawdę?! Szkoda, ale naprawdę przydatne do dzielenia się, +1. - Lee Kowalkowski
@jjrv masz przykład kodu, który nie działa z kompilatorem zamknięcia? Używam go i nie widziałem żadnych problemów. - JavaKungFu
@JavaKungFu objawem było to, że kompilator zgłasza mniej niż 100% wpisanego kodu i wyświetla ostrzeżenie, jeśli ustawiono reportUnknownTypes = CheckLevel.WARNING w CompilerOptions.java. - jjrv
No dobra, źle zrozumiałem twoją odpowiedź, myślałem, że to faktycznie spowodowało problem w skompilowanym kodzie. Dzięki. - JavaKungFu


Możesz pobrać starsze wersje w dowolnym momencie lub zmodyfikować Ostatnia wersja. To nie jest takie trudne, naprawdę (wyszukaj move_var). Następnie uruchom lokalnie jslint, używając węzła lub używając przeglądarki z prostym formularzem HTML - możesz chcieć skopiować oryginał Crockforda.

Zauważ, że ostrzeżenie zostało wprowadzone jako część a Major Przepisuji występuje tylko po for(, więc wiadomość jest trochę myląca.


5
2018-02-01 23:11





Zwróć uwagę, że przenieś wszystkie vary na szczyt różni się od "zezwalaj na jedną instrukcję var na funkcję". Wymóg przeniesienia wszystkich zmiennych na górę jest nowy i wydaje się, że nie ma przełącznika. Więcej w http://groups.google.com/group/jsmentors/browse_thread/thread/5e90c25230f8e22/70e1a95a20fb829e


4
2018-02-01 21:46





Miałem ten problem w mojej bazie kodu, kiedy chcieliśmy przejść na najnowszą wersję JSLINT. Mieliśmy ich dużo i ludzie nie byli zadowoleni z przeniesienia deklaracji. W rzeczywistości najbardziej eleganckim rozwiązaniem było użycie underscore.js i zamiast pełnej pętli pełnej, używaliśmy funkcji _.each (), która usunęła błąd JSLint i uczyniła nasz kod bardziej funkcjonalnym, czystszym, mocniejszym i łatwiejszym do czytać.


3
2017-08-29 10:22



Używam lodash, ale świetny punkt. - Shanimal


Nawet jeśli Nowy beta JSLint nie dokumentuje dyrektywy komentarza dla wielu var tolerancja w funkcji, to robi wydaje się wspierać dyrektywy z pierwotnej wersji.

Oryginalny JSLint pozwolił ci to zrobić:

/*jslint vars: true */

Z mojego doświadczenia wynika, że ​​nadal działa - przypuszczam, że jest kompatybilna wstecz. Czas tego pisania to czerwiec 2015.


1
2018-06-09 23:02





Zauważyłem, że poniższa składnia spowoduje usunięcie błędu:

function doSomethingWithNodes(nodes) {
    this.doSomething();
    var i; // HERE is where you move the 'var' to the top of the function
    for (i = 0; i < nodes.length; ++i) {
        this.doSomethingElse(nodes[i]);
    }

    doSomething(); // want to find this problem
}

0
2018-04-29 03:15