if-else használata

Egymasba agyazott if-else-ek is eleg jol kovethetoek, ha az egyiptomi stilus helyett a normalisat hasznalod. Ha hosszu, oda tudod kommentelni, hogy ez epp melyike.
A masik, voltam olyan helyen, ahol policy miatt kotelezo volt a {} kitetele akkor is, ha egy utasias voot benne. Adott esetben segithet.
Ha azonos feltetelek menten agazol el, a switch-case is jo, opcionalisan "bitfieldekkel".

--
"Ne kúrd el mégegyszer a karakterkészletet, mert akkor ez a file is conflictolni fog a merge serveren és ez azért eléggé bosszantó!"

Én (és más kollégáim is) az 5. pontban leírtakat használjuk.

A lapos struktúra olvashatóbb, és könnyebb megérteni, illetve utólag módosítani, mint a rahedli if/else ágat. Ez pedig fontosabb annál, hogy ne legyen több kilépési pont.


if (there_is_accounting_for_tastes) {
if (flame_war_wanted) {
start_an_if_else_topic();
if (gigantic_war_needed) {
build_yet_another_method();
reason_why_all_else_fails();
}
} else {
break_a_bottle_of_wine();
}
} else {
do_whatever_you_want();
}


(sub)

5-ös, Return fast, Fail fast.
Ahogy tudjuk, hogy elértük a végeredményt vagy hibára futottunk, azonnal return / exception.
Szépen látható debuggoláskor is, hogy meddig jut el a végrehajtás a függvényben.

Tódítanám még a kérdést egy kollégámmal folytatott vita alapján.
Ha ezek az ifek függvényben vannak, akkor a lokális változót kötelező-e a deklarációnál inicializálni.
vagy
Elegendő az egyes ágakban.

A problematika abban rejlik, hogy a változót talán nem is használjuk minden ágban. (és/vagy) Elfelejtünk valamilyen ágon értéket adni és kész a baj. Vagy a program logikájából következik, hogy ha nem kap értéket a változó, az azért van, mert azon az ágon úgy sem használjuk.

Ez talán vetekszik az üres else ág kiírásával.

Az első tíz-/százezer kódsor után ki fog ez alakulni magától... de persze nem szükségképpen lesz azonos mások tapasztalatával.

Én például ilyesmiket szűrtem le [Megj: nem itt akarom megvitatni őket], hogy:

- Ne csesszük el a függvény paramétereit, mert elrontjuk a debuggolást

- Minden részeredmény kerüljön változóba, hogy könnyebb legyen debuggolni

- Minden függvénynek egy kilépési pontja legyen, ott lehet az erőforrás-felszabadítás meg a naplózás, valamint oda lehet tenni a megállási pontot a debuggerben

- Abból még sosem lett baj, ha egy komponens külön forrásprogramba került, még akkor sem, ha úgy indult, hogy 'ez csak pár sor lesz' [mindig úgy indul]

- Próbáljunk a 'valószínű' helyett a 'biztos'-ra célozni a programozásnál [kedvenc példám: először lekérdezem a dátumot, aztán az időt -- nem valószínű, hogy pont a kettő között legyen éjfél]

- Az inicializálatlan/felszabadított pointer legyen NULL, még akkor is, ha 'biztos, hogy ebben a helyzetben ebből nem lehet gond'. Lehet, hogy holnap éjjel valaki másnak kell hozzányúlnia, és azután már lehet gond.

- Próbáljuk a 'definíciót' és az 'implementációt' a lehető legjobban szétválasztani [például: typedef struct semmközödhozzá *MyHandle;]

- A valóságban nincs olyan, hogy a forrásprogramban 'átdefiniálom a TAB-karaktert'. Olyan van, hogy 'átdefiniálom az indentációt'.

- Az exception-ök fő előnye, hogy tönkrevágják a program-szerkezetet. Ugyanez igaz az ON ERROR GOTO szerű hibakezelésre.

- Próbáljunk mindig warningmentes fordítást produkálni [pl: -W -Wall -Werror], néha egy-egy warning hülyeség ugyan (pl a dlsym-visszaadott értékével kapcsolatos hiszti), de a legtöbb hasznos, megszívlelendő

