it-swarm-eu.dev

Co je prokázáno jako dobrá maximální délka funkce?

Ovlivňuje délka funkce produktivitu programátora? Pokud ano, jaký je dobrý maximální počet řádků, aby nedošlo ke ztrátě produktivity?

Protože se jedná o vysoce hodnocené téma, zazálohujte si prosím nárok s některými údaji.

47
Gaurav

Protože jsem se v roce 1970 pustil do této bláznivé rakety, viděl jsem přesně jeden modul, který skutečně potřeboval být více než jedna tištěná stránka (asi 60 řádků). Viděl jsem spoustu modulů, které byly delší.

Z toho důvodu jsem napsal moduly, které byly delší, ale byly to obvykle velké stroje konečných stavů psané jako velké přepínače.

Zdá se, že část problému spočívá v tom, že se dnes programátoři neučí modularizovat věci.

Součástí problému jsou také normy kódování, které maximalizují plýtvání vertikálním prostorem. (Musím zatím potkat softwarového manažera, který si přečetl Gerald Weinberg 's " Psychologie počítačového programování ". Weinberg poukazuje na to, že více studií ukázalo, že porozumění programátora je v zásadě omezeno na to, co může programátor v daném okamžiku vidět. Pokud má programátor posouvat nebo otáčet stránku, jejich porozumění výrazně klesá: musí si pamatovat a abstraktovat.)

Jsem stále přesvědčen, že mnoho dobře zdokumentovaných nárůstů produktivity programátorů z DÁLE bylo způsobeno systémem FORTH „block“ pro zdrojový kód: moduly byly tvrdé- omezeno na absolutní maximum 16 řádků 64 znaků. Dalo by se nekonečně faktorovat, ale jste nemohli za žádných okolností napsat 17-řádkovou rutinu.

47
John R. Strohm

Jaká je správná velikost?

Závisí na jazyce, který používáte, ale obecně (a pro můj osobní vkus):

  • Ideálně , méně než 25 řádků.
  • Přijatelně , méně než 35 řádků.

Pokud je to víc, pak je to něco, k čemu se musím vrátit později a přepracovat.

Ale realisticky , jakákoli velikost, kterou musí být, když potřebujete něco doručit, a že to dává větší smysl v tuto chvíli, aby je vyplivlo takhle, dělá někdy ještě jednodušší je někdo před odesláním zkontrolovat. (ale stále se k tomu vrátíme později).

(Nedávno můj tým spustil program na naší kódové základně: našli jsme třídu s 197 metodami a další s pouze 3 metodami, ale jedna z nich byla 600 řádků. Roztomilá hra: co je horšího ze dvou zlých?)


Nyní za odpověď na další zen ... Obecně je považováno za dobrý postup citovat jednoho nebo dva skvělé muže, takže zde platí:

Všechno by mělo být co nejjednodušší, ale ne jednodušší. - A. Einstein

Dokonalost se konečně nedosáhne, když už není co přidat, ale když už není co vzít pryč. - A. De Saint Exupéry


Dodatek ke stylům komentářů

Jako doplněk k tomu by vaše funkce měly mít jasná jména vysvětlující jejich záměr. Co se týče komentářů, obvykle v rámci funkce nekomentuji:

  • komentáře říkají „proč?“ ,
  • kód říká „jak?“ .

Postačuje blok komentářů v horní části každé funkce (který vyžaduje vysvětlení). Pokud je vaše funkce malá a názvy funkcí jsou dostatečně explicitní, pak byste měli jen říct, čeho chcete dosáhnout a proč. Vložené komentáře používám pouze pro pole v některých jazycích nebo pro začátek bloku pro funkce, které porušují pravidla 25-35 řádků, pokud je záměr nejasný. Blokovací komentář používám uvnitř kódu, když se vyskytnou výjimečné situace (blok blokování, kde nepotřebujete nebo nechcete dělat nic, by měl mít komentář, například proč).

Více si přečtěte moje odpověď on Styl a doporučení kódování komentářů

31
haylem

Podle mého názoru by každá funkce měla být co nejmenší. Každá funkce by měla dělat pouze jednu věc a dělat to dobře. To opravdu neodpovídá na otázku o maximální délce, ale je to spíš moje pocity ohledně délky funkcí.

Chcete-li použít slova strýčka Boba, „Rozbalte, dokud už nemůžete víc vytáhnout. Rozbalte, dokud upustíte.“

12
Jason

Jaká by měla být maximální výška budovy? Závisí na tom, kde se staví nebo na jaké výšce chcete.
Můžete získat různé odpovědi od různých lidí, kteří přicházejí z jiného města.
Některé funkce skriptů a popisovače přerušení jádra jsou velmi dlouhé.

10
Huang F. Lei

Metoda, která pracuje pro mě, je: Mohu mít část delší funkce a dejte jméno, které dává smysl. Myslím, že délka metody není tak důležitá jako dobré pojmenování. Metoda by měla dělat to, co název říká, nic víc a méně. A měli byste být schopni dát dobré jméno. Pokud nemůžete pojmenovat svoji metodu jako dobrou, kód pravděpodobně není dobrý dohromady.

10
Mnementh

Dokud to musí být, co musí udělat, ale už ne.

10
Paul Nathan

Myslím, že existuje kompromis. Pokud máte mnoho krátkých metod, je často obtížnější je ladit než jedna dlouhá metoda. Pokud musíte přeskočit editor 20 nebo 30 různých časů, abyste mohli sledovat jedno volání metody, bude těžké udržet si vše ve vaší hlavě. Mezitím, pokud existuje jedna dobře napsaná jasná metoda, i když je to 100 řádků, je často snazší udržet si hlavu.

Skutečnou otázkou je, proč by položky měly být v různých metodách, a výše uvedenou odpovědí je opakované použití kódu. Pokud nepoužíváte kód znovu (nebo nevíte), pak může mít smysl nechat jej v jedné obří metodě, kterou lze snadno sledovat, a poté ji musíte znovu použít, rozdělte části, které je třeba znovu použít použití do menších metod.

Ve skutečnosti součástí dobrého návrhu metod je vytvoření funkčně soudržných metod (v podstatě dělají jednu věc). Na délce metod nezáleží. Pokud funkce dělá jednu dobře definovanou věc a má 1 000 řádků, je to dobrá metoda. Pokud funkce dělá 3 nebo 4 věci a má pouze 15 řádků, je to špatná metoda ...

6
Cervo

Od Cyklomatická složitost (Wikipedia):

Cyklomatická složitost části zdrojového kódu je počet lineárně nezávislých cest zdrojovým kódem.

  • Doporučuji ponechat toto číslo pod 10 v jedné metodě. Pokud se dostane na 10, pak je čas znovu faktorovat.

  • Existují nástroje, které mohou váš kód vyhodnotit a poskytnout vám číslo cyklomatické složitosti.

  • Měli byste se snažit tyto nástroje integrovat do svého sestavovacího potrubí.

  • Nepoužívejte doslova honit velikost metody, ale zkuste se podívat na její složitost a odpovědnost. Pokud má více než jednu odpovědnost, pak je pravděpodobně dobré znovu faktorovat. Pokud se jeho cyklomatická složitost zvýší, pak je pravděpodobně čas znovu faktorovat.

  • Jsem si docela jistý, že existují jiné nástroje, které vám poskytují podobnou zpětnou vazbu, ale ještě jsem neměl šanci se na to podívat.

5
CodeART

Pro mě je funkce jakákoli délka, kterou potřebuje. Většinu času, kdy ji rozdělím, je, když znovu použiji kód.

V zásadě se budu držet hlavního principu „vysoká soudržnost, nízká vazba“ a na délku není žádné omezení.

5
Ross

Otázkou by mělo být, kolik věcí by funkce měla dělat. A obvykle je vzácné, že potřebujete 100 řádků, abyste mohli dělat „jednu“ věc. Opět to záleží na úrovni, ze které se díváte na kód: Je hashování hesla jedna věc? Nebo je hashování a ukládání hesla jedna věc?

Řekl bych, že začněte ukládáním hesla jako jedné funkce. Když máte pocit, že hašování je jiné, a vy upravujete kód. Nejsem žádným odborným programátorem v žádném případě, ale IMHO, celá myšlenka funkcí začíná malá, že čím atomičtější jsou vaše funkce, tím vyšší je šance na opětovné použití kódu, nikdy nemusíte stejnou změnu provádět na více než jednom místě. , atd.

Viděl jsem SQL ložené procedury , které běží přes 1000 řádků. Je počet řádků uložených procedur také menší než 50? Nevím, ale to dělá čtení kódu, sakra. Nejen, že budete muset posouvat nahoru a dolů, musíte zadat několik řádků kódu název jako „toto ověření 1“, „tato aktualizace v databázi“ atd. - práci, kterou měl programátor udělat.

5
Narayana

Je pro mě snazší sledovat, co dělám, když vidím celou funkci najednou. Zde je návod, jak raději psát funkce:

  1. Dost krátký, aby se vešel na můj monitor s přiměřeným písmem.
  2. Pokud musí být delší než 1, dostatečně krátká, aby mohla tisknout na kus papíru v přiměřeném písmu.
  3. Pokud musí být delší než # 2, dostatečně krátká, aby mohla tisknout 2 na list papíru.

Zřídka píšu funkce déle než to. Většina z nich jsou obří přepínače C/C++.

5
Bob Murphy

dostatečně krátká, aby byla správně optimalizována

Metody by měly být tak krátké, aby dělaly přesně jednu věc. Důvod je jednoduchý: váš kód lze správně optimalizovat.

V jazyce JIT-ted, jako Java nebo C #, je důležité, aby vaše metody byly jednoduché, aby kompilátor JIT mohl kód rychle produkovat. Delší, komplikovanější metody samozřejmě vyžadují více času JIT. Také kompilátoři JIT nabízejí pouze hrst optimalizací a z toho mají prospěch jen nejjednodušší metody, což byla dokonce vyvolána v účinném C # Billa Wagnera.

V jazyce nižší úrovně, jako je C nebo C++, je důležité mít i krátké metody (asi tucet řádků), protože tímto způsobem minimalizujete potřebu ukládání lokálních proměnných v RAM spíše než v registru. (Aka „Rozlití registru“.) Všimněte si však, že v tomto neřízeném případě mohou být relativní náklady na každé volání funkce poměrně vysoké.

A dokonce i v dynamickém jazyce, jako je Ruby nebo Python), mají krátké metody také pomoc při optimalizaci kompilátoru. V dynamickém jazyce čím „dynamičtější“ je funkce, tím těžší je Například dlouhá metoda, která vezme X a může vrátit Int, Float nebo String, bude pravděpodobně provádět mnohem pomaleji než tři oddělené metody, z nichž každá vrací pouze jeden typ. To proto, že pokud kompilátor přesně ví, jaký typ funkce se vrátí, může také optimalizovat funkci volání funkce. (Např. nekontroluje typové převody.)

