Zbytečně dlouhý kód je IMHO častější problém. Upřednostňování kratšího kódu ...
Taky nemluvím o zbytečně dlouhém kódu, ale o přehledném. A ten se určitě nedosáhne minimalizací LOC. Příklad - ve wicketu (ale i pythonovském remi) bývá v konstruktorech komponent hodně dlouhá lineární sekvence vytváření a přidávání subkomponent. Jednotlivé subkomponenty mívají více řádků kódu, často jich několik spolu úzce souvisí. Když takový lineární kód nerozsekám do řady vhodně pojmenovaných metod, je z toho dlouhá nepřehledná špageta. Více LOC.
Někdy i pouhé vytvoření a úvodní nastavení proměnné, které by šlo vyřešit jednořádkovým ternárním operátorem, strčím do extra metody s if/else, když potřebuji okomentovat důvody jednotlivých variant a na první pohled nejsou zřejmé. Opět více LOC. Občas se hodí strčit do vhodně pojmenované metody i jeden řádek, než jej v toku kódu popisovat komentářem. Často právě takové krátké metody bývají vhodnými kandidáty na přetížení potomky, až za pár měsíců přijdou další požadavky vzniklé na základě praktického používání stávající funkčnosti. Protože ty metodky řeší právě jednu věc, kterou je požadavek v potomkovi rozšířit. Každá metoda volaná jen z jednoho místa logicky prodlužuje kód. Jenže má jasně viditelné a dané vstupy a jasný výstup, narozdíl od bloku kódu špagety, ze kterého pochází.
K tomu je ale potřeba pořádný editor, který umí metody včetně typů a vhodných názvů vytahovat na jednu klávesovou zkratku, a ne to dělat cut/paste...
Takových případů se najde mraky. Je to o čitelnosti a snadnosti pochopení, ne o celkové délce.
75 Odpovědí
10187 Zhlédnutí