Лучше проверить неопределенное свойство или установить как ноль? - PullRequest
Новая
       5

Лучше проверить неопределенное свойство или установить как ноль?

3 голосов
/ 20 декабря 2011

В коде легче объяснить это словами, поэтому, учитывая следующие сценарии: 

// one

var myClass = function(a, b)
{
    if(a) this.a = a;
    if(b) this.b = b;
}

// two

var myClass = function(a, b)
{
    this.a = a || null;
    this.b = b || null;
}

И скажем, у вас есть этот метод, который вызывается постоянно (много раз / секунду) 

myClass.prototype.doSomething = function()
{
    if(this.a) // do something
    if(this.b) // so something else
};

В первом случае вы проверяете неопределенное свойство, а во втором - на существующее, но со значением null.

В каком случае лучше работать в JavaScript?

Ответы [ 2 ]

3 голосов
/ 20 декабря 2011

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

http://jsperf.com/or-pipe-versus-if

Результаты, полученные мной, с использованием операторов IF вместо оператора OR для установки значений по умолчанию, работают на 6% лучше

0 голосов
/ 20 декабря 2011

В обоих случаях проверяется, имеют ли параметры a и b в конструкторе «истинное» значение.Это означает, что в обоих случаях, если вы передаете, скажем, 0 или пустую строку, или (очевидно) ложь, то это значение будет отброшено.Разница в том, что первый случай не создает свойство объекта, а во втором - значение по умолчанию, равное нулю.

В любом случае вам все равно придется проверять свойство, когда вы фактически используете его в doSomething(), и ваш if (this.a) тест будет работать независимо от того, было ли свойство установлено, равно нулю или явно задано неопределенным.

Если вы не хотите возвращать ошибку, еслизначения не указаны. Я бы хотел просто установить их напрямую: 

var myClass = function(a, b)
{
    this.a = a;
    this.b = b;
}

Если значение не указано в параметре, свойство будет создано, но будет установлено значение undefined, которое все равно будет работатьточно так же, как в вашем тесте в doSomething(), но вы бы сохраняли if или ||тест с дополнительным преимуществом не выбрасывать 0, пустую строку или ложные значения.Таким образом, конструктор выглядит лучше ...

Что касается фактического сравнения производительности, то вам действительно нужно настроить надлежащий тест (например, на jsperf.com).Если бы мне пришлось угадывать, я бы сказал, что в среднем версия if(a) this.a=a; будет быстрее, так как она выполняет задание только тогда, когда она правдива, но угадывать производительность - плохой план.Пока вы не протестируете его в разных браузерах , вы не будете знать, что один способ работает быстрее в IE, а другой - в Chrome.Если вы настроили тест, обязательно сравните его с прямым заданием, аналогичным тому, которое я показал выше.

РЕДАКТИРОВАТЬ: я только что увидел другой ответ, который обнаружил разницу в производительности на 6%.Для такой минимальной разницы и учитывая, что, как я уже упоминал выше, разница в производительности может быть обращена вспять в некоторых браузерах, я думаю, что вам лучше кодировать то, что лучше всего подходит для ваших требований к обработке, и просто не беспокоиться оспектакль.В любом случае (или все три способа, если вы включите мой ответ) ясны и просты, и они работают хорошо, они просто не делают одно и то же ...

...