Czy wartości logiczne jako argumenty metody są niedopuszczalne? [zamknięte]

Liczby pozwalają również na przyszłe modyfikacje, gdzie teraz chcesz trzeciego wyboru (lub więcej).

Użyj tego, który najlepiej modeluje twój problem. W podanym przykładzie enum jest lepszym wyborem. Jednak w innych przypadkach wartość logiczna jest lepsza. Co ma dla Ciebie większy sens:

lock.setIsLocked(True);

Lub

enum LockState { Locked, Unlocked };
lock.setLockState(Locked);

W tym przypadku, mogę wybrać opcję logiczną, ponieważ myślę, że jest ona dość jasna i jednoznaczna, i jestem prawie pewien, że mój zamek nie będzie miał więcej niż dwa stany. Jednak drugi wybór jest ważny, ale niepotrzebnie skomplikowany, IMHO.

Myślę, że prawie sam na to odpowiedziałeś, myślę, że celem końcowym jest uczynienie kodu bardziej czytelnym, i w tym przypadku enum to zrobił, IMO zawsze najlepiej jest spojrzeć na cel końcowy, a nie ogólne zasady, może myśleć o tym bardziej jako o wytycznych, tzn. enum są często bardziej czytelne w kodzie niż ogólne Boole, ints itp, ale zawsze będą wyjątki od reguły.

Pamiętasz pytanie, jakie Adlai Stevenson zadał ambasadorowi Zorinowi w ONZ podczas kryzysu kubańskiego?

" jesteś na sali sądowej świata opinia już teraz, a Ty możesz odpowiedzieć tak lub nie . Zaprzeczyłeś, że [pociski] istnieć i chcę wiedzieć, czy I dobrze Cię zrozumiałem.... Jestem przygotowani do oczekiwania na moją odpowiedź aż piekło zamarza, jeśli to twoje decyzja."

Jeśli flaga, którą masz w swojej metodzie ma taką naturę, że można ją przypiąć do decyzji binarnej , a ta decyzja nigdy nie zmieni się w decyzję trójdrożną lub n-drogową, przejdź do boolean. Oznaczenia: twoja flaga nazywa się isXXX .

Nie rób tego logicznego w przypadku czegoś, co jest przełącznikiem trybu . Zawsze jest jeden tryb więcej niż myślałeś pisząc metodę w pierwszej kolejności.

Dylemat one-more-mode ma np. haunted Unix, gdzie możliwe tryby uprawnień plik lub katalog może mieć dzisiaj skutkować dziwnymi podwójnymi znaczeniami trybów w zależności od typu pliku, własności itp.

Dla mnie, ani używanie boolean, ani wyliczanie nie jest dobrym podejściem. Robert C. Martin ujmuje to bardzo wyraźnie w swoim Clean Code Tip #12: Eliminate Boolean Arguments :

Argumenty logiczne głośno deklarują, że funkcja robi więcej niż jedną rzecz. Są mylące i powinny zostać wyeliminowane.

Jeśli metoda robi więcej niż jedną rzecz, powinieneś raczej napisać dwie różne metody, na przykład w Twoim przypadku: file.append(data) i file.overwrite(data).

Za pomocą wyliczenie niczego nie wyjaśnia. To nic nie zmienia, to nadal argument flagi.

Są dwa powody, dla których wpadłem na to, że jest to zła rzecz:

1. Ponieważ niektórzy ludzie będą pisać metody takie jak:

   ProcessBatch(true, false, false, true, false, false, true);
   

   Jest to oczywiście złe, ponieważ zbyt łatwo jest mieszać parametry i nie masz pojęcia, patrząc na to, co określasz. Tylko jeden bool nie jest taki zły.

