Ternário ou não ternário? [fechadas]

Pessoalmente, sou advogado do operador ternário: ()? :; Eu percebo que ele tem o seu lugar, mas me deparei com muitos programadores que são totalmente contra o uso, e alguns que o usam com muita frequência.

Quais são seus sentimentos sobre isso? Que código interessante você já viu usando?

Use-o apenas para expressões simples :

int a = (b > 10) ? c : d;

Não encadeie ou aninhe operadores ternários, pois é difícil de ler e confuso:

int a = b > 10 ? c < 20 ? 50 : 80 : e == 2 ? 4 : 8;

Além disso, ao usar o operador ternário, considere formatar o código de uma maneira que melhore a legibilidade:

int a = (b > 10) ? some_value                 
                 : another_value;

Isso torna a depuração um pouco mais difícil, pois você não pode colocar pontos de interrupção em cada uma das subexpressões. Eu uso raramente.

Eu os amo, especialmente em idiomas seguros para tipos.

Não vejo como isso:

int count = (condition) ? 1 : 0;

é mais difícil do que isso:

int count;

if (condition)
{
  count = 1;
} 
else
{
  count = 0;
}

editar -

Eu argumentaria que os operadores ternários tornam tudo menos complexo e mais elegante do que a alternativa.

Acorrentado, estou bem - aninhado, nem tanto.

Eu costumo usá-los mais em C simplesmente porque eles são uma instrução if que tem valor, por isso diminui a repetição ou variáveis ​​desnecessárias:

x = (y < 100) ? "dog" :
    (y < 150) ? "cat" :
    (y < 300) ? "bar" : "baz";

ao invés de

     if (y < 100) { x = "dog"; } 
else if (y < 150) { x = "cat"; }
else if (y < 300) { x = "bar"; } 
else              { x = "baz"; }

Em tarefas como essa, acho que é menos refatorar e mais claro.

Por outro lado, quando estou trabalhando em rubi, é mais provável que eu use, if...else...endporque também é uma expressão.

x =   if (y < 100) then "dog"
    elif (y < 150) then "cat"
    elif (y < 300) then "bar"
    else                "baz"
    end

(embora, reconhecidamente, para algo tão simples, eu possa usar o operador ternário de qualquer maneira).

O ?:operador ternário é apenas um equivalente funcional da ifconstrução processual . Portanto, desde que você não esteja usando ?:expressões aninhadas , os argumentos a favor / contra a representação funcional de qualquer operação se aplicam aqui. Porém, o aninhamento de operações ternárias pode resultar em um código totalmente confuso (exercício para o leitor: tente escrever um analisador que lide com condicionais ternários aninhados e você apreciará sua complexidade).

Mas há muitas situações em que o uso conservador do ?:operador pode resultar em código que é realmente mais fácil de ler do que o contrário. Por exemplo:

