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
Inline Feedbacks
Zobrazit všechny komentáře
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ě.

Aktualizace WordPressu: Co se děje pod kapotou, když kliknete na tlačítko

Kliknete na „Update" a za chvíli je hotovo. Jenže co se přesně stalo? WordPress stáhl balíček, přepsal stovky souborů, upravil databázi — a na pár vteřin váš web zmizel pro všechny návštěvníky. Většinou to proběhne bez problémů. Ale když se to rozbije, chcete přesně vědět kde a proč. Pojďme si celý proces rozebrat od začátku do konce.

Je čas přejít na ESM-only. Ekosystém je připravený

V únoru 2025 vyzval Anthony Fu, autor populárních nástrojů kolem Vue, Nuxtu a Vite, ekosystém k opuštění duálního publikování npm balíčků a přechodu na ESM-only. S odstupem více než roku je jasné, že měl pravdu - a že se ekosystém posunul ještě rychleji, než sám čekal. Node.js dnes umí require() i na ESM moduly, podíl balíčků s podporou ESM přesáhl třetinu a komunita označuje rok 2026 za „rok plné adopce ESM".