[Delphi]Procedure beeindigen door exit van andere functie

[Oscar Mopperkont]

In een bepaalde procedure roep ik een functie aan.
In die functie zit een exit.

Zodra de exit in deze functie wordt aangeroepen wil ik eigenlijk ook dat de
procedure die de functie aanroept ook ge-exit wordt. Dit kan natuurlijk door
elke keer een extra waarde(boolean) aan de functie mee te geven, en deze
elke keer in de procedure te checken en afhankelijk van die waarde de
procedure ook te exit-en.

Maar dit kan denk ik wel netter of niet?

[whoami]

Het is juist netjes dat die procedure gestopt wordt, en de 'caller' niet.

Wat je wel kunt doen, is eens proberen of 'Abort()' het door jou gewenste resultaat levert.

[Oscar Mopperkont]

whoami schreef op 02 juni 2003 @ 13:00:
Het is juist netjes dat die procedure gestopt wordt, en de 'caller' niet.

Wat je wel kunt doen, is eens proberen of 'Abort()' het door jou gewenste resultaat levert.

Dat is ook zeker netjes, maar met netter bedoelde ik dat het met een stuk minder programmacode moet kunnen.

Ik ga meteen abort proberen!

[OZ-Gump]

Mocht abort niet werken, dan lijkt een tweede retour-waarde een van de weinige oplossingen. Je kunt dan de functie van het type boolean maken en in je aanroep het volgende gebruiken:

Delphi:

  if AangeroepenFunctie(inputvar, outputvar) then
  begin
    //Code die alleen uitgevoerd mag worden
    //als AangeroepenFunctie true is
  end

Daarbij hoeft natuurlijk niet gezegd dat je de result van AangeroepenFunctie pas bij de allerlaatste regel op True zet, zodat deze alleen true retourneert als je de volledige functie doorloopt...

[jvdmeer]

Hier hebben we toch exceptions voor?

[whoami]

Idd.
Voor zover ik mij nog kan herinneren, doet die Abort method niets anders dan een EAbort exceptie gooien...

[curry684]

Abort gooit idd een EAbort, en Oscar moet eveneens idd even bijlezen over exceptions want die zijn juist bedoeld om een hierarchie van functiecalls in 1 klap te 'unwinden' tot het gewenste niveau alwaar je de exception 'vangt'.

[Oscar Mopperkont]

curry684 schreef op 02 June 2003 @ 13:37:
Abort gooit idd een EAbort, en Oscar moet eveneens idd even bijlezen over exceptions want die zijn juist bedoeld om een hierarchie van functiecalls in 1 klap te 'unwinden' tot het gewenste niveau alwaar je de exception 'vangt'.

Ik weet niet wat er precies allemaal gebeurt, maar de oplossing van Whoami met de abort werkt precies zoals ik het wil.

En ik zal idd eens is wat moeten lezen over exeptions en dergelijke, maar er is nog zoveel waar ik bij delphi over zou moeten lezen! Ben ook pas een paar weken bezig met Delphi (nu misschien 100 uur ofzo), dus ik ben nog een ontzettende newbie op het gebied van Delphi.

[Oscar Mopperkont]

OZ-Gump schreef op 02 June 2003 @ 13:12:
Mocht abort niet werken, dan lijkt een tweede retour-waarde een van de weinige oplossingen. Je kunt dan de functie van het type boolean maken en in je aanroep het volgende gebruiken:

Delphi:

  if AangeroepenFunctie(inputvar, outputvar) then
  begin
    //Code die alleen uitgevoerd mag worden
    //als AangeroepenFunctie true is
  end

Daarbij hoeft natuurlijk niet gezegd dat je de result van AangeroepenFunctie pas bij de allerlaatste regel op True zet, zodat deze alleen true retourneert als je de volledige functie doorloopt...

Dit is ook wat ik bedoelde in mijn openingspost (had het dus zelf ook bedacht), maar iig bedankt.

[curry684]