int compareTo(Object object) {
    if((isLessThan(object) && reverseOrder) || (isGreaterThan(object) && !reverseOrder)) {
       return 1;
    if((isLessThan(object) && !reverseOrder) || (isGreaterThan(object) && reverseOrder)) {
       return -1;
    else
      return 0;              
}

Agora compare isso com isso:

int compareTo(Object object) {
    if(isLessThan(object))
        return reverseOrder ? 1 : -1;         
    else(isGreaterThan(object))
        return reverseOrder ? -1 : 1;
    else        
       return 0;              
}

Como o código é mais compacto, há menos ruído sintático e, usando criteriosamente o operador ternário (isso é apenas em relação à propriedade reverseOrder ), o resultado final não é particularmente conciso.

É uma questão de estilo, realmente; as regras subconscientes que eu costumo seguir são:

• Avalie apenas 1 expressão - então foo = (bar > baz) ? true : false, mas NÃOfoo = (bar > baz && lotto && someArray.Contains(someValue)) ? true : false
• Se eu o estiver usando para lógica de exibição, por exemplo <%= (foo) ? "Yes" : "No" %>
• Apenas use-o realmente para atribuição; nunca flui lógica (então nunca (foo) ? FooIsTrue(foo) : FooIsALie(foo)) A lógica do fluxo no ternário é em si uma mentira, ignore esse último ponto.

Gosto porque é conciso e elegante para operações de atribuição simples.

Como tantas perguntas de opinião, a resposta é inevitavelmente: depende

Para algo como:

return x ? "Yes" : "No";

Eu acho que é muito mais conciso (e mais rápido para eu analisar) do que:

if (x) {
    return "Yes";
} else {
    return "No";
}

Agora, se sua expressão condicional é complexa, a operação ternária não é uma boa escolha. Algo como:

x && y && z >= 10 && s.Length == 0 || !foo

não é um bom candidato para o operador ternário.

Além disso, se você é um programador C, o GCC realmente possui uma extensão que permite excluir a parte se verdadeira do ternário, assim:

/* 'y' is a char * */
const char *x = y ? : "Not set";

Que irá definir xa yassumir ynão é NULL. Coisa boa.

Na minha opinião, só faz sentido usar o operador ternário nos casos em que uma expressão é necessária.

Em outros casos, parece que o operador ternário diminui a clareza.

Pela medida da complexidade ciclomática , o uso de ifinstruções ou o operador ternário são equivalentes. Portanto, por essa medida, a resposta é não , a complexidade seria exatamente a mesma de antes.

Por outras medidas, como legibilidade, capacidade de manutenção e DRY (não se repita), uma das opções pode ser melhor que a outra.

Eu o uso com frequência em locais onde sou obrigado a trabalhar em um construtor - por exemplo, as novas construções .NET 3.5 LINQ to XML - para definir valores padrão quando um parâmetro opcional é nulo.

Exemplo artificial:

var e = new XElement("Something",
    param == null ? new XElement("Value", "Default")
                  : new XElement("Value", param.ToString())
);

ou (obrigado asterita)

var e = new XElement("Something",
    new XElement("Value",
        param == null ? "Default"
                      : param.ToString()
    )
);

Não importa se você usa o operador ternário ou não, é importante garantir que seu código seja legível. Qualquer construção pode ficar ilegível.

Eu uso o operador ternário sempre que posso, a menos que torne o código extremamente difícil de ler, mas isso geralmente é apenas uma indicação de que meu código poderia usar um pouco de refatoração.

Sempre me intriga como algumas pessoas pensam que o operador ternário é um recurso "oculto" ou um tanto misterioso. É uma das primeiras coisas que aprendi quando começo a programar em C e não acho que diminua a legibilidade. É uma parte natural da linguagem.

(Hack do dia)

#define IF(x) x ?
#define ELSE :

Então você pode fazer if-then-else como expressão:

int b = IF(condition1)    res1
        ELSE IF(condition2)  res2
        ELSE IF(conditions3) res3
        ELSE res4;

Concordo com jmulder: não deve ser usado no lugar de a if, mas tem seu lugar para expressão de retorno ou dentro de uma expressão:

echo "Result: " + n + " meter" + (n != 1 ? "s" : "");
return a == null ? "null" : a;

O primeiro é apenas um exemplo, um melhor suporte i18n ao plural deve ser usado!

Se você estiver usando o operador ternário para uma atribuição condicional simples, acho que está bem. Eu já vi (ab) usado para controlar o fluxo do programa sem nem mesmo fazer uma atribuição, e acho que isso deve ser evitado. Use uma instrução if nesses casos.

Eu acho que o operador ternário deve ser usado quando necessário. Obviamente, é uma escolha muito subjetiva, mas acho que uma expressão simples (especialmente como expressão de retorno) é muito mais clara que um teste completo. Exemplo em C / C ++:

return (a>0)?a:0;

Comparado com:

if(a>0) return a;
else return 0;

Você também tem o caso em que a solução está entre o operador ternário e a criação de uma função. Por exemplo, em Python:

l = [ i if i > 0 else 0 for i in lst ]

A alternativa é:

def cap(value):
    if value > 0:
        return value
    return 0
l = [ cap(i) for i in lst ]

É necessário o suficiente para que, em Python (como exemplo), esse idioma possa ser visto regularmente:

l = [ ((i>0 and [i]) or [0])[0] for i in lst ]

esta linha usa propriedades dos operadores lógicos no Python: eles são preguiçosos e retornam o último valor calculado se for igual ao estado final.

Eu gosto deles. Não sei por que, mas me sinto bem quando uso a expressão ternária.

Eu já vi bestas assim (na verdade, era muito pior, pois era isValidDate e checava mês e dia também, mas não me incomodei em tentar lembrar a coisa toda):

isLeapYear =
    ((yyyy % 400) == 0)
    ? 1
    : ((yyyy % 100) == 0)
        ? 0
        : ((yyyy % 4) == 0)
            ? 1
            : 0;

onde, claramente, uma série de declarações if seria melhor (embora essa ainda seja melhor do que a versão macro que vi uma vez).

Não me importo com coisas pequenas como:

reportedAge = (isFemale && (Age >= 21)) ? 21 + (Age - 21) / 3 : Age;

ou até coisas um pouco complicadas, como:

printf ("Deleted %d file%s\n", n, (n == 1) ? "" : "s");

Bem, a sintaxe para isso é horrível. Acho ifs funcionais muito úteis e geralmente torna o código mais legível.

Sugiro criar uma macro para torná-la mais legível, mas tenho certeza de que alguém pode apresentar um caso de borda horrível (como sempre existe no CPP).

Eu gosto de usar o operador no código de depuração para imprimir valores de erro, para que eu não precise procurá-los o tempo todo. Normalmente, faço isso para impressões de depuração que não permanecerão quando terminar o desenvolvimento.

int result = do_something();
if( result != 0 )
{
  debug_printf("Error while doing something, code %x (%s)\n", result,
                result == 7 ? "ERROR_YES" :
                result == 8 ? "ERROR_NO" :
                result == 9 ? "ERROR_FILE_NOT_FOUND" :
                "Unknown");
}

Eu quase nunca uso o operador ternário, porque sempre que eu o uso, isso sempre me faz pensar muito mais do que preciso depois, quando tento mantê-lo.

Eu gosto de evitar a verbosidade, mas quando tornar o código muito mais fácil de entender, irei pela verbosidade.

Considerar:

String name = firstName;

if (middleName != null) {
    name += " " + middleName;
}

name += " " + lastName;

Agora, isso é um pouco detalhado, mas acho muito mais legível do que:

String name = firstName + (middleName == null ? "" : " " + middleName)
    + " " + lastName;

ou:

String name = firstName;
name += (middleName == null ? "" : " " + middleName);
name += " " + lastName;

Parece apenas compactar informações demais em pouco espaço, sem deixar claro o que está acontecendo. Toda vez que vejo o operador ternário sendo usado, sempre encontro uma alternativa que parecia muito mais fácil de ler ... então, essa é uma opinião extremamente subjetiva. Portanto, se você e seus colegas acham o ternário muito legível, siga em frente.

Apenas quando:

$ var = (simples> teste? simples_result_1: simples_result_2);

BEIJO.

Eu normalmente uso em coisas como esta:

before:

if(isheader)
    drawtext(x,y,WHITE,string);
else
    drawtext(x,y,BLUE,string);

after:

    drawtext(x,y,isheader==true?WHITE:BLUE,string);

Como outros já apontaram, eles são bons para condições curtas e simples. Eu gosto especialmente deles por padrão (como o || e / ou uso em javascript e python), por exemplo

int repCount = pRepCountIn ? *pRepCountIn : defaultRepCount;

Outro uso comum é inicializar uma referência em C ++. Como as referências precisam ser declaradas e inicializadas na mesma instrução, você não pode usar uma instrução if.

SomeType& ref = pInput ? *pInput : somethingElse;

Trato os operadores ternários muito como o GOTO. Eles têm o seu lugar, mas são algo que você normalmente deve evitar para facilitar a compreensão do código.

Recentemente, vi uma variação nos operadores ternários (bem, mais ou menos) que fazem a variante padrão "()?:" Parecer um exemplo de clareza:

var Result = [CaseIfFalse, CaseIfTrue][(boolean expression)]

ou, para dar um exemplo mais tangível:

var Name = ['Jane', 'John'][Gender == 'm'];

Lembre-se, isso é Javascript, então coisas assim podem não ser possíveis em outros idiomas (felizmente).

Para casos simples, eu gosto de usá-lo. Na verdade, é muito mais fácil ler / codificar, por exemplo, como parâmetros para funções ou coisas assim. Também para evitar a nova linha, eu gosto de manter todos os meus if / else.

Neseting seria um grande NÃO-NÃO no meu livro.

Então, resumindo, por um único if / else, usarei o operador ternário. Para outros casos, um if / else if / else regular (ou alternar)

Gosto do caso especial de Groovy do operador ternário, chamado de operador Elvis:?:

expr ?: default

Esse código avalia expr se não for nulo e, se for o padrão. Tecnicamente, não é realmente um operador ternário, mas definitivamente está relacionado a ele e economiza muito tempo / digitação.

Para tarefas simples, como atribuir um valor diferente, dependendo de uma condição, elas são ótimas. Eu não os usaria quando houver expressões mais longas, dependendo da condição.

Tantas respostas disseram, depende . Acho que se a comparação ternária não estiver visível em uma verificação rápida do código, ela não deverá ser usada.

Como uma questão secundária, eu também posso observar que sua própria existência é realmente um pouco anômala, devido ao fato de que em C, o teste de comparação é uma afirmação. No Icon, a ifconstrução (como a maioria do Icon) é na verdade uma expressão. Então você pode fazer coisas como:

x[if y > 5 then 5 else y] := "Y" 

... que eu acho muito mais legível do que um operador de comparação intermediário. :-)

Recentemente, houve uma discussão sobre a possibilidade de adicionar o ?:operador ao Icon, mas várias pessoas apontaram corretamente que não havia absolutamente nenhuma necessidade devido à maneira comoif funciona.

O que significa que se você pudesse fazer isso em C (ou em qualquer outro idioma que possua o operador ternery), não precisaria, de fato, do operador ternery.

Se você e seus colegas de trabalho entendem o que fazem e não são criados em grandes grupos, acho que eles tornam o código menos complexo e mais fácil de ler, porque simplesmente há menos código.

A única vez que acho que os operadores ternários dificultam o entendimento do código é quando você tem mais de 3 ou 4 em uma linha. A maioria das pessoas não se lembra de que elas têm precedência correta e quando você tem uma pilha delas, a leitura do código é um pesadelo.