4
Chris Smith

Obvykle se snažím udržovat své metody/funkce podle toho, co se hodí na obrazovku monitoru 1680x1050. Pokud se nehodí, použijte k vyřešení úkolu pomocné metody/funkce.

Pomáhá čitelnosti na obrazovce i na papíře.

4
Jason

Na nic nenavrhuji pevný limit, protože některé funkce implementují algoritmy, které jsou ze své podstaty složité a jakýkoli pokus o jejich zkrácení by zkomplikoval interakce mezi novými, kratšími funkcemi, takže výsledkem by nebylo snížení jednoduchosti. Také nevěřím, že myšlenka, že funkce by měla dělat pouze „jednu věc“, je dobrým vodítkem, protože „jedna věc“ na vysoké úrovni abstrakce může být „mnoho věcí“ na nižší úrovni.

Pro mě je funkce určitě příliš dlouhá, pokud její délka způsobuje jemné porušení DRY) a extrakce části funkce do nové funkce nebo třídy by to mohla vyřešit. Funkce může být také příliš dlouho, pokud tomu tak není, ale lze snadno extrahovat funkci nebo třídu, díky níž by byl kód modulárnější způsobem, který bude pravděpodobně užitečný vzhledem k předvídatelné změně na silnici.

4
dsimcha

