Kolega vieną dieną entuziastingu veidu parodė štai šį straipsnį, kuris teigia, jog “kiekvienas metodas turi turėti nedaugiau 10 eilučių kodo”.
Straipsnyje pateikiami vien privalumai, todėl norėčiau pasiteirauti kolegų programuotojų - kokia jų nuomonė apie šiuos teiginius?
Easier to test / Lengviau testuoti
Kiek pačiam teko susidurti su testavimu, tai manyčiau šis punktas man neatrodo teisingas. Kodėl? Kadangi metodai turės palyginti mažai kodo eilučių, pačių metodų atsiras daugiau. Norint padidinti “code coverage” lygį reikės rašyti daugiau testų. Ar ne taip? Galbūt testų rezultatai bus tikslesni? Hm… esu rašęs per mažai testų, kad galėčiau ką daugiau pakomentuoti.Easier to reuse / Lengviau panaudoti kodą keliskart
Su šiuo punktu manau, kad sutikčiau.Easier to modify / Lengviau modifikuoti
Čia man asmeniškai labai nekonkretus pasakymas, aš tai sakyčiau, kad nėra skirtumo. Pačių metodų turinį modifikuoti tai tikrai lengviau, tačiau pakeiskime metodo pavadinimą, pridėkime privalomą parametrą ir turėsime “zulinti” per kodą pirmyn-atgal ieškodami kur ką pakeisti. Žinoma, dabartiniai IDE turi funkcijas palengvinančias šį darbą, tačiau vistiek būna situacijų, kuomet jos nevisas vietas suranda ir pakeičia.Less bugs are discovered on short methods and on short classes. / Nedidelėse klasėse ir metoduose aptinkama mažiau klaidų
Gal ir tiesa, tačiau aš manau, kad tas klaidas surasti ir pašalinti gali būti pakankamai sudėtinga, kuomet kodas labai išskaidytas. Ypač logines.Development team codes faster, because there is less need for refactoring. / Programuotojai dirba greičiau, nes nereikia kodo refaktorinti.
Apie šį punktą taip pat neturiu konkrečios nuomonės, kadangi nėra tekę dirbti didesnėje komandoje. Ką jūs manote?
Taigi, kokia Jūsų nuomonė šiais klausimais?
02 Rgs 08
22:33
Dėl testavimo - it depends. Realiai aš ne visai pritariu šitam būdui <10 lines.
Aš pritariu teiginiui, jog vienas metodas turi atlikti vieną konkretų darbą.
03 Rgs 08
00:23
testavimo punktas tarsi išplaukia iš kitų - kuo mažiau kodo, tuo mažiau šansų, kad privelsi klaidų, atitinkamai mažesni testai. tačiau dėl reuse ir modifikavimo - labai priklauso nuo kalbos. o šiaip pritariu aurelijui dėl aiškiai apibrėžto metodų funkcionalumo
03 Rgs 08
00:24
Kai dar užsiminėjau programavimu, turėjau taisyklę - paprogramė/metodas ne ilgesnė kaip 20 eilučių (na gal dar +1~2). Kodėl? Tokio ilgio tekstas telpa į vieną kompo langą, lengva apžvelgti, kad pamatyti veikimą/klaidas. Aišku, kai kada gaunasi prievartinis skaldymas, bet kai įpranti - pradedai galvoti būtent tokiais 20 eilučių “kvantais”
03 Rgs 08
15:01
Iš esmės su viskuo sutinku. Tik nereikia prieit iki kraštutinumų, kai metodas 12 eilučių ir dėl to pulti skaidyti
03 Rgs 08
23:49
10 eilučių, žinoma, kiek ekstremali riba. Atsimenu, Microsoft turėjo Windows projekte ribojimą, kad metodas turėtų tilpti į tipinį programuotojo ekraną. Sounds more reasonable.
05 Rgs 08
19:02
Visiska nesamone ;] taip kodo eiluciu galima isauginti labai smarkiai, plius prarandamas greitis, plius su laiku jei didesnis projektas prades metodu vardai strigt logiskumo atzvilgiu nes ju gali atsirast daug ir panasiu, plius skaidyt po 10 eiluciu gali tapt neygyvendinama, viska perdavinet per parametrus arba naudot globalius kintamuosius irgi beda, plius parasykit jus man y 10 eiluciu uzklausa y duombaze su prepared statementais kuriu bent 3-4 yra nekalbant apie daugiau, o taip dazniausia ir buna, plius kodo skaitomumas taps labai bjaurus kai reiks sokient nuo metodo prie metodo, pagal mano kodo standarta, metodas iki dvieju 900 pixel aukscio langu ;] gaunasi apie 100 eiluciu. Klase iki 1k eiluciu. Viskas aisku ir grazu, pasikomentuoji ir ramu, o del debugingo tai gal nebent cia ir laimima. Bet ir tai debuginant suziuret
desimtis metodu besisvaidanciu argumentais tarpusavyje yra neoptimalu.
07 Rgs 08
12:10
Vidai, OOP