Dollar Sign Blues: JavaScript i PHP

Dorastałem, programując w C ++ i Javie, gdzie wszystko było bezpieczne i piękne. Kompilatorzy upewnili się, że będę na bieżąco, jeśli kiedykolwiek zbłądzę. Oczywiście wszyscy robili trochę Perla na studiach, ale nie wdychałem. W dzisiejszych czasach dzieci skupiają się na PHP na backendie i Javascript na froncie. Starając się być modnym, robię to samo (w przypadku tworzenia stron internetowych). Problem, na który wciąż wpadam, polega na tym, że przypadkowo dodaję znak dolara ($) przed zwykłymi zmiennymi w Javascripcie i oczywiście nikt nic nie mówi, ponieważ taka składnia jest często stosowana w przypadku obiektów jQuery.

Czy są jakieś narzędzia do debugowania lub sztuczki deweloperów, które pozwalają złapać zamieszanie związane ze znakiem dolara? Czy często popełniasz ten sam błąd i jak sobie z nim radzisz emocjonalnie? Narzędzia deweloperskie Chrome nie zawsze widzą, że to błąd JavaScript. Używam PhpStorm i Emacsa do rozwoju, ale te nie łapią mojej głupoty, chociaż podejrzewam, że Emacs tak robi, ale postanawia nie mówić mi o tym z przekleństwem.

Jeśli uważasz, że to pytanie jest śmieszne, myślę, że masz rację. Ale żyjemy w świecie, w którym zmienna ma przed sobą znak dolara. W takim świecie nic nie jest śmieszne.

Nie ma nic złego w używaniu $zmiennych. Nie zrobiłbym tego celowo dla każdej zmiennej, ale nadal jest to poprawna składnia. jQuery jest jednym z przykładów, w których $jest używany jako nazwa zmiennej. Dlatego też „Narzędzia programistyczne Chrome nie zawsze widzą, że to błąd JavaScript” , ponieważ w ogóle nie ma błędu.

Jeśli boisz się pisać kod, taki jak:

var demo = function demo() {
    var a = 123;
    ...
    $a = 456; // A new variable is created in global scope.
}

musisz użyć sprawdzania stylu, takiego jak jsLint , jsHint lub Google Closure Linter . Który z nich? Wybór należy do ciebie. Aby ci w tym pomóc, oto kilka uwag:

Styl

Google Closure Linter postępuje zgodnie z przewodnikiem po stylu Google JavaScript , który jest sprytnie wykonany. Użycie dobrze znanego stylu dla JavaScript lub jednego z sześciu innych języków jest dobrym pomysłem: kiedy udostępniasz swój kod lub zatrudniasz nowego programistę, są szanse, że znają już ten styl.

Wielu programistów zna również styl Douglasa Crockforda. Ten styl został szczegółowo wyjaśniony w JavaScript: The Good Parts , książka, którą warto kupić każdy, kto pracuje z JavaScript.

Jeśli chodzi o jsHint, nie mogę tak naprawdę ustalić, jakie konwencje są stosowane, a sama witryna wydaje się unikać rozmów na ten temat. Może coś mi umknęło.

Wsparcie ze strony IDE

Zarówno jsLint, jak i jsHint są obsługiwane przez PhpStorm. Tak też jest Google Closure Linter.

Środowisko

Google Closure Linter jest jednym z szeregu narzędzi . Jeśli już korzystasz z kompilatora Google Closure lub Google Closure Library , lepiej byłoby wybrać Closure Linter niż inne narzędzia.

Ścisłość

jsLint jest znany jako ścisły. jsHint jest bardziej liberalny, co nie zawsze jest dobrą rzeczą. Na przykład jeden z powodów rozwidlenia jsLint dla jsHint wyjaśniono w artykule, który pokazuje zły kod, który spowoduje błąd w jsLint, ale nie w jsHint:

/*global jQuery */

// Example taken from jQuery 1.4.2 source
jQuery.extend({
    /* ... */

    isEmptyObject: function( obj ) {
        for ( var name in obj ) {
            return false;
        }
        return true;
    }

    /* ... */
});

Kod jest zły, ponieważ wygląda na to, że JavaScript ma zakres blokowy, a nie ma. Zobacz JavaScript: The Good Parts, str. 102, załącznik A: Okropne części, zakres. Innymi słowy, oczekujemy, patrząc na kod bez znajomości językaname się, nie widoczni poza pętlą, dopóki będzie on widoczny.

Jeśli chodzi o Google Closure Linter, uważam, że jest gdzieś pośrodku między jsLint i jsHint, ale nie mam wystarczających informacji, aby to obsłużyć.

Wniosek

Unikałbym jsHint: jest zbyt liberalny, co oznacza, że ​​nie znalazłby potencjalnych błędów wykrytych przez inne kłaczki. Używany przewodnik po stylu jest trudny do znalezienia.

Wśród jsLint i Google Closure Linter wybór nie jest oczywisty. Oba są napisane przez ekspertów, obaj przestrzegają ścisłego, dobrze opisanego przewodnika po stylu, którego przestrzegają już tysiące programistów. Używaj obu przez jakiś czas, a następnie wybierz taki, który jest dla Ciebie bardziej praktyczny.