Например, вы бы предпочли эту однострочную
int median(int a, int b, int c) {
return (a<b) ? (b<c) ? b : (a<c) ? c : a : (a<c) ? a : (b<c) ? c : b;
}
или решение if / else, включающее несколько операторов return?
Когда ?:
уместно, а когда нет? Следует ли этому учить или скрывать от начинающих?
operators
conditions
оборота FredOverflow
источник
источник
Ответы:
Нет, это благословение.
Когда это что-то настолько простое, вы не хотите тратить много строк.
Когда читаемость и ясность кода страдают, а вероятность ошибки из-за недостаточного внимания возрастает, например, со многими связанными операторами, как в вашем примере.
Лакмусовый тест - это когда вы начинаете сомневаться в том, что ваш код легко читается и поддерживается в долгосрочной перспективе. Тогда не делай этого.
источник
myVar = someExpression ? false : true;
(someExpression ? var1 : var2)++
:-)Я думаю, что необъявленный троичный оператор (т. Е. Оператор, в котором он используется только один раз) - это хорошо, но если вы вкладываете больше одного, его становится несколько трудно читать.
источник
Когда это?
а когда нет?
Если у вас есть какие-то логические или функциональные вызовы внутри троичного выражения, вам будет ужасно на это смотреть.
источник
Одно отличие, на которое (я думаю) никто не указал, заключается в том, что if-else не может вернуть значение, тогда как троичный оператор может.
Исходя из F #, мне иногда нравится использовать троичный оператор для имитации сопоставления с образцом.
против
источник
var res = function() {switch(input) {case 1: return "1"; case 2: return "2"; ...}}()
эмулировать переключатели как выражения.expression
и ,statement
но я всегда беспокоюсь я получу их навыворот и сделать дураком :)const
переменных, которые не могут быть изменены позже.Пример (IMHO) правильного использования:
Это приводит к более удобочитаемому коду, чем наличие двух различных операторов печати. Вложенные примеры зависят: (понятно? Да: нет)
источник
Абсолютно не зло. На самом деле, это чисто , а если-то-иначе нет.
В функциональных языках, таких как Haskell, F #, ML и т. Д., Утверждения if-then-else считаются злыми.
Причина этого в том, что любое «действие», такое как императивный оператор if-then-else, требует, чтобы вы отделяли объявление переменной от ее определения и вводили состояние в вашу функцию.
Например, в следующем коде:
против
Первый имеет два преимущества, кроме того, что он короче:
x
является константой, и поэтому дает гораздо меньше шансов на появление ошибок, и потенциально может быть оптимизировано так, как никогда не может быть второй.x
должно быть типаParity
.Заблуждение, что в функциональных языках троичный оператор часто называют if-then-else. В Хаскеле, вы могли бы сказать
x = if n mod 3 == 1 then Odd else Even
.источник
Именно это выражение заставляет мои глаза болеть; Я бы набросился на любого разработчика в моей команде, который использовал его, потому что он не поддерживается.
Тернарные операторы не являются злыми при правильном использовании. Они даже не должны быть отдельными строками; Длинный, хорошо отформатированный, может быть очень ясным и понятным:
Мне нравится это лучше, чем эквивалентная цепочка if / then / else:
Я переформатирую их в:
если условия и назначения позволяют легкое выравнивание. Тем не менее, я предпочитаю троичную версию, потому что она короче и не имеет такого большого шума вокруг условий и заданий.
источник
ReSharper в VS.NET иногда предлагает заменить
if...else
на?:
оператора.Кажется, что ReSharper предлагает, только если условия / блоки ниже определенного уровня сложности, в противном случае он остается неизменным
if...else
.источник
Это можно переформатировать так, чтобы оно выглядело так же красиво, как комбинация if / else:
Но проблема в том, что я не совсем уверен, правильно ли я понял отступ, чтобы представлять, что на самом деле произойдет. :-)
источник
if-else
структура. Ключ форматирования.Отнюдь не злой, троичный оператор - находка.
Это наиболее полезно, когда вы хотите принять решение во вложенном выражении. Классическим примером является вызов функции:
В вашем конкретном примере троичный является почти безвозмездным, так как это выражение верхнего уровня под a
return
. Вы можете поднять условное выражение до уровня оператора, не дублируя ничего, кромеreturn
ключевого слова.NB Ничто никогда не сделает этот конкретный алгоритм для медианы легко читаемым.
источник
printf("I see %d evil construct%s in this program\n", n, "s" unless (n == 1) "s");
Если не принимать во внимание «злые» аргументы, то по своему опыту я обнаружил высокую корреляцию между использованием программистом тернарного оператора и вероятностью того, что его или ее вся кодовая база будет трудна для чтения, отслеживания и обслуживания (если это не будет явным недокументированным). Если программист больше заботится о сохранении нескольких 1-2-символьных строк, чем кто-либо, способный понять его или ее код, то любая незначительная путаница в понимании троичного утверждения обычно является верхушкой айсберга.
Тернарные операторы привлекают магические числа, как s ** t привлекает мух.
Если бы я искал библиотеку с открытым исходным кодом для решения конкретной проблемы, и я увидел код, такой как троичные операторы оригинального плаката, в кандидате на указанную библиотеку, предупреждающие звонки начали бы звучать в моей голове, и я бы начал думать о том, чтобы продолжить в какой-то другой проект, чтобы позаимствовать у.
источник
Вот пример того, когда оно является злом:
Это сбивает с толку и расточительно. Компилятор может оптимизировать второе выражение (oldValue = oldValue), но почему кодер сделал это в первую очередь?
Еще один унылый:
Некоторые люди просто не должны быть программистами ...
Грег говорит, что эквивалентно, если заявление «шумно». Это если вы пишете это с шумом. Но это то же самое, если можно записать как:
Который не шумнее, чем троичный. Интересно, есть ли в тройных сокращениях; все выражения оцениваются?
источник
if (x != 0) x = 0;
...Зло? Смотри, они просто разные.
if
это утверждение.(test ? a : b)
это выражение. Они не одно и то же.Существуют выражения для выражения значений. Заявления существуют для выполнения действий. Выражения могут появляться внутри операторов, но не наоборот. Таким образом, вы можете использовать троичные выражения в других выражениях, например, для терминов в суммировании, или для аргументов метода, и так далее. Вам не нужно , но вы можете, если хотите . В этом нет ничего плохого. Некоторые люди могут сказать, что это зло, но это их мнение.
Одно из значений троичного выражения заключается в том, что оно позволяет обрабатывать как истинные, так и ложные случаи.
if
заявления не делают.Если вы беспокоитесь о читабельности, вы можете отформатировать их.
Каким-то образом «зло» вползло в словарь программирования. Я хотел бы знать, кто первым бросил это. (На самом деле, у меня есть подозреваемый - он в Массачусетском технологическом институте.) Я бы предпочел, чтобы у нас были объективные причины для оценочных суждений в этой области, а не только вкус людей и их имена.
источник
Это имеет место. Я работал во многих компаниях, где уровень квалификации разработчиков варьируется от ужасного до волшебного. Так как код должен быть сохранен, и я не буду там вечно, я стараюсь писать вещи так, чтобы они выглядели так, как будто они там (без просмотра комментариев с моими инициалами, вы крайне редко можете посмотрите на код, над которым я работал, чтобы увидеть, где я внес изменения), и что кто-то с меньшими навыками, чем я, может его поддерживать.
Несмотря на то, что троичный оператор выглядит неестественно и круто, мой опыт показывает, что поддерживать строку кода практически невозможно. У моего нынешнего работодателя есть продукты, которые поставляются уже почти 20 лет. Я бы нигде не использовал этот пример.
источник
Я не думаю, что троичный оператор это зло.
Вот гоча, которая поставила меня в тупик, хотя. Я был программистом на C для многих (10+) и в конце 1990-х перешел на веб-программирование приложений. Как веб-программист, я вскоре столкнулся с PHP, который также имеет троичный оператор. У меня была ошибка в PHP-программе, которую я, наконец, отследил до строки кода с вложенным троичным оператором. Оказывается, что троичный оператор PHP связан слева направо, но троичный оператор C (к которому я привык) ассоциируется справа налево.
источник
Все, что делает ваш код более уродливым, является злом.
Если вы используете троичный код, чтобы сделать свой код чище, тогда обязательно используйте его. Иногда в таких как php замечательно делать встроенные замены, например
Это экономит несколько строк, и это довольно ясно, но ваш пример требует, по крайней мере, лучшего форматирования, чтобы быть ясным, и троичный не очень хорош для многострочных, тогда вы могли бы также использовать if / else.
источник
Могу я это сказать? Мне не удается найти это конкретное применение троичной операции зла :
Пожалуйста, помилуй, моя репутация уже довольно жалкая.
источник
Крупнейшая победа: показывает, что существует единственная цель действия.
Вы можете следовать двум путям кода, и читатель должен внимательно прочитать, какие две переменные устанавливаются. В этом случае это только одна переменная, но читатель должен прочитать больше, чтобы понять это. В конце концов, это могло быть так:
С троичным оператором ясно, что устанавливается только одна переменная.
На самом низком уровне это принцип СУХОЙ (не повторяй себя) в своей самой базовой форме. Если вы можете указать
$foo
только один раз, сделайте это.источник
Если ... то ... еще раз имеет тенденцию подчеркивать условие и, следовательно, снимать акцент с выполняемых операций.
троичный оператор противоположен, он имеет тенденцию скрывать условие и поэтому полезен, когда выполняемая операция более важна, чем само условие.
В некоторых языках есть небольшой технический недостаток, заключающийся в том, что они не вполне взаимозаменяемы из-за того, что один является оператором, а другой - выражением, например условно инициализирующими константами в C ++.
источник
Я думаю, что при разработке для однородной группы людей не возникает никаких проблем, но когда вам приходится иметь дело с людьми, которые работают с разными уровнями, этот вид oneliners только вводит дополнительный уровень сложности в код. Итак, моя политика в этом вопросе: код ясен и не объясняет, а не код короток и объясняет 123123 раза.
Меня не следует учить новичкам, я предпочитаю, чтобы они выяснили это, когда возникнет необходимость, поэтому он будет использоваться только тогда, когда это необходимо, а не каждый раз, когда вам нужно, если.
источник
IMO, сам оператор не является злом, но синтаксис, используемый для него в C (и C ++), чрезмерно лаконичен. ИМО, Алгол 60 сделал это лучше, так что-то вроде этого:
будет выглядеть примерно так (но в целом придерживаться C-подобного синтаксиса):
Несмотря на это, чрезмерно глубокое вложение может привести к проблемам с читабельностью, но, по крайней мере, A) любой, кто вообще занимался программированием, может понять это просто, и B) люди, которые понимают его, могут довольно легко справиться со значительно более глубоким вложением. ОТО, я бы также отметил, что в LISP (например) a
cond
во многом напоминает троичное выражение - не набор операторов, а одно выражение, которое дает значение (опять же, большая часть LISP такая же). .)источник
A = (x==y) ? B : C
Магазин, который регулярно пишет 600-1200-строчные методы, не должен говорить мне, что троица "трудна для понимания". Любой магазин, который регулярно допускает пять условий для оценки ветви кода, не должен говорить мне, что конкретно сформулированные условия в троичной системе «трудны для чтения».
источник
Когда?: Уместно, а когда нет?
Следует ли этому учить или скрывать от начинающих?
Неважно, но это не должно быть преднамеренно скрыто, поскольку это не слишком сложно для "новичка", чтобы учиться.
источник
В вашем примере:
очень просто читать и очевидно. Переменная между <<является возвращаемым значением.
Обновить
то же самое, но меньше строк кода. Все еще просто, я думаю.
источник
Это также необходимо для const
источник
const
так на определенных языках. В C #const
всегда должно быть время компиляции известного значения. что означает неconst int nLegs = isChicken ? 2: 4 ;
будет работать, ноconst int nLegs = true ? 2: 4 ;
будет