Exceptions zijn vrij fundamenteel, dus ik zou dat bijlezen even erg hoog op je agenda plaatsen

[Tomatoman]

curry684 schreef op 02 June 2003 @ 14:49:
Exceptions zijn vrij fundamenteel, dus ik zou dat bijlezen even erg hoog op je agenda plaatsen

En om dat nog eens te onderstrepen sluit tomatoman zich hierbij aan.

[Verwijderd]

Daarnaast zou ik het gebruik van exit etc. gelijk proberen af te leren. Het is zelden nodig en zet aan tot het schrijven van spagetti-applicaties, iets wat je nu al ziet.

Vaak als je met dit soort problemen komt te zitten, komt dit omdat je het verkeerd aanpakt.

[martijn_brinkers]

Het gebruik van Exceptions voor 'program flow' vind ik op zn zachts gezegd erg lelijk. Zoals de naam als zeg, Exception, maw iets wat een uitzonderings situatie is. Om nou control flow te laten plaatsvinden dmv exceptions is net zo erg als veelvuldig gebruik van goto's (in feite is het een soort geavanceerde vorm van goto). Dus ik zou gewoon een boolean ofzo terug geven en de control flow op een nette manier te laten plaatsvinden en niet misbruik te maken van language features.

Just my 2 cents

[curry684]

TijnFLiP schreef op 02 June 2003 @ 21:40:
Het gebruik van Exceptions voor 'program flow' vind ik op zn zachts gezegd erg lelijk. Zoals de naam als zeg, Exception, maw iets wat een uitzonderings situatie is. Om nou control flow te laten plaatsvinden dmv exceptions is net zo erg als veelvuldig gebruik van goto's (in feite is het een soort geavanceerde vorm van goto). Dus ik zou gewoon een boolean ofzo terug geven en de control flow op een nette manier te laten plaatsvinden en niet misbruik te maken van language features.

Correct, maar ik had uit Oscar's posts nogal het gevoel dat het juist om error unwinding ging. Wellicht was mijn visie daarover nogal gekleurd omdat ik het topic pas las toen de exceptions al door meerdere mensen waren genoemd

[Verwijderd]

Als die Mopperkont dit nog leest:

wat wil je eigenlijk precies doen? Je vraag is of het netter kan, om daar een goed antwoord op te kunnen geven, moeten we meer weten over wat je wil doen.

[ Voor 5% gewijzigd door Verwijderd op 02-06-2003 23:21 ]

[Oscar Mopperkont]

Verwijderd schreef op 02 June 2003 @ 23:20:
Als die Mopperkont dit nog leest:

wat wil je eigenlijk precies doen? Je vraag is of het netter kan, om daar een goed antwoord op te kunnen geven, moeten we meer weten over wat je wil doen.

Ik zal het zo goed mogelijk proberen uit te leggen.


In mijn programma geeft de gebruiker twee bestanden als input.

In bestand 1 staat een lijst met artikelen en daarachter de vraag
In bestand 2 staan alle combinaties van artikelen en daarachter het aantal keer dat ze met elkaar gevraagd worden.

Eerst lees ik bestand 1 in en zet die informatie in een Array (noem die Array1). Elk artikel krijgt daarbij een indexnummer mee.

