Ez szerintetek megfelelő definíció?

A "jó" itt talán nem a megfelelő jelző.

Sőt, ez nem is feltétlenül igaz.

Sőt!...

A lehető legrövidebb kód általában nem a lehető legjobban karbantartható kód. Hacsak nem szkriptnyelvről van szó, akkor nem kell spórolni a kódhosszúságon, a fordító úgyis amit tud, optimalizál. A kódminőségnek pedig a legfőbb összetevői az átláthatóság és a karbantarthatóság.

Mint ahogy alapelv a program kisebb részekre bontása is. Ez gyökeresen ellent mond az általad megfogalmazott "lehető legkevesebb függvényt tartalmazza" kitételnek.

Jó, de a "legkevesebb szükséges" nem azt jelenti, hogy "pont annyit, amennyivel átláthatóan megoldható a feladat".

Amire te gondolsz, az a kód újrafelhasználhatósága, akár programon belül is. De vedd észre azt is, hogy az univerzális nem mindig hatékony. Az adott feladat határozza meg, hogy mi az ideálisabb: írni egy általános(abb) függvényt, vagy kifejezetten az adott célra egyet?

"A lehető legkevesebb függvény alatt azt értem, hogy a legkevesebb szükséges függvényt tartalmazza, nem azt, hogy csak egyet vagy kettőt.

Például, ha kell három rokon függvény, akkor szerintem optimálisabb egyet megírni és paraméterezni, hogy mi legyen az eredmény, mint írni hármat.

Ha mondjuk egy string végeiről kell eltávolítani a space karaktereket, akkor jobb ha ír valaki egy Trim függvényt Left,Right,Both paraméterekkel, mintha írna egy TrimRight, egy TrimLeft és egy Trim függvényt."

Ez az egész gondolatmeneted ellentmond minden elvnek, ami a szoftverfejlesztés elmúlt évtizedei alatt kialakult.

Nincs rosszabb a minél nagyobb, minél hosszabb, mindent is megcsináló függvényeknél. Tesztelhetetlenek, megérthetetlenek, módosíthatatlanok.

Talán ne 2 hónap programozás után próbáld meg megfejteni a szoftverfejlesztést.

#7 "Ez az egész gondolatmeneted ellentmond minden elvnek, ami a szoftverfejlesztés elmúlt évtizedei alatt kialakult."

Ja, valóban. Ezért sincsenek az OOP-ben túlterhelhető függvények és operátorok, ugye?

Ez így zöldség.

1./ Mit jelent, hogy legoptimálisabb? Milyen szempontból? Egyáltalán mit értünk azon, hogy optimális? Még a régi tankönyvek is azt írták, hogy ez a kérdés legalábbis erősen gázos. Mert lehet optimalizálni futásidőre és memória foglaltságra. Vagy az egyik lesz "optimális" vagy a másik. Ld. pl. az egyik ezzel foglalkozó tankönyv minta feladata, állítsuk elő az első 5 000 db. prím számot a./ lehető legkisebb összes memória igénnyel, és b./ a lehető leggyorsabban. Érdekes feladat volt.

Az OOP esetén már megint más az optimális. És a mai fejlesztési trendek alapján is mást értünk optimálison. Ez egy tök jól használható "gumi" megfogalmazás. Mert (és ezt már Knuth is leírta valamelyik könyvében, már nem emlékszem melyikben olvastam), hogy nem létezik egyértelműen optimális megoldás. A mai világban már nem csak a klasszikus futásidőre, memória igényre lehet optimalizálni egy programot és adatszerkezeteket, hanem fejlesztés időszükséglete, tesztelés időszükséglete, karbantarthatóság, tovább fejleszthetőség, portabilitás (hardver és op.rendszer szinten is). Nagyon számottevőek sokszor a biztonság kérdései is.

2./ Lehető legkevesebb függvényt tartalmazza. Ennek eredménye a kezelhetetlen, áttekinthetetlen, se vége se hossza kódok. Sőt ne is tartalmazzon függvényt, és még ciklust se, mert minek /láttam olyat, hogy a ciklust a "barátunk" kifejtve írta meg, tényleg működött, csak hát na szóval érthetően nem szeretjük, egy esetet amikor tényleg hasznos volt később azért erről még írok/. Legyen az egész egy lineáris utasítás folyam. Akkor optimális? Térjünk vissza az assemblyben megírt alkalmazásokhoz ahol nem (vagy csak minimálisan) használtak "függvényeket" (ott szubrutinnak hívták).