2. Ponieważ kontrolowanie przepływu programu przez prostą gałąź tak/nie może oznaczać, że masz dwie zupełnie różne funkcje, które są zawinięte w jedną w awkard sposób. Na przykład:

   public void Write(bool toOptical);
   

   Naprawdę, to powinny być dwie metody

   public void WriteOptical();
   public void WriteMagnetic();
   

   Ponieważ kod w nich może być zupełnie inny; mogą one wykonywać różne rodzaje obsługi błędów i walidacji, a może nawet muszą sformatować wychodzące dane w inny sposób. Nie możesz tego powiedzieć po prostu używając Write() lub nawet Write(Enum.Optical) (choć oczywiście możesz mieć jedną z tych metod, jeśli chcesz, po prostu wywołaj wewnętrzne metody WriteOptical/Mag).

Myślę, że po prostu to zależy. Nie robiłbym z tego nic wielkiego poza numerem 1.

Wyliczenia są lepsze, ale nie nazwałbym param logicznych "niedopuszczalnymi". Czasami po prostu łatwiej jest wrzucić jeden mały boolean i przejść dalej (pomyśl o prywatnych metodach itp.)

Wartości logiczne mogą być w porządku w językach, które mają nazwane parametry, takich jak Python i Objective-C, ponieważ nazwa może wyjaśnić, co robi parametr:

file.writeData(data, overwrite=true)

Lub:

[file writeData:data overwrite:YES]

Nie zgodzę się, że jest to dobra zasada . Oczywiście, Enum tworzy w niektórych przypadkach lepszy jawny lub szczegółowy kod, ale z reguły wydaje się on o wiele lepszy.

Najpierw pozwól mi wziąć twój przykład: Odpowiedzialność programistów (i zdolność) do pisania dobrego kodu nie jest tak naprawdę zagrożona przez posiadanie parametru Boolean. W twoim przykładzie programista mógł napisać taki sam kod, pisząc:

dim append as boolean = true
file.writeData( data, append );

Albo wolę więcej ogólne

dim shouldAppend as boolean = true
file.writeData( data, shouldAppend );

Drugi: Przykład Enum, który podałeś, jest tylko "lepszy", ponieważ mijasz CONST. Najprawdopodobniej w większości aplikacji przynajmniej niektóre, jeśli nie większość parametrów Czasu, które są przekazywane do funkcji, są zmiennymi. w takim przypadku mój drugi przykład (podając zmienne o dobrych nazwach) jest znacznie lepszy i Enum dałoby ci niewielkie korzyści.

Liczby mają określoną korzyść, ale nie powinieneś zastępować wszystkich wartości logicznych liczbami. Jest wiele miejsc, w których prawda / fałsz jest najlepszym sposobem na przedstawienie tego, co się dzieje.

Jednak używanie ich jako argumentów metody jest nieco podejrzane, po prostu dlatego, że nie możesz zobaczyć bez zagłębiania się w rzeczy, co mają robić, ponieważ pozwalają ci zobaczyć, co prawda / fałsz faktycznie oznacza

