Sprawdzanie, czy metoda zwraca false: przypisać wynik do zmiennej tymczasowej, czy bezpośrednio wywołać metodę w warunkowym?

Czy dobrą praktyką jest wywoływanie metody, która zwraca wartości prawda lub fałsz w instrukcji if?

Coś takiego:

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

czy lepiej jest przechowywać je w zmiennej, a następnie porównywać je, używając innych wartości jak to

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

Mam nie tylko na myśli .NET, mam na myśli pytanie we wszystkich językach programowania, tak się składa, że ​​użyłem .NET jako przykładu

Tak jak w przypadku wszystkich tych rzeczy, to zależy.

Jeśli nie zamierzasz użyć wyniku połączenia, ValidateCredentialsnie ma potrzeby (oprócz celów debugowania) przechowywania wyniku w zmiennej lokalnej. Jeśli jednak sprawi, że kod będzie bardziej czytelny (a przez to łatwiejszy w utrzymaniu), będzie mieć do niego zmienną.

Kod nie będzie wymiernie mniej wydajny.

Dlaczego warto korzystać z dodatkowej zmiennej? Wolę zastosować pierwsze podejście, jest bardziej czytelne i proste.

Czy dobrą praktyką jest wywoływanie metody, która zwraca wartości prawda lub fałsz w instrukcji if?

Tak, jeśli warunek nie jest wystarczająco prosty, aby można go było wstawić i zapewnić, aby był czytelny.

czy lepiej jest przechowywać je w zmiennej, a następnie porównywać je, używając innych wartości jak to

Powinieneś to zrobić tylko wtedy, gdy używasz wartości w wielu miejscach lub potrzebujesz jej, aby kod był bardziej czytelny. W przeciwnym razie przypisanie do zmiennej nie jest konieczne. Niepotrzebny kod jest w najlepszym wypadku marnotrawstwem, aw najgorszym przypadku źródłem wady.

Pokazać...

Ponieważ chodzi przede wszystkim o KISS , nie ma potrzeby tworzenia dodatkowej zmiennej, gdy można się bez niej obejść. Nie trzeba też pisać więcej ... kiedy nie ma takiej potrzeby.

Ale ponieważ wysychasz , jeśli później dzwonisz ValidateCredentialsi piszesz ValidateCredentials(txtUser.Text, txtPassword.Text), wiesz, że powinieneś był utworzyć dodatkową zmienną.

Tak, zwykle dobrze jest stosować takie metody, jak gdyby warunki. Jest to pomocne, jeśli nazwa metody wskazuje, że metoda zwraca bool; na przykład CanValidateCredentials. W językach w stylu C metoda ta często przyjmuje postać przedrostków Is i Can, aw języku Ruby z „?” przyrostek.

Jest jeszcze jeden problem, który nie został jeszcze wskazany: ocena zwarcia . Jaka jest różnica między tymi dwoma fragmentami kodu?

Ex # 1:

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

Ex # 2:

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

Te dwa fragmenty kodu wydają się robić to samo, ale jeśli twój język obsługuje ocenę zwarć, te dwa fragmenty są różne. Ocena zwarcia oznacza, że ​​kod oceni minimum potrzebne do spełnienia lub niepowodzenia warunku. Jeśli przykład # 1, jeśli foo () zwraca false, bar () i baz () nie są nawet obliczane. Jest to przydatne, jeśli baz () jest długo działającym wywołaniem funkcji, ponieważ można je pominąć, jeśli foo () zwraca false lub foo () zwraca true, a bar () zwraca false.

Tak nie jest w przykładzie 2. foo (), bar () i baz () są zawsze oceniane. Jeśli oczekujesz, że bar () i baz () wykażą skutki uboczne, będziesz mieć problemy z przykładem 1. Przykład 1 powyżej jest faktycznie równoważny z tym:

Ex # 3:

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

Pamiętaj o tych różnicach w swoim kodzie, wybierając między przykładami 1 i 2.

Rozwijając nieco kwestię czytelności ...

Mogę wymyślić dwa dobre powody, aby przechowywać wynik w zmiennej:

1. Jeśli zamierzasz używać warunku więcej niż jeden raz, zapisanie go w zmiennej oznacza, że ​​musisz wywołać tę funkcję tylko raz. (Zakłada się, że przechowywana wartość jest nadal aktualna; jeśli trzeba ją ponownie przetestować, oczywiście nie ma to zastosowania).

2. Przechowywanie go w zmiennej poprawia czytelność, nadając warunkowi nazwę bardziej znaczącą niż to, co widzisz w wywołaniu funkcji.

Na przykład:

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

nie poprawia czytelności, ale to:

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

prawdopodobnie tak, ponieważ nie jest to od razu oczywiste, że feof(file1) && feof(file2)oznacza to, że zakończyliśmy przetwarzanie.

passwordsMatchZmienna w tej kwestii jest prawdopodobnie lepszym przykładem niż moje.

Zmienne jednorazowe są użyteczne, jeśli nadają sensowną nazwę pewnej wartości. (Jest to oczywiście korzystne dla ludzkiego czytelnika).