Velmi záleží na tom, co je v kódu.

Viděl jsem rutinní linii, se kterou jsem neměl žádný problém. Byl to obrovský přepínací příkaz, žádná možnost nepřekročila tucet řádků a jedinou regulační strukturou v jakékoli variantě byla jediná smyčka. V dnešní době by to bylo psáno s objekty, ale tehdy to nebylo možné.

Také se dívám na 120 řádků ve spínači přede mnou. Žádný případ nepřesahuje 3 řádky - stráž, přiřazení a přestávka. Analyzuje textový soubor, objekty nejsou možné. Jakákoli alternativa by byla těžší číst.

3
Loren Pechtel

Většina kompilátorů nezáleží na délce funkce. Funkce by měla být funkční, ale měla by být snadno pochopitelná, změnit a znovu použít pro lidské bytosti. Vyberte si délku, která vám nejlépe vyhovuje.

2
LennyProgrammers

Možná délka funkce není tak dobrá metrika. Pokusíme se použít cyklomatická složitost , také na metody, a jedním z budoucích pravidel kontroly zdroje kontroly, že cyklomatická složitost na třídách a metodách musí být nižší než X.

Pro metody je X nastaveno na 30, a to je docela těsné.

1
Antonio Bakula

Mým obecným pravidlem je, že funkce by se měla na obrazovku hodit. Existují pouze tři případy, které jsem zjistil, že mají tendenci toto porušovat:

1) Funkce odeslání. Ve starých časech to bylo běžné, ale většina z nich je v těchto dnech nahrazena dědičností objektů. Objekty však fungují pouze uvnitř vašeho programu, takže při práci s daty přicházejícími odjinud uvidíte příležitostné funkce odeslání.

2) Funkce, které provádějí celou řadu kroků k dosažení cíle a kde kroky postrádají dobré rozdělení. Skončíte s funkcí, která jednoduše volá dlouhý seznam dalších funkcí v pořadí.

3) Stejně jako # 2, ale pokud jsou jednotlivé kroky tak malé, že jsou jednoduše vloženy do sebe a ne samostatně.

1
Loren Pechtel