2014-01-17 3 views
-2

Иногда я использую тернарные выражения для упрощения &, уменьшая длину моего кода.Тернарные высказывания в Javascript: ловушки без назначения?

Тройные операторы традиционно используются для присвоения значения переменного, но в JS я также могу написать тройные заявления без каких-либо уступок для выполнения отличаясь результатов на основе булевого ответ на вопрос - пример:

anyVariable > someValue ? 
    funcOne(anyVariable): 
    funcTwo(anyVariable); 

Этот код не вызывает ошибок, но jsLint жалуется, что он видел выражение, где ожидалось назначение или вызов функции.

Есть ли какие-либо подводные камни или потенциальные проблемы, о которых я должен знать при использовании тернарных утверждений (в Javascript) таким образом?

+1

Я бы избегал этого только на том основании, что он читает плохо, а не стандартную конструкцию if/else. – mccainz

+0

Использование трехмерных выражений вместо if/else может быть технически возможным и «короче», но, конечно же, не улучшает ваш код. Потенциальная проблема заключается в том, что любой, кто смотрит ваш код (и это может включать вас через 6 месяцев), не будет понимать его так близко, как если бы вы использовали соответствующую конструкцию. Кроме того, после того, как вы уменьшите свой JS, он все равно не намного короче. – veddermatic

+0

Не полный ответ, но на самом деле мне довелось проверить производительность между стандартной структурой 'if/then' и ее тройным эквивалентом вчера, для другого вопроса SO, и значения производительности были очень похожими, с очень небольшим преимуществом при использовании 'if/then' с некоторыми браузерами. – talemyn

ответ

2

Здесь не должно быть никаких подводных камней. Рассмотрите следующее сообщение:

b = a = 10; 

Мы можем опустить часть инструкции "b =" без каких-либо проблем. И тот же случай для тройных высказываний.

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

// user made a typo on the first line. but this code has correct syntax 
b = 10 + 
a > 10 ? fun(20) : fun(0); 

// same scenario using if-else will generate a compilation error which is preferred. 
b = 10 + 
if (a>10) { 
    fun(20); 
} 
else { 
    fun(0); 
} 
+0

Благодарим за предоставление потенциальной ошибки кода вместо мнений о читаемости/правильности. – 1nfiniti

0

Я бы избегал этого, если вы используете его неправильно, то это вызовет ошибки (я видел invalid left hand assignment среди других). Если вы используете хороший мини-инструмент (например, Uglify), он будет делать все это для вас при запуске процесса сборки, что позволит вашему коду разработки читать и легко.

Я хотел бы использовать его только для назначения.

1

JS (L | H) int собирается жаловаться на это, потому что это просто выражение, а не утверждение. В подобных случаях, это «лучше» (аргументированный), чтобы использовать, если:

if(anyVariable > someValue){ 
    funcOne(anyVariable); 
} else { 
    funcTwo(anyVariable); 
} 

редактировать Если краткость это цель, которую вы всегда можете опустить фигурные скобки:

if(anyVariable > someValue) funcOne(anyVariable) 
else funcTwo(anyVariable); 

/

Бонус здесь в том, что ваш код более читабельен (поскольку это все назначения или вызовы функций), и если вам нужно продлить или выполнить более одной операции в eac h, вы настроены на это.

Где тройной оператор используется хорошо, однако, в назначениях:

var thisVariable = someValue > thatValue ? someValue : thatValue; 

Это пройдет линт, и заявление, в то время как лаконичны, все еще довольно читаемое, однако, при тестировании против «falsey "ценности, я предпочитаю:

var thisVariable = someValue || thatValue; 

someValue Если это "falsey", он установит thisVariable в thatValue.

+0

Что делать, если someValue не является ложным? В качестве примера предположим, что someValue = 10. Я также не согласен с читабельностью. Я думаю, что троичный пример, который я представил, очень читабельен и более консенсус, чем if/else для ситуаций с одним заявлением. Я согласен с выгодой от расширяемости, но TBH я действительно использую это только в ситуациях с одним заявлением, где не требуется делать больше. Принимая во внимание, что оператор вызывает функции, любые избыточные утверждения, которые вам нужно выполнить в выражении if, могут быть делегированы внутри функции. – 1nfiniti

+0

@mikeyUX, если 'someValue' не является ложным, в этом последнем примере' thisVariable' будет установлен в 'someValue'. Булевы операторы в JS являются короткозамкнутыми - как только условие выполнено, остальная часть выражения не будет оценена. Поскольку 'someValue' не является ложным, он просто возвращает и устанавливает для этого' thisVariable'. – tkone

+0

@mikeyUX как для удобочитаемости, поэтому я включил термин аргументативный. Для моей команды и моего кода мы не разрешаем использовать тернар как таковой. Помните: терминология может сделать создание кода «проще», но это не упрощает его обслуживание. Чем более явным вы являетесь в своем коде, тем легче будет определить, что именно было сделано вами в будущем. – tkone

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