Перевірка, чи метод повертає значення 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;
}

або краще зберігати їх у змінній, а потім порівнювати їх за допомогою інших значень, таких як ця

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

Я маю на увазі не тільки .NET, я посилаюся на питання на всіх мовах програмування. Так буває, що я використовував .NET як приклад

Як і у всіх цих речах, це залежить.

Якщо ви не збираєтеся використовувати результат свого дзвінка, ValidateCredentialsтоді немає необхідності (крім випадків налагодження) зберігати результат у локальній змінній. Однак, якщо він робить код читабельнішим (і, отже, більш доступним), матиме змінну.

Код не стане помірно менш ефективним.

Навіщо використовувати додаткову змінну? Я вважаю за краще використовувати перший підхід, він читабельніший і простіший.

Чи є гарною практикою викликати метод, який повертає істинні чи помилкові значення у операторі if?

Так, якщо умовне не є досить простим, щоб його можна було читати.

або краще зберігати їх у змінній, а потім порівнювати їх за допомогою інших значень, таких як ця

Ви повинні зробити це лише в тому випадку, якщо ви використовуєте значення в декількох місцях або вам потрібно, щоб зробити код більш читабельним. Інакше присвоєння змінній непотрібне. Непотрібний код - у кращому випадку марнотратний, а в гіршому - джерело дефекту.

Подивимося...

Оскільки це все про KISS , не потрібно створювати додаткову змінну, коли можна обійтися без неї. Крім того, немає потреби вводити більше ... коли немає необхідності.

Але тому, що ви СУХА , якщо ви пізніше дзвонили ValidateCredentialsі знаходите себе, набираючи текст, ValidateCredentials(txtUser.Text, txtPassword.Text)ви знаєте, що вам слід створити додаткову змінну.

Так, зазвичай добре застосовувати такі методи, як якщо б умови. Це корисно, хоча якщо назва методу вказує, що метод повертає bool; наприклад, CanValidateCredentials. У мовах стилю С цей метод часто має форму префіксів Is and 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 () завжди оцінюються. Якщо ви очікуєте, що бар () і 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Змінної в питанні, ймовірно, кращий приклад , ніж мій.

Змінні для одноразового використання корисні, якщо вони дають змістовну назву якомусь значенню. (Це, звичайно, на користь людському читачеві.)