Vérifier si une méthode retourne false: attribuer le résultat à une variable temporaire, ou mettre l'appel de méthode directement au conditionnel?

Est-ce une bonne pratique d'appeler une méthode qui renvoie des valeurs vraies ou fausses dans une instruction if?

Quelque chose comme ça:

private void VerifyAccount()
{
    if (!ValidateCredentials(txtUser.Text, txtPassword.Text))
    {
        MessageBox.Show("Invalid user name or password");
    }
}

private bool ValidateCredentials(string userName, string password)
{
    string existingPassword = GetUserPassword(userName);
    if (existingPassword == null)
        return false;

    var hasher = new Hasher { SaltSize = 16 };
    bool passwordsMatch = hasher.CompareStringToHash(password, existingPassword);

    return passwordsMatch;
}

ou est-il préférable de les stocker dans une variable puis de les comparer en utilisant des valeurs if else comme celle-ci

bool validate = ValidateCredentials(txtUser.Text, txtPassword.Text);
if(validate == false){
    //Do something
}

Je ne fais pas seulement référence à .NET, je fais référence à la question dans tous les langages de programmation, il se trouve que j'ai utilisé .NET comme exemple

Comme pour toutes ces choses, cela dépend.

Si vous n'utilisez pas le résultat de votre appel à, ValidateCredentialsil n'est pas nécessaire (sauf à des fins de débogage) de stocker le résultat dans une variable locale. Cependant, si cela rend le code plus lisible (et donc plus facile à maintenir), une variable va avec.

Le code ne sera pas sensiblement moins efficace.

Pourquoi utiliser une variable supplémentaire? Je préfère utiliser la première approche, elle est plus lisible et simple.

Est-ce une bonne pratique d'appeler une méthode qui renvoie des valeurs vraies ou fausses dans une instruction if?

Oui, si le conditionnel n'est pas assez simple pour être intégré et qu'il soit lisible.

ou est-il préférable de les stocker dans une variable puis de les comparer en utilisant des valeurs if else comme celle-ci

Vous ne devez le faire que si vous utilisez la valeur à plusieurs endroits ou si vous en avez besoin pour rendre le code plus lisible. Sinon, l'affectation à une variable n'est pas nécessaire. Un code inutile est au mieux un gaspillage et au pire une source de défaut.

Laisse voir...

Parce qu'il s'agit de KISS , il n'est pas nécessaire de créer une variable supplémentaire lorsque vous pouvez vous en passer. De plus, il n'est pas nécessaire de taper plus ... quand il n'y en a pas besoin.

Mais ensuite, parce que vous SECHEZ , si vous appelez plus tard ValidateCredentialset que vous vous retrouvez à taper, ValidateCredentials(txtUser.Text, txtPassword.Text)vous savez que vous devriez avoir créé une variable supplémentaire.

Oui, il est généralement bon d'utiliser de telles méthodes comme si les conditions étaient réunies. Il est cependant utile si le nom de la méthode indique qu'elle renvoie un booléen; par exemple CanValidateCredentials. Dans les langages de style C, cette méthode prend souvent la forme de préfixes Is et Can, et en Ruby avec le "?" suffixe.

Il y a une autre préoccupation qui n'a pas encore été soulignée: l' évaluation des courts-circuits . Quelle est la différence entre ces deux fragments de code?

Ex # 1:

if(foo() && bar() && baz())
{
    quz();
}

Ex # 2:

bool isFoo = foo();
bool isBar = bar();
bool isBaz = baz();
if(isFoo && isBar && isBaz)
{
    quz();
}

Ces deux fragments de code semblent faire la même chose, mais si votre langue prend en charge l'évaluation des courts-circuits, ces deux fragments sont différents. L'évaluation de court-circuit signifie que le code évaluera le minimum dont il a besoin pour réussir ou échouer une condition. Si l'exemple # 1, si foo () renvoie false, bar () et baz () ne sont même pas évalués. Ceci est utile si baz () est un appel de fonction de longue durée car vous pouvez l'ignorer si foo () retourne false ou foo () retourne vrai et bar () retourne faux.

Ce n'est pas le cas dans l'exemple # 2. foo (), bar () et baz () sont toujours évalués. Si vous vous attendez à ce que bar () et baz () présentent des effets secondaires, vous aurez des problèmes avec l'exemple # 1. L'exemple # 1 ci-dessus est en fait équivalent à ceci:

Ex # 3:

if(foo())
{
    if(bar())
    {
        if(baz())
        {
            quz();
        }
    }
}

Soyez conscient de ces différences dans votre code lorsque vous choisissez entre les exemples # 1 et # 2.

Développer un peu le problème de lisibilité ...

Je peux penser à deux bonnes raisons de stocker le résultat dans une variable:

1. Si vous comptez utiliser la condition plusieurs fois, l'enregistrer dans une variable signifie que vous ne devez appeler la fonction qu'une seule fois. (Cela suppose que la valeur stockée est toujours valide; si vous devez la tester à nouveau, cela ne s'applique bien sûr pas.)

2. Si le stockage dans une variable améliore la lisibilité en donnant à la condition un nom plus significatif que ce que vous voyez dans l'appel de fonction.

Par exemple, ceci:

bool foo_is_ok = is_ok(foo);
if (foo_is_ok) ...

n'aide pas la lisibilité, mais ceci:

bool done_processing = feof(file1) && feof(file2);
if (done_processing) ...

le fait probablement, car ce n'est pas immédiatement évident, cela feof(file1) && feof(file2)signifie que nous avons terminé le traitement.

La passwordsMatchvariable dans la question est probablement un meilleur exemple que le mien.

Les variables à usage unique sont utiles si elles donnent un nom significatif à une valeur. (C'est bien sûr pour le bénéfice du lecteur humain.)