Пишем высококачественный JavaScript код. Часть 3 из 4

Третья часть урока, посвященного коду JavaScript. Простые рекомендации для создания легко поддерживаемого проекта. 

Избегайте подразумеваемого преобразования типов



JavaScript подразумевает преобразование типов переменных при их сравнении. Поэтому такие сравнения как false == 0 или "" == 0 возвращают true.

Чтобы избежать проблем, вызванных подразумеваемым преобразованием типов, всегда используйте операторы === и !== для проверки и значений и типов сравниваемых выражений:

Code
var zero = 0;
if (zero === false) {
  // код, размещенный здесь не выполнится, так как zero является 0, а не false
}

// плохо
if (zero == false) {
  // данный блок кода будет всегда выполняться
}


Существует другая школа программирования, в рамках которой принято считать, что чрезмерно использовать оператор ===, когда достаточно оператора == . Например, когда используется typeof, который возвращает строку, нет причин требовать жесткого соответствия. Но JSLint требует жесткого соответствия. И, кроме того, код будет выглядеть более целостным и уменьшит количество размышлений при чтении ("Данный оператор == используется намеренно или по ошибке?").

Избегайте использования eval()



Функция eval() берет произвольную строку и выполняет ее как код JavaScript. Если код известен (а не определяется в ходе выполнения процесса), вообще нет причин использовать eval(). Если код динамически генерируется во время выполнения, то часто возможно достичь цели лучшим методом, чем использование eval().Например, использование записи с квадратными скобками для динамического доступа к свойствам лучше и проще:

Code
// плохо
var property = "name";
alert(eval("obj." + property));

// предпочтительно делать так
var property = "name";
alert(obj[property]);



Использование eval() также может повлиять на безопасность, так как вы можете выполнять код (например, полученный из сети), который наносит ущерб. Достаточно распространенная порочная практика работы с ответом JSON на запрос AJAX. В данном случае лучше использовать встроенные методы браузера для разбора ответа JSON, чтобы решить задачу безопасным методом и правильно. Для браузеров, которые не поддерживают JSON.parse(), можно использовать библиотеку с JSON.org.

Также важно помнить, что передача строк функциям setInterval(), setTimeout(), и конструктору Function() в большинстве случаев похоже на использование eval(). Следовательно, таких действий надо избегать. На заднем плане JavaScript оценивает и выполняет строки, которые вы передаете, как программный код:

Code
// плохо
setTimeout("myFunc()", 1000);
setTimeout("myFunc(1, 2, 3)", 1000);

// предпочтиетльно
setTimeout(myFunc, 1000);
setTimeout(function () {
  myFunc(1, 2, 3);
}, 1000);


Использование нового конструктора new Function() похоже на eval(), поэтому к нему надо относиться с осторожностью. Это мощный инструмент, но часто используемый неправильно. Если вам абсолютно необходимо использовать eval(), рассмотрите вместо него использование new Function(). Есть небольшое потенциальное преимущество, так как код, определяемый в new Function(), будет запускаться в локальном пространстве функции, поэтому переменные, определенные с директивой var в определяемом коде не будут становиться глобальными автоматически. Другой способ избежать автоматического определения глобальных переменных - оборачивать вызов eval() в функцию.

Рассмотрим следующий пример. Здесь только un остается глобальной переменной, загрязняющей пространство имен:

Code
console.log(typeof un); // "undefined"
console.log(typeof deux); // "undefined"
console.log(typeof trois); // "undefined"

var jsstring = "var un = 1; console.log(un);";
eval(jsstring); // Записывает "1"

jsstring = "var deux = 2; console.log(deux);";
new Function(jsstring)(); // Записывает "2"

jsstring = "var trois = 3; console.log(trois);";
(function () {
  eval(jsstring);
}()); // Записывает "3"

console.log(typeof un); // число
console.log(typeof deux); // undefined
console.log(typeof trois); // undefined


Другое отличие между eval() и конструктора new Function()заключается в том, что eval() может пересекаться с цепочкой пространства имен, а выполнение Function происходит в песочнице. Не важно, где вы выполняете Function, она использует только глобальное пространство имен. Поэтому она меньше загрязняет локальное пространство имен. В следующем примере eval() может получить доступ и модифицировать переменные в своем внешнем пространстве имен, а Function не может (использование Function и new Function идентично):

Преобразование числа с помощью parseInt()



Используя parseInt(), вы можете получить число из строки. Функция принимает второй параметр - основание системы счисления, который часто опускается. А зря. Проблема проявляется, когда надо разобрать строку, начинающуюся с 0: например, часть даты, которую вводят в поле формы. Строка, которая начинается на 0, обрабатывается как восьмеричное число (основание 8 ), что было определено в ECMAScript 3 (но изменено в ECMAScript 5). Для исключения несовместимости и неожиданных результатов всегда следует использовать параметр основания системы счисления:

