Тернарный (условный) оператор и стиль - PullRequest
5 голосов
/ 06 ноября 2010

Если вы ненавидите троичного условного оператора в первую очередь, вам не нужно отвечать;)

Я обычно вижу это в тандеме с выражением присваивания, например:

var foo = (some_condition) ? then_code : else_code;

Однако я хотел бы использовать его для замены простого кода, например:

if(some_condition) {
  do_something_simple;
} else {
  do_something_else;
}

и вместо этого:

(some_condition) ? do_something_simple : do_something_else;

Я, вероятно, буду делать это в JavaScript. В приведенном выше примере он возвращает значение undefined, поэтому ему не требуется присваивание. Мне нравится сэкономленное пространство, но мне интересно, что люди думают об этом типе использования, так как, опять же, я обычно вижу только троичный, используемый с заданием.

РЕДАКТИРОВАТЬ: я видел ответы, ссылаясь на "скрытые намерения". Классически используемый в выражениях, как это скрывает намерение больше, чем использование в выражении? Особенно в динамическом языке, где можно увидеть использование троичных операторов повсеместно?

Ответы [ 4 ]

3 голосов
/ 06 ноября 2010

Условный оператор обычно должен использоваться в выражениях - выражениях, производящих значения, - и его лучше не использовать в качестве замены оператора if / then / else. При случайном использовании особых проблем не возникает; Систематическое использование, я думаю, что это будет скрывать смысл кода от читателей.

2 голосов
/ 06 ноября 2010

Это моё личное предпочтение:

В этом случае я думаю, что это входит в мысль "код написан для людей, чтобы читать, а не для машины".Поскольку большинство людей не пишут if then else таким образом, это может привести к путанице, увеличению времени на понимание кода и, возможно, к появлению ошибок - если кто-то видел это и думал, что ни к чему не присваивается, его нужно «оставить»Если мы переписываем код, и давайте удалим его, тогда очистка кода станет введением ошибки.


Цитируется из: Программы должны быть написаны для людей, которые могут читать, и только для машин - только для исполнения.

- из «Структуры и интерпретации компьютерных программ» Абельсона и Суссмана

Чарли Мартин сказал Код для компьютеров или для людей? :

Если компьютерне запускается, он сломанЕсли люди не смогут прочитать это, оно будет сломано.Вскоре.

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

0 голосов
/ 06 ноября 2010

Тернарный оператор хорош для зрелых / стабильных программ, но не в постоянно меняющейся среде.Предположим, вы должны добавить дополнительный код в любую ветку - это намного проще, если вы используете синтаксис if / then / else.

0 голосов
/ 06 ноября 2010

Вопрос глупый, потому что вы говорите о JavaScript, который допускает странные вещи.

Тернарный условный оператор в классическом языке программирования требует, чтобы оба случая были выражениями, а не операторами. Таким образом, вы можете использовать его для выбора между двумя выражениями в соответствии с логическим условием, но не как обычная ветвь if / else.

в языке, подобном JavaScript, эта разница исчезает, потому что оператор фактически возвращает значение, так что вы можете использовать троичный и просто отбросить значение undefined , возвращаемое вашим оператором.

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

...