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
if (!validate)
zamiastif (validate == false)
.IsValidCredentials
, chociaż gramatycznie niewygodny, jest powszechnym formatem do wskazywania logicznej wartości zwracanej.!
jest operatorem „NIE”, neguje każde wyrażenie logiczne. Podobnieif (!validate)
jest z odwrotnościąif (validate)
. Instrukcja if zostanie wprowadzona, jeślivalidate
nie jest prawdziwa.Odpowiedzi:
Tak jak w przypadku wszystkich tych rzeczy, to zależy.
Jeśli nie zamierzasz użyć wyniku połączenia,
ValidateCredentials
nie 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.
źródło
!ValidateCredentials
jest bardziej czytelny, ponieważ wyraźnie mówi, co robi w kodzie. To bardzo jasne. Jeśli funkcja, którą wywołujesz, nie ma nazwy „samodokumentującej”, być może lepiej będzie użyć zmiennej. Na obecnym etapie zaleciłbym pominięcie zmiennej i pozostanie przy posiadanym kodzie samodokumentującym.Dlaczego warto korzystać z dodatkowej zmiennej? Wolę zastosować pierwsze podejście, jest bardziej czytelne i proste.
źródło
Tak, jeśli warunek nie jest wystarczająco prosty, aby można go było wstawić i zapewnić, aby był czytelny.
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.
źródło
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
ValidateCredentials
i piszeszValidateCredentials(txtUser.Text, txtPassword.Text)
, wiesz, że powinieneś był utworzyć dodatkową zmienną.źródło
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.
źródło
if (cat.canOpenCanOfCatFood())
.Jest jeszcze jeden problem, który nie został jeszcze wskazany: ocena zwarcia . Jaka jest różnica między tymi dwoma fragmentami kodu?
Ex # 1:
Ex # 2:
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:
Pamiętaj o tych różnicach w swoim kodzie, wybierając między przykładami 1 i 2.
źródło
Rozwijając nieco kwestię czytelności ...
Mogę wymyślić dwa dobre powody, aby przechowywać wynik w zmiennej:
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).
Przechowywanie go w zmiennej poprawia czytelność, nadając warunkowi nazwę bardziej znaczącą niż to, co widzisz w wywołaniu funkcji.
Na przykład:
nie poprawia czytelności, ale to:
prawdopodobnie tak, ponieważ nie jest to od razu oczywiste, że
feof(file1) && feof(file2)
oznacza to, że zakończyliśmy przetwarzanie.passwordsMatch
Zmienna 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).
źródło
done_processing
zmienną. W końcu nazwadone_processing
pełni funkcję komentarza. A prawdziwy komentarz pozwala mi powiedzieć jedno lub dwa słowa o tym, dlaczego ten warunek sygnalizuje, że zakończyliśmy przetwarzanie. Nie dlatego, że jestem świetnym komentatorem, prawdopodobnie nie zrobiłbym żadnego z prawdziwego kodu ...done_processing
to bardziej trwały sposób wyrażania intencji.