> efi_gop() 90 sor, 2 hatalmas if block benne
Mámint? Az egyik az egészet öleli körbe, és azt nézi, hogy van-e gop támogatás. Nem szétvágható. A másik meg a paraméterátadást, hogyha sikerült az üzemmódot váltani, csak akkor csapja felül az értékeket. Nem látom be, hogy mi értelme lenne ezt szétszedni, különös tekintettel arra, hogy külön-külön egyik kódrészlet sem működőképes önmagában. Talán nem tűnt fel, de az első blokk végigfut a lehetséges módokon, és amit talál, azt állítja be a második. Szorosan összetartoznak, egyiknek sincs értelme a másik nélkül. Ráadásul ha szét akarnád venni, akkor át kéne adni paraméterben a lokális változók felét, a harmadát meg duplikálni kéne (mint a gop, status, mode info stb.).
> bios_open() szintén 90 sor, szintén két hatalmas if block benne
Igen, van ebben is if... és az feltűnt, hogy egy ciklus az egész, mert a könyvtárfa és elérési út bejárás rekurzív algoritmusát átkonvertáltam iterációra? Van fogalmad arról, hogy veremköltsége lenne annak, ha ez szétbontanád?
> fw_init() 100 sor, 4 if-else block benn
Újfent, minek? Semmi értelme, nem lehetséges "félig inicializálni". Vagy megteszed, vagy sem. Ráadásul itt kőkemény hardware-s függőségek is vannak benne, nem lehet csak úgy szétcincálni. Nem véletlenül vannak ott azok a kommentek. Esetleg efi_init-re és bios_init-re szétvágható.
Nem mindegy, mit mikor hívsz (például a memóriatérkép lekérés BIOS-on előbb kell történjen, mint a kernelbetöltés, mivel tudnod kell, hogy melyik régiók szabadok. Ezzel szemben UEFI alatt csakis a legeslegvégén, közvetlenül az ExitBootServices hívása előtt lehetséges, ugyanis a memóriatérkép folyamatosan változik időközben!)
> Például a fw_loadconfig mondjuk be tudja tölteni a configot kb4 féle képpen
De nem tudja, és minek is kéne tudnia? Ennek az egész projektnek pont az a lényege, hogy mindenre pontosan egy megoldást, méghozzá a lehető legegyszerűbb megoldást nyújta.
> hanem egy funkciónak 3-4 módja is bele van sűrítve egybe.
Megint meg kell kérdeznem, ne csak a levegőbe lógjon, amit mondasz, mire gondolsz konkrétan? Minden függvények pontosan egyetlen egy, jól definiált funkciója van. Alábbi posztomban meg is találod a leírást. TÉVEDÉS, amit mondasz, hogy többféle módja is lenne, mert nincs.
> A másik hogy az ifek belsejét kivenném egy függvénybe aminek a neve leírja hogy mit jelent az a feltétel, pl "if(!memcmp(s, "kernel", 6))", de ez már csak hab a tortán
Valóban, aranyba foglalnám a kezét annak, aki ilyet merészel csinálni, hogy soha a büdős életben ne tudjon többé programokat írni. Ettől mászok a leginkább a falra, ez a kontraproduktivitás nonpluszultrája meg csimborasszója. Nem lesz olvashatóbb a kód egy csöppet sem, viszont hazavágod a karbantarthatóságot: most egy úgy parancs bevezetéséhez pontosan egyetlen egy ponton kell belenyúlni a kódba, a Te a megoldásoddal meg a fasz tudja hány helyen kéne! Normááááális...?
> A másik a progress bar, tök jó hogy van de nem része a core funkcionalitásnak, én kicsapnám egy külön modulba.
Édes drága öcsém. Már hogy ne lenne része a core funkcionalitásnak az user visszajelzés??? Az egyik legfontosabb, máskülönben azt hinnéd, lefagyott a géped bekapcsolás után! Semmi más visszajelzés nincs, ez az egyetlen! És miféle modulról hablatyolsz itt, az egész betöltő egyetlen egy fájl (forrásban és binárisban is). Miféle modulok? Nagyon el vagy tévedve.
> A clean code lényege az olvashatóság, ez nehezen olvasható szerintem
A clean code arra való, hogy szar, nehezen karbantartható, és ótvar performanciájú programokat alkossanak, hogy aztán tripla áron refaktorálni kelljen félévente, és azért hívják úgy, hogy ez ne tűnjön fel nagyon a mánádzsereknek. Egyszer már ideraktam, de iderakom mégegyszer a linket: https://www.computerenhance.com/p/clean-code-horrible-performance
FONTOS, ez a cikk nemcsak dumál meg mellébeszél, ez nem marketingbullshit, hanem konkrét, kézzelfogható mérési eredményeket tartalmaz.
> persze ha ez az ára a hatékonyságnak és a hatékonyság a legfontosabb akkor nincs mit tenni.
Még mindig nem érted. Alacsony szinten nem lehet bohóckodni meg szórakozni. Ha négy-öt függvényhívás mélységed van, akkor máris betelik a verem, és itt nincs run-time stack-protektor, vagy canary ellenőrzés, mert bare metalon futsz. Akkor veszed csak észre, hogy baj van, amikor lefagy valami a stacksmashtől. Nemcsak arról van szó, hogy fontos-e a hatékonyság, hanem hogy mi lehetséges és mi nem erőforrásszegény környezetben.