Quel code est plus lisible?

Question

Supposons que j'ai deux méthodes d' bool Foo() et bool Bar(). Ce qui est le plus lisible?

if(Foo())
{
    SomeProperty = Bar();
}
else
{
    SomeProperty = false;
}

ou

SomeProperty = Foo() && Bar();

D'une part, je considère que le court-circuit && à être une fonction utile et le deuxième exemple de code est beaucoup plus courte. D'autre part, je ne suis pas sûr que les gens sont généralement habitués à voir && en dehors d'une instruction conditionnelle, donc je me demande si c'introduire une certaine dissonance cognitive qui fait le premier échantillon de la meilleure option.

Qu'en pensez-vous? Existe-il d'autres facteurs qui influent sur la décision? Comme, si l' && expression est plus qu'une ligne peut tenir sur l'écran, dois-je préfère l'ancien?

---

Post-réponse précisions:

Quelques choses que je devrais avoir inclus dans la question initiale, que les réponses apportées jusqu'.

• Bar() peut être plus coûteux à exécuter que d' Foo(), mais ni la méthode devrait avoir des effets secondaires.
• Les méthodes sont nommés de façon plus appropriée, pas comme dans cet exemple. Foo() se résume à quelque chose comme CurrentUserAllowedToDoX() et Bar() est plus comme, XCanBeDone()

Answer 1

Je suis d'accord avec le consensus général que les Foo() && Bar() est raisonnable , sauf si c'est le cas qu'Bar() est utile pour ses effets secondaires ainsi que sa valeur.

Si c'est le cas qu'Bar() est utile pour ses effets secondaires ainsi que sa valeur, mon premier choix serait la refonte de la Barre (de), de sorte que la production de ses effets secondaires et le calcul de sa valeur étaient des méthodes distinctes.

Si, pour quelque raison que c'était impossible, alors je vous en serais très préférez la version originale. Pour moi la version originale plus met clairement en évidence que l'appel à la Barre() est une instruction qui est utile pour ses effets secondaires. La dernière forme à me souligne que Bar() est utile pour sa valeur.

Par exemple, étant donné le choix entre

if (NetworkAvailable())
  success = LogUserOn();
else
  success = false;

et

success = NetworkAvailable() && LogUserOn();

Je prendrais le premier, et pour moi, c'est trop facile de négliger l'effet secondaire important dans le second.

Cependant, si c'était un choix entre

if (NetworkAvailable())
  tryWritingToNetworkStorage = UserHasAvailableDiskQuota();
else
  tryWritingToNetworkStorage = false;

et

tryWritingToNetworkStorage = NetworkAvailable() && UserHasAvailableDiskQuota();

J'ai choisi ce dernier.

Answer 2

J'aime cette notation abrégée en supposant que votre langue le permet:

 SomeProperty = Foo() ? Bar() : false;
 

Answer 3

 SomeProperty = Foo() && Bar();
 

C'est beaucoup plus lisible. Je ne vois pas comment quelqu'un pourrait choisir l'autre franchement. Si l'expression && est plus longue que 1 ligne, divisez-la en 2 lignes ...

 SomeProperty = 
   Foo() && Bar();

      -or-

SomeProperty = Foo() && 
               Bar();
 

Cela nuit à peine à la lisibilité et à la compréhension de mon humble avis.

Answer 4

Cela dépend de ce que Foo et Bar font.

Par exemple, IsUserLoggedIn() && IsUserAdmin() serait certainement mieux en tant que && , mais il existe d'autres combinaisons (je ne peux penser à aucune désinvolture) où les ifs seraient meilleurs.

Dans l'ensemble, je recommanderais && .

Answer 5

Ni. J'aimerais commencer avec le renommage SomeProperty, Foo et Bar.

Ce que je veux dire c'est, vous devez structurer votre code de transmettre clairement vos intentions. Avec différentes fonctions, je pourrais utiliser les différentes formes. Comme il est, cependant, la forme est très bien. Considérer:

IsFather = IsParent() && IsMale();

et

if (FPUAvailable()) {
    SomeProperty = LengthyFPUOperation();
} else {
    SomeProperty = false;
}

Ici, la première forme des contraintes de la logique et de la relation. La seconde insiste sur le court-circuit. Je n'aurais jamais écrire le premier exemple, dans le deuxième formulaire. Je serais probablement préfèrent la seconde forme pour le deuxième exemple, surtout si je visais pour plus de clarté.

Le Point est, il est difficile de répondre à cette question avec SomeProperty et Foo() et Bar(). Il y a quelque chose de bon, réponses génériques défense && pour les cas habituels, mais je n'aurais jamais totalement exclure la seconde forme.