Соглашения об именах JavaScript [закрыто]

257

Я знаю, что существует много противоречий (возможно, не противоречий, но, по крайней мере, аргументов) о том, какое соглашение об именах лучше для JavaScript.

Как вы называете свои переменные, функции, объекты и тому подобное?

Я оставлю свои собственные мысли по этому поводу, так как я не занимался JS долго (только пару лет), и я только что получил запрос на создание документа с соглашениями об именах для использования в наших проектах на работе , Так что я искал (google-ing) вокруг, и есть так много разных мнений.

В книгах, которые я читал на JS, также используются разные соглашения об именах, но все они сходятся в одном: «Найдите то, что вам подходит, и придерживайтесь его» Но теперь, когда я так много прочитал, я обнаружил, что некоторые другие методы мне нравятся немного лучше, чем те, к которым я привык.

peirix
источник
Современное руководство по соглашениям о присвоении имен в здравом смысле в JS: robinwieruch.de/javascript-naming-conventions
Робин Виеруч

Ответы:

202

Я следую соглашениям по кодексу Дугласа Крокфорда для javascript. Я также использую его инструмент JSLint для проверки соблюдения этих соглашений.

Geoff
источник
30
JSLint может быть слишком радикальным и ограничительным для многих разработчиков, тогда JSHint может быть лучшим выбором.
Павел Ходек
7
Крокфорд не вдавался в этот уровень детализации, но как насчет переменных, которые начинаются с заглавной буквы, потому что они ссылаются на аббревиатуру - должна ли первая буква или вся аббревиатура быть в нижнем регистре? Пример: ECBhandleпротив ecbHandle(не имеет значения, что означает ЕЦБ).
Дан Даскалеску
13
Хотя это хорошая ссылка, я не могу поверить, что «ответ по ссылке» имеет так много голосов. Вы можете по крайней мере извлечь и отформатировать соответствующие части связанной страницы.
Адриен Бе
2
Я думаю, что он справляется со ссылкой. Если вы так обеспокоены, вы должны отредактировать сообщение.
nckbrz
4
Я действительно смотрю на Крокфорда, но его кодовые соглашения кажутся очень устаревшими. Я бы посоветовал взглянуть на ответ @PavelHodek ниже по списку
Пер Хорншой-Ширбек
160

Как говорит Джефф, Крокфорд говорит , что это хорошо.

Единственное исключение, за которым я следую (и которое широко используется), - это использование $ varname для обозначения объекта jQuery (или любой другой библиотеки). Например

var footer = document.getElementById('footer');

var $footer = $('#footer');

Deebster
источник
7
Я также использую $ для этого. Я часто вижу, что люди используют $ для обозначения кэшированной копии объекта. Я всегда предполагал, что это игра слов. кеш> "наличные"> $
Шон Уиннери,
1
Возможно, это не самая лучшая идея, если вы используете AngularJS - для основных служб добавлен префикс «$»
Филип Собчак
2
Я настоятельно рекомендую НЕ использовать специальные символы в именах переменных. Многие фреймворки используют $ особенно.
nckbrz
1
@nixxbb Это нормально, если вы правильно определяете область видимости переменных - что и делают приличные рамки.
Андре Фигейредо
1
Я вижу, что гильделины Крокфорда упоминают: «Не используйте знак подчеркивания _ в качестве первого или последнего символа имени. Иногда оно предназначено для указания конфиденциальности». Я лично использую underbar, чтобы указать частных участников. Это плохая практика? Есть ли альтернатива?
Ян Г
112

Вы можете следовать этому руководству по стилю Google JavaScript

В общем, используйте functionNamesLikeThis, variableNamesLikeThis, ClassNamesLikeThis, EnumNamesLikeThis, methodNamesLikeThis и SYMBOLIC_CONSTANTS_LIKE_THIS.

РЕДАКТИРОВАТЬ: см. Хорошую коллекцию руководств по стилю JavaScript и Beautifiers .

Павел Ходек
источник
15
Я не уверен, полностью ли я согласен с этим, учитывая, что они разработали Dart и GWT (javascript api для chrome-расширений также очень похож на java). Для некоторых команд в Google лучший способ разработки javascript - написать его на другом языке.
Badunk
2
Я всегда находил соглашение между частными именами Google странным , вместо того, чтобы _fooBarэто делать fooBar_- Microsoft правильно поняла
Даниэль Соколовский
3
@DanielSokolowski А как насчет использования IntelliSense? Если вы ставите префикс перед большим количеством переменных, то это просто еще один символ, который вы должны вводить каждый раз, когда получаете доступ к этим переменным. В конце концов, ваш список intellisense выглядит чище, и вам будет проще найти то, что вам нужно.
FreeAsInBeer
@FreeAsInBeer правда о дополнительном символе, но я не думаю, что это быстрее. Печатание _при ссылке на приватные переменные сразу же приведет к ограничению результатов; в конце концов подумал, что это личное предпочтение.
Даниэль Соколовский
1
Спасибо за ссылку на список руководств по стилю. Я не знаю, стоит ли следовать исключительно или как еще решить, какой из них или мне следует использовать объединение. Но зная, где найти несколько в одном месте, это настоящее благо.
Roger_S
9

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

define(['Lightbox'],function(Lightbox) {
  var myLightbox = new Lightbox() // not sure whether this is a constructor (non-static) or not
  myLightbox.show('hello')
})

Я подумываю о том, чтобы попробовать соглашение, в котором статические модули используют «the», чтобы указать свое предсуществование. Кто-нибудь видел лучший способ, чем этот? Будет выглядеть так:

define(['theLightbox'],function(theLightbox) {
  theLightbox.show('hello') // since I recognize the 'the' convention, I know it's static
})
SimplGy
источник
6

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

Сказав это, я думаю, что большинство библиотек обычно следуют упрощению Java CamelCase. Я нахожу советы Дугласа Крокфорда достаточно вкусными для меня.

Хавьер
источник
2

Это отдельный вопрос, который может зависеть от того, как вы работаете. Некоторые люди любят помещать тип переменной в начале переменной, например "str_message". И некоторые люди любят использовать подчеркивание между своими словами («my_message»), в то время как другие любят разделять их заглавными буквами («myMessage»).

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

Короче говоря: английский, строчные буквы, хорошо организованные имена переменных и функций предпочтительнее для меня. Имена должны описывать их существование, а не быть короткими.

Ивар
источник
2
«поэтому функции и переменные (кроме закрытых переменных внутри функций) должны начинаться с имени службы, чтобы избежать конфликтов». Это утверждение является неточным . Вы можете правильно иметь «пространство имен» функций и объектов, которые не проходят через несколько структур JavaScript. Была очень хорошая презентация о том , как этого добиться от MIX11 channel9.msdn.com/Events/MIX/MIX11/OPN08
Chris Marisic