Соглашения об именах Javascript

12

Я из Java и новичок в JavaScript. Я заметил много методов JavaScript, использующих имена параметров из одного символа, например, в следующем примере.

doSomething(a,b,c)

Мне это не нравится, но один из разработчиков JavaScript убедил меня, что это сделано для уменьшения размера файла, отметив, что файлы JavaScript необходимо передавать в браузер.

Затем я обнаружил, что разговариваю с другим разработчиком. Он показал мне, как Firefox будет обрезать имена переменных, чтобы быстрее загружать страницу. Это стандартная практика для веб-браузеров?

Каковы наилучшие методы преобразования имен, которые следует соблюдать при программировании на JavaScript? Имеет ли значение длина идентификатора, и если да, то в какой степени?

javascript naming coding-standards conventions ManuPK
источник
13
Я очень сомневаюсь, что браузеры меняют имена переменных. При наличии eval, это небезопасно (да, evalэто ужасно, но это часть стандарта, и вы не выбрасываете стандартную компиляцию для оптимизации), и это не помогает ни капли в сокращении трафика - вы все равно отправить полный файл.
4
Я часто видел разработчиков, спорящих о преимуществах коротких имен переменных. Не слушай их. Это почти всегда оправдание для «я слишком большой, чтобы придумать хорошее имя» или «я слишком ленив, чтобы набирать столько символов».
Док Браун
@DocBrown: Даже мне это не понравилось. Так как я не являюсь экспертом в JavaScript, хотел знать лучшие практики.
ManuPK
В конце концов, речь шла о дополнительных данных объемом около 50-100 КБ, чтобы использовать осмысленные имена методов? Если 100 КБ вызывает проблему со скоростью, ее не стоит пытаться решить, потому что эта проблема возникнет у недостаточно большого пула пользователей.
Ramhound

Ответы:

26

Вы обнаружите, что сами разработчики не используют короткие имена переменных. При разработке они используют значимые и подробные имена переменных.

Затем в процессе сборки / выпуска написанный ими код пропускается через минификатор / обфускатор с целью минимизации размера файла, что является наилучшей практикой для ускорения работы веб-сайта. Это необязательный шаг , если вы заботитесь , что много о производительности. Большинство небольших сайтов не делают этого.

Вы , как разработчик, не должны заботиться о процессе минификации / запутывания; написать свой код, чтобы он был читабельным, значимым, хорошо документированным и хорошо структурированным. Затем, если вам так важна производительность (необязательно, не забудьте!), Добавьте минификатор / обфускатор в процесс выпуска, чтобы минимизировать код (удалить пробелы, новые строки, комментарии и т. Д.) И скрыть его (например, сократить переменную). имена). Хорошую статью, которая объясняет обфускацию против минификации, можно найти здесь .

Кроме того, Desktop FireFox не усекает период имен переменных . Усечение имен переменных позволяет ускорить загрузку страницы. К тому времени, когда FireFox получает файл, он уже загружен, поэтому в этом нет необходимости. Ваш друг может запустить плагин, который делает это; в этом случае, скажите ему, чтобы удалить его, потому что это бесполезно.

В завершение некоторые (мобильные) браузеры имеют возможность использовать серверы среднего уровня, которые перехватывают ответы запрошенных вами ресурсов и сжимают их для вас (что может включать минимизацию файлов JavaScript). Обратите внимание, что сжатие выполняется на сервере (то есть до того, как вы загрузили страницу), поэтому потенциальная выгода от загрузки меньшего файла, а не в браузере, как только вы уже загрузили файл (как предложено в вопросе). Такие мобильные браузеры включают Opera Mini и более новые версии Google Chrome (по крайней мере для iOS; не уверен насчет Android). Для получения дополнительной информации см. Здесь .

Matt
источник
11

Нет, не все браузеры будут автоматически сокращать JavaScript, чтобы повысить производительность.

Однако в случае JavaScript вы не должны жертвовать удобочитаемостью / удобством сопровождения кода для повышения скорости обработки или безопасности, поскольку существуют инструменты, называемые обфускаторами, и другие инструменты, называемые шинкерами (или компрессорами), которые были разработаны для этой цели.

Помните, не оптимизируйте заранее. Если ваша страница загружается достаточно быстро, и в вашем JavaScript нет слишком чувствительного содержимого, не беспокойтесь об этом. Назовите свои переменные значимыми именами. Читаемость кода очень важна для удобства сопровождения и редко, если вообще когда-либо, должна приноситься в жертву.

Если вам нужна ссылка на некоторые хорошие соглашения по кодированию JavaScript, я рекомендую использовать их .

CFL_Jeff
источник
2

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

С учетом вышесказанного вы, вероятно, должны в любом случае обслуживать минимизированные (например, через YUI Compressor ) версии ваших скриптов.

Если вам интересны лучшие практики для веб-разработки в целом, я предлагаю прочитать Что должен знать каждый программист о веб-разработке?

Craige
источник
1

Я работал в JavaScript очень долгое время.

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

Казалось, работает нормально. Я знаю, что есть случаи против использования этого, но это хорошо сработало для нас. Особенно, когда у вас есть массивные файлы JavaScript, где вам нужно что-то найти.

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

