Přejít k navigační liště

Zdroják » Zprávičky » Jak dlouhá by měla být funkce v JavaScriptu?

Jak dlouhá by měla být funkce v JavaScriptu?

Zprávičky JavaScript, Různé

Nálepky:

Thomas Fuchs, autor Prototype a Scriptaculous, se na svém blogu zamýšlí nad tím, jak dlouhé by měly být funkce v JavaScriptu. Thomas Fuchs obhajuje názor, že by měly být dlouhé nejvýše deset řádků, a shrnuje argumenty pro tento postoj.

Komentáře

Odebírat
Upozornit na
guest
6 Komentářů
Nejstarší
Nejnovější Most Voted
Jirka

Timhle by se mel ridit kazdy programator, nejen javascriptar.

Karel
Satai

Tezko zaklad uspechu, ale rekl bych, ze kvalita kodu souvisi mimo jine s kratkymi funkcemi. Tezko z deseti radku udelat pevne pravidlo, ale jak je celkem pekne ukazano v knize Clean code, neni od veci se o deset (osm, dvanact, vyberte si sam) radku snazit. A nebo jeste jinak: kazda funkce nad deset radku je misto, kde by se programator mel zamyslet: Delam tu jen jednu vec? Neni cas na refactoring? Neujizdi mi zanoreni podminek a cyklu uz moc doprava?

Karel

V zásadě s vámi souhlasím, jen upozorňuji, že je tam implikace, nikoliv ekvivalence. Pokud si vezmete dobrý kód, pak zjistíte, že funkce jsou buď krátké, nebo se jedná o strukturovaný kód (špagetový kód kde se nic neopakuje a neskáče se dozadu ani dopředu je tím nejlepším, co vás mohlo potkat). Čili dobrý kód je krátký, v tom s vámi bezvýhradně souhlasím. Jenže s opačným tvrzením, že krátký kód je dobrý, nesouhlasím. Bohužel odkazovaný článek je napsán stylem „chcete psát lepší kód? Tak piště kratší funkce!“, což je dle mého názoru a zkušeností nesmysl. Pokud špatný kód rozkouskujete tak stále zůstane špatným kódem. Právě proto jsem uvedl odkaz na Cargo Cult, protože právě tohle je krásný příklad – lidé, kteří věří, že jejich program bude lepší jen tím, že bude z krátkých funkcí. To je mylné přesvědčení a následování tohoto kultu naopak problém zhoršuje, protože ho skrývá. Pokud vás programování samo nepřivede k psaní krátkých funkcí, pak násilné kouskování jen přidělává chyby a problémy. Program se totiž musí členit logicky a přirozeně, nikoliv po 10 řádcích. Pokud někdo program dělit neumí, tak ať ho raději nedělí.

mpts

…čirou náhodou nástroje speciálně pro JavaScript, které z deseti tisíc řádků udělají řádek jeden? ;-))

Mickey

To s tím vůbec nesouvisí, jde o čitelnost kódu pro programátora a jeho snadnější pochopení a následné provádění přesných a lokalizovaných změn.

Sám se snažím o to, aby funkce (metody) dělali jen jednu věc a pokud ta věc nejde udělat jednoduše (10 – 15 příkazů, volání), tak ji rozdělím na více dílčích částí (klasická analýza) a tu pak zase řeším jednoduše. To samé v objektovém návrhu, pokud potřebuje objekt ke svému životu enormě velké množství informací, je dobré jej rozdělit na několik dílčích objektů. Většinou se dostanete tak do max. 1. a 2. úrovně zanoření v objektovem modelu a při voláni funkcí (metod) max. do 3. az 4 úrovně.

TypeScript 7 v Go: rychlejší buildy, chybějící API

Betaverze TypeScriptu 7.0 ukazuje víc než rychlejší tsc. Microsoft převádí kompilátor a jazykovou službu z původní kódové základny psané v TypeScriptu a běžící jako JavaScript do Go, přidává paralelní typovou kontrolu a připravuje novou editorovou část postavenou na LSP. Pro část nástrojů ale nepůjde o prostou výměnu binárky: TypeScript 7 zatím nemá stabilní náhradu dnešního Compiler API.

Prolog nezmizel. Jen dnes žije v jiných nástrojích

Prolog nezmizel. Jeho hlavní myšlenku dnes potkáváme v nástrojích, které se Prologu na první pohled nepodobají: v CodeQL pro analýzu kódu, v Rego pro policy-as-code, v Z3 pro práci s omezeními a v Leanu pro formální důkazy. Každý řeší jiný problém, ale všechny připomínají totéž: někdy je lepší popsat vztahy, pravidla, omezení nebo tvrzení než vrstvit další if.