Проверка, возвращает ли метод значение false: присваивать результат временной переменной или помещать вызов метода непосредственно в условное выражение?

Является ли хорошей практикой вызывать метод, который возвращает значения true или false в операторе if?

Что-то вроде этого:

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;
}

или лучше сохранить их в переменной, а затем сравнить их, используя значения if else, как это

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

Я имею в виду не только .NET, я имею в виду вопрос на всех языках программирования, так получилось, что я использовал .NET в качестве примера.

Как со всеми этими вещами это зависит.

Если вы не собираетесь использовать результат вашего вызова, ValidateCredentialsтогда нет необходимости (кроме как в целях отладки) сохранять результат в локальной переменной. Однако, если это делает код более читабельным (и, следовательно, более легким для сопровождения), чтобы иметь переменную, пойти с этим.

Код не будет заметно менее эффективным.

Зачем использовать дополнительную переменную? Я предпочитаю использовать первый подход, он более читабелен и прост.

Является ли хорошей практикой вызывать метод, который возвращает значения true или false в операторе if?

Да, если условие недостаточно простое, чтобы его можно было встроить и сделать его читабельным.

или лучше сохранить их в переменной, а затем сравнить их, используя значения if else, как это

Это следует делать только в том случае, если вы используете значение в нескольких местах или вам нужно, чтобы код был более читабельным. В противном случае присвоение переменной не требуется. Ненужный код в лучшем случае является расточительным, а в худшем - источником дефекта.

Давай посмотрим ...

Поскольку все дело в KISS , нет необходимости создавать дополнительную переменную, когда вы можете обойтись без нее. Кроме того, нет необходимости печатать больше ... когда нет необходимости.

Но тогда, потому что вы СУХОЙ , если вы позже звонили ValidateCredentialsи печатали, ValidateCredentials(txtUser.Text, txtPassword.Text)вы знаете, что вы должны были создать дополнительную переменную.

Да, обычно хорошо использовать такие методы, как будто условия. Это полезно, хотя, если имя метода указывает, что метод возвращает bool; например CanValidateCredentials. В языках стиля C этот метод часто принимает форму префиксов Is и Can, а в Ruby - '?' суффикс.

Есть еще одна проблема, которая еще не была отмечена: оценка короткого замыкания . В чем разница между этими двумя фрагментами кода?

Пример № 1:

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

Пример № 2:

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

Эти два фрагмента кода, кажется, делают то же самое, но если ваш язык поддерживает оценку короткого замыкания, эти два фрагмента различны. Оценка короткого замыкания означает, что код оценит минимум, необходимый для прохождения или отказа условия. Если в примере № 1, если foo () возвращает false, bar () и baz () даже не оцениваются. Это полезно, если baz () является долгосрочным вызовом функции, потому что вы можете пропустить его, если либо foo () возвращает false, либо foo () возвращает true, а bar () возвращает false.

Это не так в примере № 2. foo (), bar () и baz () всегда оцениваются. Если вы ожидаете, что bar () и baz () будут демонстрировать побочные эффекты, у вас будут проблемы с примером №1. Пример №1 выше фактически эквивалентен этому:

Пример № 3:

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

Помните об этих различиях в вашем коде при выборе между примерами № 1 и № 2.

Немного расширив тему читабельности ...

Я могу придумать две веские причины для сохранения результата в переменной:

1. Если вы собираетесь использовать условие более одного раза, сохранение его в переменной означает, что вам нужно вызывать функцию только один раз. (Это предполагает, что сохраненное значение все еще допустимо; если вам нужно повторно протестировать его, конечно, это не относится.)

2. Если сохранение его в переменной улучшает читабельность, давая условию имя, которое более значимо, чем то, что вы видите в вызове функции.

Например, это:

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

не помогает читабельность, но это:

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

возможно, так как это не сразу очевидно, это feof(file1) && feof(file2)означает, что мы закончили обработку.

passwordsMatchПеременной в вопросе, вероятно, лучший пример , чем мой.

Переменные одноразового использования полезны, если они дают значимое имя некоторому значению. (Это, конечно, на благо читателя.)