Pourquoi faire simple quand on peut pondre ça?

Peut être une tentative d'obfuscation de code ?

Je me demande si ça ajoute pas des risques de bugs?

Et tentative d'offuscation du programmeur qui reprendra le code ensuite.

L'utilité des conditions ternaires c'est un vieux et long débat.

Certains trouvent ça beaucoup moins lisible. (faut dire que t'as des tarés qui te mettent des conditions ternaires dans des conditions ternaires dans des conditions ternaires... mais je connais des extrémistes qui en refusent toute utilisation, même modérée)

Comme dit, pour faire des assignations de booléens ou ce genre de choses, c'est quand même plus propre.

Après, pondre une imbrication de conditions avec, non.

L'argument que j'avais vu, c'est que ça :

If(condition){
  var=value1;
 } else {
  var=value2;
 }

ça peut être lu de façon intuitive par un humain, c'est presque de l'anglais.

Alors que ça : var = condition ? value1 : value2; c'est incompréhensible sans connaitre cette syntaxe exacte.

J'ai jamais compris les gens qui utilisent des prédicats ne pouvant qu'être vrais ou faux…

Et ça te fout les Boole ?

if(condition)
     var = value1;
 else
     var = value2;

Déjà, ça allège et ça enlève les accolades égyptiennes.
Deuxièmement, il y a des cas, en C++ au moins, où on est obligé d'utiliser l'écriture ternaire. Je pense notamment à la méta-programmation template.

Mais on peut tout à fait combiner les avantages des deux, comme dans plein de langages fonctionnels qui permettent d'écrire quelque chose comme

var = if condition then value1 else value2

Si on considère que l'opérateur ?: est naturellement incompréhensible pour ce travail, on peut faire le même raisonnement pour tous les opérateurs sauf ceux de l'arithmétique de base.

bool*

Non, Boole ça marche.

@TuXiC69 : "c'est incompréhensible sans connaitre cette syntaxe exacte"

Si seulement il existait des trucs qui permettraient de connaître des trucs qu'on ne connaissait pas avant...

Plus sérieusement : C'est un excellent argument pour ne rien faire, parce que même la roue, faut savoir comment ça marche avant de vouloir en mettre une sous ta charrette.

Le problème ici c'est pas l'utilisation de "?:" mais le fait qu'il fasse un test sur 2 valeurs "en dur" à savoir 100 et 0 non ?

je ne me prononce pas : il avait peut être prévu de rajouter plus de conditions derrière

ça me rappelle un truc : il ne serait pas payé à la ligne de code ou au caractère???

C'est une hypothèse intéressante, je propose qu'on fonde un groupe d'étude pour l'investiguer.

Du genre:
int inc = 100 > 0 ? 100 < 0 ? -1 : 1 : 100 < 0 ? -1 : 1;
inc = 0 > 100 ? 0 == 0 ? 1 : 100 == 100 ? 1 : 1 : 100 < 0 ? -1 : -1;

Je l'aime trop (ton Boole) !

Merci, c'est vrai que c'est quand même beaucoup plus lisible.

Autant ecrire lisiblement vu que le compilo se charge de l'optim. C'est quand même plus propre.

@Douxware : arh, quand j'étais jeune (y a pas très longtemps) on m'a interdit les conditions sans accolades, pour des questions de lisibilité la encore. C'est un peu con mais ça m'est resté.
Tout comme je ne peux pas supporter les string entre double-quotes en PHP, tellement on m'avait martelé que les simple-quotes étaient + optimisées (ce qui semble être vrai d'après les benchmarks trouvables sur le web, mais la différence est tellement minime qu'elle est souvent négligeable).
Y a des traumatismes comme çà ^^

@Geist : Non. La il y a deux syntaxes logiquement équivalentes (et d'un point de vue performance aussi il me semble, mais j'ai pas checké), dont une lisible intuitivement et pas l'autre.
Si il n'y a qu'une syntaxe possible, incompréhensible ou pas, il n'y a pas de question a se poser.

moi je trouve tout à faire lisible la version ternaire et parfois je préfère une ligne ternaire que 4

@Douxware et @TuXiC69 : Les conditions sans accolades sont "interdit" pour la simple et bonne raison que cela augmente grandement les chances de bugs car cela devient plus difficile de voir où commence et où se termine les opérations de ta condition.