П'ять чи менше порад щодо написання хорошого JavaScript? [зачинено]

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

Зазвичай мені допомагає пам'ятати кілька найважливіших директив, які я можу попросити себе за кожен зроблений мною крок. (На мій погляд, жменька - п’ять і менше.)

Чи можете ви перелічити п’ять (або менше) питань, характерних для JavaScript, я повинен задавати себе за кожен крок, який я здійснюю, коли кодую JavaScript? Якими вони були б?

Оновлення: для уточнення, я не прошу про п’ять речей, які слід пам’ятати під час вивчення JavaScript; Я прошу п’ять питань, щоб завжди задавати себе йти вперед, що кожен повинен завжди задавати. Питання на високому рівні, такі як: "Чи я можу це повторити десь ще?" або "чи достатньо конкретна назва цієї змінної / функції (або занадто конкретна)" <== за винятком цих прикладів питань, не властивих JavaScript. Я шукаю директиви, властиві JavaScript.

Я відповім на це у двох частинах. Один - це "П'ять чи менше порад щодо того, як навчитися писати хороший JavaScript". Інша - "П'ять чи менше порад щодо написання хорошого JavaScript".

Навчання:

1. Задавати питання
2. Слухай
3. Прочитайте
4. Зробіть речі

Виконуємо:

1. Уникайте глобалістів (модулюйте)
2. Робіть важкі речі поза петлями (вибір DOM, оголошення функцій тощо)
3. Дізнайтеся, як працює область
4. Дізнайтеся, коли і як використовувати закриття
5. Дізнайтеся, як працює об'єктно-орієнтований JS

EDIT (додавання запитань на виконання ОП):

На яку сферу я посилаюся?

Це повинно допомогти глобальним витокам, обробникам подій та коли використовувати закриття.

Чи повторююсь я?

Важлива правильна абстракція та використання методик ОО. Використовуйте їх розумно.

Чи повторюється мій код?

Надзвичайно легко виявити, що ви отримуєте доступ до DOM у циклі або створюєте функції (анонімні чи іншим чином) у циклі. Зауважте, що це може бути правдою для коду, який використовує setTimeoutабо setIntervalтрадиційного циклу.

Чи означає це, що я думаю, що це означає?

Цінні і хибні значення в JS можуть бути дещо хитрими, особливо при використанні не строгих порівнянь ( ==на відміну від ===). Динамічне введення тексту, введення примусу та те, чи посилаєтесь на об'єкти чи літерали, також можуть бути доречними.

По-перше, знайте, як працює технологія, яка стоїть за нею.

Це потрібно знати, тому що знання, як воно працює, тому що ви збираєтеся стикатися з проблемами мереж, або, як я вже бачив безліч разів, люди цілком розуміють, що насправді є на стороні сервера та клієнта. Одне з найпоширеніших запитань щодо новичка, яке я бачу, - "Як я можу змусити JS змінити змінну в моєму коді ASP ?!"

• Ви розумієте, що Ethernet / Wi-Fi та TCP / IP мають загальне уявлення про те, що відбувається?
• Скільки HTTP ви насправді знаєте?
• Ви насправді отримуєте HTML? Звичайно, ви можете знати, як працюють теги та створюють гніздо, але чи ви насправді розумієте режим доктрипу та химерності? Ви розумієте, що не слід ставити теги абзацу навколо елемента списку?
• Винайдіть JavaScript (і поясніть, що його можна запустити на сервері). ecmascript, сценарій життя, москрипт, jsscript, вузол ...
• Вивчіть API вікна, вивчіть API DOM та вивчіть API XHR. Якщо ви не знаєте цих трьох речей, у вас немає коду для написання бізнесу для браузера.

Зрозумійте, що ваш код більший, ніж ви, або ваша конкретна ситуація

