Конвенції про іменування JavaScript [закрито]


257

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

Як ви називаєте свої змінні, функції, об'єкти тощо?

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

Книги, які я читав на JS, також використовують різні умови іменування самих, але всі вони домовляються про один біт: "Знайдіть те, що вам підходить, і дотримуйтесь цього". Але тепер, коли я так багато читав навколо, я виявив, що деякі інші методи мені подобаються трохи краще, ніж те, до чого я звик.


Відповіді:


202

Я дотримуюся правил коду Дугласа Крокфорда щодо javascript. Я також використовую його інструмент JSLint для перевірки дотримання цих конвенцій.


30
JSLint може бути занадто радикальним і обмежуючим для багатьох розробників, тоді JSHint може бути кращим вибором.
Павло Ходек

7
Крокфорд не вникає в цей рівень деталізації, але як бути зі змінними, які, мабуть, починаються з великої літери, тому що вони посилаються на абревіатуру - чи має бути перша літера або весь абревіатура нижній регістр? Приклад: ECBhandleпорівняно ecbHandle(не має значення, що означає ЄЦБ).
Дан Даскалеску

13
Хоча це гарне посилання, я не можу повірити, що "відповідь на посилання" має стільки голосів. Ви можете принаймні витягнути і відформатувати відповідні частини пов’язаної сторінки.
Адрієн Бе

2
Я думаю, що він прекрасно справляється за посиланням. Якщо ви так стурбовані, вам слід відредагувати публікацію.
nckbrz

4
Я дійсно придивляюся до Крокфорда, але його кодові умовності здаються дуже застарілими. Я б порадив, дивлячись на @PavelHodek, відповісти далі за списком
Per Hornshøj-Schierbeck

160

Як каже Джефф, те, що говорить Крокфорд, - це добре.

Єдиним винятком, за яким я слідую (і я широко бачив), є використання $ varname для позначення об’єкта jQuery (або будь-якої бібліотеки). Напр

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

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


7
Я також використовую $ для цього. Я часто бачу, як люди використовують $ для позначення кешованої копії об'єкта. Я завжди припускав, що це гра на словах. кеш> "готівка"> $
Шон Уїннері

1
Це може бути не найкращою ідеєю, якщо ви використовуєте AngularJS - основні сервіси мають префікс "$"
Філіп Собчак

2
Я настійно рекомендую НЕ використовувати спеціальні символи в назвах змінних. Особливо багато фреймворків використовують $.
nckbrz

1
@nixxbb Це добре, якщо ви правильно використовуєте змінні - які гідні рамки також роблять.
Andre Figueiredo

1
Я бачу, що в керівництві Крокфорда згадується "Не використовувати _ underbar в якості першого або останнього символу імені. Іноді воно покликане вказувати на конфіденційність". Я особисто використовую underbar для позначення приватних членів. Це погана практика? Чи є альтернатива?
Ян Г

112

Ви можете дотримуватися цього посібника зі стилю Google JavaScript

Загалом, використовуйте functionNamesLikeThis, зміннуNamesLikeThis, ClassNamesLikeThis, EnumNamesLikeThis, methodNamesLikeThis та SYMBOLIC_CONSTANTS_LIKE_THIS.

РЕДАКТУЙТЕ: Дивіться приємну колекцію посібників стилів і стилів JavaScript .


15
Я не впевнений, чи повністю я згоден з цим, враховуючи, що вони розробили Dart і GWT (хромовані розширення javascript api також дуже схожі на Java). Для деяких команд у Google найкращим способом розробити JavaScript може бути написання його якоюсь іншою мовою.
badunk

2
Я завжди вважав, що приватна конвенція Google про іменування дивна , а не _fooBarвони fooBar_- Microsoft це правильно зрозуміла
Даніель Соколовський

3
@DanielSokolowski Що робити з використанням 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
})

6

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

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


2

Це індивідуальне питання, яке може залежати від того, як ви працюєте. Дехто любить ставити тип змінної на початку змінної, наприклад, "str_message". А деякі люблять використовувати підкреслення між своїми словами ("my_message"), а інші люблять розділяти їх великими літерами ("myMessage").

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

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


2
"тому функції та змінні (крім приватних змінних усередині функцій) повинні почати з імені служби, щоб уникнути конфліктів". Це твердження є неточним . Ви можете правильно мати функції "іменного простору" та об'єкти, які не кровоточать через декілька каркасів javascript. Була дуже гарна презентація того, як цього досягти на каналі MIX119.msdn.com/Events/MIX/MIX11/OPN08
Кріс Марісіч
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.