Каковы главные ловушки JavaScript? [закрытый]

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

var foo = { 
    bar: "bar", 
    baz: "baz", 
};

Обратите внимание на комментарий @JulianR: В массивах,IE не терпит сбой напрямую, выбрасывая синтаксическую ошибку, но потерпит неудачу при попытке использовать массив, потому что добавленная запятая заставляет IE думать, что в массиве есть еще один элемент со значением undefined, чем есть на самом деле. Поэтому, если у вас когда-либо возникает ошибка, потому что по какой-то причине последним элементом в массиве является undefined: это запятая.

• Забыть объявить переменные с помощью var
• Непонимание (или непонимание) области действия и закрытия переменных
• Попытка решить неприятные проблемы совместимости, которые команды фреймворков уже решили

Преобразование булевых типов.

''        ==   '0'           //false
0         ==   ''            //true
0         ==   '0'           //true
false     ==   'false'       //false
false     ==   '0'           //true
false     ==   undefined     //false
false     ==   null          //false
null      ==   undefined     //true
" \t\r\n" ==   0             //true

А также разница между null и undefined. Как указано в таблице выше, сравнение null и undefined с == возвращает true, а с === - false. Такое поведение имеет смысл, если понять, что undefined сильно отличается от переменной, имеющей null значение, а что-то, имеющее значение undefined, отличается от чего-то being undefined.

Самые большие трудности, с которыми я сталкиваюсь для новичка, - это понимание контекста выполнения (то есть, что «это» означает, когда и где бы оно ни встречалось) и прототип системы наследования.

• Использование window.onload = init(); вместо window.onload = init;
• Логические эквивалентности (как уже упоминалось)
• Замыкания внутри цикла.
• Использование варианта цикла для варианта цикла in для итерации по массивам.
• Не используется ; , потому что это «необязательно».
• это (просто... в общем :))
• Не использовать var
• Зная, что obj.ref === obj["ref"]

Это не настоящий подводный камень в кодировании, а скорее общая мысль:
Не доверяйте тому, что делает ваш JavaScript, он может быть отключен или даже исправлен обезьянами. Это означает, что никогда не полагайтесь на валидацию на стороне клиента. НИКОГДА.

+ для объединения строк:

var a = '2';
var b = 3;

a * b #  6
a - b # -1
a + b #  23

Для полного понимания всей концепции прототипирования требуется некоторое время, но вот некоторые распространенные подводные камни:

Забывание сбросить свойство конструктора после назначения объекта прототипа:

var Foo() = function ()
{
    this.batz = '...';
};
Foo.prototype = new Bar();
Foo.prototype.constructor = Foo;

Если вы забудете наименьшую строку, new Foo() фактически выполнит Bar().

Еще одна ловушка с прототипированием заключается в итерации по объектам/массивам без фильтрации членов прототипа:

for (var i in obj) {
    if (obj.hasOwnProperty(i)) {
        //stuff...
    }
}

Дополнительное условие пропустит все члены, унаследованные от прототипа obj.

• Создание сайтов, которые не работают без JavaScript
• Использование JavaScript для вещей, которые должны выполняться на стороне сервера
• Использование фреймворков для простых задач, для которых они не требуются

• Замыкания - иначе известные как лямбда-функции - остерегайтесь утечек памяти.
• Браузерные различия, тестирование в Internet Explorer и по крайней мере в одном другом браузере является обязательным. Функции, которые работают только в некоторых браузерах или работают по-разному в разных браузерах, следует избегать. Если это невозможно, то лучше использовать браузерно-специфическое ветвление, определяя особенности браузера, а не его версии. Это повышает вероятность того, что код будет работать в будущих браузерах и в браузерах, которые не были протестированы.
• Увлечение абстракцией фреймворка jQuery или Ajax и незнание основного JavaScript достаточно хорошо, чтобы знать, как исправить проблемы фреймворка.
• Незнание того, что JavaScript может быть использован в некоторой степени для написания ООП кода. Фактически, он может дать вам очень базовый каркас ООП с объектами.
• Чувствительность к регистру (если вы разработчик VB.NET)
• Защита IP - знание того, что вы можете замаскировать JavaScript, но исходный код, который вы выложите, будет очень легко украсть и переделать. Это может даже не быть проблемой в зависимости от сложности клиентского приложения, которое вы пишете.

Я не могу вспомнить больше, но надеюсь, что это поможет.

По общему признанию, я был виноват в некоторых из них в прошлом, для вашего развлечения они выделены жирным шрифтом:

• Незнание неправильного (и очень немногого правильного) использования eval

   eval ( "obj." + prop); 

• Использование с операторами
• Использование parseInt (str, base) без указания аргумента base .
• Использование this в функциях таймера / обратного вызова.
• Использование в таймерах выражений, подобных eval

   setTimeout ("someFunc (myScopedVarWhoops)"); 

• Мышление jQuery - это название языка, который вы кодируете
• Выполнение простых задач JavaScript с использованием фреймворка - $ (1) .plus ( 1) кто-нибудь? ;-)
• Использование continue без увеличения или изменения условной переменной.
• Переполнение глобального пространства имен переменными
• Забвение var в или до для операторов. for (i = 0; i <10; i ++)
• Использование обфускатора и простое выполнение его в вашем коде
• Не совсем ловушка, но бессмысленно - условие возврата? true: false; вместо return condition;
• Отсутствие комментариев к вашему коду действительно применимо ко всем языкам.
• Использование операторов try ... catch ... finally для обнаружения ошибок вместо использования операторов if для проверки переменных.
• Глупая попытка остановить "просмотр источника", блокируя щелчки правой кнопкой мыши на ваших страницах (я был молод * рыдает * !)
• Использование {0: "Foo" , 1: «Бар», 2: «Foobar»} вместо [«Foo», «Bar», «Foobar»]
• Использование parseInt () при вводе пользователем

   parseInt ("1,000") // -> 1, неверно!
  + "1,000" // -> NaN, правильно! 

Некоторые уже упоминались:

• По возможности не использовать операторы строгого равенства ( === )
• Установка обработчиков событий на возвращаемое значение функции вместо ссылки на указанную функцию
• Not ; правильное завершение операторов
• Использование for ... в циклах на массивах

Возможно, придумаю еще кое-что после того, как я высплюсь: -)