Właściwości (szczególnie z obiektowymi inicjalizatorami C#3) lub słowa kluczowego argumenty (a la ruby lub python) są znacznie lepszym sposobem, aby przejść tam, gdzie w przeciwnym razie użyłbyś argumentu logicznego.

C# przykład:

var worker = new BackgroundWorker { WorkerReportsProgress = true };

Przykład Rubiego

validates_presence_of :name, :allow_nil => true

Przykład Pythona

connect_to_database( persistent=true )

Jedyną rzeczą, o której myślę, gdzie argument metody boolean jest właściwą rzeczą, jest Java, gdzie nie ma ani właściwości, ani argumentów słów kluczowych. Jest to jeden z powodów, dla których nienawidzę Javy : - (

Chociaż prawdą jest, że w wielu przypadkach liczby są bardziej czytelne i rozszerzalne niż wartości logiczne, absolutna zasada, że "wartości logiczne nie są akceptowalne" jest głupia. Jest nieelastyczny i nieproduktywny-nie pozostawia miejsca na ludzki osąd. Są podstawowym typem wbudowanym w większości języków, ponieważ są przydatne-Rozważ zastosowanie go do innych wbudowanych typów: powiedzenie na przykład "nigdy nie używaj int jako parametru" byłoby po prostu szalone.

Ta zasada to tylko kwestia stylu, nie ma możliwości wystąpienia błędów lub wydajności uruchomieniowej. Lepszą zasadą byłoby "preferowanie enum niż booleanów ze względu na czytelność".

Spójrz na. Net framework. Wartości logiczne są używane jako parametry w kilku metodach. API. Net nie jest idealne, ale nie sądzę, że użycie boolean jako parametrów jest dużym problemem. Podpowiedź zawsze podaje nazwę parametru, możesz też zbudować tego rodzaju wskazówki - wypełnij swoje komentarze XML dotyczące parametrów metody, pojawią się one w podpowiedzi.

Powinienem również dodać, że jest przypadek, w którym powinieneś wyraźnie refactorować wartości logiczne do wyliczenia - gdy masz dwie lub więcej wartości logicznych na swojej klasie lub w swojej metodzie params, a nie wszystkie stany są ważne (np. nie jest ważne, aby oba były ustawione jako true).

Na przykład, jeśli twoja klasa ma właściwości takie jak

public bool IsFoo
public bool IsBar

I jest błędem, aby oba były prawdziwe w tym samym czasie, to, co masz w rzeczywistości, to trzy ważne Stany, lepiej wyrażone jako coś w stylu:

enum FooBarType { IsFoo, IsBar, IsNeither };

Niektóre zasady, których może lepiej przestrzegać twój kolega to:

Nie bądź dogmatyczny ze swoim projektem.
• Wybierz to, co najbardziej pasuje do użytkowników Twojego kodu.
• nie próbuj wbijać kołków w każdy otwór tylko dlatego, że podoba Ci się kształt w tym miesiącu!

Boolean byłby akceptowalny tylko wtedy, gdy nie zamierzamy rozszerzać funkcjonalności frameworka. Enum jest preferowane, ponieważ można rozszerzyć enum i nie łamać poprzednich implementacji wywołania funkcji.

Inną zaletą Enum jest to, że jest łatwiejszy do odczytania.

Jeśli metoda zadaje pytanie takie jak:

KeepWritingData (DataAvailable());

Gdzie

bool DataAvailable()
{
    return true; //data is ALWAYS available!
}

void KeepWritingData (bool keepGoing)
{
   if (keepGoing)
   {
       ...
   }
}

Argumenty metody Boolean wydają się mieć absolutnie doskonały sens.

To zależy od metody. Jeśli metoda robi coś, co jest bardzo oczywiste prawda / fałsz, to jest w porządku, np. poniżej [choć nie mówię, że jest to najlepszy projekt dla tej metody, to tylko przykład, gdzie użycie jest oczywiste].

CommentService.SetApprovalStatus(commentId, false);

Jednak w większości przypadków, takich jak przykład, który wymieniasz, lepiej jest użyć wyliczenia. Istnieje wiele przykładów w samym. NET Framework, gdzie ta konwencja nie jest przestrzegana, ale to dlatego, że wprowadzili tę wytyczne projektowe dość późno w cyklu.

To sprawia, że rzeczy są nieco bardziej wyraźne, ale zaczyna znacznie rozszerzać złożoność interfejsów - w czystym boolean wybór, taki jak dodawanie/nadpisywanie, wydaje się przesadą. Jeśli chcesz dodać kolejną opcję (której w tym przypadku nie mogę wymyślić), zawsze możesz wykonać refaktor (w zależności od języka)

Liczby mogą z pewnością uczynić kod bardziej czytelnym. Jest jeszcze kilka rzeczy, na które warto zwrócić uwagę (przynajmniej w. Net)

Ponieważ podstawowym zapisem enum jest int, domyślną wartością będzie zero, więc powinieneś upewnić się, że 0 jest rozsądną wartością domyślną. (Np. struktury mają wszystkie pola ustawione na zero podczas tworzenia, więc nie ma możliwości określenia wartości domyślnej innej niż 0. Jeśli nie masz wartości 0, nie możesz nawet przetestować enum bez odlewania do int, co byłoby złe styl.)

Jeśli Twoje enum są prywatne dla Twojego kodu (nigdy nie ujawnione publicznie), możesz przestać czytać TUTAJ.

Jeśli twoje liczby są opublikowane w jakikolwiek sposób do kodu zewnętrznego i / lub są zapisywane poza programem, rozważ ich jawne numerowanie. Kompilator automatycznie numeruje je od 0, ale jeśli zmienisz swoje liczby bez podawania im wartości, możesz skończyć z wadami.

Mogę legalnie pisać

WriteMode illegalButWorks = (WriteMode)1000000;
file.Write( data, illegalButWorks );

Do walki z tym, każdy kod, który zużywa enum, którego nie możesz być pewien (np. publiczne API) musi sprawdzić, czy enum jest poprawne. Możesz to zrobić poprzez

if (!Enum.IsDefined(typeof(WriteMode), userValue))
    throw new ArgumentException("userValue");

Jedynym zastrzeżeniem Enum.IsDefined jest to, że używa odbicia i jest wolniejszy. Występuje również problem z wersjonowaniem. Jeśli musisz często sprawdzać wartość enum, lepiej będzie, jeśli:

public static bool CheckWriteModeEnumValue(WriteMode writeMode)
{
  switch( writeMode )
  {
    case WriteMode.Append:
    case WriteMode.OverWrite:
      break;
    default:
      Debug.Assert(false, "The WriteMode '" + writeMode + "' is not valid.");
      return false;
  }
  return true;
}

Problem z wersjonowaniem polega na tym, że stary kod może wiedzieć tylko, jak obsłużyć 2 liczby, które masz. Jeśli dodasz trzecią wartość, Enum.Isdefiniowane będą prawdziwe, ale stare kod nie musi sobie z tym poradzić. UPS.

Jest jeszcze więcej zabawy, którą możesz zrobić z [Flags] enumami, a kod weryfikacyjny dla tego jest nieco inny.

Zwrócę również uwagę, że dla przenośności, powinieneś użyć call ToString() na enum, i użyć Enum.Parse() podczas odczytywania ich z powrotem. Zarówno ToString(), jak i Enum.Parse() mogą również obsługiwać [Flags] enum, więc nie ma powodu, aby ich nie używać. Pamiętaj, że to kolejna pułapka, bo teraz nie możesz nawet zmienić nazwy enum bez możliwości łamanie kodu.

Więc, czasami trzeba zważyć wszystkie powyższe W kiedy zadajesz sobie pytanie Czy mogę uciec z tylko bool?

IMHO wydaje się, że enum byłoby oczywistym wyborem w każdej sytuacji, w której możliwe są więcej niż dwie opcje. Ale na pewno są sytuacje, w których logiczny jest wszystko, czego potrzebujesz. W takim przypadku powiedziałbym, że użycie enum, w którym działa bool, byłoby przykładem użycia słów 7, gdy zrobi to 4.

Wartości logiczne mają sens, gdy masz oczywisty przełącznik, który może być tylko jedną z dwóch rzeczy (tj. stan żarówki, włączony lub wyłączony). Poza tym dobrze jest napisać to w taki sposób, aby oczywiste było, że to, co przekazujesz - np. zapis na dysku - niebuforowany, buforowany liniowo lub synchroniczny-powinno być przekazywane jako takie. Nawet jeśli nie chcesz teraz zezwalać na zapis synchroniczny (a więc jesteś ograniczony do dwóch opcji), warto rozważyć uczynienie ich bardziej szczegółowymi, aby wiedzieć, co robią to na pierwszy rzut oka.

To powiedziawszy, możesz również użyć False I True (boolean 0 i 1), a następnie, jeśli potrzebujesz więcej wartości później, rozwiń funkcję, aby wspierać wartości zdefiniowane przez użytkownika (powiedzmy, 2 i 3), a twoje stare wartości 0/1 będą ładnie portować, więc Twój kod nie powinien pękać.

Czasami łatwiej jest modelować różne zachowania z przeciążeniami. Kontynuacja twojego przykładu to:

file.appendData( data );  
file.overwriteData( data );

To podejście rozkłada się, jeśli masz wiele parametrów, z których każdy pozwala na stały zestaw opcji. Na przykład metoda otwierająca plik może mieć kilka permutacji trybu pliku (otwórz/Utwórz), dostępu do pliku (Odczyt/Zapis), trybu udostępniania (brak/Odczyt/Zapis). Całkowita liczba konfiguracji jest równa iloczynom kartezjańskim poszczególnych opcji. Oczywiście w takich przypadkach wielokrotne przeciążenia nie są odpowiednie.

Liczby mogą, w niektórych przypadkach, uczynić kod bardziej czytelnym, chociaż Walidacja dokładnej wartości enum w niektórych językach (na przykład C#) może być trudna.

Często parametr logiczny jest dołączany do listy parametrów jako nowe przeciążenie. Jednym z przykładów w. NET jest:

Enum.Parse(str);  
Enum.Parse(str, true); // ignore case

Ta ostatnia stała się dostępna w późniejszej wersji. NET framework niż pierwsza.

Jeśli wiesz, że będzie tylko zawsze dwie opcje, boolean może być w porządku. Enum są rozszerzalne w sposób, który nie złamie starego kodu, chociaż stare biblioteki mogą nie obsługiwać nowych wartości enum, więc wersjonowanie nie może być całkowicie pominięte.

EDIT

W nowszych wersjach C# możliwe jest użycie nazwanych argumentów, które IMO mogą uczynić kod wywołujący jaśniejszym w taki sam sposób, jak enums. Używając tego samego przykładu jak powyżej:

Enum.Parse(str, ignoreCase: true);

Gdzie zgadzam się, że Enum są dobrym sposobem, w metodach, w których masz 2 opcje (i tylko dwie opcje możesz mieć czytelność bez enum.)

Np.

public void writeData(Stream data, boolean is_overwrite)

Kocham Enums, ale boolean też jest przydatny.

To jest późny wpis na Starym poście, i jest tak daleko w dół strony, że nikt nigdy go nie przeczyta, ale ponieważ nikt już tego nie powiedział....

Komentarz w wierszu służy do rozwiązania nieoczekiwanego problemu bool. Oryginalny przykład jest szczególnie ohydny: wyobraź sobie, że próbujesz nazwać zmienną w funkcji deklearacja! To byłoby coś w stylu

void writeData( DataObject data, bool use_append_mode );

file.writeData( data, true );

Z

file.writeData( data, true /* use_append_mode */);

To naprawdę zależy od dokładnej natury argumentu. Jeśli nie jest to tak/nie lub prawda/fałsz, to enum czyni go bardziej czytelnym. Ale z enum musisz sprawdzić argument lub mieć akceptowalne domyślne zachowanie, ponieważ niezdefiniowane wartości podstawowego typu mogą być przekazywane.

Użycie enums zamiast booleans w twoim przykładzie pomaga uczynić wywołanie metody bardziej czytelnym. Jest to jednak substytut mojego ulubionego elementu wish w C#, nazwanego argumentami w wywołaniach metod. Składnia:

var v = CallMethod(pData = data, pFileMode = WriteMode, pIsDirty = true);

Byłoby doskonale czytelne, a następnie można zrobić to, co programista powinien zrobić, czyli wybrać najbardziej odpowiedni typ dla każdego parametru w metodzie bez względu na to, jak wygląda w IDE.

C # 3.0 pozwala na użycie nazwanych argumentów w konstruktorach. I Nie wiem, dlaczego nie mogą tego zrobić również metodami.

Wartości logiczne true/false tylko. Więc nie jest jasne, co to reprezentuje. Enum może mieć wymowną nazwę, np. OVERWRITE, APPEND, itd. Więc wyliczenia są lepsze.