Un argument convaincant pour l'opérateur virgule

L'opérateur virgule est l'un des opérateurs les moins connus dans les langages de type C tels que JavaScript et C++. Essentiellement, il délimite une séquence d'expressions et ne renvoie que le résultat de la finale.

const a = 1;
const b = 2;
const c = 3;
const result = (a, b, c, 4, 5, 6, true);
console.log(result); // true

if (false, true) console.log('hello'); // hello

Il est alors naturel de se demander : quand serait-il utile de regrouper plusieurs expressions sur une seule ligne ? De plus, même si cela était utile, pourquoi une séquence d'expressions séparées par des virgules (dans un une seule ligne) est-elle plus lisible et maintenable qu'une séquence d'instructions séparées par des points-virgules (sur plusieurs lignes) ? Quand faut-il préférer l’un à l’autre ?

Ce sont des questions auxquelles j'ai eu du mal à répondre au fil des années, mais maintenant je pense avoir enfin une réponse. Dans cet article, je présente un cas convaincant – peut-être le seul à parler franchement – ​​en faveur de l'opérateur virgule.

Un exemple motivant

Parlons d'abord de l'opérateur ternaire conditionnel. Comme vu ci-dessous, si la condition est vraie, elle évalue la valeur. Sinon, il évalue un autre. L'accent est mis ici sur le mot clé « évaluation » car les branches ne s'exécutent que lorsque leur condition est remplie.

const result = condition ? value : another;

Dans la plupart des cas, c'est soigné et joli. Cependant, là où cela s'effondre, c'est lorsque nous devons faire une logique plus complexe entre les branches avant de renvoyer la valeur conditionnelle. À ce stade, nous recourons à cette malheureuse perversion :

let result; // Uninitialized! Yikes!
if (condition) {
    // Do some complex stuff in between...
    doSomething();
    // ...
    result = value; // Actual Assignment
} else {
    // Do other complex stuff in between...
    doAnotherThing();
    // ...
    result = another; // Actual Assignment
}
// Hopefully we didn't forget to initialize `result`!

Maintenant, cette formulation pose de nombreux problèmes.

1. Le résultat n'est pas initialisé au début. Ce n'est pas mauvais en soi, mais un moyen simple et éprouvé d'éviter les bogues dus à un élément non défini consiste simplement à toujours initialiser les variables.
2. L'initialisation du résultat se trouve littéralement au bas de la branche, très détachée de sa déclaration.
3. À la fin du conditionnel, espérons que le résultat soit sûrement initialisé. Si ce n’est pas nous, nous ferions mieux d’espérer que nos coéquipiers appliqueront également cela. Si ce n’est pas le cas maintenant, nous ferions mieux d’espérer que les futurs développeurs respecteront cela également !

Il existe un moyen de contourner cette limitation si l'on insiste sur l'utilisation d'expressions ternaires conditionnelles. Il suffit de refactoriser le code en fonctions. C'est certainement plus facile à dire qu'à faire. Ce gadget vieillit très vite !

function computeWrappedValue() {
    // ...
    return value;
}

function computeWrappedAnother() {
    // ...
    return another;
}

// How cumbersome!
const result = condition ? computeWrappedValue() : computeWrappedAnother();

Les langages de programmation basés sur les expressions (tels que Rust) ont une solution plus élégante. En reclassant l'if instruction en if expression, chaque branche peut être évaluée et ainsi renvoyer des valeurs qui pourront ensuite être stockées dans une variable.

// A conditional ternary operator thus looks like this. Each branch
// returns a value, which is captured by the `result` variable.
// We thus ensure that `result` is always initialized by construction.
let result = if condition { value } else { another };

// If we wanted to do something more complex, we use the same syntax.
let result = if condition {
    do_something();
    // In Rust, the last expression without a semicolon is the value
    // that will be "returned" by the overall `if` expression.
    result
} else {
    do_another_thing();
    another
};

Pouvons-nous émuler cela dans des langages de type C ? Vous avez probablement prévu depuis longtemps où je vais avec cela, mais oui !

Un cas convaincant

Ce que nous voulons, c'est un moyen d'exécuter arbitrairement des instructions avant de renvoyer une valeur dans les branches ternaires. Eh bien, heureusement pour nous, c'est exactement à quoi sert l'opérateur virgule.

// Parenthesized for clarity.
const result = condition
    ? (doSomething(), value)       // evaluates to `value`
    : (doAnotherThing(), another); // evaluates to `another`

La particularité de cette formulation est le fait que les expressions de branche ne sont évaluées que lorsque cela est nécessaire. Nous imitons efficacement le comportement des langages de programmation basés sur les expressions. Fini le temps des fonctions wrapper ad hoc !

Mais hélas, on ne peut aller que jusqu'à présent avec cette technique. Vous pouvez imaginer que pour certains n suffisamment grands, regrouper n instructions sur une seule ligne demande déjà d'être refactorisé dans sa propre fonction. Personnellement, je reconsidérerais déjà ma décision au moment où n> 3. Tout ce qui est supérieur à cela est une construction douteuse en termes de lisibilité.

// Maybe we should reconsider here?
const result = condition
    ? (x++, thing = hello(), doSomething(), value)
    : (++y, thing = world(), doAnotherThing(), another);

// Okay, stop. Definitely turn back now!
const result = condition
    ? (
        x++,
        thing = hello(),
        doSomething(),
        doMore(y),
        doEvenMore(thing),
        value,
    ) : (
        ++y,
        thing = world(),
        doAnotherThing(),
        doMore(y),
        doEvenMore(thing),
        another,
    );
// Unless, of course, you're fine with this. It kinda does
// look like a Rust `if` expression if you squint hard enough.

Conclusion

En conclusion, nous avons vu un cas convaincant en faveur de l'opérateur virgule : les opérations ternaires conditionnelles complexes. L'opérateur virgule brille lorsque les branches sont courtes et douces, mais passe très vite de mode après trois instructions en ligne. À ce stade, il est probablement préférable de refactoriser le code.

Alors, devriez-vous utiliser des opérateurs virgules ? Honnêtement... ouais ! Le code lisible tient compte du prochain lecteur, donc tant que les chaînes de virgules ne sont jamais excessivement longues, j'accepterais – et même encouragerais – ce style de codage. Si l'on considère les alternatives (c'est-à-dire les variables non initialisées et les micro-fonctions refactorisées), l'opérateur virgule n'est pas si mal après tout.

En pratique, je saupoudre déjà mes propres bases de code de ces drôles d'opérateurs virgules. Bien qu'en toute honnêteté, j'ai rarement besoin de conditions ternaires multi-instructions de toute façon. Mais quand je le fais, j'ai un outil sympa à ma ceinture qui exprime de manière concise mon intention.

À cette fin, je repose mes arguments convaincants en faveur de l'opérateur virgule.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!