- Az OO nagyobbrészt parasztvakítás, kisebbrészt szintaktika

- Ha a W-rendszernek olyan típusai vannak, hogy 'Wchar', 'Wint', 'Wpointer', akkor kezdhetünk arra gondolni hogy a fejlesztőkön erőt vett a hatalmi téboly.

- Ha X komponens azt állítja, hogy felülről kompatibilis Y komponenssel, akkor szinte biztos, hogy ez csak a leggyakrabban használt funkciókra vonatkozik, de lehet, hogy azokra is csak fenntartásokkal [pl: OpenSSL-1.1 vs 1.0.x]

- Ha egy program 'megkönnyíti' a programozó dolgát, az a nemtriviális esetekben megnehezítést jelent [például a 64-bites Windows system32-es kavarása]

- Nagyon sok szép módszer, szabály és technika létezik, ezek egyrésze triviális [pl: rajzoljunk köröket, és húzzunk a körök közé nyilakat], másrésze butaság, a harmadik része hasznos, de olyan sok van belőlük, hogy nem lehet mindet követni; ha kérdezik, bátran mondjad, hogy eddig a BUSH-módszertan elveit követted (ahol minden betű jelent valamit), de már tervezel áttérni a BRUSH-módszertanra, ami még ütősebb.

En azt gondolom, hogy ha ennyi ifed van egy fuggvenyben (1 es 2), akkor valahol valamit ki kellene szervezni. Tehat pl. van egy fuggvenyed, ami az egyik ilyen osszetett feltetelt vizsgalja es az alapjan ter vissza true-val vagy false-al. Ennek az az elonye, hogy konnyen tesztelheto, es olvashato is. (Mar ha szansz 10 masodpercet a fuggveny nev kigondolasara.)

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT
Refaktor Magazin

az ilyeneket miert nem a prog.hu -n beszelitek meg ?

sub

~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~
Fedora 24

A 2-es es 6-os pont kombinalva = erlangos verzio: pattern match a feltetelekre a fuggveny fejleceben, szukseg szerint guardokkal diszitve. A legspecifikusabb matchtol haladsz a kevesbe specifikus fele: kulon elonye, hogy ha egy feltetelre nincs match, akkor szepen elcrashel a process a megfelelo hibauzenettel a megfelelo fuggvenyre hivatkozva, nem pedig neman tovabbfut (ez jo!). Dialyzer elvileg szol forditasi idoben, ha nem teljeskoru a match (konfiguralhato).

A mellekhatasa, hogy matcheles kozben ki is bontjuk a kapott strukturat, igy ket legyet utunk egy csapasra. Pattern matching for president!

Ha egyszerubb a szerkezet, akkor esetleg olvashatobb egy case struktura, de az nagyon konnyen tulburjanzik (foleg az altalanosan elfogadott 80 karakteres sorszelesseg betartasaval), szoval csak ovatosan.

ui: micsoda? nincs erlang verzio a peldakodbol? hat ezt surgosen potolni kell :)

Körülményektől függ, hogy hogyan áttekinthetőbb.
Alapesetben az 1.-et (egymásba ágyazott if-ek) használom. 1-est könnyebb végigkövetni, a 2-esben az "!" kirakását könnyebb elrontani.

Ha hosszabb a kód, áttérek a 2-esre (össze &&-elt feltételek), viszont akkor arra törekszem, hogy az összetett feltételt kiemeljem:
bool ertelmesNev = cond1 && cond2 && cond3;
if (értelmesnév) ...

Másik változat, sem többszörös behúzás, sem összetett feltétel:
if (!cond1) {
} else if (!cond2) {
} else if (!cond3) {
} else {
}

8. Minden if után szerepeljen else ág is, akár üresen is, hogy lehessen látni, hogy nem felejtődött el.
Akkor meg azt nem lehet látni, hogy miért üres az else - elfelejtődött, avagy szándékosan üres.

Nem hasznalok else-t. Ternary operatort csak akkor ha nagyon rovid hozza a feltetel es a kod.