C# véletlenszerű számgenerálásnál meglehet adni "kivéve" értéket? (bővebben lent)
Sziasztok!
Véletlen szám generálásánál meglehet adni kivételt? A következő a helyzet:
Végrehajtatok két véletlen szám generálást 0,100 értékek között. A második generálásnál viszont feltételül kéne adnom, hogy amit generál az nem lehet egyenlő az első generálásnál kapott értékkel? Első körben 'if' függvényre és a végén 'goto;' --> újragenerálásra gondoltam, de meglehet oldani esetleg egy sorban valami '!= X' megadással esetleg az egyenletben?
Az a Reiter könyv egy tragédia egyébként.
És pont erre valók a vezérlési szerkezetek, csak azokat követni is lehet.
Nem tudom, nem ismerek túl sok könyvet, de nemrég beleolvastam a Reiter könyvbe és borzasztó.
Összevissza veszi a témaköröket, olyan dolgokkal magyaráz a könyv elején, amiket a könyv végén tárgyal, követhetetlen.
A kérdezőnek: egyáltalán nem erőforrás-igényes, a probléma kizárólag elvi. Az ugrással mindössze annyi a baj, hogy túlzott szabadságot ad a programozást tanulónak, aki hajlamos lehet a gondjait megoldandó a programrészek átrendezése helyett ugrásokkal átdrótozni a programot. Ami azért válhat káros szokássá, mert a sok ugrás logikailag nehezen követhetővé tudja tenni a programot. Ha azok nem egy szorosan vett séma szerint történnek, hanem ahogy éppen alakul. A logikailag nehezen követhető program pedig a program írójának is nehezíti a hibák keresését és megoldását, ez rejtett hibák megmaradását teszi valószínűbbé, és lassítja a fejlesztőmunkát. Ha pedig másnak kell a programot átnéznie, azt meg kiveri a víz. (Megnézheted ezt is: http://www.gyakorikerdesek.hu/szamitastechnika__programozas_..
De az ugrás egyáltalán nem valami emberiség elleni bűn, hanem csak egy bizonyos szemlélet szerint lehetőleg kerülendő megoldás. Az ugrás használható gondosan, szervezetten is, mindig csak a szükséges távolságra, kevés és logikus belépési pontra.
Az olyan programnyelv, amelyben eljárásokból és függvényekből áll össze a program, túl nagy távolságokra nem is lehet ugrani, mert az eljárás határát nem lehet vele átlépni. Ezért ha az ugrásra tényleg szükség van, nem kell cifrázni, címke, goto, aztán menjünk tovább.
Viszont a dühöngőknek igaza van abban, hogy mivel az ugrás, egész pontosan a GOTO-val előírt ugrás tényleg összegubancolhatja a szálakat, úgy helyes, ha a programozó mielőbb rászokik arra, hogy az ún. strukturált programozási metódust követő elemekből építi a programot. A fáradság hosszabb távon mindenképpen megtérül.
Ha a dolog nagyon sürgős, akkor mehet az ugrás is, de aztán mindenképpen érdemes átgondolni, hogy szabályos egy- vagy többágú elágazásokkal és ciklusokkal hogyan lehet ugyanazt megcsinálni. Néha úgy, hogy egy adott programszakaszt önálló eljárássá teszünk, és annak a meghívása több helyről is megtörténhet. Néha meg csak úgy, hogy kifejezetten ezért kilépésjelző lokális változókat kell felvenni, de az is megengedett, hogy egy DO WHILE 1 ... LOOP végtelen ciklust nyitunk egy programrész körül, amelyből egy vagy több BREAK utasítással úgy lehet kilépni, hogy garantáltan és nyilvánvalóan a LOOP utáni utasítás következik. Ez egy áttekinthetőbb megoldás. Vannak ilyen kis trükkök, és egyfajta szakmai önérzetből is célszerű ezeket kifundálni és rutinná tenni.
Hominida, nagyszerűen megmagyaráztad, hogy miért ne használjon valaki GOTO-t a 21. században, akkor viszont nem értem, hogy miért érveltél az elején mellette. A többi válaszoló aki a GOTO-tól sikítófrászt kapott ugyan ezt gondolta szerintem, csak lusta volt kifejteni.
Ha nem egy egyszer használatos eldobható programról van szó, ahol nem szempont a későbbi karbantarthatóság, akkor okés a dolog. Viszont ha később át kéne adni másnak egy programot, amiben GOTO-t használsz, szerintem az átvevő fejlesztő érdeklődéssel a szemében megkérdezné, hogy mit keres ez itt, ilyet utoljára az apja használt általános hatodikban informatika szakkörön.
Félreértettél. Elmagyaráztam, hogy mi a hátránya annak, ha valaki GOTO-kkal farigcsálja a programját működőképessé, és hogy mi az erdete annak, hogy egypáran sikítófrászt kapnak a GOTO hallatán, értelmezés nélkül, babonaszerűen. Sőt, a bunkó és öntelt kinyilatkoztatásokig elmennek, mintha ők lennének a programozás Nagy Öregjei.
Semmi köze a dolognak az időszámításunkhoz. A programozás elve semmi lényegesben nem változott az elmúlt hatvan évben. A GOTO használata sem tűnt el, csak másképp hívják, ezt már elmondtam.
Én amellett érveltem, hogy a GOTO elleni hitbuzgó tiltakozás értelmetlen, az utasítás nyugodtan használható, csak ésszel kell használni. Valamint hogy ma már gyakran kellemesebb érzés GOTO helyett más vezérlő utasításokkal operálni, mert rugalmasságot ad. De a GOTO nem tilos, csak ritkán nyereséges.
De ha valaki azért sikítozik, mert a GOTO-t lehet rosszul használni, az kapcsolja le a villanyt és bújjon egy kő alá, mert szinte mindent lehet olvashatatlanul használni. A híres Objektumokról ez igencsak elmondható, a C nyelvek összevont műveleteiről is, az összetett típusdeklarációkról is, de még a tömegesen felvett skalár változókkal is el lehet cseszni a programot. Mondjam azt, hogy ez már a 21. század, itt nincsenek skalár változók, csak azért, mert vannak más lehetőségek is?
Én két egyszerű Basic és egy assembly nyelvjáráson tanultam ki először a szakmát, ezért én nem pánikolok be az ugró utasításoktól. Megszoktam őket. Én el tudom őket olvasni. Megtanultam jól használni is őket. Ezért én nem sikítozok. Néha használom is, olyan nyelvben, amelyben ez a normális, például DOS batchben, de sejtésem szerint Linuxban ugyanígy tennék. Engem csak az idegesít, amikor a pánikolók, a tájékozatlanok az észt osztják, bunkó módon.
Kapcsolódó kérdések:
Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!