Является ли хорошей практикой вызывать метод, который возвращает значения 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 в качестве примера.
if (!validate)
вместоif (validate == false)
.IsValidCredentials
, хотя грамматически неудобно, является общим форматом для указания логического возвращаемого значения.!
является оператором «НЕ», он отрицает любое логическое выражение. Так жеif (!validate)
как и противоположностьif (validate)
. Оператор if будет введен, еслиvalidate
не верно.Ответы:
Как со всеми этими вещами это зависит.
Если вы не собираетесь использовать результат вашего вызова,
ValidateCredentials
тогда нет необходимости (кроме как в целях отладки) сохранять результат в локальной переменной. Однако, если это делает код более читабельным (и, следовательно, более легким для сопровождения), чтобы иметь переменную, пойти с этим.Код не будет заметно менее эффективным.
источник
!ValidateCredentials
более читабелен, потому что он явно говорит о том, что он делает в коде. Это очень ясно. Если вызываемая вами функция не имеет «самодокументируемого» имени, то лучше использовать переменную. В нынешнем виде я бы порекомендовал опустить переменную и использовать оставшийся самодокументированный код.Зачем использовать дополнительную переменную? Я предпочитаю использовать первый подход, он более читабелен и прост.
источник
Да, если условие недостаточно простое, чтобы его можно было встроить и сделать его читабельным.
Это следует делать только в том случае, если вы используете значение в нескольких местах или вам нужно, чтобы код был более читабельным. В противном случае присвоение переменной не требуется. Ненужный код в лучшем случае является расточительным, а в худшем - источником дефекта.
источник
Давай посмотрим ...
Поскольку все дело в KISS , нет необходимости создавать дополнительную переменную, когда вы можете обойтись без нее. Кроме того, нет необходимости печатать больше ... когда нет необходимости.
Но тогда, потому что вы СУХОЙ , если вы позже звонили
ValidateCredentials
и печатали,ValidateCredentials(txtUser.Text, txtPassword.Text)
вы знаете, что вы должны были создать дополнительную переменную.источник
Да, обычно хорошо использовать такие методы, как будто условия. Это полезно, хотя, если имя метода указывает, что метод возвращает bool; например CanValidateCredentials. В языках стиля C этот метод часто принимает форму префиксов Is и Can, а в Ruby - '?' суффикс.
источник
if (cat.canOpenCanOfCatFood())
.Есть еще одна проблема, которая еще не была отмечена: оценка короткого замыкания . В чем разница между этими двумя фрагментами кода?
Пример № 1:
Пример № 2:
Эти два фрагмента кода, кажется, делают то же самое, но если ваш язык поддерживает оценку короткого замыкания, эти два фрагмента различны. Оценка короткого замыкания означает, что код оценит минимум, необходимый для прохождения или отказа условия. Если в примере № 1, если foo () возвращает false, bar () и baz () даже не оцениваются. Это полезно, если baz () является долгосрочным вызовом функции, потому что вы можете пропустить его, если либо foo () возвращает false, либо foo () возвращает true, а bar () возвращает false.
Это не так в примере № 2. foo (), bar () и baz () всегда оцениваются. Если вы ожидаете, что bar () и baz () будут демонстрировать побочные эффекты, у вас будут проблемы с примером №1. Пример №1 выше фактически эквивалентен этому:
Пример № 3:
Помните об этих различиях в вашем коде при выборе между примерами № 1 и № 2.
источник
Немного расширив тему читабельности ...
Я могу придумать две веские причины для сохранения результата в переменной:
Если вы собираетесь использовать условие более одного раза, сохранение его в переменной означает, что вам нужно вызывать функцию только один раз. (Это предполагает, что сохраненное значение все еще допустимо; если вам нужно повторно протестировать его, конечно, это не относится.)
Если сохранение его в переменной улучшает читабельность, давая условию имя, которое более значимо, чем то, что вы видите в вызове функции.
Например, это:
не помогает читабельность, но это:
возможно, так как это не сразу очевидно, это
feof(file1) && feof(file2)
означает, что мы закончили обработку.passwordsMatch
Переменной в вопросе, вероятно, лучший пример , чем мой.Переменные одноразового использования полезны, если они дают значимое имя некоторому значению. (Это, конечно, на благо читателя.)
источник
done_processing
переменную. В конце концов, имяdone_processing
выполняет функцию комментария. И реальный комментарий позволяет мне сказать одно или два слова о том, почему это условие сигнализирует о том, что мы закончили с обработкой. Не то чтобы я был великим комментатором, хотя, вероятно, я бы не делал ни в реальном коде ...done_processing
является более надежным способом выражения намерения.