Bestand twee wordt ook ingelezen en daarvan wordt alles in een tabel gezet (array van array's). Daarbij moet hij eerst het indexnummer van het artikel zoeken, om te weten waar iets in de tabel gezet moet worden.
Daarvoor heb ik dus een functie geschreven, die heel simpel het indexnummer zoekt door heel Array1 door te lopen en de naam van het artikel te vergelijken, en zodra er een match is zijn indexnummer uit te lezen.

Als de gebruiker echter in bestand twee een artikel heeft staan dat in bestand 1 niet voorkomt, dan komt er geen indexnummer terug van de functie en kunnen de gegevens niet in de tabel weggeschreven worden.

Als dit het geval is dan moet de gebruiker een error krijgen dat hij dus niet twee matchende bestanden heeft opgegeven.


Nu kan ik dat oplossen door de functie die naar een indexnummer zoekt ook een boolean waarde mee te geven (of MaxInt) en elke keer te controleren of er een index gevonden is. (zoals ik al in mijn opening zei, en wat ook al voorgesteld is)
Maar ik dacht juist dat het netter was als je het met zo min mogelijk programmeertaal doet, en de abort zoals voorgesteld door Whoami werkt bij mij prima, en doet precies wat ik wil, zonder dat ik daar teveel regels aan heb vuilgemaakt.

Maar ik begrijp nu van iedereen dat het juist niet netjes is om functies als abort/exit te gebruiken. Nu vraag ik mij dus af waarom??? Want het programma werkt op die manier wel precies zoals ik wil en het kost je weinig regels.


_{Hele probleem zou natuurlijk niet bestaan als gebruiker gewoon altijd goede input geeft, maarja een programma moet natuurlijk wel een beetje fool-proof zijn.}

[ Voor 4% gewijzigd door Oscar Mopperkont op 03-06-2003 10:21 ]

[whoami]

Eerlijk gezegd; ik vind het niet onnetjes.

[Oscar Mopperkont]

whoami schreef op 03 June 2003 @ 10:28:
Eerlijk gezegd; ik vind het niet onnetjes.

Hmm, maar wie is nu de grootste Delphi-Goeroe?? En wi mag dus bepalen wat wel e niet netjes is

Ik sluit me iig aan bij Whoami!

[martijn_brinkers]

Want het programma werkt op die manier wel precies zoals ik wil en het kost je weinig regels.

'Weinig regels' en 'het werkt toch' zijn imho op zichzelf geen goede argumenten om te laten zien dat iets de beste keus is.

zie bijv. een voorbeeld van kampioenschap 'The International Obfuscated C Code Contest'. Zeer compacte code maar of je daar blij mee moet zijn ;-)

http://ioccc.org/2001/ctk.c

Ik zelf ben erg voor hele duidelijke code die in een oogopslag te doorgronden is. Wanneer je gebruik moet maken van exceptions is niet altijd heel duidelijk begrensd en er zijn altijd situaties te bedenken waarin je zowel voor als tegen argumenten kan bedenken. Ik zelf probeer exceptions te gebruiken voor uitzonderings situaties die bij een normaal gebruik van je programma niet op treden.

In jouw specifieke geval zou het dus goed kunnen dat je het beste een Exception (Abort bijv.) kan gebruiken omdat het een uitzondering situatie is (gebruiker geeft niet matchende bestanden op).

Een groot voordeel van het gebruik van exceptions tegenover het terug geven van status informatie is dat je exceptions niet kan negeren en dus moet afvangen.

[OZ-Gump]

Als eerste: het feit dat ik hier op reageer, wil niet zeggen dat ik mezelf een delphi-geroe vindt!

Er is voor allebei de kanten iets te zeggen.

Enerzijds die van het gemak van features: de programmeeromgeving Delphi levert een hele hoop mogelijkheden. Een van deze mogelijkheden is het gebruiken van een Exit of een Abort. Zo lang je code redelijk leesbaar blijft, en je gebruikt niet voor elk wiswasje een exit, lijkt het me dat dit geen enkel probleem is.

Anderzijds die van coding-conventions en general good-coding behaviour. Het is code-matig gezien netter om de exotische gevallen binnen de huidige procedures op te vangen dan hiervoor achterover te leunen door het maar door een exception op te laten vangen. Geef je je procedure/functie een extra variabele mee, dan blijft je code altijd leesbaar, ook als er straks een enorme uitbreiding gedaan moet worden waardoor je code en het aantal aanroepen van de betreffende procedure verdrievoudigen. Ook maakt dit het lezen van je code door anderen een stuk makkelijker, waardoor samenwerken makkelijker en sneller wordt omdat je, zoals al eens gezegd, geen spaghetti-code krijgt, waar je van de ene naar de andere procedure goto't (?).

