Comment écrivez-vous une variable (simple) «bascule»?

Question

Étant donné les idiomes suivants:

1)

variable = value1
if condition
  variable = value2

2)

variable = value2
if not condition
  variable = value1

3)

if condition
  variable = value2
else
  variable = value1

4)

if not condition
  variable = value1
else
  variable = value2

Que préférez-vous et pourquoi?

Nous supposons que le chemin d'exécution le plus courant est celui où la condition est fausse.

J'ai tendance à apprendre à utiliser 1), bien que je ne sois pas tout à fait sûr pourquoi je l'aime plus.

Remarque: Les exemples suivants sont peut-être plus simples, et donc plus lisibles, mais tous les langages n'offrent pas cette syntaxe et ne conviennent pas pour étendre l'affectation de variable de manière à inclure plus d'une instruction à l'avenir. / em>

variable = condition ? value2 : value1
...
variable = value2 if condition else value1

Answer 1

En théorie, je préfère le n ° 3 car cela évite de devoir attribuer une valeur à la variable deux fois. Dans la réalité, même si j’utilise l’un quelconque des quatre précédents, cela serait plus lisible ou exprimerait plus clairement mon intention.

Answer 2

Je préfère la méthode 3 car elle est plus concise et plus logique. Il définit la valeur une seule fois, il peut être déplacé en tant que bloc et ce n'est pas ce qui est sujet aux erreurs (ce qui se produit, surtout dans la méthode 1, si valeur-à-valeur1 et vérification-et-éventuellement-valeur-à-valeur-2 sont séparés par d'autres déclarations)

Answer 3

3) est l'expression la plus claire de ce que vous voulez qu'il se passe. Je pense que tous les autres nécessitent une réflexion supplémentaire pour déterminer quelle valeur va se retrouver dans la variable.

En pratique, j'utiliserais l'opérateur ternaire (? :) si j'utilisais un langage qui le supportait. Je préfère écrire dans un style fonctionnel ou déclaratif que impératif dès que je peux.

Answer 4

J'ai tendance à utiliser le numéro 1 beaucoup moi-même. si condition se lit plus facilement que si! condition , surtout si vous manquez accidentellement le "!", du moins à mon avis.

La plupart des codes que je fais sont en C #, mais j’ai quand même tendance à éviter l’opérateur terniaire, à moins que je ne travaille avec des variables (principalement) locales. Les lignes ont tendance à être très longues TRES rapidement chez un opérateur ternaire si vous appelez trois couches plus profondément dans une structure, ce qui diminue rapidement la lisibilité.

Answer 5

  

Remarque: les exemples suivants sont peut-être plus simples, et donc plus lisibles, mais tous les langages n'offrent pas une telle syntaxe.

Ce n'est pas un argument pour ne pas les utiliser dans des langages qui fournissent une telle syntaxe. Incidemment, cela inclut toutes les langues courantes actuelles après mon dernier décompte.

  

et ils ne conviennent pas pour étendre l'affectation de variable de manière à inclure plusieurs instructions à l'avenir.

C'est vrai. Cependant, il est souvent certain qu’une telle extension ne se produira absolument jamais car la condition donnera toujours l’un des deux cas possibles.

Dans de telles situations, je préférerai toujours la variante d'expression à la variante d'instruction, car elle réduit l'encombrement syntaxique et améliore l'expressivité. Dans d’autres situations, j’ai tendance à utiliser l’instruction switch mentionnée précédemment - si le langage le permet. Sinon, retournez au générique si .

Answer 6

L’instruction

switch fonctionne également. Si c’est simple et qu’il y a plus de 2 ou 3 options, c’est ce que j’utilise.

Answer 7

Dans une situation où la condition pourrait ne pas se produire. J'irais avec 1 ou 2. Sinon, c'est juste basé sur ce que je veux que le code fasse. (c.-à-d. je suis d'accord avec cruizer)

Answer 8

J'ai tendance à utiliser sinon ... à revenir.

Mais si vous cherchez à renvoyer une variable. Obtenir les disqualificateurs en premier lieu tend à le rendre plus lisible. Cela dépend vraiment du contexte de la déclaration et de la langue. Une déclaration de cas peut fonctionner mieux et être lisible la plupart du temps, mais les performances en pâtissent sous VB, donc une série de déclarations if / else est plus logique dans ce cas particulier.

Answer 9

Méthode 1 ou méthode 3 pour moi. La méthode 1 permet d'éviter une entrée / sortie de scope supplémentaire, mais la méthode 3 évite une affectation supplémentaire. J'aurais tendance à éviter la méthode 2 car j'essaie de garder la logique de condition aussi simple que possible (dans ce cas, le! Est étranger car il pourrait être réécrit comme la méthode 1 sans elle) et la même raison s'applique à la méthode 4.

Answer 10

Cela dépend de la condition que je teste.

S'il s'agit d'une condition d'indicateur d'erreur, j'utiliserai 1) la définition de l'indicateur d'erreur pour détecter l'erreur, puis, si la condition est réussie, effacez l'indicateur d'erreur. De cette façon, il n'y a aucune chance de rater une condition d'erreur.

Pour tout le reste j'utiliserais 3)

La logique de NOT ne fait qu'ajouter à la confusion lors de la lecture du code - bien dans ma tête, je ne peux parler pour personne d'autre: -)

Answer 11

Si la variable a une valeur par défaut naturelle, je choisirais # 1. Si l’une ou l’autre des valeurs convient également (en) à une valeur par défaut, j’aimerais utiliser la valeur # 2.

Answer 12

Cela dépend. J'aime les opérateurs ternaires, mais parfois c'est plus clair si vous utilisez une déclaration 'if'. Laquelle des quatre options que vous choisirez dépendra du contexte, mais j’ai tendance à choisir celle qui rend le code plus clair, et cela varie d’une situation à l’autre.