3./ A legrövidebb kód szinte biztos, hogy nem lesz a legoptimálisabb semmilyen téren. A kód rövidítés eredményei azok a megoldások amelyek teljesen érthetetlenek, és nem javíthatóak. Ld. pl. perl regexpjei. Abban nem egy esetben egyszerűbb újra kitalálni, mint végig bogarászni, hogy "mire gondolt a költő". Szintén vannak olyan programnyelvek, hogy olyan rövíd a kód, hogy kb. csak az érti meg aki egyszer leírta. Amikor ma olyan elvárások vannak, hogy "öndokumentáló kód" ami nem a kód rövidülését fogja magával hozni. Nő a használt névtérben a nevek hossza (akár változó, akár eljárás, objektum, metódus, bármi). Ez pont ellene hat a rövid kódnak. Már nem emlékszem melyik rendszerben volt olyan (erről mint történeti érdekesség tanultunk), hogy a változó név max 2 db. nagybetű lehetett /a második karakter lehetett számjegy is, ezzel kb. 900 változót lehetett használni/, tömb esetén meg már csak 1 db. nagybetű lehett a tömb név. Ugyanígy a fájlnevek hossza sem véletlenül nő, sokáig 8+3 karakter volt (PC-n) a fájlnév, és 8 karakter a directory neve. Azzal lehetett rövidebb kódokat írni. Nem lesz semmivel sem jobb egy olyan kód ami rövidebb. Ugyanígy az sem biztos, hogy jó ha egy kód hosszú. És pont az optimalizáció esetén jön sok esetben, hogy a kód nyúlik. Pl. fejlesztettünk egy nagyon speciális beágyazott rendszerre programot. És amikor nagyon időkritikus volt egy rész, és azt minden más feltételtől függetlenül 128x kellett végrehajtani. Ha ciklussal írtuk volna meg akkor 1. érték adás a ciklus változónak /ez még a cikluson kívül/. 2. ciklus változó csökkentése. Ha ez 0 akkor kiugrás a ciklusból. Vissza a ciklus elejére. Ez alaphangon is ciklusonként +2 db. utasítás (csökkentés, ugrás) ami +256 db. utasítás a teljes ciklus során. (Az egész ciklus 4 hasznos utasításból állt). Áttekinthetlen, hosszú kód lett, de jelentősen gyorsabb lett ez a része a programnak. Nagyon messze volt a "rövid" kódtól. Igaz soha nem voltunk rá büszkék, hogy ezt így leírtuk, de a feladatot másképpen nem tudtuk volna megoldani, így is éppen, hogy belefértünk a max. futásidőbe.

Igazán én úgy fognám meg, hogy "jó a program":

1./ Azt csinálja amire kitalálták. Nem többet, nem kevesebbet.

2./ A tervezett életciklusa alatt karbantartható. <- Ez egy fontos dolog mert nem egyszer születnek olyan programok, amelyekről mindenki tudja, hogy összesen egyszer kell lefutnia. Pl. speciális számításokhoz használt programok. Ha egyszer lefutott többet nem is lesz rá szükség (rengeteg ilyen is van a tudományos/műszaki életben. Zsák szám írjuk az ilyeneket, hogy egy adott mérési elrendezés kiértékelését, modellezését végzi a program. Aztán jön egy tök más elrendezés és kell egy tök más program. És totál más pl. egy olyan banki rendszer amit megírtak valamikor az 1960-as évek elején, és máig használják.

3./ Jól dokumentált. Lehet tudni, hogy hogyan működik, miért úgy. Több helyen írják, hogy ha egy programozó legalább kb. 3 évig nem nyúlt hozzá egy régi programjához, kb. 3 évvel később olyan mintha egy idegen írta volna. (az egyes ezzel foglalkozó kutatások 2,5 - 5 év közé teszik ezt az időt, a programozó felkészültsége, szakmában eltöltött idő, és a program bonyolultságának függvényében).

4./ Összeségében gazdaságos a használata (pl. TCO modell alapján). Pl. a TCO modell azért jó ez esetben, mert figyelembe veszi az összes költséget onnan kezdve, hogy valakinek az agyában megfogalmazodott a gondolat, hogy egy ilyen programra szükség van, egészen odáig, hogy a programot "kidobják" /ld. pl. amit írtam 1x használt programok esete/. Ez figyelembe veszi a fejlesztés telje sidőszükségletét, a hardver árát, a hardver által elfogyasztott villany árát stb.

5./ Figyelembe veszi az alapvető biztonsági követelményeket (tűzbiztonság, élet- és balesetbiztonság, egészségkárosító hatások, környezet- és természetvédelem szempontjait is). Elsőre szoftver esetén ez furcsának hat, de pl. egy lélegeztető gép szoftverjének már vannak ilyen komponensei.

6./ Figyel a várható adatbiztonsági kockázatokra, és megfelelően kezeli azokat. Szintén fontos a "várható" ld. 1x használatos program esetén erre nem annyira kell figyelni, de pl. egy országos egészségügyi rendszer esetén ez egy nagyon komoly szempont lesz.

De ez nem csak a szoftverre hanem bármilyen műszaki/mérnöki alkotásra igaz.