Idén 50 éves a BASIC programozási nyelv

Címkék
Idén 50 éves a BASIC programozási nyelv
2014-04-28T14:42:06+02:00
2014-05-12T11:43:26+02:00
2022-07-22T20:21:28+02:00
  • Kevesebb azonosító, kevesebb hibalehetőség. Átírtam az előbbi példakódot goto ugrásokra, úgy, mintha nem szerveztem volna ki:

    Előtte:
    public static bool FindFoo(StreamReader reader) ... ... if (FindFoo(new FileReader("foo.lists")) DoFooStuff();
    Utána:

    bool isFooFound = false; StreamReader reader = new FileReader("foo.lists"); while ((line = reader.ReadLine()) != null) { for (int i = 0; i < line.GetEntryCount(); i++) if ("foo".Equals(line.GetEntry(i))) { isFooFound = true; goto doFooStuff; } } doFooStuff: if (isFooFound) DoFooStuff();
    Szerintem a fenti változat jóval gyorsabban megérthető. Mondjuk nekem az az alapelvem, hogy egy kód _csak_ azt csinálja, ami a feladata. Ami alacsonyabb-szintű részfeladat, azt kíméletlenül kiszervezem. A példában a "foo" keresése tipikusan ilyen alacsonyszintű-feladat.
    Mutasd a teljes hozzászólást!
  • De miért lenne átláthatóbb, elegánsabb bármivel is a korai return, mint a goto a külső cikluson kívülre (vagy label ugyanígy)?
    Mutasd a teljes hozzászólást!
  • Szerintem jobb elkerülni az egymásba-ágyazott ciklusok használatát, de tény, hogy sokszor nem elkerülhető. Ugyanakkor több megoldás is van arra, hogy elegánsan lezárjunk egy ilyen esetet.

    Az egyik kedvencem, hogy a "kereső" jellegű ciklusokat kiszervezem egy metódusba, aztán returnnel visszatérek, így akármilyen mélyen is vannak egymásba ágyazva a ciklusok, egyértelmű a visszatérés. pl.

    public static bool FindFoo(StreamReader reader) { while ((line = reader.ReadLine()) != null) { for (int i = 0; i < line.GetEntryCount(); i++) if ("foo".Equals(line.GetEntry(i))) return true; } return false; }

    (String.GetEntry() és String.GetEntryCount() egy-egy kiterjesztett metódus listák felbontására)

    Szvsz a "goto" használatát az esetek 99.99%-ban el lehet kerülni, bár pont a múlt héten sikerült írnom egy eljárást, ahol másképp nem volt elkerülhető a redundancia, mint goto ugrással...
    Mutasd a teljes hozzászólást!
  • "A VB-s példában ha a külső (i-s) for ciklusból akarsz kilépni, akkor van más jól átlátható megoldás, mint a goto? Mert gondolom, hogy az Exit For az a belsőből lépne ki."

    Igen, az Exit For csak a belsőből lépne ki.
    Mi lenne az?
    Mutasd a teljes hozzászólást!
  • A VB-s példában ha a külső (i-s) for ciklusból akarsz kilépni, akkor van más jól átlátható megoldás, mint a goto? Mert gondolom, hogy az Exit For az a belsőből lépne ki.
    Mutasd a teljes hozzászólást!
  • Az egyetlen valtozat, ami nem hasznal tobb utasitast az a NPL eltal javasolt while/break/continue.

    Bevallom kicsit gyengusz volt a peldam, ha egyszer kivalthato lassulas nelkul.
    Max annyi lehet a mentsegem, hogy
    label re; ... re: ... goto re;
    while true do begin ... continue; ... else break end;
    Kevesebbet kell irni es nem lesz egy plusz indent.

    Kozben megnéztem még azt az 5 helyet ahol találtam goto-t es foleg ilyenek: peldaul stringkereso funkcioban a legvegen van egy olyan resz, ami ellenorzi, hogy WholeWords eseten kulonallo szo-e a talalat es ha nem, akkor ujraprobalkozik. Es ezt inkabb ugy csinalom meg, hogy csinalok egy beszedes WholeWordsRetry: labelt, minthogy az egesz masfel oldalas cuccot belepakoljam egy loop-ba.

    Az 5-bol a legbonyolultabb eset az egy FTP uploader volt, ami az egesz folyamatot levezenyli es a kozepebol barhonnan hiba eseten odaugrik egy cleanup: labelre, ami a legvegen van. Itt még loopon belul is kiugorhat, szoval break kizarva.
    Mondjuk ezt a funkcionalitast megoldhattam volna ugyis, hogy exceptionokat dobalok, majd pedig azokat figyelmen kivul hagyom, hogy legvegul a cleanup kod mindig lefusson.

    Akarhogy is, a legerosebb erven max az lehet, hogy meg akarok uszni egy kilometeres loop es indent beirasat mikozben beszedes nevet tudok adni a labelnek.

    Amugy ahhoz kepest, hogy semmi bajom a goto-val, meglepoen keveset talaltam belole a kodomban, es abbol is csak 1-et, amit a nested loopok miatt csak booleanokkal lehetne kivedeni.
    Mutasd a teljes hozzászólást!
  • ha jól értelmezem, akkor real_het a következő szerkezetet írta:
    label: A if P B goto label

    nyilván(?) a következőt szerette volna elkerülni (a "felesleges" checket):
    repeat A cont := P if cont B until not cont

    te a következőt csináltad belőle:
    while true A if P B continue else break

    szerintem abban igazad van, hogy ki lehet váltani, de a kód nem lett átláthatóbb szerintem,

    az "akadémiai" hozzáállás szerint ez lenne az egyik "megoldás":
    A while P B A

    csak úgye nem akarjuk az A-t külön "egységbe", azaz mondjuk föggvénybe "kiszervezni", és kibontani sem lenne szerencsés,

    persze írhatnánk a következőt is:
    while true A if not P break B

    most ez átláthatóbb (annál, amit real_het írt)?

    ki tudja...
    Mutasd a teljes hozzászólást!
  • Szerintem a labelled break nem goto.
    A goto-val előre-hátra tudsz ugrani, mig a labelled break-kel tudomásom szerint csak előre.

    Cserébe viszont van continue, amivel tudsz kvázi hátrafelé is ugrani. Nem mintha az irány lényeges lenne, mert a goto is nem azért ellenjavallott, mert hátrafelé ugrik, hanem mert megtöri az utasítások szekvenciális követhetőségét, ami nélküle amúgy biztosított (legalábbis szálon belül). Na, most ebből a szempontból a continue, a break vagy a függvény vége előtti return is éppen olyan rossz, hiszen ezek is azt eredményezik, hogy nem a soron következőre, hanem valamilyen ki tudja hol lévő (lehet a képernyőn nem is látható) utasításra kerüljön át a vezérlés.

    Más kérdés, hogy ennek ellenére gyakran használjuk, mert sok esetben ez a törés a linearitásban összességében nem rontja, hanem javítja az átláthatóságot azon keresztül, hogy egy csomó plusz kódot megspórol, amit egyébként be kellene írnunk ha nem használhatnánk ezeket a szerkezeteket, amit összességében már nehezebb lenne megérteni és követni, mint így. De ez nyilván ugyanígy igaz lehet bizonyos esetekben a goto-ra is.

    Amiért mégsem szokás annyira gyakran használni az inkább az, hogy a blokkon belüli goto-ra általában nincs szükség (többek között pont azért, mert van break, continue és társai, amik maguk is goto-k, csak kvázi fix a blokkhoz képest fix helyen lévő címkékre), a blokkhatárokon átívelő goto-t pedig vagy eleve nem engedi meg a legtöbb nyelv, vagy ha mégis, akkor általában a fent említette egyenlege ennek már negatív, és valójában nem egyszerűsíti, hanem nehezíti a kód követését, megértését.
    Mutasd a teljes hozzászólást!
  • "Ilyen alapon akkor egy sima break is béna goto."

    Nem.

    az csak egy GO

    Mutasd a teljes hozzászólást!
  • "tégy mindig és mindenben belátásod szerint"

    Köszi, én is ezt ajánlom neked.
    Mutasd a teljes hozzászólást!
  • Részemről befejeztem, elmondtam amit akartam, tégy mindig és mindenben belátásod szerint.
    Mutasd a teljes hozzászólást!
  • "Akkor:labelled break = béna goto"

    Ilyen alapon akkor egy sima break is béna goto.
    Tudsz jobbat esetleg?
    Mutasd a teljes hozzászólást!
  • " tudomásom szerint csak előre."

    Akkor:

    labelled break = béna goto


    "Ilyen alapon a return is goto volna."

    return = return
    Mutasd a teljes hozzászólást!
  • "labelled break = goto"

    Szerintem a labelled break nem goto.
    A goto-val előre-hátra tudsz ugrani, mig a labelled break-kel tudomásom szerint csak előre.
    Ilyen alapon a return is goto volna.
    Mutasd a teljes hozzászólást!
  • mikor jobb az intervallum eleje-vége tárolása és mikor jobb csak az eleje (mint volt a példában).


    Csak éppen a példában/kérdésben egyértelmű eleje és vége volt, nem pedig (csak) eleje
    Case 1, 10 To 15, Is > 100

    Nálad pedig 15.1-nél mennyi?
    {10, kodA},
    {16, invalid},


    Nálad egy olyan "bizonytalan" kód van, amihez tudni kell, a vizsgált adatnak milyen a típusa.
    Pl. Ha eddig nem voltak fillérek egy vizsgált adatbázis mezőben, mától pedig vannak, akkor tegnap még a 15-nél nagyobbra nem vonatkozott a kód, ma meg már (majdnem) 16-ig igen
    Tehát az adatforrás változása miatt (ami esetleg rajtad kívüli) programkódot kell változtatnod.
    Tehát a megoldásod:
    - hosszabb definíciót igényel
    - (másik felhasználó általi) értelmezéséhez ismerni kell a vizsgált adat típusát
    - nehezebbet tehető be 2. lépésként egy közbülső ág feltétel vagy ha a KodA eljárás neve változik, több helyen kell módosítani. (Persze a tied előnye, ha szét kell szedni a 3 ágat - KodA, KodB, KodC, a VB-s megoldásnál kell egy/két Copy/paste és pár törlés)


    És persze nem azt mondom, hogy van amikor nem jobb az általad leírt megoldás, csak éppen a Basic-es forma is indokolt (egyszerűbb és egyértelműbb) lehet bizonyos esetben.

    remélem 2 mp alatt átlátod,

    Átláttam. A
    Case .. 10 To 15,..
    és a
    {10, kodA},
    {16, invalid},
    vagy ugyan azt eredményezi, vagy nem.
    Mutasd a teljes hozzászólást!
  • "... Szinten boolean checkeket sporolok igy meg, ha egy csak repeat-until koze raknam az ujraprobalkozasokat ..."

    re: while PeekChar='''' do begin result:=result+GetChar; while not(PeekChar in[#0,''''])do result:=result+GetChar; result:=result+GetChar; end; if PeekChar='#' then begin result:=result+GetChar; while PeekChar in['$','0'..'9']do result:=result+GetChar; goto re; end;


    Lehet, hogy a példád nem a legjobb, de egy középen tesztelő végtelen ciklussal nem lehetne kiváltani a goto-t?

    while true do begin while PeekChar='''' do begin result:=result+GetChar; while not(PeekChar in[#0,''''])do result:=result+GetChar; result:=result+GetChar; end; if PeekChar='#' then begin result:=result+GetChar; while PeekChar in['$','0'..'9']do result:=result+GetChar; continue; end else begin break; end; end;
    Sosem programoztam még Pascal-ban, remélem jó a kód.
    Mutasd a teljes hozzászólást!
  • "ott vannak a labelled breakek, erre a valos use-casere"

    labelled break = goto
    Mutasd a teljes hozzászólást!
  • "De nekem az is logikusabb..."


    Mindig az adott feladat dönti el, mi a jó algoritmus.
    Azért a hatalmas tapasztalatoddal remélem 2 mp alatt átlátod, mikor jobb az intervallum eleje-vége tárolása és mikor jobb csak az eleje (mint volt a példában).

    Mutasd a teljes hozzászólást!
  • "... a javaban (ami ugye nem tamogatja a gotot, mert a "goto" karomkodas), ott vannak a labelled breakek ..."

    Számomra ez az etalon.
    Ezt igazán átvehetné a VB.net is, netán a C# is.
    Ez hasonlít egy picit a VB nevesített Exit For/Do/While utasításaira  azzal a különbséggel, hogy a Java/JavaScript-ben ezek egyedi nevekkel valósíthatók meg.
    Pl. a következő Java kód VB-ben vagy C#-ban macera volna:

    outerfor: for (i = 0; i < 10; i++) { for (j = 0; j < 10; j++) { if(i==5){ break outerfor; } ... code ... }

    Mindazonáltal VB-ben még mindig lehet trükközni pl. egy Exit Do-val:

    Do For i = 0 To 9 For j = 0 To 9 If i = 5 Then Exit Do End If Next ... code ... Next Loop While False
    Az ugró utasítások rontják a kód olvashatóságát, ebben van a legnagyobb veszélyük.
    Újabb szokásom az, hogy minden ugró utasítást - beleértve a return-t is - önálló sorba rakok és ha lehet kerülöm a használatát pl. inline if-fel a sor végén elbújva, bármennyire is szebbnek tűnik.
    Mutasd a teljes hozzászólást!
  • "De bizony megvannak a saját good practicejei (A Microsoft is ír párat), amikor bizony egy szuper megoldás. megnéztem mi van ott switch-case-ben goto nested loop goto"

    A VB-ben van:
    Exit For
    Exit Do
    Exit While
    valamint van Exit Select is, bár szerintem az nem fontos, mivelhogy a VB-ben nincs  fallthrough.

    Ezek az utasítások VB-ben sok esetben kitudják váltani a gyors goto-t, legalábbis én a goto-t csak sebesség optimalizálásra használnám, ha az extrém fontos, amúgy meg nem szoktam használni én sem.
    Megjegyezném hogy van még:
    Continue For
    Continue Do
    Continue While

    Egyébként nem értem, hogy a C szintaxisú nyelvekben miért nincsenek ilyen nevesített break és continue utasítások, szerintem hasznosak volnának.
    Mutasd a teljes hozzászólást!
  • "Nem folytatom, mert destruktív vagy."

    Értem. Ha te bizonyítás nélkül kimondod, hogy
    "így ahogy van életszerűtlen és/vagy beteges"
    az normális, ha érdekelne, hogy hogyan kell megvalósítani az destruktív.

    "néhány évtizedes tapasztalatot vagyok hajlandó díj és bérmentve átadni..."

    Azért kíváncsi lennék, hogy az éppen érintett nyelvben és az azzal manapság megoldandó feladatkörben ki tudna több évtizedes tapasztalatot átadni a másiknak. (Bár nem vagyok biztos benne, hogy a programozásnál a kor érdem, nem pedig csak állapot)

    "Egy ilyen szerkezetben ugye csak az intervallum elejét tárolod


    Hát ha neked egyszerűbb az 1 érték vizsgálatához megvizsgálnod, hogy egy következő elem mennyi (pl. mettől tart az 1-el kezdődő 1 elemű tartomány), akkor használd nyugodtan azt a megoldást.

    De nekem az is logikusabb, ha egy tartomány kezdetét és végét adom meg, nem pedig a kezdetét, és a végénél (valamennyivel) nagyobb értéket.

    Azt most ne nézzük, hogy senki nem mondta, hogy egész számok témakörében gondolkodunk.

    Egyébként meg a 2,3,4,5... nem feltétlenül kihagyandó, csak egy másik case vonatkozik pár elemre
    Mutasd a teljes hozzászólást!
  • "Szép segédtömb lesz:
    numberOfTheProducts>100"


    Nekem szokott sikerülni megfelelő algoritmust találni

    Egy nagyon általános esetre példa (csak neked, csak most):
    struct: int intervallumeleje, enum kodertek
    array of struct: összetett/zavaros értékhalmaz, amit kódértékké kell konvertálni

    A tömbben meg a példa szerinti esetre:
    Case 1, 10 To 15, Is > 100 {1, kodA}, {2, invalid}, // vagy kodX ha a csak példa hiányossága miatt nem tudjuk {10, kodA}, {16, invalid}, // vagy kodY ha a csak példa hiányossága miatt nem tudjuk {101, kodA}, {MaxInt+1,invalid} // feldolgozó kódtól függően elmaradhat
    Egy ilyen szerkezetben ugye csak az intervallum elejét tárolod, a vége pedig a rákövetkező elem - 1 [persze ezer másféle szerkezetet alkalmazhatsz]

    Ezzel a módszerrel egy felettébb átláthatatlan, szalmakazal értékkészletben is rendet lehet teremteni.
    Külön szedhető a program const(!) csoportjába, átláthatóan formázható. {szólottam volt a "magic number" fogalomról, olvass utána; most még jelzem azt is, hogy az átlátható/jól olvasható az jobb, mert szebb és érthetőbb}
    Mellesleg akár adatbázisban vagy paraméter TXT/XML-ben is tárolható, ha igény mutatkozik rá később.

    (*): "Külön szedhető" akár egy titkárnő is beviheti/ellenőrizheti a tartalom helyességét, nem kell drága programozó óradíjjal 100 oldalas programterv tartalmat egyeztetni a begépelt kóddal. [erős túlzás, de didaktív, ha a finom célzásokra nem vagy fogékony]
    -----------------------------------------------------------------------------------
    Ha nincs konstruktív kérdésed ezzel kapcsolatban, a "negatív hullámaiddal" "ne zavard köreimet"
    Mutasd a teljes hozzászólást!
  • Nem folytatom, mert destruktív vagy. {én meg nem háborúzni akarok, hanem 'okítanálak' (néhány évtizedes tapasztalatot vagyok hajlandó díj és bérmentve átadni... de ha nem kell, hát nem kötelező) }

    Amire utaltam, hogy nem a nyelvi képességeket kell felturbózni, mert igencsak nagyon nagy valószínűséggel a megoldandó feladat algoritmizálása a hibás, ha ilyen eszköz szükséges lehet.
    Mutasd a teljes hozzászólást!
  • "Konkrétan nem, mert ez a kis részlet így ahogy van életszerűtlen és/vagy beteges"

    Ez aztán az érv

    " Ezek a számok "valamitől" függenek, ha mástól nem a rendszertervtől"

    Mondjuk egy 5 éve kialakított rendszertervtől, amit nem kívánnak pár érték kizárása miatt újratervezni és egy halom részt végigtesztelni újból.

    De megértem, hogy könnyebb kifogást találni, hogy miért nem írod meg optimálisabban, mint megírni.

    "ekkor pl. egy segédtömb feldolgozásáv"

    Szép segédtömb lesz:
    numberOfTheProducts>100



    (Már várom a következő érved, hogy egy numberOfTheProducts esetén nem fordulhat ilyen elő. )
    Mutasd a teljes hozzászólást!
  • Az ugrótáblás switch utasítás nem syntax sugar, mivelhogy más C nyelvű utasításokkal nem lehet kiváltani, lásd: teljesítmény
    A lefordított gépikód teljesen másképp van megvalósítva, mint az if-nél.

    Hát azért ha nagyon badass vagy, egy function pointer arrayyel esetleg kiválthatod, de nem egyszerű, tényleg nem nevezném syntax sugarnak.

    (Ellentétben a VB.Net-es selecttel)
    Mutasd a teljes hozzászólást!
  • "...az első ötletem lenne, hogy ki kell rúgni az algoritmizálót/programtervezőt."

    A második ötletnek javaslom, hogy egy picit mélyedj el azon, hogy esetleg nem te vagy valamihez túlságosan hozzá szokva, ami neked általában célszerű és ezért nem veszed észre más dologban a lényeget.
    Csak az ugrótáblát emeled ki, mint előnyét a switch utasításnak.
    Pedig ezt csak nagyobb - többszázezres vagy többmilliós - ciklusokon belül tudod kihasználni észrevehetően és ahogy gyorsulnak a CPU-k a jövőben ezek a számok csak még nagyobbak lesznek és még extrémebb feladatoknál lesz jelentős a sebesség különbség az if-hez vagy a VB Select-Case-hez képest.
    If-else vs switch - Which is better?

    Viszont a másik előnyéről a redundancia mentes vizsgálatról és az ebből adódó  jól olvasható és karbantartható kódról mélyen hallgatsz, valahogy ez téged hidegen hagy.
    Számomra ez a furcsa.
    Alap dolognak tartom még egy kezdő programozónál is, hogy egy kód, ahol lehet legyen redundancia mentes.

    Egy "mezei", CIKLUSON KÍVÜLI switch elágazásnak a sebességbeli előnye az if-hez vagy a VB-féle Select-Case-hez képest nulla.
    Senki nem vesz észre nanoszekundumos különbségeket.
    Viszont fellehet tenni a kérdést, hogy melyik jobb a 3 közül?
    A kérdés abszolút nem értelmetlen, mert gyakran fordul elő, sokkal gyakrabban, mint egy több milliós ciklus.
    Szerintem és gondolom szerinted is, if utasítást használni a switch helyett teljesen értelmetlen.
    Redundáns, nem kifejező, nehezen karbantartható, stb.
    A VB-féle Select-Case utasítás egy switch utasítás helyett viszont mindenképpen javasolt az én értelmezésemben cikluson kívül, vagy egy rövidebb ciklusban.
    Hátránya nincs, csak előnye.
    Tudsz változókra is elágazni akárcsak az if utasítással.
    Tudsz lebegőpontos számokra, stringekre netán, dátumokra is elágazni.
    Tudsz intervallumok alapján elágazni.
    Biztonságosabb, mert nem kell break-et használnod, nincs fallthrough.

    "Mellesleg ez nem "case" abban az értelemben, hogy az valamiféle érték alapú ugrótábla."

    Nincs sehol kőbe vésve, hogy a case = ugrótábla.

    "A példa szervezésileg abnormális."

    A példa nem feltétlenül életszerű, de nem is az volt a kérdés, hogy az-e.

    " Egy ilyen "össze-vissza" szabályrendszer inkább if else jellegű megoldásért "kiállt"..."

    És valóban a VB Select-Case a háttérben ugyanúgy vagy hasonlóan fut le, mint egy if-else szerkezet.
    Ezért lehet azt mondani rá, hogy syntax sugar, akárcsak a feltételes operátor (?:) vagy pl. a for ciklus.
    A VB Select-Case szerkezete gyakorlatilag egy speciális szintaxisú if-else szerkezet, akárcsak a for ciklus, ami egy speciális szintaxisú while ciklus.

    " A switch utasítás attól "nagy" (a syntax sugaron kívül, aminek ugye örülünk, de nem abban áll a kiválóság)..."

    Az ugrótáblás switch utasítás nem syntax sugar, mivelhogy más C nyelvű utasításokkal nem lehet kiváltani, lásd: teljesítmény
    A lefordított gépikód teljesen másképp van megvalósítva, mint az if-nél.

    "Ez attól nagyszerű pl. hogy ha egy későbbi fejlesztésben az enum új értékkel bővül, akkor nem kell adott esetben kódsorok százezreit átnyálazni, hanem a warningok jelzik szépen a nem lekezelt helyeket."

    Ez csak akkor állja meg a helyét, ha nem használsz default ágat viszont helyette mindig felhasználod maradék enumerátor értékeket külön case ágakban fallthrough-val.
    Ennek az ára viszont egy nem túl kényelmes és nem túl szép kód.
    Biztonság szempontjából ugyan pluszt ad, de így sem fogod megúszni a tesztelést.
    Mindazonáltal én kiválóan megvagyok általában enélkül a "minden-enum-felhasználva" feature nélkül is.

    " Valójában (tisztán programozás filozofiai megközelítésben) egy 'switch' csak erősen korlátos értékhalmazt szelektálhat."

    Ezt az erősen korlátozott tudású elágazást hívják ugrótáblás elágazásnak, amit csak hosszabb ciklusokban tudsz jellemzően jól kihasználni.

    " Vagyis egy enum vagy char (mint kapott karakter) logikus, de 'általában' az integer (mint egy adat/érték), ne adj isten string, már valamiféle programtervezési hibára utal."

    Valóban logikus az enum vagy char vizsgálat ugrótáblával egy hosszú ciklusban, de mint írtam, cikluson kívül vagy egy rövidebb ciklusban a VB Select-Case elágazás sokal több előnnyel jár, valamint nem lehet programtervezési hiba, mert a háttérben egy if szerkezet gyakorlatilag.

    "Tehát rettentő nagy valószínűséggel ki kell tenni egy külön függvénybe..."

    Ha kiteszed függvénybe max. azt éred el, hogy a VB Select-Case-ből lefordított redundanciás if-else szerkezetedet átrakod máshová.
    Ugyanott vagy ahol a part szakad.

    "A visszatérő értéke (a fenti példánál) nagy valószínűséggel egy 'A csoportba', 'B csoportba' stb. (vagyis logikusan egy enum) amit a régi-jó C-s switch-case kimondottan jól kezel."

    Amely visszatérő értéket előtte egy vagy több if szerkezetből vagy egy tömbből kaptál meg, tehát nem a switch teljesítménye lesz a mérvadó.
    Megint ugyanott vagy ahol a part szakad.

    "A csoportkódot visszaadó függvényben azért csak van valamiféle logika, ekkor pl. egy segédtömb feldolgozásával lehet egy kilométeres, mindenféle 'cafrangokkal ékes' feltételrendszert ugyancsak jól kvantált csoportkódokká szelidíteni."

    Bocs, de nem bonyolítod túl ezt az egyszerű kis elágazási feladatot?
    Függetlenül attól, hogy az a VB Select-Case elágazási példa életszerű vagy sem, ez neked tényleg ennyire bonyolult???

    Egyébként előzőleg már megszületett a konklúzió.
    Mindkét utasításnak (switch vs. Select-Case) megvan a maga helye és haszna.
    Sőt olyan javaslat is elhangzott már, hogy mindkettő jó volna ugyanabba a programozási nyelvbe.
    Mindazonáltal szerintem ma egy átlagos fejlesztésben többször kilehet használni a Select-Case tudását, mint a switch teljesítményét, de ezt mindenki maga döntse el.
    Mutasd a teljes hozzászólást!
  • Ez nem zsigeri elutasítás. Egy adott probléma bármikor megoldható goto nélkűl ha jól van megtervezve.

    Minden probléma megoldható nem hogy GOTO, de osztályok, generikusok, anonim függvények, stb. nélkül is. Nem azért használjuk őket, mert kellenek a megoldáshoz, hanem mert egyszerűbbé teszik azt. Szóval ez nem érv a GOTO ellen. (Mondom ezt úgy, hogy batch fájlok kívül utoljára talán negyed évszázada, ha használtam.)

    switch-case-ben goto
    nested loop goto
    Eltérő véleményünk van arról, hogy mi a szuper megoldás :)

    Azért az jelent valamit, hogy ez szinte minden mainstream nyelvben (még az olyan újakban is, mint a C#) megvan ugyanezekben a szerkezetekben. Csak nem goto-nak hívják, hanem break-nek.
    Mutasd a teljes hozzászólást!
  •  Most ha neked van egy kokemenyen nestelt loopod, akkor vajon mindig jobb korje epiteni egy wrap fuggvenyt, hogy ki tudj ugorni belole, mint hogy valasztani egy egyertelmu label nevet es odaugrani?

    Én az a fajta vagyok, aki inkább 5x átgondolja, miként lehet ezt megoldani, de a goto soha sem merülne fel bennem

    Egyebkent a javaban (ami ugye nem tamogatja a gotot, mert a "goto" karomkodas), ott vannak a labelled breakek, erre a valos use-casere.
    Azok is zavarnak?

    Ezer éve nem javaztam, és annyira nem is ismerem
    Mutasd a teljes hozzászólást!
  • Pont irtad is: nested loopbol kilepes ugy, hogy nem kell egy kulon bool-t ellenorizni a 2. loopban, vagy nem kell a kulso loopot egy kulon funct-ba rakni, ahonnan mar megy a return.

    Nalam olyan helyeken jott pl jol, hogy 'ujraprobalkozas': Amikor van egy nagyobb programresz loopokkal, ifekkel, miegymassal, amiben belul akar tobb helyen is donthet ugy a program, hogy kezdje ujra, akkor csinalok a legelejere egy 're:' labelt, es barhol elofordul egy feltetel, hogy ujra kell kezdeni, akkor az odaugrik. Szinten boolean checkeket sporolok igy meg, ha egy csak repeat-until koze raknam az ujraprobalkozasokat.

    Peldaul itt ez az izé, ami egy pascal formatumu stringet megprobal beolvasni: 'bla''bla'#32#$20#32'hello'#13#10
    re: while PeekChar='''' do begin result:=result+GetChar; while not(PeekChar in[#0,''''])do result:=result+GetChar; result:=result+GetChar; end; if PeekChar='#' then begin result:=result+GetChar; while PeekChar in['$','0'..'9']do result:=result+GetChar; goto re; end;

    En sem szeretem a sok goto-t, de ha igy atlathatobb (meg gyorsabb is, ami parseolasnal nem hatrany), mint egy kulso loop es egy boolean, akkor miert is ne...
    Mutasd a teljes hozzászólást!
Címkék
abcd