2015-08-19 1 views
0

Итак, у меня есть модульный компонент ... что означает, что он может появляться в нескольких приложениях. Все они являются внутренними, поэтому поведение компонента может «расти» по мере добавления дополнительных продуктов.Лучшая проверка работоспособности для переменной JavaScript

В целом, есть, вероятно, лучше дизайн, чтобы сделать то, что я хочу сделать, но в интересах быстрого развития, я делаю это:

function someFunc(opt) { 
    if(typeof(taEnvironment) !== "undefined")) { 
    if(taEnvironment === "webApp") { 
     // do stuff when a variable taEnvironment exists and its value is "webapp" 
    } 
    } 
} 

Это утомительно делать это каждый раз, когда мне нужно проверить на «webApp», поэтому я хочу отвлечь его немного. Предлагаемый рефакторинг выглядит как это:

function someFunc(opt) { 
    if(environment("webApp")) { 
     // do stuff when a variable taEnvironment exists and its value is "webapp" 
    } 
} 

//...elsewhere in the same module... 
function environment(env) { 
    var envSet = false; 
    if(typeof(env) === "undefined") { 
    return envSet; 
    } 
    if(typeof(taEnvironment) !== "undefined")) { 
    if(taEnvironment === env) { 
     envSet = true; 
    } 
    return envSet; 
} 

2-часть вопроса:

  1. Даже просто глядя на первый не переработан фрагмент кода; это обычный способ проверить такие переменные? Вы не можете комбинировать проверку типа с проверкой значения, потому что если она не определена, вы получите отказ при проверке значения. Поэтому сначала я проверяю typeof для «undefined», а затем вложен внутри, я проверяю значение. Это SEEMS, как единственный способ сделать это, но если есть лучший образец, я все уши!

  2. В зависимости от ответа на # 1 - если # 1 является разумным или ожидаемым способом делать вещи, имеет ли смысл предлагаемый рефактор? Или я не создаю каких-либо значительных преимуществ?

+0

Полагаю, у вас есть некоторое использование для этого, где вы не проходите литераловую строку, а 'env' может быть' undefined'. – crush

+0

Несмотря на то, что кажется, что вы не знаете, где будет объявлено 'taEnvironment', я бы все же объявлял его в самом внешнем закрытии, содержащем весь код, если это вообще возможно. 'Typeof foo ===" undefined "' hack просто слишком болезнен и почти всегда можно избежать. Я имею в виду, если вы можете создать функцию в той же области, что и ответы ниже, почему вы не можете просто «var taEnvironment;» вместо этого? –

+0

var taEnvironment объявляется внутри отдельного приложения где-то. Проверка работоспособности предназначена для проектов, в которых нет необходимости; то разработчику не обязательно нужно объявлять его. Объявляемая taEnvironment считается факультативной. @crush: не совсем. Это, наверное, слишком много. ;) –

ответ

1

Это имеет смысл, хотя есть некоторые шаги, которые вы можете предпринять, чтобы облегчить будущие поколения.

Когда многоразовые функция возвращает логическое значение, вы можете сделать это очевидным, поставив функцию в форме вопроса, например isEnvironment(x) вместо просто неоднозначного environment(x)

Вы можете также упростить саму функцию, просто возвращая оценку условия taEnvironment === env вместо установки переменной и затем возвращающей эту переменную.

Вот очищены версия вашей функции:

function isEnvironment(env) { 
    if(typeof taEnvironment === "undefined") { 
    return false; 
    }else{ 
    return taEnvironment === env; 
    } 
} 
1

это обычный способ проверки для таких переменных?

Да.

Имеет ли смысл предлагаемый рефактор?

Да. Вы можете также использовать try...catch, но это действительно до вас:

function environment(env) { 
    try { 
    return typeof env !== 'undefined' && taEnvironment === env; 
    } catch (e) { 
    return false; 
    } 
} 

Примечание: typeof не функция, это оператор.

+0

Я бы смутился, чтобы рассказать вам, сколько раз я рассматривал typeof как функцию ... Я, должно быть, сделал это раз несколько лет назад, и это сработало (круглые скобки просто неактуальны), поэтому я просто так делал это когда-либо так как ... Спасибо за ваш ответ, а также предложение try/catch! –

2

Вы можете проверить все условия в то же время.Оператор && остановится на первое false результата:

function environment(env) { 
    return typeof taEnvironment !== 'undefined' && 
      taEnvironment === env; 
} 
+0

Этот 'typeof env! == 'undefined' &&' не нужен. Параметр определенно объявлен, и если первый тест '! ==' проходит, то если 'taEnvironment === env' также проходит, вы автоматически узнаете, что' env' не был 'undefined'. –

+0

Да, его можно удалить. Отредактировано, спасибо. – manji

+0

Супер чистый. Мне нравится, что это простой однострочный возврат. Этот ответ научил меня чему-то эффективному коду. Я в конечном счете все еще собираюсь с явной проверкой состояния, но я точно получил что-то из этого ответа. –

0

Недавно я также получил пробег из hasOwnProperty, когда «переменный» Я хочу, чтобы проверить, не является дискретным переменным и сам по себе, а скорее ожидаемое свойство объекта.

Так что, учитывая какой-то объект флага:

flags = { 
    appStarted: true, 
    userAuthenticated: true 
} 

я, возможно, потребуется, чтобы увидеть, если пользователь сделал что-то. Я мог бы либо инициализировать объект, чтобы иметь thingDone: false, а затем проверить истинность в моем условном; или я просто не мог инициализировать по умолчанию и проверьте, чтобы увидеть, если он был установлен:

if (flags.hasOwnProperty("thingDone")

Этот ответ выходит за рамки первоначального вопроса (который был специально о проверке переменных), но он может оказаться полезным для тех, кто в противном случае проверил бы if(typeof flags.thingDone === "undefined"). Это шесть из полутора десятков других (то же самое), но я нахожу его более лично семантически значимым. Ваш пробег может отличаться.

Смежные вопросы