Алан Делимон
источник
5
Венгерская нотация? Это старая школа. Венгерская нотация является старинной версией разработки и со временем не рекомендуется.
Smokefoot
2
Я склонен использовать его немного, но только для значений, обернутых jquery, которые я начну с $. Проблема с венгерской нотацией состоит в том, что люди обычно говорили вам тип в терминах «int» против «String», а не в терминах семантики программы
Захарий К
«Особенно, когда у вас есть массивные файлы JavaScript, где вам нужно что-то найти». -- Я слышу тебя. Но венгерская нотация - просто липкая штукатурка ... она не поможет в долгосрочной перспективе, она просто запутает, когда вам нужно изменить тип чего-либо, но у вас нет времени, чтобы изменить все префиксы переменных. Автоматизация всего, где GWT входит в свою собственную IMO.
фанкибро
1
Я не обязательно покупаю, используя обозначения как «ломающие» слабо типизированные аспекты языка. Конечно, вам придется изменить имя при смене типа, но в любом случае это было бы полезно, чтобы вы могли отслеживать, что вы делаете. Я знаю, что есть аспекты, которые ужасны. Но, если вы когда-либо работали в БОЛЬШОМ (я говорю о сотнях тысяч строк кода) проекте на свободно типизированном языке, это может помочь вам быстрее найти свой путь в определенных случаях. Сказать, что оно датировано и т. Д., На самом деле не решает основную проблему, которую пытался решить ОП.
Алан Делимон
1
Венгерская нотация - это одна из тех вещей, которую люди сразу отрицают, не понимая почему. Выяснилось, что он попадает в ту же категорию, в gotoкоторой люди бездумно повторяют мантру «не используйте goto ... не используйте goto ...» . Реальность такова, что это просто инструмент в вашем наборе инструментов. Как и у любого инструмента, есть ситуации, когда он полезен, и ситуации, когда он не так полезен (или даже вреден). Как будто кто-то имел неудачный опыт, пытаясь распилить кусок дерева с молотком, а затем заявил: «Никогда не используйте молотки, пилы намного лучше!» , Широкие обобщения всегда неправильны
MattDavey
1

Длина идентификатора не имеет значения. Как говорят другие, в производстве Minification можно использовать для сокращения времени загрузки скрипта. На самом деле, следует придерживаться приемлемого соглашения о кодировании / именовании, особенно потому, что JavaScript - это необычный язык, и в течение столь длительного времени JavaScript игнорировался как просто вещь для выполнения работы. Если вы ищете место для соглашения об именах, Google JavaScript Style Guide - хорошее место. Это предполагает,

  • functionNamesLikeThis, например, getCashbackData () {}
  • variableNamesLikeThis, например, var alertInterval = 10;
  • ClassNamesLikeThis, например, var CustomerOrder = {getOrderLines: function () {}}
  • EnumNamesLikeThis, например, var ColorOfChoice = {White: "#FFFFFF"}
  • methodNamesLikeThis, например, var CustomerOrder = {getOrderLine: function () {}}
  • SYMBOLIC_CONSTANTS_LIKE_THIS, например, var EPOCH_UNIX = "01011970"
Тед
источник
У вас есть что-нибудь еще, чтобы добавить связку ссылок? Я имею в виду, вы даже не объясняете, кто такой Дуглас Крокфорд.
Ramhound
0

Взволнованный философией «разработчика чистого кода» (и учитывая, что теперь вы знаете из постов выше, что из-за минимизации размера имен ваших переменных будет иметь нулевое влияние на производительность), я могу только посоветовать

  1. Найдите лучшую IDE для ваших личных потребностей разработки, которая имеет достойные функции автозаполнения и intellisense, такие как aptana, netbeans, eclipse (все бесплатно) или любой из многочисленных коммерческих продуктов (если бы у меня была бесплатная игра, я бы посмотрите на продукты JetBrains)

  2. Напишите свой код таким образом, чтобы любое комментирование было излишним. Это означает, что вместо того, чтобы писать

    getXy(e) { return [e.pageX, e.pageY ] }

    что может означать действительно что угодно (особенно в сумасшедшем свободно типизированном языке, таком как js;), вы заставляете код выражать себя

    getPageCoordinatesFromEvent(event) { 
    return [event.pageX, event.pageY ];
}

    В хорошей IDE вы, как правило, никогда не наберете имя переменной длиной более двух секунд - если вы наберете несколько букв и просто нажмете ввод из автозаполнения. Если вы настаиваете на том, чтобы печатать каждый символ самостоятельно, хорошая IDE в любом случае заметит вас в опечатке. Это просто очень поверхностный пример, поэтому я настоятельно рекомендую (не как форму критики, а как честную рекомендацию), чтобы вы

  3. Получите книги «Чистый код» Роберта К. Мартина или «Прагматичный программист» Ханта / Томаса и никогда больше не задавайте себе подобных вопросов - вы будете слишком заняты работой на сервере непрерывной интеграции, чтобы автоматизировать скучный тест - и создайте части процесса разработки (включая минимизацию) и сконцентрируйтесь на забавной части, написав четко понятный код, который отлично работает!

PS Если вам нужно быстро освоить разработку современного javascript-кода, взгляните на книгу Джона "Mr. jQuery" Ресига о "Pro Javascript Techniques" сразу после или вместе с вышеизложенным.

Philzen
источник