• Звичайно, ви щось написали, але кожен це може побачити. Це все "відкрите" джерело. Звичайно, ви можете притупити це, мінімізувати, як би там не було ... Наприкінці дня, якщо я хочу бачити, що ви кодуєте, для мене тривіально перемогти будь-які застосовані вами методи.
• Вам потрібно зрозуміти кілька відмінностей браузерів. Націліть на найпопулярніші або ті, які мають ваш демографічний ринок. Наприклад, ie6 не буде відображати елементи комірки таблиці DOM, якщо ви додаєтеChild, а не методи DOM API спеціально для таблиць. Більше прикладів існує, їх потрібно вивчити.
• Вам потрібно зрозуміти, як писати код навколо цих проблем у браузерах, а не у вашому конкретному браузері. Ви швидко дізнаєтесь речі, які добре працюють в одному браузері, а в іншому повільно. Вам доведеться з’ясувати, як працюють браузери та чому вони відрізняються.
• З любові до бороди Одіна, не пишіть код, який дозволяє мені робити наскрізні сценарії на ваш код. Якщо ви здійснюєте ajax дзвінок до стільника і робите щось на кшталт cell.innerHTML = "<script>alert("xss")</script>", і з’являється вікно попередження, ви зробили це неправильно.
• Тримайтеся кривавого пекла подалі від DynamicDrive, w3Schools та веб-сайтів, які дають погані поради. Потрібно знайти спільноти, які дають хороші поради. Тут, у Stack Overflow, у нас є чати JavaScript та Node.JS, і ми робимо все можливе, щоб продовжувати розширювати межі того, що "краще", оскільки сайти типу w3s зберігають застарілі дані і ніколи не турбуються з цим. Ви повинні дотримуватися офіційних сайтів, таких як W3C , Mozilla Developer Network (MDN). Попросіть експертну перевірку коду. Коли вам здається, що ви робите щось болісне зі своїм кодом, коли ви робите багато вирізання + вставки + налаштування зі своїм кодом, вам слід негайно зайти в кімнату чату і попросити рекомендацій щодо написання кращого коду.
• Коли ви приїжджаєте за керівництвом або хочете поділитися тією справді класною річчю, яку ви зробили ... будь ласка, дуже ласкаво. Будь ласка, переконайтеся, що ви це задокументували, переконайтеся, що ваші імена змінних мають сенс, переконайтеся, що вони не всі однолінійні. Вам потрібно написати чистий код. Якщо у вас є купа сміття, ви не тільки провалилися, не захоче ніхто, хто знає, як допомогти . Допоможіть нам допомогти вам.
• Ви хочете написати JavaScript - це здорово, поважайте, що не всі підтримують JavaScript. Дві причини цього - 1) Швидший Інтернет для всіх (а не "відключити всі речі", що призводить до повільнішого досвіду). 2) Веб-доступний для людей у ​​браузерах, що базуються на консолях, людям, що працюють без сценарію, мобільних телефонах. Що я намагаюся сказати, це те, що ваш сайт повинен граціозно деградувати, якщо хтось не має JavaScript, і, принаймні, використовувати <noscript>теги, щоб попередити їх про таке.
• Через характер прототипу JavaScript, ви можете внести зміни до того, як мова насправді працює-- що дуже приємно. Розумієте, JavaScript розвивається, ми витягуємо з "Сценарій 3 ECMA", що є старшою версією JS, і "ECMA Script 5" (він же, es5). Через прототип ми можемо виправити мову es3 в полі, щоб він працював як es5. Це означає, тобто 6, 10-річний браузер отримує мовну функцію, яка з’явилася минулого року. Використовуйте es5-shim де завгодно, вони справді круті, і вам потрібно заглянути.
• Західний світ англомовних білих дітей - це не той, хто користується Інтернетом. Код відповідно. Це означає, що вам потрібно зрозуміти інтернаціоналізацію та написати код, що стосується більш високого попиту. 10 років тому в мережі було менше 500 мільйонів людей, сьогодні це приблизно 2 мільярди, а ще через 10 років? Напевно, близько до кожної людини на планеті буде доступ до Інтернету, це означає, що вам потрібно підтримувати імена, які не відповідають реггесу /[a-z ']/i, але включають хінди, арабську мову, наголоси (це вже існуюча проблема у недалекоглядних розробників), китайська , та інші. Зрозумійте набори символів, Unicode та UTF-8.

Ви програміст, а не фабрика макаронних виробів. Перестаньте писати спагетті.

• Назвіть свої змінні після речей, які мають сенс.
• Документуйте свій код. Мені все одно, якщо ви використовуєте JSDoc, що працює від носорога, або у вас є маса каракулей. Напишіть документацію, яка допоможе особі, яка збирається використовувати ваш код. Напишіть документацію для того, хто хоче покращити або підтримувати ваш код. Включіть корисні коментарі. Коментарі, як "This fizzes the bizz"напіванглійська напівфранцузька мова, чи не корисні. Опишіть, що робить функція. Опишіть складні розділи коду.
• З'ясуйте, як обмежити повторення коду. Шукайте модульний дизайн або функціональні зразки. Подивіться, що можна абстрагувати. Ви ніколи не повинні закінчувати різання + вклеювання + виправлення великих сегментів коду, щоб зробити те саме.
• Вам потрібно зрозуміти API DOM. DOM та віконні об'єкти забезпечують багато чудових речей. Це звучить як багато роботи, але це тому, що це велика страшна абревіатура. Багато з вас ніндзя JavaScript люблять писати такі коди, як <a href="javascript:alert("foo")">. FFS НЕ РОБИТИ ЦЕ. Дочекайтеся завантаження повного документа, відокремте свій код JavaScript від html-документа. Це основні практики OOP 101, ніколи не вбудовуйте JS або CSS у свій html-документ. З’ясуйте, як це зробити правильно, або знайдіть когось, хто вміє показати вам, як це зробити. Знову ж задайте питання.
• Javascript:foo("buz")є psudeo-протокол, він не повністю підтримується, і якщо ви не в лінії Javascript ви б не використати його в першу чергу. Я обіцяю вам від щирого серця, що немає жодної причини на цій землі або в будь-якій точці Всесвіту, яку вам НЕОБХІДНО вводити свій JavaScript всередині елемента HTML. Колись. Тож не робіть цього. Я навіть не буду допомагати людям , які роблять , що більше, це що погано.

З'ясуйте, як написати код таким чином, щоб він не ламався весь час.

• Глобальні змінні - одна з найбільших проблем. З’ясуйте, як працює функціональне програмування в JavaScript. З’ясуйте, що таке підйомник. З’ясуйте, як уникнути глобальних змінних.
• Використовуйте інструменти аналізу статичного коду. Вони одразу попередить вас про всі маленькі "ой", які ви зробили під час написання коду. Забули десь крапку з комою? О, ось воно. Чи є десь глобальний? О, ось воно. Код, який може створити купу таємничих помилок при спробі його запуску? О! Ось вони! Немає більше гвинтівки та дивлячись у купу коду годинами, намагаючись зрозуміти щось, що є лише синтаксичною помилкою. (Ну, навряд чи хтось, ви, можливо, зробили щось, чого не вдається зловити, але це, як правило, приголомшливо).
• Тест одиниці. Причин не бути таким. Там є багато інструментів для тестування одиниць. В основному, тестування одиниць "Ось моя функція" і "Я хочу, щоб вона виводила Y" "Ось кілька тестових входів" І тест "Чи всі вони працювали?" Існує багато рамок тестування JS, як популярний QUnit. Огляньте свою улюблену пошукову систему і подивіться, що тикає ваші фантазії. Але використовуйте їх.
• Управління джерелами управління, також відоме як управління версіями. Гіт популярний, і з вагомих причин. Так само SVN та кілька інших. Що вам потрібно перестати робити це миттєво - це редагування виробничого коду. Вам потрібно зупинити перейменування файлів. main_backup_20110911.js.bak.1Ви втрачаєте речі, ваш каталог стає безладним, ви не можете легко "перемотатися" на попередній момент часу. Ви не бачите, що відбувається, ви не можете робити патчі коду. Отже, тільки почніть вивчати GIT, це займе у вас годину, і ви ніколи не повернетесь назад.
• Експертна оцінка. Ти не такий хороший, як і я. Я стаю кращим, прошу відгуки, наскільки це можливо. Ось так і слід робити.

Напишіть JavaScript, який люблять люди

• З’ясуйте, чому ваш код повільний. Використовуйте jspref і створюйте тести.
• Перестаньте прив'язувати події до одного елемента DOM, це повільно, і створюються серйозні проблеми, пов'язані з бурхливими подіями, які витратять багато вашого часу. Дослідження "делегація подій" в JavaScript.
• СТОПУЙТЕ за допомогою innerHTML для редагування DOM. Це повертається до вивчення того, що таке HTML, та вивчення того, що таке DOM. HTML - це дані, що надсилаються з сервера, який використовує механізм візуалізації веб-переглядача, щоб створити купу об’єктів програмування, які в кінцевому підсумку є об’єктом документа. Коли ви використовуєте innerHTML, ви просите веб-переглядач відновити все. На щастя, як і близько 10 років тому, ми створили API DOM, і він дозволяє "додавати дитину" або "створювати текстовий вузол", не оновлюючи це все. innHTML - це ганьба, яку винайшов Microsoft - якщо ви користуєтесь ним, ви також втрачаєте всі привілеї, щоб скупотати про те, що IE6 є жахливим, оскільки ви допомагаєте, щоб сміття залишалося назавжди. Вивчіть ДОМ.
• Потрібно працювати всюди, де тільки може. Якщо щось не підтримується, його потрібно граціозно погіршити, щоб досвід не смокчуть - ви не можете просто ляпнути своїх користувачів в обличчя та зіткнутись.
• Авторське право та ліцензія є важливими. Не відривайте важку працю інших людей. Якщо хтось каже "не для перепродажу", ви не можете його продати. Не шуміть, інакше ми будемо ненавидіти ваш код, щоб зірвати працьовитих людей.
• JS - це прототипи, а не класи. Перестаньте це робити. Якщо ви не розумієте, як працює прототип, вам потрібно. Google це. JavaScript не заснований на класах, перестаньте намагатися складати класи, він дуже рідко спрацьовує добре. Люди намагаються написати класичний код на мові прототипу і використовують це як те, що "чому мова смокче", я міг би зробити той самий випадок, коли Рубі не змогла підтримати прототип. Дізнайтеся щось нове і перестаньте робити це неправильно.

Завжди орієнтуйтеся на основи.

• Ви помиляєтесь, і це приголомшливо, адже зараз ви щось знаєте. Нічого не гірше, ніж той, хто не визнає, що помиляється, і продовжує грюкати поганий код у двері, ніби вони - ніндзя супергероя рок-зірки. Вони просто дурні. Признайся, що ти можеш помилитися, визнай, що ти можеш помилитися, попроси допомогу.
• Вам не завжди потрібен jQuery. jQuery створює багато повільних кодів і допомагає людям, які не знають JS, писати JS. Це додаткова проблема, оскільки JS не вимагає, щоб ви знали JS, щоб писати JS. Піди розберися. Як тільки ви зрозумієте кілька речей, про які я згадував вище, таких як навчання подій, вивчення DOM, вивчення внутрішнього HTMLML, ви побачите, чому jQuery може завдати шкоди вашому коду. Його можна правильно використовувати в багатьох місцях, але часто ви можете використовувати меншу бібліотеку або навіть задихати стандартний JavaScript, який постачається разом із вашим браузером, щоб щось досягти. Вам не потрібно jQuery, щоб робити що-небудь, це полегшує написання коду, який класно, якщо ви навчаєтесь, але вам потрібно почати робити краще і більше вчитися - коли ви знаєте більше, ви зрозумієте як це все-таки пишіть кращий код у jQuery.Ознайомтеся з деякими іншими бібліотеками JavaScript і перестаньте бути настільки уважними.
• Вам не потрібно вирізати + вставити + налаштувати, зробіть DRY-код. Про це я вже згадував, але важливо і тут. Ви не можете написати код якості, якщо база вашого коду - це ганьба.
• Не зловживайте масивами / об’єктними відмінностями, навчіться циклічно. Дізнайтеся, чому ви використовуєте a for (;;)і чому ви використовуєте for( in )цикл. Коли користуватися циклом час. Перестаньте вкладати IF, коли ви можете просто використовувати корпус комутатора. Об'єкти не зберігають порядок, тому не використовуйте їх як масив; стара Opera / FF, стара MISE, іноді Flash не поважає порядок об’єктів. Використовуйте масив, якщо ви хочете вести порядок речей, використовуйте об'єкт, якщо ви хочете об'єкт (те, що не має порядку елементів).
• Як структури рішень можна використовувати на вашу користь, не додаючи складності вашому коду. Перестаньте вкладати IF, з’ясуйте, як працюють логічні оператори Boolean. З’ясуйте, як працює корпус комутатора.
• RTFM. Найкраще місце, щоб дізнатися про кращий код, - прочитавши фактичну специфікацію. Прочитайте специфікації RFC у тій частині коду, яку ви намагаєтесь використовувати. Прочитайте документ ECMAScript. Прочитайте специфікацію W3C DOM. Прочитайте специфікацію W3C XHTML / HTML / HTML5. Прочитайте характеристики, вони гарні.

Зосередьтеся на тривалій грі, а не на швидкому спалаху і помирайте.

• Ви повинні допомогти громаді, ви повинні написати код, який буде довгий час. Майте пристрасть до свого коду та спільноти. Якщо ви десь залишили погані знання, поверніться до біса і виправте це. Погану інформацію справді важко очистити і застрягнути назавжди. Зробіть свою роль. Не допоможіть w3schools погіршити Інтернет.
• Не стрибайте з нізвідки і кажіть "Ей, у мене чудова ідея, як користуватися which", киньте купу коду, який ніхто не може використовувати і зникнути. Ви нічого не сприяли. Не використовуйте змінні , як aі chezburger.
• Навчіться визначати поганий і хороший код, знайдіть його у власному коді, зробіть свій поганий код у хороший.
• Створити щось, щось навчитися, чогось навчити.
• Розширити свій кругозір. Ви не можете просто писати JavaScript назавжди - взяти суботник у щось інше, що вас цікавить, поверніться, поділіться вивченим та подивіться, чи зможете ви знайти місце для нього в громаді. Спробуйте показати іншому світу, яке значення має JavaScript, поки ви там.
• Ви все ще помиляєтесь, навіть коли все знаєте. Використовуйте доказ, щоб бути правильним, а не своїм статусом / повноваженнями. Ти ніколи не можеш мати рацію, але твій доказ завжди правильний. Не вступайте в підступні сірники, настільки важко, як іноді уникати. Або є докази, або немає. Полум'я нікому не допомагає.

Для всіх, хто цікавиться, я фактично взяв більшість цього з особистих записок до підручника, про який я ніде не писав.

1. Прочитайте Jaglas Douglas Crockford : хороші частини . Це досить підказка, але, чесно кажучи, це найкраща порада, яку я коли-небудь чув для написання гарного JavaScript.

2. Так само читайте статті Дугласа Крокфорда на Javascript .

alert('This illustrates how JavaScript has first-class functions');
alert('It also illustrates how to use closures.  Try running this code in your browser.');

var funky = function(s) {
    alert("We're getting funky with " + s);
};

var makeFunkyObject = function(funkyFunction) {
    var numberOfTimesAlerted = 0;
    var fn = { };
    fn.alertFunky = function(s) {
        funkyFunction(s);
        numberOfTimesAlerted++;
    }
    fn.getNumberOfTimesAlerted = function() {
        return numberOfTimesAlerted;
    }
    return fn;
}

var funkyObject = makeFunkyObject(funky);

funkyObject.alertFunky('Alice'); // alerts We're getting funky with Alice
funkyObject.alertFunky('Bob'); // alerts We're getting funky with Bob
alert(funkyObject.getNumberOfTimesAlerted()); // alerts 2

alert('Also, be sure to distinguish between learning about JavaScript and learning about the DOM');
alert('The former is awesome; the latter, not so awesome.');

Ось декілька питань, які повинні вас запустити на JavaScript.

1. Як працює JSON і для чого це добре?

2. Чому об’єкти функцій в JavaScript?

3. Чому я не повинен використовувати eval?

4. Як створити події в javascript?

5. Як мені функцію виявлення у JavaScript?

В основному охоплює більшість речей, які вам потрібно зробити в JavaScript.

1. Завжди використовуйте крапки з комою. Неявні крапки з комою (в JS) - жахлива ідея, особливо з деякими цікавими синтаксисами, що плавають навколо у спільному використанні. Вони, як правило, вимагаються будь-яким мініфікатором JS.
2. Уникайте eval () . Це спричиняє всілякі проблеми, і це дуже швидкий спосіб уповільнити вашу програму. Більшість застосувань - це фактично зловживання. Кожен раз, коли ви думаєте, що вам потрібно скористатися eval(), двічі і втричі перевіряйте інший спосіб; майже завжди є більш чистий, простіший спосіб, якщо ви насправді не намагаєтеся виконати цілий рядок, що вартує JavaScript.
3. (function() {/* stuff */})()це хороший спосіб охопити набір коду та створити для нього локальну область. Використання предметів - інший, часто кращий спосіб; об'єкти є більш аналогічними просторам імен в інших мовах при використанні таким чином. Просто слідкуйте за this. На відміну від більшості інших мов, thisне завжди посилається на те, що ви можете інтуїтивно вважати, що це робить. Також пам’ятайте, що якщо не вказано інше, всі змінні, функції та інші об'єкти JS є глобальними, навіть у кількох .jsфайлах.
4. Знайдіть і вивчіть / використовуйте хорошу бібліотеку JS. jQuery - одна з найбільш популярних. Це зробить для вас багато важких підйомів, включаючи такі функції, як виявлення функцій та обмеження маніпуляцій з DOM та безліч способів, що різні речі реалізуються в різних браузерах.
5. Завжди використовуйте крапки з комою. Серйозно. Отримайте IDE, який попереджає вас про їх забуття. Я не хочу озвучувати шахрайство, але кілька разів було введено помилок через відсутність крапки з комою та браузер не попередить вас про це.

Я вважаю, що класи є досить потужним інструментом для структури коду. Існує багато мовних агностичних правил щодо проектування систем на основі класів, а деякі принципи ОО насправді більш очевидно реалізуються при використанні класів.
Тому я пропоную вам поглянути на CoffeeScript .

Звідти я пропоную вам просто спробувати зібрати інформацію про те, як реалізувати SOLID , DRY , GRASP , KISS та YAGNI , і що ще важливіше, як вирішувати ситуації, коли вони, схоже, конфліктують (вони ніколи цього не роблять, лише ваше розуміння їх чи ця проблема є). Це досить легко знайти навіть на зміні stackexchange.

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

Я припускаю, що ви використовуєте JavaScript для розробки інтерфейсу на стороні клієнта у веб-додатку.

1) Якщо це має бути клієнтська чи це повинна бути серверна? Я знаю, що я пішов і написав серйозні фрагменти коду, які справді заслуговують на те, щоб бути на стороні сервера і навпаки. Дуже багато разів я спробую здійснити дзвінок AJAX для чогось, що в кінцевому підсумку буде краще розміщено в коді Сервера, який буде включений у дорогу. Особливо речі, які мають статичний характер, але змінюються досить регулярно (наприклад, список категорій.)

2) Чи є плагін, який робить це вже? Я багато використовую JQuery, і відповідь майже завжди ТАК! Я часто беру плагін-код, який хтось написав, і адаптую його до моїх потреб (зазвичай додаю додаткові заняття до речей тощо), але рідко мені коли-небудь потрібно починати з нуля.

3) Чи правильне місце для цього Javascript? Іноді я зловживаю себе тим, що додаю цілу купу динамічного стилю до чогось через Javascript, коли має набагато більше сенсу використовувати інтелектуальний CSS.

4) Чи варто використовувати інший інструмент? Це те, з чим я стикаюся останнім часом. Є кілька альтернатив JavaScript, наприклад, сценарій кави, який добре обробляється в моєму стеці (Rails 3.1), і я розглядав, чи варто переміщувати туди більшу частину свого коду чи ні.

5) Це хороший код Javascript? Javascript - код, як і будь-який інший код. Чи хороший цей код, як і решта мого коду? Якщо ні, то чому б і ні? Це викидання? Я лінивий?