Какие анти-шаблоны существуют для JavaScript?

Я нахожу, что не делать, это трудный урок для изучения, чем то, что нужно делать.

По моему опыту, то, что отделяет эксперта от промежуточного, - это способность выбирать из различных, казалось бы, эквивалентных способов сделать одно и то же.

Итак, когда дело доходит до JavaScript , какие вещи вы не должны делать и почему?

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

Ответы

Ответ 1

Язык:

  • Пространство имен, загрязняющее, создавая большой след переменных в глобальном контексте.

  • Обработчики событий привязки в форме "foo.onclick = myFunc" (нерационально, должен использоваться attachEvent/addEventListener).

  • Использование eval практически в любом контексте, отличном от JSON

  • Почти все использование document.write(используйте методы DOM, такие как document.createElement)

  • Прототипирование объекта Object (BOOM!)

  • Небольшой это, но выполнение больших количеств строковых конкат с "+" (создание массива и объединение его гораздо более эффективно)

  • Обращаясь к несуществующей константе undefined

Дизайн/Развертывание:

  • (обычно), не поддерживающий поддержку noscript.

  • Не упаковывать ваш код в один ресурс

  • Ввод встроенных (то есть тело) скриптов в верхней части тела (они блокируют загрузку)

Спецификация Ajax:

  • не указывая начало, конец или ошибку запроса пользователю

  • опрос

  • передача и разбор XML вместо JSON или HTML (при необходимости)

edit: Я продолжаю думать больше!

Ответ 2

Помимо уже упомянутых...

  • Использование конструкции for..in для перебора массивов
    (итерации по методам массивов и индексам)

  • Использование встроенного Javascript как <body onload="doThis();">
    (негибкий и предотвращает несколько прослушивателей событий)

  • Использование конструктора 'Function()' (плохо по тем же причинам eval() плохо)

  • Передача строк вместо функций setTimeout или setInterval
    (также использует eval() внутренне)

  • Опираясь на неявные утверждения, не используя точки с запятой
    (плохая привычка подбирать и может привести к неожиданному поведению)

  • Использование/*.. */для блокировки строк кода
    (может мешать литералам регулярных выражений, например: /* /.*/ */)

    < евангелизация > И, конечно, не используя Prototype;) </евангелизация >

Ответ 3

Самым большим для меня не понимание самого языка программирования JavaScript.

  • Использование иерархии объектов и создание очень глубоких цепочек наследования. Мелкие иерархии отлично работают в большинстве случаев в JS.
  • Не понимая ориентацию объектов на основе прототипов и вместо этого создавая огромное количество лесов, чтобы заставить JS вести себя как традиционные языки OO.
  • Без необходимости использовать парадигмы OO, когда процедурное/функциональное программирование может быть более кратким и эффективным.

Затем есть те, которые используются во время выполнения браузера:

  • Не использовать хорошие шаблоны событий, например, делегирование событий или шаблон наблюдателя (pub/sub) для оптимизации обработки событий.
  • Выполнение частых обновлений DOM (например,.appendChild в цикле), когда узлы DOM могут быть в памяти и добавлены за один раз. (ОГРОМНОЕ повышение эффективности).
  • Использование библиотек для выбора узлов со сложными селекторами, когда можно использовать собственные методы (getElementById, getElementByTagName и т.д.). В наши дни это становится проблемой, но стоит упомянуть.
  • Расширение объектов DOM, если вы ожидаете, что сторонние скрипты будут на той же странице, что и ваша (вы в конечном итоге сожжете друг друга).

И, наконец, проблемы с развертыванием.

  • Не уменьшать ваши файлы.
  • Конфигурации веб-сервера - не gzipping ваши файлы, а не кэширование их разумно.

<plug> У меня есть советы по оптимизации на стороне клиента , которые охватывают некоторые из вещей, упомянутых выше, и многое другое, в моем блоге. </plug>

Ответ 4

Несколько вещей прямо на моей голове. Я отредактирую этот список, когда думаю больше.

  • Не загрязнять глобальное пространство имен. Вместо этого организуйте вещи в объектах;
  • Не пропускайте переменные var. Это загрязняет глобальное пространство имен и может вызвать у вас проблемы с другими такими сценариями.

Ответ 5

  • обнаружение браузера (вместо проверки того, существуют ли конкретные методы/поля, которые вы хотите использовать)
  • используя alert() в большинстве случаев

см. также Crockford "Javascript: The Good Parts" для других вещей, которых следует избегать. (edit:), он немного строг в некоторых своих предложениях, таких как использование "===" над "==", поэтому возьмите их с чем-то вроде соли соли для вас)

Ответ 6

любое использование 'with'

с (document.forms [ "mainForm" ]. элементы) {   input1.value = "junk";
  input2.value = "junk";   }

Ответ 7

любая ссылка на

document.all

в вашем коде, если только он не находится в специальном коде, только для IE, чтобы преодолеть ошибку IE. (cough document.getElementById() кашель)

Ответ 8

Не использовать среду на основе сообщества для выполнения повторяющихся задач, таких как манипуляция DOM, обработка событий и т.д.

Ответ 9

Плохое использование позиционирования скобок при создании операторов

Вы всегда должны положить скобу после инструкции из-за автоматической вставки точки с запятой.

Например:

function()
{
    return
    {
        price: 10
    }
}

сильно отличается от этого:

function(){
    return{
        price: 10
    }
}

Becuase в первом примере, javascript вставляет точку с запятой для вас, фактически оставляя вас с этим:

function()
{
    return;    // oh dear!
    {
        price: 10
    }
}

Использование setInterval для потенциально длительных задач.

Вы должны использовать setTimeout вместо setInterval для случаев, когда вам нужно что-то делать повторно.

Если вы используете setInterval, но функция, которая выполняется в таймере, не завершена к моменту окончания следующего таймера, это плохо. Вместо этого используйте следующий шаблон, используя setTimeout

function doThisManyTimes(){
    alert("It happening again!");
}

(function repeat(){
    doThisManyTimes();
    setTimeout(repeat, 500);
})();

Это очень хорошо объясняется Paul Irish на его 10 вещей, которые я узнал из источника jQuery видео

Ответ 10

Эффективное кэширование редко выполняется:

  • Не храните на сервере копию библиотеки (jQuery, Prototype, Dojo), если вы можете использовать общий API, например API библиотек Google для ускорения загрузки страницы.
  • Объедините и уменьшите все свои script, которые вы можете добавить в один
  • Используйте mod_expires, чтобы дать всем вашим сценариям бесконечный срок службы кеша (никогда не загружать)
  • Верните свои имена файлов javascript, чтобы новое обновление было принято клиентами без необходимости перезагрузки/перезапуска (то есть myFile_r231.js или myFile.js? r = 231)