it-swarm-eu.dev

Kdy a proč byste měli používat neplatné (místo např. Bool / int)

Občas se setkávám s metodami, kdy se vývojář rozhodl vrátit něco, co není pro tuto funkci kritické. Myslím, že když se podíváme na kód, zřejmě to funguje stejně dobře jako void a po chvilce přemýšlení se zeptám "Proč?" Zní to dobře?

Někdy souhlasím s tím, že nejčastěji je lepší vrátit něco jako bool nebo int, spíše než udělat void. Nejsem si však jistý, na celkovém obrázku, o výhodách a nevýhodách.

V závislosti na situaci může vrácení int upozornit volajícího na množství řádků nebo objektů ovlivněných metodou (např. 5 záznamů uložených do MSSQL). Pokud metoda jako "InsertSomething" vrací booleovský řetězec, mohu si nechat metodu navrženou tak, aby v případě úspěchu vrátila true, jinak false. Volající si může vybrat, zda bude na základě těchto informací jednat nebo ne.

Na druhou stranu,

  • Může to vést k méně jasnému účelu metody volání? Špatné kódování mě často nutí znovu zkontrolovat obsah metody. Pokud něco vrátí, řekne vám, že metoda je typu, ve kterém máte něco s navráceným výsledkem.
  • Dalším problémem by bylo, kdyby vám implementace metody nebyla známa, co se vývojář rozhodl vrátit, což není funkce kritická? Samozřejmě to můžete komentovat.
  • Návratová hodnota musí být zpracována, když by zpracování mohlo být ukončeno v závorkové metodě.
  • Co se stane pod kapotou? Dostala volaná metoda false kvůli hozené chybě? Nebo se vrátil nepravdivý kvůli vyhodnocenému výsledku?

Jaké máte s tím zkušenosti? Jak byste na to jednali?

30
Independent

V případě, že návratová hodnota bool označuje úspěch nebo neúspěch metody, dávám přednost paradigmatu Try- prefix použitému v různých metodách .NET.

Například metoda void InsertRow() by mohla vyvolat výjimku, pokud již existuje řádek se stejným klíčem. Otázkou je, je rozumné předpokládat, že volající zajistí, aby jejich řádek byl jedinečný před voláním InsertRow? Pokud odpověď zní ne, poskytl bych také funkci bool TryInsertRow(), která vrací false, pokud řádek již existuje. V jiných případech, jako jsou chyby připojení db, by mohl TryInsertRow stále vyvolávat výjimku, za předpokladu, že udržování připojení db je odpovědností volajícího.

32
Bubblewrap

IMHO vracející „stavový kód“ pramení z historických dob, než se výjimky staly běžnou součástí jazyků střední a vyšší úrovně, jako je C #. V dnešní době je lepší hodit výjimku, pokud některá neočekávaná chyba zabránila vaší metodě v úspěchu. Tímto způsobem je jisté, že chyba nezůstane bez povšimnutí, a volající to může vyřešit podle potřeby. V těchto případech je tedy v pořádku, že metoda nevrací nic (tj. void) namísto logického stavového příznaku nebo celočíselného stavového kódu. (Samozřejmě bychom měli dokumentovat, jaké výjimky může metoda vyvolávat a kdy.)

Na druhé straně, pokud se jedná o funkci v přísném smyslu, tj. Provádí určitý výpočet na základě vstupních parametrů a očekává se, že výsledek tohoto výpočtu vrátí, je typ návratu zřejmý.

Mezi nimi je šedá oblast, když se jedna může rozhodne vrátit některé „extra“ informace z metody, pokud je to pro její volající považováno za užitečné. Stejně jako váš příklad o počtu zasažených řádků ve vložce. Nebo pro metodu vložení prvku do asociativní kolekce může být užitečné vrátit předchozí hodnotu spojenou s tímto klíčem, pokud existuje. Taková použití lze identifikovat pečlivou analýzou (známých a předpokládaných) scénářů použití API.

28
Péter Török

Peterova odpověď pokrývá výjimky dobře. Další úvahy zde zahrnují Separace Command-Query

Princip CQS říká, že metoda by měla být buď příkazem, nebo dotazem, a ne oběma. Příkazy by nikdy neměly vrátit hodnotu, pouze upravovat stav a dotazy by měly pouze vracet a neměnit stav. Díky tomu je sémantika velmi jasná a přispívá ke zlepšení čitelnosti a udržitelnosti kódu.

Existuje několik případů porušování zásady CQS je dobrý nápad. Obvykle se jedná o výkon nebo bezpečnost vlákna.

14
Andy Lowry

Bez ohledu na to, jakou cestou budeš s tím chodit. Nemáte tam návratové hodnoty pro budoucí použití (např. Funkce vždy vrátí true), je to hrozná ztráta úsilí a nedělá to jasnější čtení kódu. Pokud máte návratovou hodnotu, měli byste ji vždy používat a abyste ji mohli používat, měli byste mít alespoň 2 možné návratové hodnoty.

3
refro

Psal jsem hodně prázdných funkcí. Ale protože jsem se dostal k celé metodě zřetězování trhlin, začal jsem se vracet spíše než prázdnota - možná také nechám někoho využít výhody návratu, protože nemůžete dělat dřep s prázdnotou. A pokud s tím nechtějí nic dělat, mohou to prostě ignorovat.

1
Wyatt Barnett