Bepaalde situaties vragen dus om bepaalde aanpakken... En dat kan (en zal) in elke situatie weer verschillend zijn.

In jouw situatie:
Al met al lijkt het me dat je een keuze moet maken tussen twee goeien (of twee slechten, net wat je wil ). Feit blijft echter dat je m.i. beter kunt coden wat goed voelt, dan coden wat goed gevonden wordt. Oftewel: ga niet anders coden omdat anderen dat beter vinden. Tenzij IEDEREEN zegt dat je anders moet gaan werken, dan zou er wel eens iets serieus mis kunnen zijn met je coding-style

[Oscar Mopperkont]

TijnFLiP schreef op 03 June 2003 @ 11:00:
[...]


'Weinig regels' en 'het werkt toch' zijn imho op zichzelf geen goede argumenten om te laten zien dat iets de beste keus is.

zie bijv. een voorbeeld van kampioenschap 'The International Obfuscated C Code Contest'. Zeer compacte code maar of je daar blij mee moet zijn ;-)

http://ioccc.org/2001/ctk.c

Ik zelf ben erg voor hele duidelijke code die in een oogopslag te doorgronden is. Wanneer je gebruik moet maken van exceptions is niet altijd heel duidelijk begrensd en er zijn altijd situaties te bedenken waarin je zowel voor als tegen argumenten kan bedenken. Ik zelf probeer exceptions te gebruiken voor uitzonderings situaties die bij een normaal gebruik van je programma niet op treden.

In jouw specifieke geval zou het dus goed kunnen dat je het beste een Exception (Abort bijv.) kan gebruiken omdat het een uitzondering situatie is (gebruiker geeft niet matchende bestanden op).

Een groot voordeel van het gebruik van exceptions tegenover het terug geven van status informatie is dat je exceptions niet kan negeren en dus moet afvangen.

Owke, ben ik het mee eens.

Maar die Abort hoef ik toch niet af te vangen ofzo? Ik geef nu namelijk het bericht dat de bestanden niet matchen nadat er geconstateerd is dat er geen indexnummer gevonden kan worden.
daarna wordt de abort aangeroepen, en die hoef ik toch niet af te vangen? Het programma staat nu imers gewoon stop en kan opnieuw opgestart worden. Ik constateer iig niet dat het na een abort anders werkt dan ervoor.


_{Vind het trouwens altijd wel knap dat mensen het allemaal kunnen volgens zonder dat ik maar 1 regel programmacode heb neergezet}

[Oscar Mopperkont]

OZ-Gump schreef op 03 June 2003 @ 11:10:
... Tenzij IEDEREEN zegt dat je anders moet gaan werken, dan zou er wel eens iets serieus mis kunnen zijn met je coding-style

Ben net begonnen met programmeren (zoals ik al zei 100 uur delphi-ervaring, verder nooit echt les erin gehad), dus heb nog niet echt een coding style. Maar ik probeer het allemaal wel een beetje goed te doen, vind het namelijk wel leuk om te doen.

[Verwijderd]