Code
var month = "06",
  year = "09";
month = parseInt(month, 10);
year = parseInt(year, 10);


В данном примере, если вы опустите параметр основания системы счисления ( вызовете функцию как parseInt(year)), то получите значение 0, потому что "09” подразумевается как восьмеричное число (как будто вы сделали вызов parseInt( year, 8 )), а 09 - неправильное число по основанию 8.

Альтернативные методы преобразования строки в число:

Code
+"08" // результат 8
Number("08") // 8


Данные методы часто выполняются быстрее parseInt(), потому что parseInt() делает разбор строки, а не простое конвертирование. Но если вы предполагаете, что ввод может быть в виде "08 hello”, то parseInt() вернет число, а другие методы - потерпят неудачу с возвратом NaN.

Требования к коду



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

Серьезные стычки и разборки возникают при обсуждении различных аспектов требований к коду (например, чем выполнять отступы - пробелами или табуляциями). Поэтому при введении требований к коду нужно серьезно готовиться к дискуссиям. Но требования к коду и неукоснительно следование им очень важно для существования и успешного развития проекта.

Отступы



Код без отступов очень трудно читать. Очень важно установить стандарт на отступы.

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

А где следует делать отступы? Правило простое - везде, где есть фигурные скобки. То есть в теле функций, циклах (do, while, for, for-in), операторах if и switch, и свойствах object . Следующий код показывает примеры использования отступов:

Code
function outer(a, b) {
  var c = 1,
  d = 2,
  inner;
  if (a > b) {
  inner = function () {
  return {
  r: c - d
  };
  };
  } else {
  inner = function () {
  return {
  r: c + d
  };
  };
  }
  return inner;
}


Фигурные скобки



Фигурные скобки всегда следует использовать, даже в случаях, когда они являются опциями. Технически, когда вы имеет только одно выражение в операторе if или for, фигурные скобки не требуются, но их следует использовать все равно. Они делают код более целостным и простым для расширения.

Представим, что у вас есть цикл с одним выражением. Вы можете опустить скобки, что не будет синтаксической ошибкой:

Code
// плохо
for (var i = 0; i < 10; i += 1)
  alert(i);


Но что если позже потребуется добавить еще одну строку в тело цикла?

Code
// плохо
for (var i = 0; i < 10; i += 1)
  alert(i);
  alert(i + " is " + (i % 2 ? "odd" : "even"));


Вторая функция alert находится вне цикла, а отступы могут сыграть с вами плохую шутку. Лучше всего в расчете на перспективу всегда использовать скобки, даже для однострочного блока:

Code
// предпочтительно
for (var i = 0; i < 10; i += 1) {
  alert(i);
}


Также и для условий:

Code
// плохо
if (true)
  alert(1);
else
  alert(2);

// предпочтительно
if (true) {
  alert(1);
} else {
  alert(2);
}


Положение открытой скобки



Часто возникает вопрос, где располагать открытую скобку - на той же строке или на следующей?

Code
if (true) {
  alert("Сообщение!");
}


Или

Code
if (true)
{
  alert("Сообщение");
}


В данном примере положение скобки является вопросом предпочтения. Но есть случаи, когда программа будет вести себя по-разному в зависимости от положения скобки. Такая ситуация возникает из-за механизма вставки точки с запятой - JavaScript не разбирается, когда вы решили не заканчивать строку правильно, и добавит точку с запятой за вас. Данное поведение может вызвать проблемы, когда функция возвращает литеральный объект, а открытая скобка находится на следующей строке:

Code
// предупреждение: неожиданный return
function func() {
  return
  // далее следует блок кода, который никогда не выполнится
  {
  name : "Batman"
  }
}


Если вы ожидали, что данная функция вернет объект со свойством name, то будет неприятно удивлены. По причине подразумеваемой точки с запятой функция вернет undefined. Предыдущий код эквивалентен следующему блоку:

Code
// предупреждение: неожиданный return
function func() {
  return undefined;
  // далее следует блок кода, который никогда не выполнится
  {
  name : "Batman"
  }
}


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

Code
function func() {
  return {
  name : "Batman"
  };
}


Обратите внимание на точку с запятой. Так же, как и фигурные скобки, всегда следует использовать точку с запятой, даже когда она подразумевается конструкцией кода JavaScript. Это не только дисциплинирует и соответствует более строгому подходу к кодированию, но и помогает избежать двусмысленных ситуаций, как в вышеприведённом примере.

  • FalleN

  • 2336

  • 1

  • 0
Теги: код, javascript

Ссылки на статью:

Похожие статьи: