Уникайте мається на увазі перетворення типів
Щоб уникнути проблем, викликаних мається на увазі перетворенням типів, завжди використовуйте оператори === та! == для перевірки і значень і типів порівнюваних виразів:
Існує інша школа програмування, в рамках якої прийнято вважати, що надмірно використовувати оператор ===. коли досить оператора ==. Наприклад, коли використовується typeof. який повертає рядок, немає причин вимагати жорсткої відповідності. Але JSLint вимагає жорсткої відповідності. І, крім того, код буде виглядати більш цілісним і зменшить кількість роздумів при читанні ( "Даний оператор == використовується навмисно або помилково?").
Уникайте використання eval ()
Використання eval () також може вплинути на безпеку, так як ви можете виконувати код (наприклад, отриманий з мережі), який завдає шкоди. Досить поширена хибна практика роботи з відповіддю JSON на запит AJAX. В даному випадку краще використовувати вбудовані методи браузера для розбору відповіді JSON, щоб вирішити задачу безпечним методом і правильно. Для браузерів, які не підтримують JSON.parse (), можна використовувати бібліотеку з JSON.org.
Використання нового конструктора new Function () схоже на eval (). тому до нього треба ставитися з обережністю. Це потужний інструмент, але часто використовуваний неправильно. Якщо вам абсолютно необхідно використовувати eval (). розгляньте замість нього використання new Function (). Є невелике потенційне перевагу, так як код, який визначається в new Function () повинна запускатись в локальному просторі функції, тому змінні, визначені з директивою var в обумовленому коді НЕ будуть ставати глобальними автоматично. Інший спосіб уникнути автоматичного визначення глобальних змінних - обертати виклик eval () в функцію.
Розглянемо наступний приклад. Тут тільки un залишається глобальною змінною, що забруднює простір імен:
Інша відмінність між eval () і конструктора new Function () полягає в тому, що eval () може перетинатися з ланцюжком простору імен, а виконання Function відбувається в пісочниці. Не важливо, де ви виконуєте Function. вона використовує тільки глобальний простір імен. Тому вона менше забруднює локальне простір імен. У наступному прикладі eval () може отримати доступ і модифікувати змінні в своєму зовнішньому просторі імен, а Function не може (використання Function і new Function ідентично):
Перетворення числа за допомогою parseInt ()
Використовуючи parseInt (), ви можете отримати число з рядка. Функція приймає другий параметр - основа системи числення, який часто опускається. А даремно. Проблема виявляється, коли треба розібрати рядок, що починається з 0: наприклад, частина дати, яку вводять в поле форми. Рядок, що починається на 0, обробляється як вісімкове число (підстава 8), що було визначено в ECMAScript 3 (але змінено в ECMAScript 5). Для виключення несумісності і несподіваних результатів завжди слід використовувати параметр основи системи числення:
В даному прикладі, якщо ви опустите параметр основи системи числення (викличете функцію як parseInt (year)), то отримаєте значення 0. бо "09" мається на увазі як вісімкове число (як ніби ви зробили виклик parseInt (year, 8)), а 09 - неправильне число по підставі 8.
Альтернативні методи перетворення рядка в число:
Дані методи часто виконуються швидше parseInt (). тому що parseInt () робить розбір рядки, а не просте конвертування. Але якщо ви припускаєте, що введення може бути у вигляді "08 hello", то parseInt () поверне число, а інші методи - потерплять невдачу з поверненням NaN.
Вимоги до коду
Важливо скласти вимоги до коду і дотримуватися їх - такий крок зробить код цілісним, передбачуваним і істотно більш легким і зрозумілим. Новий розробник вашої команди, наступний вимоги до коду, істотно швидше увійде в робочий ритм, сприймаючи код, написаний іншими учасниками проекту.
Серйозні сутички і розбирання виникають при обговоренні різних аспектів вимог до коду (наприклад, ніж виконувати відступи - пробілами або табуляціями). Тому при введенні вимог до коду потрібно серйозно готуватися до дискусій. Але вимоги до коду і неухильно дотримання ним дуже важливо для існування і успішного розвитку проекту.
А де слід робити відступи? Правило просте - всюди, де є фігурні дужки. Тобто в тілі функцій, циклах (do, while, for, for-in), операторах if і switch. і властивості object. Наступний код показує приклади використання відступів:
Фігурні дужки
Фігурні дужки завжди слід використовувати, навіть у випадках, коли вони є опціями. Технічно, коли ви маєте тільки один вислів в операторі if або for. фігурні дужки не потрібні, але їх слід використовувати все одно. Вони роблять код більш цілісним і простим для розширення.
Уявімо, що у вас є цикл з одним виразом. Ви можете опустити дужки, що не синтаксичної помилкою:
Але що якщо пізніше буде потрібно додати ще один рядок в тіло циклу?
Друга функція alert знаходиться поза циклом, а відступи можуть зіграти з вами поганий жарт. Найкраще в розрахунку на перспективу завжди використовувати дужки, навіть для однострочного блоку:
Також і для умов:
За рахунок отримання інформації відразу по двох каналах (зір і слух) ефективність навчання значно перевершує навчання по книгах. А домашні завдання і онлайн-тести дозволять вам постійно думати на мові, що вивчається і відразу перевіряти свої знання!
Якщо ви давно хочете як слід вивчити HTML, то у мене для Вас є чудова новина!
Якщо ви вже вивчили HTML і хочете рухатися далі, то наступним кроком буде вивчення технології CSS.
Якщо ви хочете розібратися з поняттями домену і хостингу, навчитися створювати бази даних, закачувати файли сайту на сервер по FTP, створювати піддомени, налаштовувати поштові скриньки для свого сайту і стежити за його відвідуваністю, то цей курс створений спеціально для вас!