Oscar Mopperkont schreef op 03 June 2003 @ 10:20:
Bestand twee wordt ook ingelezen en daarvan wordt alles in een tabel gezet (array van array's). Daarbij moet hij eerst het indexnummer van het artikel zoeken, om te weten waar iets in de tabel gezet moet worden.
Daarvoor heb ik dus een functie geschreven, die heel simpel het indexnummer zoekt door heel Array1 door te lopen en de naam van het artikel te vergelijken, en zodra er een match is zijn indexnummer uit te lezen.

Delphi zelf gebruikt voor dit soort geintjes de IndexOf functie. Wil je het netjes doen, dan noem je je eigen functie IndexOf en implementeer je het gebruik ervan op dezelfde wijze. dwz. 'niet gevonden' retourneerd -1. Je kunt dan in je aanroepende procedure de exception raisen, of op een andere manier je fout afhandelen.

Handige tip misschien: check de tstringlist en de bijbehorende objectlist (tstringlist.objects). Dit kan in dit geval een stuk prettiger werken.

Voorbeeld (legt het snelst uit)

Delphi:

// een object waar je artikelen in kunnen
type
  TMijnArtikel = class(TObject)
    private
    public
      property Artikel: String;  // weet de juiste types niet, class is ook niet completed
      property Vraag: String;
  end

[..]
  // zo proppen we de artikelen in een array (tstringlist)
  oMijnArtikel  := TMijnArtikel.Create;
  oMijnArtikel.Vraag := cVraag;  // cVraag = string met vraag
  oMijnArtikel.Artikel := cArtikel; // cArtikel = string met artikel (oid)
  oMijnArtikelLijst := TStringlist.Create;
  oMijnArtikelLijst.AddObject(cArtikel, oMijnArtikel);

[..]
  // zo kijken we of een artikel in de lijst zit
  nArtikelIndex := oMijnArtikelLijst.IndexOf(cZoekArtikel); // cZoekArtikel = Gezochte Artikel
  If nArtikelIndex = -1 then 
      raise // of iets dergelijks, iig. is hij dus niet aanwezig
    else
      begin
        oGevondenArtikel:=TMijnArtikel(oMijnArtikelLijst.Objects[nArtikelIndex]);
        cVraag:=oGevondenArtikel.Vraag;
        MessageDlg('gevonden vraag:'+cVraag,mtInformation,[mbOk],0);
      end;

Maar ik dacht juist dat het netter was als je het met zo min mogelijk programmeertaal doet, en de abort zoals voorgesteld door Whoami werkt bij mij prima, en doet precies wat ik wil, zonder dat ik daar teveel regels aan heb vuilgemaakt.

Over het algemeen is inderdaad waar dat hoe minder code hoe beter (vuistregel). Echter het gaat hier om de leesbaarheid (=onderhoudbaarheid) van de code. Deze mag er niet onder lijden uiteraard.

Met 1 exit of abort in een hele applicatie, valt het allemaal wel te overzien. Echter ga je structureel gebruik maken van deze functies (wat de meeste mensen _die_ ze gebruiken ook doen) dan wordt je applicatie al snel heel onoverzichtelijk, omdat er continu heen-en-weer gesprongen wordt. Daarnaast is een fout snel gemaakt doordat je met geneste loops etc. kunt zitten, welke loop exit/abort je dan?, enzovoort. Break en Exit liggen qua mogelijkheden imo te dicht bij ordinaire goto's. Bij uitzondering kan het eleganter zijn om ze wel te gebruiken, maar over het algemeen moet je ze (imo) mijden.

[ Voor 3% gewijzigd door Verwijderd op 03-06-2003 13:52 ]

[BoomSmurf]

Een abort gebruik ik idd nooit (derive tenminste je eigen exception of zo). Maar exit's en break's zeker wel! Natuurlijk moet je ze wel structureel op dezelfde plek gebruiken. Een break voor een loop en een exit voor een check.

Exit:
Stel je voor je bent bezig met een object met functies dat werkt op een database. Een voorbeeld functie heeft nogal wat parameters die allemaal tegen de database vergeleken moeten worden voor de uiteindelijke operatie uitgevoerd kan worden.

Nou kun je een hele leuke structuur maken met geneste if/then/begin/end, maar tegen de tijd dat je bij de 'core' bent ben je drie monitoren verder aan het typen. Shiet niet op. Je kunt ook in je init deel elke benodigde query op elke parameter toepassen, voldoet ie niet, geef je een exit. Als je het zo doet krijg je een hele mooie init structuur die ook nog eens een stuk beter te volgen is! Op de 'normale' manier zou je de hele tijd bezig zijn met queries openen, dan een if then begin, en uiteindelijke na de end de goeie query afsluiten. Volgens mij maak je daar een stuk sneller een fout bij!

Iets vergelijkbaars komt redelijk vaak voor (hiero iig). Natuurlijk zou je de hele functie kunnen onderverdelen en andere functies dat je met één lange if statement ook vooruit zou kunnen. Als het echter één groot (nou ja niet TE groot natuurlijk) geheel is zonder delen die ook door andere functies gebruikt worden, dan schiet dit ook niet zo op.

Break:
IMHO is het gebruik van een break in een loop heel normaal. Bv:

code:

ok := true;
for i := low(myRecords) to high(myRecords) do begin
   ok := ok AND ValidateRecord(myRecords[i]);

   if not ok then begin
      setLength(myRecords, i);

      break;
   end;
end;

Hoe zou jij dit anders doen? Je kan wel een beetje exceptions gaan lopen raizen e.d. in de ValidateRecord functie en dat opvangen met een try..finally/except call maar dit schiet IMHO niet echt op als er ook niet echt iets ergs fout gaat. Bovendien freten try..finally/except een hoop cpu-cycles, niet normaal. Dan kom je met aantal niveaus diepe loop met een break een stuk beter uit de bus.

Mijn E0.02.

[martijn_brinkers]

Ben net begonnen met programmeren (zoals ik al zei 100 uur delphi-ervaring, verder nooit echt les erin gehad), dus heb nog niet echt een coding style. Maar ik probeer het allemaal wel een beetje goed te doen, vind het namelijk wel leuk om te doen.

Dat is het allerbelangrijkste! dat je er plezier in hebt. Dan is het alleen nog maar een kwestie van ervaring op doen om een goede programmeur te worden.

Maar exit's en break's zeker wel! Natuurlijk moet je ze wel structureel op dezelfde plek gebruiken. Een break voor een loop en een exit voor een check.

Ik gebruik ook vrij vaak exit en break. Zoals al is vermeld moet je ze wel op zo'n manier gebruiken dat de structuur van je programma duidelijk blijft (eigenlijk een loze zin van mij want daar zijn we het natuurlijk allemaal over eens)

Ik maak ook veel gebruik van try/finally omdat dan duidelijker is wat de control flow is. vb:

Delphi:

procedure DoeIets;
var 
  S : TStringList;
begin
  S := TStringList.Create;
  try
    // Doe iets met S
    if EenOfAndereVoorwaarde = False then
    begin
      Exit;
    end
  finally
    S.Free;
  end;
end;

Het is nu altijd gegarandeerd dat S ook ge-freed wordt. Het is ook duidelijker voor een ander persoon die bijv. een extra check toevoegd. Stel dat je geen Exit zou hebben gebruikt en ook geen try/finally maar die andere persoon voegt die check toe en doet Exit als niet aan de check wordt voldaan. Dan zou je een memory leak hebben. Door de try/finally verhoog je imho de duidelijkheid van je code.

[Verwijderd]

BoomSmurf schreef op 04 June 2003 @ 00:20:
Een abort gebruik ik idd nooit (derive tenminste je eigen exception of zo). Maar exit's en break's zeker wel! Natuurlijk moet je ze wel structureel op dezelfde plek gebruiken. Een break voor een loop en een exit voor een check.

Aargh... welkom spagetticode..

Delphi:

ok := true;
for i := low(myRecords) to high(myRecords) do 
  begin
    ok := ok AND ValidateRecord(myRecords[i]);
    if not ok then 
      begin
         setLength(myRecords, i);
         break;
      end;
  end;

Ik heb even je code anders geidenteerd, dat leest wat beter (althans, voor mij).
Vragen: Wat is het nut van die AND? Volgens mij is die totaal nutteloos, aangezien je breakt als ok=false, zal hij nooit bij die and aankomen dat ok false is. Hier zie je al dat je zelf verward bent door de break. Dan poging 2:

Delphi:

for i := low(myRecords) to high(myRecords) do 
  begin
     if not ValidateRecord(myRecords[i]) then 
       begin
         setLength(myRecords, i);
         break;
      end;
  end;

Dit is al een stukje netter, nu die overbodige OK variabele eruit gesloopt is.. Maar nog steeds die hele nare break. Dat komt omdat je een for/next loop gebruikt die niet nodig is. Dan hoe het (imo) wel moet:

Delphi:

  i:=low(myRecords);
  while  (i<high(myRecords)) and ValidateRecord(myRecords[i]) do inc(i);
  If i<>high(myRecords) then SetLength(myRecords,i);

Zo zie je, 3 regeltjes code over, zonder break.

Dan de volgende patient:

Delphi:

procedure DoeIets;
var 
  S : TStringList;
begin
  S := TStringList.Create;
  try
    // Doe iets met S
    if EenOfAndereVoorwaarde = False then
    begin
      Exit;
    end
  finally
    S.Free;
  end;
end;

Kun je me het nut van die exit in dit geval uitleggen, ik zie het namelijk niet..

Los daarvan.. de try..finally is bij dit soort constructies altijd obligaat, of je nu een exit gebruikt of niet. Wel toon je hier aan dat de kans op memory leaks veel groter wordt door het gebruik van exits.

//edit
klein haast-bugje verwijderd

[ Voor 8% gewijzigd door Verwijderd op 04-06-2003 12:35 ]

[Verwijderd]

Wat ook vaak helpt is eens kijken in de help van borland delphi. vanaf 4 is deze dermate goed dat je veel nette oplossingen kunt vinden. Dit wil niet zeggen dat dat de enige nette oplossingen zijn maar wel eenduidig. Vooral die voorbeelden die ze geven zijn erg handig.

Hmm toch jammer dat ik nu in Java moet werken vond de borland omgeving toch echt super voor Delphi.

[OZ-Gump]

@ hezik
Jij bent goed bezig..... tijd over?

Neemt bij mij nog niet het gevoel weg dat in sommige (uitzonderlijke) situaties het gebruik van een exit te rechvaardigen is. Het voorbeeld dat hezik onder handen heeft genomen is echter niet zo'n situatie...

[Verwijderd]

OZ-Gump schreef op 04 June 2003 @ 12:54:
@ hezik
Jij bent goed bezig..... tijd over?

neuh, niet echt.. maar hoe meer zieltjes ik kan redden van de exit/break/abort-hell hoe beter

Neemt bij mij nog niet het gevoel weg dat in sommige (uitzonderlijke) situaties het gebruik van een exit te rechvaardigen is. Het voorbeeld dat hezik onder handen heeft genomen is echter niet zo'n situatie...

Klopt, als je mijn 1e post leest, zie je ook dat ik niet zeg dat het NOOIT mag. Echter in de meeste gevallen is het niet nodig, je moet break/exits echt alleen gebruiken wanneer je anders op hele gekunstelde constructies uitkomt. Bij uitzondering dus. Ikzelf ben nog nooit een situatie tegen gekomen waar het perse MOEST.

Breaks en exits werken helaas als een soort drugs. Zodra men ze ontdekt heeft, gaat men niet meer zitten nadenken. Dus ipv. wat denkwerk (eventueel met oplossingstabel oid) zet men gewoon een break/abort/exit neer, waardoor je uiteindelijk code krijgt die 'invested' is met dit soort sprongen. En geloof me, het zit er de 1e dag als je het programmeert nog overzichtelijk en logisch uit, maar als je het anderhalf jaar later terug krijgt voor onderhoud is er geen chocola meer van te maken.

[DiGuru]

Inderdaad heel interessant onderwerp. Ik probeer de dingen altijd zoveel mogelijk te programmeren zoals ik ze in mijn hoofd heb zitten. Veel mensen vinden dat het veel korter/netter/sneller kan, maar ze zijn het er allemaal over eens, dat mijn sources wel heel logisch en leesbaar zijn.

En dat is op termijn eigenlijk altijd het belangrijkste.

Leuke zijsprong: de compiler van Delphi is zodanig slim, dat hij in de meeste gevallen van vergelijkbare source ook vergelijkbare code maakt. Als je dus naar het uiteindelijke resultaat gaat kijken, zie je meestal geen of heel weinig verschil tussen uitgebreide, makkelijk leesbare code en nette/snelle/korte code. De enige uitzondering zijn de genoemde onderbrekingen van de program flow, exceptions vind je bijvoorbeeld altijd terug als ze gebruikt worden (behalve als de oprimizer heeft vastgesteld dat die exception nooit kan optreden ).

Kortom, als je zoveel mogelijk programmeert zoals je het in je hoofd hebt zitten, maak je het jezelf een stuk makkelijker. En als je het daarnaast ook heel uitgebreid doet en geen lange en complexe statements gebruikt, is ook je opvolger daar heel blij mee.

[whoami]

DiGuru schreef op 04 June 2003 @ 20:36:
Inderdaad heel interessant onderwerp. Ik probeer de dingen altijd zoveel mogelijk te programmeren zoals ik ze in mijn hoofd heb zitten. Veel mensen vinden dat het veel korter/netter/sneller kan, maar ze zijn het er allemaal over eens, dat mijn sources wel heel logisch en leesbaar is.

En dat is op termijn eigenlijk altijd het belangrijkste.

Leuke zijsprong: de compiler van Delphi is zodanig slim, dat hij in de meeste gevallen van vergelijkbare source ook vergelijkbare code maakt. Als je dus naar het uiteindelijke resultaat gaat kijken, zie je meestal geen of heel weinig verschil tussen uitgebreide, makkelijk leesbare code en nette/snelle/korte code. De enige uitzondering zijn de genoemde onderbrekingen van de program flow, exceptions vind je bijvoorbeeld altijd terug als ze gebruikt worden (behalve als de oprimizer heeft vastgesteld dat die exception nooit kan optreden ).

Kortom, als je zoveel mogelijk programmeert zoals je het in je hoofd hebt zitten, maak je het jezelf een stuk makkelijker. En als je het daarnaast ook heel uitgebreid doet en geen lange en complexe statements gebruikt, is ook je opvolger daar heel blij mee.

Daar ben ik het niet mee eens.
Je moet zogoed mogelijk programmeren dat de code onderhoudbaar, aanpasbaar, schaalbaar en leesbaar is.
Als je programmeert zoals het 'in je hoofd zit', dan kan ik me wel inbeelden dat die code op termijn toch niet zo logisch zal zijn en vlugger in 'spaghetti-code' zal resulteren.

[Verwijderd]

Ik ben het er ook niet mee eens. Het probleem met 'programmeren zoals het in je hoofd zit' is dat voor een ander niet te zien is hoe iets 'in jouw hoofd zit'. Door op die manier te programmeren maak je code die voor jouzelf ten alle tijde leesbaar is, maar waar een ander z'n kop dagen over kan breken.

Ik zeg niet dat dit perse zo moet zijn, je kunt het intuitief goed 'in je hoofd hebben zitten', waardoor je code gewoon goed is.

[DiGuru]

Met 'zoals het in mijn hoofd zit', bedoel ik dat ik het schrijf zoals mensen het bekijken, het vertalen in een vorm zoals de computer het bekijkt laat ik aan de compiler over

Hoe meer het onze (menselijke) logica volgt, hoe beter. Ik streef er naar het zo te schrijven, dat als ik iemand moet uitleggen hoe het werkt ik gewoon de source kan voorlezen.

[martijn_brinkers]

Kun je me het nut van die exit in dit geval uitleggen, ik zie het namelijk niet..

weinig fantasie zeker. Het voorbeeld geeft een principe aan en niet een code voorbeeld dat 'in the field' gebruik wordt. Er zijn genoeg voorbeelden te geven waar een exit handig is als je een functie wil verlaten omdat er niet aan een voorwaarde is voldaan. Je kan ook best werken met If etc. zonder Exit maar dat kan ook juist onduidelijkere code opleveren.

Zo zie je, 3 regeltjes code over, zonder break.

Ja 3 regels maar wel minder duidelijk dan hoe het origineel was imo.

[ Voor 15% gewijzigd door martijn_brinkers op 04-06-2003 21:25 ]