JavaScript: «Запретить ведение _ в идентификаторах» в качестве опции в JSLint - PullRequest
1 голос
/ 31 декабря 2008

Я только что начал писать свою собственную JavaScript Framework (только для обучения), и некоторые частные члены добавили префикс _ , например:

var _isFireBugEnabled = function () {
    return (window.console && window.console.firebug);
};

Когда я запускал свой код для JSLint Крокфорда (как всегда), с включенным Recommended Options, мне сказали, что я не должен использовать _ в качестве идентификатора.

Мой вопрос: Почему JSLint предупреждает меня о том, что не следует использовать _ в качестве идентификатора?

Есть ли какие-то побочные эффекты или последствия, которые я здесь упускаю?

PS. Насколько я мог сканировать только сейчас, это не задокументировано в книге

Ответы [ 2 ]

13 голосов
/ 31 декабря 2008

Причина в том, что Дуглас Крокфорд ненавидит около 78% Javascript *. Многие люди думают, что он немного строг, и на самом деле многие библиотеки используют ведущие подчеркивания в производственном коде. Я не вижу в этом ничего плохого. Побочных эффектов нет.

Кроме того, символ '$', а не подчеркивание, был символом, выделенным для "системного" кода в спецификации ECMA .

из ECMA 262, раздел 7.6:

Этот стандарт определяет один вылет из грамматики, приведенной в Unicode стандарт: знак доллара ($) и подчеркивание (_) разрешено везде в идентификаторе. Знак доллара предназначен для использования только в механически сгенерированный код.

* Примечание: я шучу. Он действительно ненавидит только половину, и у него обычно есть веская причина. Я не согласен с Крокфордом, но он обычно очень прав.

8 голосов
/ 31 декабря 2008

Я на самом деле написал Крокфорду по электронной почте. Это был его ответ:

Я думаю, что _ должно быть зарезервировано для реализация системного кода, а не используется приложениями.

Я с ним несколько не согласен, я склонен использовать _ для обозначения действительно частных членов в моих собственных классах, потому что это дает мне понять, что является личным. У Google Caja есть некоторые правила использования _, но нет ничего, что могло бы вызвать проблемы с тем, что вы описываете.

...