Блюз знаків долара: Javascript та PHP

Я виріс програмувати C ++ та Java, де все було безпечно і красиво. Компілятори переконалися, що я перевіряю, чи коли-небудь я відхилився. Звичайно, всі трохи поправили Perl у коледжі, але я не вдихнув. Діти в ці дні - це PHP на бекенді та Javascript на передній панелі. Намагаючись бути хіп, я роблю те саме (для веб-розробки). Проблема, з якою я постійно стикаюся, полягає в тому, що я випадково додаю знак долара ($) перед звичайними змінними в Javascript, і, звичайно, ніхто нічого не каже, тому що це юридичний синтаксис, який часто використовується для об’єктів jQuery.

Чи є які-небудь інструменти налагодження чи фокуси розробників, щоб уникнути плутанини цього знака долара? Чи часто ви робите одну і ту ж помилку, і як ви з цим емоційно справляєтеся? Інструменти для розробників Chrome не завжди бачать, що це помилка Javascript. Я використовую PhpStorm та Emacs для розробки, але вони не вловлюють моєї дурості, хоча я підозрюю, що Emacs робить, але вирішує не говорити мені про це не зважаючи на це.

Якщо ви вважаєте це питання смішним, я думаю, ви праві. Але ми живемо у світі, де змінна має знак долара перед собою. У такому світі нічого смішного немає.

У використанні $змінних немає нічого поганого . Я б не робив це спеціально для кожної змінної, але це все-таки дійсний синтаксис. jQuery - один із прикладів, коли $використовується як ім'я змінної. Ось чому "Інструменти для розробників Chrome не завжди бачать, що це помилка Javascript" , оскільки помилки в першу чергу немає.

Якщо ви боїтеся писати код на зразок:

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

то вам доведеться використовувати перевірку стилів, наприклад jsLint , jsHint або Google Closing Linter . Який із них? Ви самі вирішите зробити вибір. Щоб допомогти вам у цьому, ось кілька приміток:

Стиль

Google закриття Linter слідує посібнику стилів Google JavaScript , який, як відомо, зроблено спритно. Використовувати відомий стиль для JavaScript або будь-яку з шести інших мов - це гарна ідея: коли ви ділитесь кодом або наймаєте нового розробника, швидше за все, вони вже знайомі з цим стилем.

Багато розробників також знайомі зі стилем Дугласа Крокфорда. Цей стиль детально пояснюється в JavaScript: "Гарні частини" - книгу, яку варто придбати всім, хто працює з JavaScript.

Що стосується jsHint, я не можу реально знайти, які конвенції використовуються, а сам веб-сайт, схоже, уникає розмов про цю тему. Можливо, я щось пропустив.

Підтримка IDE

Обидва JSLint і jsHint підтримуються на PhpStorm. Це також стосується закриття Google Linter.

Середовище

Лінія закриття Google - один із ряду інструментів . Якщо ви вже використовуєте компілятор закриття Google або бібліотеку закриття Google , бажано обрати лінійку закриття над іншими інструментами.

Строгість

jsLint, як відомо, суворий. jsHint більш дозволений, що не завжди є доброю справою. Наприклад, одна з причин розщедрити jsLint для jsHint пояснюється в статті, де показано неправильний код, який призведе до помилки в jsLint, але не в 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;
    }

    /* ... */
});

Код поганий, оскільки, схоже, JavaScript має область блоку, в той час як його немає. Див. JavaScript: Добрі частини, стор. 102, Додаток A: Жахливі частини, сфера застосування. Іншими словами, дивлячись на код, не знаючи мови, ми очікуємоname він не буде видно поза циклом, в той час як він залишиться видимим.

Що стосується закриття Linter Google, я вважаю, що він знаходиться десь посередині між jsLint та jsHint, але у мене недостатньо інформації, щоб це підтримати.

Висновок

Я б уникнув jsHint: він занадто дозвільний, це означає, що він не знайде потенційних помилок, які б інші літери виявили. Посібник зі стилю, який використовується, важко знайти.

Серед jsLint та Google Closure Linter вибір не очевидний. Обидва написані експертами, обидва слідують суворому, добре описаному посібнику зі стилю, за яким вже слідують тисячі розробників. Використовуйте обидва певний час, а потім виберіть той, який є більш практичним для вас.