[alg] Slechtste programmeervoorbeelden deel 2

[Verwijderd]

Grijze Vos schreef op zondag 04 februari 2007 @ 22:46:
De grote grap is wel, dat als een architect zijn brug instort hij moeilijk werk gaat vinden in de toekomst, als een programma crasht, dan mag je een support contract gaan afsluiten. Best apart eigenlijk.

De vergelijking gaat niet helemaal op, het gaat natuurlijk altijd om de impact van het falen. Een fysieke brug die instort kan mensenlevens kosten. De vergelijking gaat dus beter op voor bijvoorbeeld medische aparatuur. Ik denk dat daarbij ongeveer dezelfde consequenties voor een dergelijke architect van toepassing zijn.

[flowerp]

Gerco schreef op zondag 04 februari 2007 @ 22:41:
"Goed genoeg" is zowel een te weinig als teveel toegepaste term. Het is me regelmatig gebeurd dat een project uitliep omdat mensen te ver vooruit dachten. Het is me echter ook gebeurd dat er geen tijd was om iets op de goede manier te doen en het dan maar "Goed genoeg" moest.

Een paar maanden later konden we overnieuw beginnen, "Goed genoeg" bleek niet bestand tegen ook maar de kleinste verandering van de eisen.

Helemaal mee eens. Veel van de slechte programmeervoorbeelden in dit topic zijn zeker te wijten aan een "goed genoeg" mentaliteit. De programmeur weet wel dat het beter moet, maar zolang het werkt wordt er niet bij stil gestaan.

Ik heb met name 1 project gezien waar de "goed genoeg" mentaliteit tot wel 2 jaar(!) werd volgehouden. Met figuurlijk de tong uit de mond was men alleen maar bezig met features eruit te pompen, zonder ook maar over onderhoudbaarheid na te denken.

Echter, toen opeens werd er een zekere tresshold overschreden waarbij de tijd besteed aan bugfixes en kleine veranderingen zo exponentieel toenam dat het alle verdere ontwikkeling volledig wegdrukte. Het bedrijf in kwestie was echter wel met haar hele hebben en houden afhankelijk van die ene software base (denk aan een bedrijf zoals Hyves waar het hele bestaansrecht van 1 enkele web app komt). Dit speelde zo'n 3 jaar geleden. Laatst sprak ik toevallig iemand die nog steeds bij dat bedrijf werkt. Ondanks alle refactor pogingen van de afgelopen 3 jaar, is men nog dagelijks zeer veel tijd kwijt om om het totaal kromme database model heen te werken en de meest simpele bugs oplossen kost dagen.

Aan de andere kant zijn er natuurlijk ook wel voorbeelden waarin programmeurs totaal los staan van enige realiteits zin en een bizarre eigenwijze perfectie tot in het oneindige willen doorvoeren. Het gevolg is dan dat je in het gunstigste geval zoiets als EJB2 krijgt, en in het ongunstigste geval een stuk code (of specificatie) waar ondanks dat er miljoenen in gepompt is en/of jaren overheen gegaan zijn nog niet eens uitgevoerd kan worden en 1 nuttig ding voor een gebruiker kan doen.

Het beste is natuurlijk een goede balans vinden tussen deze 2. Dat vereist echter een kundig persoon met zowel een goede opleiding als veel ervaring. Deze mensen zijn helaas erg zeldzaam.

[Verwijderd]

Verwijderd schreef op zondag 04 februari 2007 @ 22:10:
[...]
Simpel: omdat je er dan meer aan verdient

Programmeurs hebben vaak de irritante neiging om te goed werk te leveren. De klant betaald voor een werkend product, niet een school voorbeeld 'hoe te programmeren'.

Jij vergeet voor het gemak de garantie(s)(periodes)... En die worden niet gefactureerd naar de klant. Die zijn natuurlijk wel deels ingecalculeerd, maar ze blijven geld kosten...

[ Voor 7% gewijzigd door Verwijderd op 05-02-2007 00:10 ]

[Verwijderd]

Verwijderd schreef op maandag 05 februari 2007 @ 00:08:
Jij vergeet voor het gemak de garantie(s)(periodes)... En die worden niet gefactureerd naar de klant. Die zijn natuurlijk wel deels ingecalculeerd, maar ze blijven geld kosten...

Nee hoor, die vergeet ik niet. Simpelweg een kwestie van rekening mee houden. Het doel is dus uiteraard werken naar een "goed genoeg" voor dergelijke contracten. We moeten beseffen dat "goed genoeg" een zeer rekbaar begrip is, het zegt feitelijk nog vrij weinig. Het enige waar een dergelijk begrip voor waakt is over-engeneering.

[Gerco]

Verwijderd schreef op maandag 05 februari 2007 @ 07:28:
Nee hoor, die vergeet ik niet. Simpelweg een kwestie van rekening mee houden. Het doel is dus uiteraard werken naar een "goed genoeg" voor dergelijke contracten.

Hoe bepaal je dat je daar bent aangekomen? Goed genoeg voor de baas is het meestal op het moment dat het werkt (en geen seconde later). Voor sommige programmeurs zal het nooit goed genoeg zijn. Waar is de balans?

Ik moet toegeven dat ik soms neig naar over-engineering. Dan moet ik mezelf bewust intomen en genoegen nemen met een bepaald ontwerp. Ik heb ook nogal wel eens last gehad van het bekende "Second System Syndrome" en "Build one to throw away". Nu ik dat in hobbyprojecten van mezelf geleerd heb, kan ik ervoor waken op professioneel vlak. Dat heeft me al flink geholpen in het verleden

[ Voor 28% gewijzigd door Gerco op 05-02-2007 09:17 ]

[Verwijderd]

Gerco schreef op maandag 05 februari 2007 @ 09:16:
Waar is de balans?

De programmeur die dat weet, mag zichzelf professional noemen

[farlane]

Verwijderd schreef op zondag 04 februari 2007 @ 22:53:
De vergelijking gaat niet helemaal op, het gaat natuurlijk altijd om de impact van het falen.

Ligt natuurlijk helemaal aan de toepassing van de software. Stel dat het de software betrof die de besturing van de (ophaal)brug voor zijn rekening neemt die op een verkeerd moment de brug openstuurt.

[Verwijderd]

farlane schreef op maandag 05 februari 2007 @ 10:55:
Ligt natuurlijk helemaal aan de toepassing van de software. Stel dat het de software betrof die de besturing van de (ophaal)brug voor zijn rekening neemt die op een verkeerd moment de brug openstuurt.

Dat zeg ik. Het gaat dus om de impact van het falen.

[Verwijderd]

Aan de hand van dit topic ben ik even door mijn allereerste VB.net programma gaan spitten, een programma beginnend met een overzicht van 20 rekensommen.

Visual Basic:

        Dim A, B, C, D As Double
        Dim Operator As String


        A = Val(txtSom1a.Text)
        B = Val(txtSom1b.Text)
        D = Val(txtAntwoord1.Text)
        Operator = txtOperator1.Text
        Select Case Operator
            Case "+"
                C = A + B
            Case "-"
                C = A - B
            Case "*"
                C = A * B
            Case "/"
                C = A / B
        End Select
        If D = C Then
            Aantalpunten += 1
            txtAntwoord1.BackColor = Color.LightGreen
        Else
            txtAntwoord1.BackColor = Color.Red
        End If

En dat dus twintig maal, voor elke som een keer

[flowerp]

Verwijderd schreef op maandag 05 februari 2007 @ 11:07:
[...]
Dat zeg ik. Het gaat dus om de impact van het falen.

Voor directe high-risk projecten gelden natuurlijk inderdaad hele andere regels. Echt fault tolerant programmeren is (naar horen zeggen) een vrij extreem iets, waar formele bewijzen uitgevoerd moeten worden voor elke regel, en waar soms meerdere teams aan een identieke implementatie werken die dan runtime allemaal uitgevoerd worden en met elkaar vergeleken in uitkomst. Je hebt het dan over software voor bijvoorbeeld vliegtuigen of de space shuttle.

Nog even snel een geinige feature comitten door die 'handige' stagiare 10 minuten voordat een versie live gaat is er daar zeker niet bij

Toch is er mischien ook wel wat te zeggen om een of andere betere vorm van kwaliteits controlle in te voeren voor gewone software. Tegenwoordig wordt een misdaad die economische schade tot gevolg heeft dikwijls zwaar bestraft, soms nog zwaarder als een geweldsdelict.

Maar wat voor economische schade veroorzaakt die bug in de bedrijfs web applicatie niet, waardoor 10 winkels hun bestelling niet konden doen en daarmee 100 verkopen mislopen? Vermeningvuldig dit met een factor X voor alle software die op een of andere manier zakelijk gebruikt wordt, en je hebt een behoorlijke schade post die te danken is aan al die kleine bugjes overal.

Veel van de schade gaat precies over veel van die gevallen die in dit topic genoemd worden. Code die in 95% van de gevallen goed loopt en dus "goed genoeg" gevonden wordt.

[Verwijderd]

flowerp schreef op dinsdag 06 februari 2007 @ 00:17:
Veel van de schade gaat precies over veel van die gevallen die in dit topic genoemd worden. Code die in 95% van de gevallen goed loopt en dus "goed genoeg" gevonden wordt.

Nou die was dus duidelijk niet goed genoeg... Overigens gaat je, reeds eerder gemaakte, vergelijking met code uit dit topic nauwelijks op. Er staan hier toch overwegend hobby projectjes.

[Onbekend]

offtopic:
Even de Ads van Google:



Vooral die advertenties over vrouwen die a.d.h. van dit topic uitgezocht worden.

[HawVer]

Grijze Vos schreef op zondag 04 februari 2007 @ 22:46:
De grote grap is wel, dat als een architect zijn brug instort hij moeilijk werk gaat vinden in de toekomst, als een programma crasht, dan mag je een support contract gaan afsluiten. Best apart eigenlijk.

Als je een enorm probleem veroorzaakt met slechte code is het ook snel afgelopen. Als een architect een brug bouwt waar een tijd later scheuren in wegdek komen, wordt er ook een onderhoudsbedrijf op af gestuurd.

[ Voor 13% gewijzigd door HawVer op 06-02-2007 08:43 ]

[Verwijderd]

..nevermind...

[ Voor 94% gewijzigd door Verwijderd op 06-02-2007 09:13 ]

[HawVer]

Verwijderd schreef op dinsdag 06 februari 2007 @ 09:13:
..nevermind...

Was een spuit11 reactie van mij..

[LuCarD]

code:

CAPG_CAPITALISATIONID == 0 || (((GCI_CREDITINTERESTRATE == 0 || ISNULL(GCI_CREDITINTERESTRATE)) || (GDI_DEBITINTERESTRATE == 0 || ISNULL(GDI_DEBITINTERESTRATE))) && ((CRINT_CREDITINTRATE == 0 || ISNULL(CRINT_CREDITINTRATE)) || (DEBINT_DEBITINTRATE == 0 || ISNULL(DEBINT_DEBITINTRATE))))

Debug jij dit even? Zonder documentatie. Zonder comments. Zonder humor

Ik ben nu met een project waar dit soort statements schering en inslag zijn. Allemaal gepropt in SSIS IF statement.

[ Voor 3% gewijzigd door LuCarD op 08-02-2007 17:29 ]

[Verwijderd]

code:

CAPG_CAPITALISATIONID == 0 || 
  (
    (
      (GCI_CREDITINTERESTRATE == 0 || ISNULL(GCI_CREDITINTERESTRATE))
     || (GDI_DEBITINTERESTRATE == 0 || ISNULL(GDI_DEBITINTERESTRATE))
    ) 
    &&
   (
     (CRINT_CREDITINTRATE == 0 || ISNULL(CRINT_CREDITINTRATE)) 
     || (DEBINT_DEBITINTRATE == 0 || ISNULL(DEBINT_DEBITINTRATE))
   )
)

enters toevoegen helpt al

edit: volgens mij gaat het nergens over

[ Voor 5% gewijzigd door Verwijderd op 08-02-2007 17:34 ]

[Verwijderd]

Verwijderd schreef op donderdag 08 februari 2007 @ 17:32:

code:

CAPG_CAPITALISATIONID == 0 || 
  (
    (
      (GCI_CREDITINTERESTRATE == 0 || ISNULL(GCI_CREDITINTERESTRATE))
     || (GDI_DEBITINTERESTRATE == 0 || ISNULL(GDI_DEBITINTERESTRATE))
    ) 
    &&
   (
     (CRINT_CREDITINTRATE == 0 || ISNULL(CRINT_CREDITINTRATE)) 
     || (DEBINT_DEBITINTRATE == 0 || ISNULL(DEBINT_DEBITINTRATE))
   )
)

enters toevoegen helpt al

edit: volgens mij gaat het nergens over

Het kan zelfs nog beter als er consequent om wordt gegaan met 0 en dbnull waarden, welke in dit voorbeeld gelijk zijn aan elkaar:

code:

CAPG_CAPITALISATIONID == 0 || 
  (
      (GCI_CREDITINTERESTRATE == 0 || GDI_DEBITINTERESTRATE == 0)
    &&
     (CRINT_CREDITINTRATE == 0 || DEBINT_DEBITINTRATE == 0 )
)

[Voutloos]

code:

 (GCI_CREDITINTERESTRATE == 0 || ISNULL(GCI_CREDITINTERESTRATE))
     || (GDI_DEBITINTERESTRATE == 0 || ISNULL(GDI_DEBITINTERESTRATE))

De haakjes zorgen hier alleen voor verwarring, want met haakjes op andere plekken of helemaal weg verandert er niets aan de logica. Deze constructie is in natuurlijke taal niet al te moeilijk te begrijpen, dus het probleem valt wel mee: Of dat 1e geval is 0, óf een interestrate en een intrate zijn 0 of null.

Als je continu checks met x == 0 || isnull(x) ziet, raak je daar wel aan gewend en kan het allemaal, mits een beetje normaal met whitespace en haakje omgegaan wordt, wel redelijk leesbaar zijn.

Ik zou zelf overigens altijd eerst checken op null en dan pas op 0. Voor deze code maakt het niet uit, maar ik wil liever eerst weten of een var null is cq. kan zijn, voordat ik het met een concrete waarde ga vergelijken.

[Reinier]

Ik kwam net nog wat leuke tabelletjes in een van onze pakketten tegen



Check die namen En ze zijn allemaal vrijwel identiek:







Tja, wat moet je er van zeggen

[MTWZZ]

Ik krijg echt serieus de neiging om iets te posten in het "WTF situaties" topic in de HK
Het mooie bij dit soort dingen is dat er meestal nog een redelijk logische gedachte achter zit ook

[MBV]

@Reinier: Zoiets was vorig jaar ook op TDWTF. Even naar het engels vertalen, en hij mag in de Sidebar WTF's

[Reinier]

MBV schreef op donderdag 08 februari 2007 @ 21:05:
@Reinier: Zoiets was vorig jaar ook op TDWTF. Even naar het engels vertalen, en hij mag in de Sidebar WTF's

Heb erover zitten twijfelen Komt misschien nog

[Verwijderd]

@Reinier: dit is echt briljant! Als ik mijn uiterste best zou doen om iets absurds te maken, zou het niet in de buurt komen van de absurditeit hiervan.

Kun je nog een beetje uitleggen wat hiervan eigenlijk de bedoeling is? Ben wel benieuwd welke zieke geest zoiets bedenkt.

[RobIII]

Verwijderd schreef op vrijdag 09 februari 2007 @ 13:24:
Ben wel benieuwd welke zieke geest zoiets bedenkt.

Belangrijker: van welk bedrijf komt dit? Dan weet ik welke software ik voortaan moet mijden

[Not Pingu]

Misschien zit er wel een gedachte achter, wie weet wilden ze het mogelijk maken om sorteermogelijkheden dynamisch in te stellen?

[Woy]

Not Pingu schreef op vrijdag 09 februari 2007 @ 13:31:
Misschien zit er wel een gedachte achter, wie weet wilden ze het mogelijk maken om sorteermogelijkheden dynamisch in te stellen?

En dat is niet mogenlijk met minder tabellen omdat??

[Not Pingu]

Ok, "Nooit, Bijna nooit, Regelmatig, Meestal" is wel een beetje dubbelop met: "Zelden, Vaak niet, Meestal wel, Altijd" etc.

[.oisyn]

That's not the point. Het gaat erom dat je niet aparte tabellen nodig hebt voor elke mogelijke combinatie van woorden. Simpel voorbeeld: maak gewoon 1 tabel met dezelfde kolommen als de huidige tabellen, maar inclusief een extra 'tag' (een enum of een string of whatever) die samen met de huidige PK de nieuwe PK vormt. De contents van elke losse tabel kun je vervolgens in die enkele grotere tabel plaatsen door voor elke kleine tabel een unieke tag te gebruiken.

En een [SELECT * FROM tbl_NooitZeldenVaakAltijd] wordt dan [SELECT * FROM tbl_HippeTabelNaam WHERE tag='NooitZeldenVaakAltijd']

[ Voor 12% gewijzigd door .oisyn op 09-02-2007 13:47 ]

[Woy]

.oisyn schreef op vrijdag 09 februari 2007 @ 13:45:
That's not the point. Het gaat erom dat je niet aparte tabellen nodig hebt voor elke mogelijke combinatie van woorden. Simpel voorbeeld: maak gewoon 1 tabel met dezelfde kolommen als de huidige tabellen, maar inclusief een extra 'tag' (een enum of een string of whatever) die samen met de huidige PK de nieuwe PK vormt. De contents van elke losse tabel kun je vervolgens in die enkele grotere tabel plaatsen door voor elke kleine tabel een unieke tag te gebruiken.

En een [SELECT * FROM tbl_NooitZeldenVaakAltijd] wordt dan [SELECT * FROM tbl_HippeTabelNaam WHERE tag='NooitZeldenVaakAltijd']

Idd daar doelde ik op. Dan hoef je tenminste ook niet een extra tabel aan te maken als je nog een extra sorteer mogenlijkheid toe wilt voegen.

Maar ik heb vaak het idee dat mensen bang zijn om "veel" records in een tabel te stoppen en dan liever een extra tabel aanmaken.

[ Voor 7% gewijzigd door Woy op 09-02-2007 14:35 ]

[Reinier]

Precies, dit kan makkelijk in een enkele tabel. En als je er al voor kiest om het in meerdere tabellen te stoppen, geef ze dan in ieder geval een normale naam. Wat als je een optie wilt toevoegen, dan zou je in feite de tabelnaam moeten uitbreiden met je nieuwe optie
En RobIII: het is niet netjes om te melden over welke leverancier het gaat, toch?
Nee, ik grapte ook maar

[ Voor 12% gewijzigd door RobIII op 14-02-2007 23:55 ]

[Dido]

rwb schreef op vrijdag 09 februari 2007 @ 14:33:
Maar ik heb vaak het idee dat mensen bang zijn om "veel" records in een tabel te stoppen en dan liever een extra tabel aanmaken.

Jamaar, het is ook eng om honderden records in 1 tabel te hebben!

Daarnaast is het ook heerlijk overzichtelijk om aparte tabellen te hebben als "Verkoop_2006_Januari", "Verkoop_2006_Februari", dan weet je tenminst waar je de informatie moet zoeken

[Verwijderd]

Weinig mis met het stoppen van veel records in 1 tabel, zolang je maar geen redundancy hebt.

[Robtimus]

Idd. Wij hebben een tabel met een soort van access codes, welke geverifieerd moeten worden. Daar zitten ondertussen al zo'n 5 miljoen records in, en dat worden er heus nog wel meer.
(Vraag maar niet waarom er zoveel zijn, dat komt door de klant.)

Dit systeem heeft trouwens wel een enorme fout gehad. Ter info: de database lookup gaat vooral op de code zelf, om te kijken of deze in de database zit. Alleen werd na een tijdje de lookup trager en trager en trager. Wat blijkt: dit belangrijke veld, dat uniek voorkomt in de database, waarop exact gezoekt wordt, waarvan al honderdduizenden verschillende records waren, had geen index...
Even een index erop gezet, en de snelheid was drastisch verhoogd.

[muba]

Ik had vandaag ook wel weer een leuke...

Perl:

for (my $c = 0; $c <= length($word); $c++) {
    ...
    ...

    $match[0] = someCalculation($somevalue);
    # hier komt in sommige gevallen,
    # en specifiek in het geval dat ik aan het testen was
    # -1 uit

    ...
    ...

    $c += $match[0];
   # en je maar afvragen waar die endless loops vandaan komen...
}

[elTigro]

MUBA schreef op maandag 12 februari 2007 @ 04:21:
Ik had vandaag ook wel weer een leuke...

Een soort van afstraffing op invoer van illegale waarden? In het kader van:
(bash)

code:

echo 'Geef een getal tussen 0 en 10'
read somevalue

'Eigen schuld, moet je maar geen -1 invullen'

[HawVer]

MUBA schreef op maandag 12 februari 2007 @ 04:21:
Ik had vandaag ook wel weer een leuke...

Perl:

for (my $c = 0; $c <= length($word); $c++) {
    ...
    ...

    $match[0] = someCalculation($somevalue);
    # hier komt in sommige gevallen,
    # en specifiek in het geval dat ik aan het testen was
    # -1 uit

    ...
    ...

    $c += $match[0];
   # en je maar afvragen waar die endless loops vandaan komen...
}

Hij is fijn Het veranderen van de waarde van een loop is tricky. Dat probeer ik zelf zoveel mogelijk te voorkomen. Meestal is er wel een weg om heen.

[Verwijderd]

HawVer schreef op maandag 12 februari 2007 @ 09:41:
[...]

Hij is fijn Het veranderen van de waarde van een loop is tricky. Dat probeer ik zelf zoveel mogelijk te voorkomen. Meestal is er wel een weg om heen.

en anders de waarde gewoon altijd nog een keer in de loop zelf checken en/of zeer goed testen.

[Verwijderd]

Verwijderd schreef op zondag 11 februari 2007 @ 19:21:
zolang je maar geen redundancy hebt.

Gelukkig is de werkelijkheid niet zo zwart-wit

[GoodspeeD]

Verwijderd schreef op maandag 12 februari 2007 @ 12:41:
[...]
Gelukkig is de werkelijkheid niet zo zwart-wit

Bedoel je nou dat een tabel niet volgestopt mag worden of dat je in werkelijkheid wel degelijk redundante informatie in je tabellen hebt staan?

In het eerste geval ben ik het niet met je eens. In het tweede geval helaas wel. In onze database komt het helaas regelmatig voor dat we redundante informatie hebben, puur omdat anders queries veel te lang gaan duren. Duurde even voordat ik daar met mijn hoofd bij kon. Op school geleerd dat je alles moet normaliseren en dan kom je in het bedrijfsleven en blijkt dat vaak toch niet volledig op te gaan.

Ik ben er wel nog steeds een beetje sceptisch over. Als je je database goed genormaliseerd hebt, resulteert dit uiteindelijk in een kleinere database (opslaggrootte) wat ook weer resulteert in snelheidswinst na verloop van tijd.

Maar goed: die discussie staat los van dit onderwerp.

[RobIII]

GoodspeeD schreef op woensdag 14 februari 2007 @ 15:55:
Ik ben er wel nog steeds een beetje sceptisch over. Als je je database goed genormaliseerd hebt, resulteert dit uiteindelijk in een kleinere database (opslaggrootte) wat ook weer resulteert in snelheidswinst na verloop van tijd.

Dat is lang niet in alle gevallen waar; als je in een bepaalde query (bijvoorbeeld) 24 tabellen moet joinen met een bult where-clauses en weet ik wat al niet meer om een ordertotaal op te halen dan zal dat altijd resulteren in een tragere uitvoering van de query dan wanneer je de totalen meteen bij de order had opgeslagen. Het is dan wel niet genormaliseerd en redundant, maar wel efficiënter en sneller; kleine DB of niet.
Dat je met kleine DB projectjes weinig merkt van de verschillen wil niet zeggen dat je dat bij huge-ass DB's ook niet doet.

[bobo1on1]

Ik doe bij Dirksen een cursus C, nou zit er een opdracht bij waarbij je een programma moet schrijven waarbij je een database aan kunt leggen van personen, je moet een naam, adres en telefoonnummer opslaan in een linked list.

Nou vraagt het programma in een loop om de gegevens, nou is de bedoeling dat het programma stopt met vragen als je als naam een x invoert.

Nou zit er wat voorbeeldcode bij van de prachtige oplossing die ze hiervoor gevonden hebben:

C:

char Naam[255];

printf("Naam ('x' om te stoppen) : ");
gets(Naam);

if (Naam[0] == 'x') return (0);
if (strlen(Naam) > 25) printf("Invoer niet geaccepteerd\n");

[.oisyn]

bobo1on1 schreef op woensdag 14 februari 2007 @ 17:55:
[..] nou [..] Nou [...] nou [..] Nou [..]

[code]

Ook lullig als je xandra heet oid

[ Voor 31% gewijzigd door .oisyn op 14-02-2007 18:07 ]

[Theuno]

bobo1on1 schreef op woensdag 14 februari 2007 @ 17:55:
Ik doe bij Dirksen een cursus C, nou zit er een opdracht bij waarbij je een programma moet schrijven waarbij je een database aan kunt leggen van personen, je moet een naam, adres en telefoonnummer opslaan in een linked list.

Nou zit er wat voorbeeldcode bij van de prachtige oplossing die ze hiervoor gevonden hebben:

C:

char Naam[255];

printf("Naam ('x' om te stoppen) : ");
gets(Naam);

if (Naam[0] == 'x') return (0);
if (strlen(Naam) > 25) printf("Invoer niet geaccepteerd\n");

Ik neem aan dat er meer functie omheen zit. Maar multiple returns zijn ranzig slecht onderhoudbaar op den duur. Die x is puur een schoolvoorbeeld, maar ook daar hadden ze al beter kunnen vragen om een andere toets of combinatie.

..zelfs een q is beter.. denk ik zo ?

[ Voor 7% gewijzigd door Theuno op 14-02-2007 18:14 ]

[bobo1on1]

Er zit uiteraard meer omheen, maar je snapt het idee wel.

Een q kan ook niet, wat als je nou quinten heet?

De tekst inlezen met gets vind ik helemaal smerig, als iemand meer dan 254 tekens invoert kunnen er hele rare dingen gebeuren.

[ Voor 37% gewijzigd door bobo1on1 op 14-02-2007 18:24 ]

[Woy]

Theuno schreef op woensdag 14 februari 2007 @ 18:14:
[...]
Maar multiple returns zijn ranzig slecht onderhoudbaar op den duur.

Ik vindt multiple returns helemaal niet perse slecht en onderhoudbaar. Je moet er zeker mee oppassen maar ik gebruik het regelmatig. Vooral bij controles aan het begin van een functie. Je kan dan wel allerlei if's gaan gebruiken om toch maar aan het einde van de functie te returnen maar dat vindt ik juist weer minder onderhoudbaar.

[Kwistnix]

Theuno schreef op woensdag 14 februari 2007 @ 18:14:
[...]


Maar multiple returns zijn ranzig slecht onderhoudbaar op den duur.

Niet per definitie. Ik vind het geforceerd handhaven van single point of exit in bepaalde gevallen juist erg onduidelijk. Als je in een methode de exit points niet meer kan overzien, dan is ie waarschijnlijk toch te complex en moet ie nodig gerefactored worden.

Edit: rwb was sneller

[ Voor 3% gewijzigd door Kwistnix op 14-02-2007 18:59 ]

[Verwijderd]

bobo1on1 schreef op woensdag 14 februari 2007 @ 17:55:

C:

char Naam[255];

printf("Naam ('x' om te stoppen) : ");
gets(Naam);

if (Naam[0] == 'x') return (0);
if (strlen(Naam) > 25) printf("Invoer niet geaccepteerd\n");

Ik zie aanzienlijke problemen met het volgende:

1) wat bobo1on1 al schreef: gets() checkt niet de lengte van de buffer, dus als de user meer dan sizeof(Naam)-1 chars invoert, dan is er sprake van een buffer-overflow;

2) als de gebruiker EOF (Unix: ^D, Windows: ^Z) intypt, dan retourneert gets() NULL - waar niet op gecontroleerd wordt. Probleem is dat in dit geval de variabele Naam ongewijzigd is;

3) onder Unix kan gets() onderbroken worden door een signal, te vinden door na de call van gets() errno te testen op EINTR (system call interrupted) of iets vergelijkbaars. Afhankelijk van de reden van de signal, kan overwogen worden gets() opnieuw aan te roepen.

Als dit voorbeeldcode bij Dirksen is, dan ben ik van mening dat zij een serieus niveau-probleem hebben...

Geval 3) ben ik onder meer tegengekomen in een multi-threaded applicatie, waarin de signals gegenereerd door de code van een 3rd-party CORBA-lib me om de haverklap om de oren vlogen - en pending kbd reads steeds weer afgebroken werden. En in de meeste gevallen herstart moesten worden.

Merk daarnaast op dat gets() de LF vervangt door '\0', iets om rekening mee te houden als in plaats van gets(), fgets(), getchar() of bijvoorbeeld fread() gebruikt wordt.

Tenslotte ben ik van mening dat het zinvoller is het gebruik van multiple-returns per situatie te beoordelen, dan om het - al dan niet dogmatisch - ranzig te noemen.

[Spleasure]

RobIII schreef op woensdag 14 februari 2007 @ 16:05:
[...]

Dat is lang niet in alle gevallen waar; als je in een bepaalde query (bijvoorbeeld) 24 tabellen moet joinen met een bult where-clauses en weet ik wat al niet meer om een ordertotaal op te halen dan zal dat altijd resulteren in een tragere uitvoering van de query dan wanneer je de totalen meteen bij de order had opgeslagen. Het is dan wel niet genormaliseerd en redundant, maar wel efficiënter en sneller; kleine DB of niet.
Dat je met kleine DB projectjes weinig merkt van de verschillen wil niet zeggen dat je dat bij huge-ass DB's ook niet doet.

Het mooiste is een goed genormaliseerde database en dan wat views aanmaken om vaakgebruikte en complexe queries te versimpelen.

[RobIII]

Spleasure schreef op woensdag 14 februari 2007 @ 22:58:
[...]


Het mooiste is een goed genormaliseerde database en dan wat views aanmaken om vaakgebruikte en complexe queries te versimpelen.

Dat het queryen van een view makkelijker "uit te schrijven" is zal ik niet ontkennen; maar vraag jezelf eens af wat een gebruiker daar van vindt, van ziet of wat 'ie er om zal geven? En met een view maak je het ophalen van die data (doorgaans) echt niet sneller hoor; als de query traag is vanwege vele joins en whatnots dan lost een view dat heus niet automagisch voor je op. De gebruiker merkt het echter wel als z'n rapport er binnen 1 seconde staat of binnen 30.
Een goed genormaliseerde database is een database die niet helemaal doorgeslagen is naar de 7e normaalvorm omdat wij programmeurs dat zo fijn vinden werken, maar een database die gewoon doet wat 'm gevraagd wordt binnen redelijke response-tijd. Een beetje redundante data is nog nooit iemand aan dood gegaan

[ Voor 3% gewijzigd door RobIII op 15-02-2007 00:40 ]

[bobo1on1]

Verwijderd schreef op woensdag 14 februari 2007 @ 22:19:
[...]

Ik zie aanzienlijke problemen met het volgende:

Ik ga ze denk ik eens een mailtje sturen

Dit is wat ik er van gemaakt heb:

C:

int VraagGegevens (persoon *input)
{
    printf("Voer de naam in (x om te stoppen):");
    scanf("%25s",input->Naam);
    ClearInbuffer();
    if (strcmp(input->Naam,"x") == 0) return 0;
    printf("Voer het adres in:");
    scanf("%25s",input->Adres);
    ClearInbuffer();
    printf("Voer het telefoonnummer in:");
    scanf("%10s",input->Tel);
    ClearInbuffer();
    printf("\n");
    return 1;
}

void ClearInbuffer()
{
    char Readchar;
    do
    {
        Readchar = getchar();
    }
    while (Readchar != '\n');
}

[Swaptor]

RobIII schreef op woensdag 14 februari 2007 @ 23:44:
[...]Een goed genormaliseerde database is een database die niet helemaal doorgeslagen is naar de 7e normaalvorm omdat wij programmeurs dat zo fijn vinden werken, maar een database die gewoon doet wat 'm gevraagd wordt binnen redelijke response-tijd. Een beetje redundante data is nog nooit iemand aan dood gegaan

Wat RobIII zegt dus.

'Goed' genormaliseerd is genormaliseerd naar de performance die de DB moet leveren onder de gestelde voorwaarden, dus ook wanneer dit niet geheel netjes is en/of beter uitgevoerd had kunnen worden. Zolang alles, en dan bedoel ik dus heeeel veel, goed gedocumenteerd is zodat iemand anders ook snapt welke hersenkronkels jij had toen je de applicatie creëerde is een ietwat suboptimale implementatie qua stijl en netheid ook perfect.

Helaas weet zowat iedereen hier dat het laatste eigenlijk nooit voorkomt, behalve in je eigen applicaties

[GoodspeeD]

RobIII schreef op woensdag 14 februari 2007 @ 16:05:
[...]

Dat is lang niet in alle gevallen waar; als je in een bepaalde query (bijvoorbeeld) 24 tabellen moet joinen met een bult where-clauses en weet ik wat al niet meer om een ordertotaal op te halen dan zal dat altijd resulteren in een tragere uitvoering van de query dan wanneer je de totalen meteen bij de order had opgeslagen. Het is dan wel niet genormaliseerd en redundant, maar wel efficiënter en sneller; kleine DB of niet.
Dat je met kleine DB projectjes weinig merkt van de verschillen wil niet zeggen dat je dat bij huge-ass DB's ook niet doet.

Dat zeg ik. Ik geloof best dat je bij huge-ass databases het verschil merkt. Sterker nog: dat is de reden waarom we hier op het werk dus een aantal redundante kolommen in tabellen hebben. Maar ik zie ook regelmatig redundantie waarvan ik denk dat het toch echt een beetje overbodig is.

Je houdt gewoon altijd de eindgebruiker vs ontwikkelaar discussie. De eindgebruiker wil alles zien en het liefst binnen een fractie van een seconde. De ontwikkelaar wil het het liefst zo logisch mogelijk in elkaar zetten. Zoals ik al zei: het duurde even voordat ik daar met mijn hoofd bij kon.

[Woy]

Swaptor schreef op donderdag 15 februari 2007 @ 00:45:
[...]

Wat RobIII zegt dus.

'Goed' genormaliseerd is genormaliseerd naar de performance die de DB moet leveren onder de gestelde voorwaarden, dus ook wanneer dit niet geheel netjes is en/of beter uitgevoerd had kunnen worden. Zolang alles, en dan bedoel ik dus heeeel veel, goed gedocumenteerd is zodat iemand anders ook snapt welke hersenkronkels jij had toen je de applicatie creëerde is een ietwat suboptimale implementatie qua stijl en netheid ook perfect.

Helaas weet zowat iedereen hier dat het laatste eigenlijk nooit voorkomt, behalve in je eigen applicaties

Documentatie dat is toch datgene wat je door de compiler haalt en executables oplevert?

[GoodspeeD]

rwb schreef op donderdag 15 februari 2007 @ 09:45:
[...]

Documentatie dat is toch datgene wat je door de compiler haalt en executables oplevert?

Roflcopter

[Dido]

Veel Lansa hoef je niet te kennen om te bedenken dat dit makkelijekr kan
En het commentaar stond er al in, niet alleen slaat het algoritme als een tang op een varken, maar degene die het verzonnen heeft is er trots genoeg op om het te documenteren

code:

Change field(#BLAAT) to(1)
* loop until all the indexes you want toUSE are in the combobox
* change the loopvalue (now 3)  to the no off indexes you want toUSE
Dowhile cond('#blaat *le 5')
* add a when value_is for each index
  Case of_field(#BLAAT)
    When value_is('= 1')
* SETthe code for the index
      Change field(#FOO) to(IETS)
* SETthe description for the index
      Change field(#BAR) to(*MTXTIETS)
    When value_is('= 2')
* SETthe code for the index
      Change field(#FOO) to(NOGIETS)
* SETthe description for the index
      Change field(#BAR) to(*MTXTTNOGIETS)
    When value_is('= 3')
* SETthe code for the index
      Change field(#FOO) to(ANDERS)
* SETthe description for the index
      Change field(#BAR) to(*MTXTANDERS)
    When value_is('= 4')
* SETthe code for the index
      Change field(#FOO) to(WHAT)
* SETthe description for the index
      Change field(#BAR) to(*MTXTWHAT)
    When value_is('= 5')
* SETthe code for the index
      Change field(#FOO) to(EVER)
* SETthe description for the index
      Change field(#BAR) to(*MTXTEVER)
  Endcase
* add the item to the combobox
  Add_Entry to_list(#LIJST)
* increase the loopcounter
  Change field(#BLAAT) to('#blaat + 1')
Endwhile

[ Voor 6% gewijzigd door Dido op 15-02-2007 11:51 ]

[Wijnbo]

Geen idee of ie al vaker langsgekomen is.... maar zeer vaak zulke constructies gemaakt, vaak over veel regels verdeeld waardoor je het overzicht kwijt bent:

Java:

for (x = 0; x < 5; x++){
  blaat
  blaat
  for (y = 0; y < 5; y++){
    blaat nogiets
  }
  for (x = 0; x < 5; x++){
  bladiebla
  }
}

En maar afvragen vanwaar die eindeloze loop

[Mischa_NL]

ik kwam nog iets tegen van mezelf van jaren geleden, toen ik net begon me asp.

Visual Basic:

IP = request.servervariables("remote_host")
SQL = "SELECT * FROM Ban_IP"
Set objRec = objcon.execute(SQL)

Do while NOT objRec.EOF

if objRec.fields("IP") = IP then
response.Redirect("?Page=Gastenboek&Content=Banned")
end if

objRec.movenext
loop

De bedoeling is natuurlijk dit:

Visual Basic:

IP = request.servervariables("remote_host")
SQL = "SELECT * FROM Ban_IP WHERE IP = " & IP
Set objRec = objcon.execute(SQL)

if not objRec.EOF then
response.Redirect("?Page=Gastenboek&Content=Banned")
end if

[Verwijderd]

StonedKinG34 schreef op donderdag 15 februari 2007 @ 14:50:
Geen idee of ie al vaker langsgekomen is.... maar zeer vaak zulke constructies gemaakt, vaak over veel regels verdeeld waardoor je het overzicht kwijt bent:

Java:

for (x = 0; x < 5; x++){
  blaat
  blaat
  for (y = 0; y < 5; y++){
    blaat nogiets
  }
  for (x = 0; x < 5; x++){
  bladiebla
  }
}

En maar afvragen vanwaar die eindeloze loop

nou, daar had je wel even iets mooiers van kunnen maken
Persoonlijk vind ik het gebruik van blaat en bladiebla nog stukken erger Vooral leuk als dat soort dingen in foutmeldingen opduiken. Dat iemand met het programma werkt dan opeens: PLOINK: Error in function Blaat stack bla is empty. Lekker professioneel

[Salandur]

StonedKinG34 schreef op donderdag 15 februari 2007 @ 14:50:
Geen idee of ie al vaker langsgekomen is.... maar zeer vaak zulke constructies gemaakt, vaak over veel regels verdeeld waardoor je het overzicht kwijt bent:

Java:

for (x = 0; x < 5; x++){
  blaat
  blaat
  for (y = 0; y < 5; y++){
    blaat nogiets
  }
  for (x = 0; x < 5; x++){
  bladiebla
  }
}

En maar afvragen vanwaar die eindeloze loop

daarom doe ik eigenlijk altijd

Java:

for (int x = 0; x< iets; x++) {
  ..
}

[GoodspeeD]

Salandur schreef op donderdag 15 februari 2007 @ 15:24:
[...]


daarom doe ik eigenlijk altijd

Java:

for (int x = 0; x< iets; x++) {
  ..
}

Begrijp ik het nou goed en declareer je de variabele in je for-loop zodat, als je dat nog een keer zou doen je een compilefout zou krijgen?

[.oisyn]

GoodspeeD schreef op donderdag 15 februari 2007 @ 15:37:
[...]

Begrijp ik het nou goed en declareer je de variabele in je for-loop

Zo begrijp je het goed

zodat als je dat nog een keer zou doen je een compilefout zou krijgen?

zo niet meer
De x leeft binnen de scope van de for, en niet erbuiten. In de meeste talen met dergelijke scoping rules verbergt een naam gedefinieerd in de binnenste scope de namen in de omliggende scopes. Dus geen compilefout maar gewoon prima werkende code (edoch onduidelijk, maar goed )

In C++ heb je wat vage regels hieromtrent die wat ranzig zijn imho:

C++:

#include <iostream>

int main()
{
    int a = 5, b = 5;

    {
        int a(a);
        int b = b;
        std::cout << a << ", " << b << std::endl;
    }
}

Q: Wat is de output van dit programma?

[ Voor 20% gewijzigd door .oisyn op 15-02-2007 15:45 ]

[BasieP]

GoodspeeD schreef op donderdag 15 februari 2007 @ 15:37:
[...]

Begrijp ik het nou goed en declareer je de variabele in je for-loop zodat, als je dat nog een keer zou doen je een compilefout zou krijgen?

ja en nee,
je kan op deze manier BINNEN de loop nog steeds de variable gebruiken (dus het kan nog steeds fout gaan) maar je kan hem in ieder geval nu buiten de loop niet gebruiken

[Salandur]

BasieP schreef op donderdag 15 februari 2007 @ 15:50:
[...]

ja en nee,
je kan op deze manier BINNEN de loop nog steeds de variable gebruiken (dus het kan nog steeds fout gaan) maar je kan hem in ieder geval nu buiten de loop niet gebruiken

en als je het standaard aan houd kan je hem binnen je loop niet nog een keer gebruiken omdat de compiler dan gaat klagen dat x al gedeclareerd is.

[GoodspeeD]

Salandur schreef op donderdag 15 februari 2007 @ 16:29:
[...]

en als je het standaard aan houd kan je hem binnen je loop niet nog een keer gebruiken omdat de compiler dan gaat klagen dat x al gedeclareerd is.

En dat was dus wat ik bedoelde met mijn vraag.

[ Voor 7% gewijzigd door GoodspeeD op 15-02-2007 16:54 ]

[MetroidPrime]

StonedKinG34 schreef op donderdag 15 februari 2007 @ 14:50:
Geen idee of ie al vaker langsgekomen is.... maar zeer vaak zulke constructies gemaakt, vaak over veel regels verdeeld waardoor je het overzicht kwijt bent:

Java:

for (x = 0; x < 5; x++){
  blaat
  blaat
  for (y = 0; y < 5; y++){
    blaat nogiets
  }
  for (x = 0; x < 5; x++){
  bladiebla
  }
}

En maar afvragen vanwaar die eindeloze loop

Die code komt niet in een eindeloze loop, maar de tweede for-loop met x zorgt er voor dat x meteen naar 5 wordt opgehoogd en de buitenste loop wordt vervolgens verlaten, terwijl x nog steeds 0 had moeten zijn.

.oisyn schreef op donderdag 15 februari 2007 @ 15:40:
zo niet meer
De x leeft binnen de scope van de for, en niet erbuiten. In de meeste talen met dergelijke scoping rules verbergt een naam gedefinieerd in de binnenste scope de namen in de omliggende scopes. Dus geen compilefout maar gewoon prima werkende code (edoch onduidelijk, maar goed )

In Java krijg je dan juist een compilerfout. De tweede x komt dan binnen de scope van de eerste x en dat accepteert de Java compiler niet.

[MBV]

MetroidPrime schreef op donderdag 15 februari 2007 @ 17:00:
[...]


Die code komt niet in een eindeloze loop, maar de tweede for-loop met x zorgt er voor dat x meteen naar 5 wordt opgehoogd en de buitenste loop wordt vervolgens verlaten, terwijl x nog steeds 0 had moeten zijn.

Maar als je de eerste loop van 0 tot 10 laat lopen wel, en waarschijnlijk iets verkeerd geanonimiseerd

[.oisyn]

MetroidPrime schreef op donderdag 15 februari 2007 @ 17:00:
In Java krijg je dan juist een compilerfout. De tweede x komt dan binnen de scope van de eerste x en dat accepteert de Java compiler niet.

Stupid Java

[Verwijderd]

Salandur schreef op donderdag 15 februari 2007 @ 16:29:
[...]

en als je het standaard aan houd kan je hem binnen je loop niet nog een keer gebruiken omdat de compiler dan gaat klagen dat x al gedeclareerd is.

Buiten dat, is het hierdoor een lokale variabele, waardoor hij snel en goed met de garbage collecting mee gaat.

[Woy]

Verwijderd schreef op donderdag 15 februari 2007 @ 18:40:
[...]


Buiten dat, is het hierdoor een lokale variabele, waardoor hij snel en goed met de garbage collecting mee gaat.

Tja maar voor een int is dat natuurlijk niet echt interesant. Als het om een of ander object gaat wat veel resources gebruikt begint het wel wat interessanter te worden.

[Verwijderd]

Verwijderd schreef op donderdag 15 februari 2007 @ 18:40:
[...]


Buiten dat, is het hierdoor een lokale variabele, waardoor hij snel en goed met de garbage collecting mee gaat.

Ik heb eigenlijk nooit het idee dat iets snel met de Garbage Collecting mee gaat
Volgens mij zou het ook belachelijk veel processorkracht vergen als een Garbage Collector zo efficiënt gaat werken dat je dergelijke kleine momenten zou kunnen detecteren in het geheugenverbruik.

[Verwijderd]

Verwijderd schreef op donderdag 15 februari 2007 @ 19:16:
[...]

Ik heb eigenlijk nooit het idee dat iets snel met de Garbage Collecting mee gaat
Volgens mij zou het ook belachelijk veel processorkracht vergen als een Garbage Collector zo efficiënt gaat werken dat je dergelijke kleine momenten zou kunnen detecteren in het geheugenverbruik.

Een echt groot verschil maakt het inderdaad niet, maar het maakt wel een verschil. En de garbage collector komt vaker langs dan je denkt.

[Voutloos]

Misschien een domme vraag, aangezien een aantal mensen ervan overtuigd is dat GC aan de slag moet: is er uberhaupt wel GC nodig voor een dusdanig lokale variabele met primitief datatype?

[Verwijderd]

Voutloos schreef op donderdag 15 februari 2007 @ 22:32:
Misschien een domme vraag, aangezien een aantal mensen ervan overtuigd is dat GC aan de slag moet: is er uberhaupt wel GC nodig voor een dusdanig lokale variabele met primitief datatype?

Ja.

[Voutloos]

Had ik kunnen verwachten. Alhoewel, misschien is GC toch stiekem niet van toepassing omdat x geëlimineerd kan worden na wat loop unrolling.

[Verwijderd]

Voutloos schreef op donderdag 15 februari 2007 @ 22:53:
Had ik kunnen verwachten. Alhoewel, misschien is GC toch stiekem niet van toepassing omdat x geëlimineerd kan worden na wat loop unrolling.

Als er sprake is van een GC binnen een platform/taal, dan zal alleen deze opruimen. Er kan dus geen sprake zijn van elimineren.

[Voutloos]

Crap, de java naar bytecode compiler doet blijkbaar niet aan optimalisaties. Ik houd wel op met mijn Java onkunde hardop te verkondigen.

edit:
... hmz, maar kan de JIT compiler dit niet toch stiekem wel doen? Anders vallen er voor JIT wel een aantal boeiende optimalisaties af.

[ Voor 34% gewijzigd door Voutloos op 15-02-2007 23:19 . Reden: vraag blijft toch aan me knagen ja. okedag ]

[Verwijderd]

Voutloos schreef op donderdag 15 februari 2007 @ 23:10:
Crap, de java naar bytecode compiler doet blijkbaar niet aan optimalisaties. Ik houd wel op met mijn Java onkunde hardop te verkondigen.

edit:
... hmz, maar kan de JIT compiler dit niet toch stiekem wel doen? Anders vallen er voor JIT wel een aantal boeiende optimalisaties af.

Een JIT compiler dient snel te zijn. Hij zal wel wat optimalisaties doen, maar het lijkt me niet de bedoeling dat eerst een minuut bezig is om vanalles en en nog wat te optimaliseren en vervolgens te compileren

[DaCoTa]

Verwijderd schreef op donderdag 15 februari 2007 @ 22:37:
[...]
Ja.

Niet per definitie. Primitieve datatypes worden gepooled. Er is dus een verzameling beschikbaar welke hergebruikt kunnen worden. (Als ik me niet vergis tenminste)

[Macros]

Voutloos schreef op donderdag 15 februari 2007 @ 22:32:
Misschien een domme vraag, aangezien een aantal mensen ervan overtuigd is dat GC aan de slag moet: is er uberhaupt wel GC nodig voor een dusdanig lokale variabele met primitief datatype?

Nee!
Locale variabelen bestaan op de stack. Ze staan dus niet op de heap en worden dus niet gegarbage collect. Dat is wel basic kennis. Objecten die worden aangemaakt bestaan wel op de heap, dus die worden wel gecollect.

[Voutloos]

Zie je wel! Kriebelde het niet voor niets bij mij.

[Verwijderd]

Mischa_NL schreef op donderdag 15 februari 2007 @ 15:09:
ik kwam nog iets tegen van mezelf van jaren geleden, toen ik net begon me asp.

Visual Basic:

IP = request.servervariables("remote_host")
SQL = "SELECT * FROM Ban_IP"
Set objRec = objcon.execute(SQL)

Do while NOT objRec.EOF

if objRec.fields("IP") = IP then
response.Redirect("?Page=Gastenboek&Content=Banned")
end if

objRec.movenext
loop

De bedoeling is natuurlijk dit:

Visual Basic:

IP = request.servervariables("remote_host")
SQL = "SELECT * FROM Ban_IP WHERE IP = " & IP
Set objRec = objcon.execute(SQL)

if not objRec.EOF then
response.Redirect("?Page=Gastenboek&Content=Banned")
end if

Hehe, ook lekker voor je achterliggende database.

Stel je voor dat je gastenboek enorm veel items heeft, en hij daar allemaal overheen loopt

[Verwijderd]

Macros schreef op vrijdag 16 februari 2007 @ 09:27:
[...]

Nee!
Locale variabelen bestaan op de stack. Ze staan dus niet op de heap en worden dus niet gegarbage collect. Dat is wel basic kennis. Objecten die worden aangemaakt bestaan wel op de heap, dus die worden wel gecollect.

Waarom zou het basis kennis zijn, kun je geen software schrijven als je dit niet weet
(althans, software met talen die garbage collectors gebruiken natuurlijk )

Wel handig om te weten overigens

[ Voor 7% gewijzigd door Verwijderd op 16-02-2007 09:38 ]

[.oisyn]

Verwijderd schreef op donderdag 15 februari 2007 @ 19:16:
[...]

Ik heb eigenlijk nooit het idee dat iets snel met de Garbage Collecting mee gaat
Volgens mij zou het ook belachelijk veel processorkracht vergen als een Garbage Collector zo efficiënt gaat werken dat je dergelijke kleine momenten zou kunnen detecteren in het geheugenverbruik.

Met simpele refcounting kun je objecten al opruimen als dat nodig is zodra ze uit scope gaan. Refcounting pakt natuurlijk niet cyclic references mee (object A heeft een referentie naar object B, terwijl die weer een referentie naar A hebben - als ze nog op de stack staan is de refcount van beide 2, maar uit scope wordt het 1 waardoor ze nog niet opgeruimd worden), maar daar is de GC voor. Dat hoeft dus niet heel veel processorkracht te vereisen.

De vraag is natuurlijk of je wilt dat na het eind van elk scope block mogelijk finalizers aangeroepen worden.

Voutloos schreef op donderdag 15 februari 2007 @ 23:10:
Crap, de java naar bytecode compiler doet blijkbaar niet aan optimalisaties. Ik houd wel op met mijn Java onkunde hardop te verkondigen.

edit:
... hmz, maar kan de JIT compiler dit niet toch stiekem wel doen? Anders vallen er voor JIT wel een aantal boeiende optimalisaties af.

De JIT compiler heeft veel meer informatie dan de compiler, en kan dus ook veel beter optimizen dan de compiler. Hij weet bijvoorbeeld de implementatie van *alle* functies van de app (hij kan dus inlinen waar nodig), en op wat voor systeem de sourcecode draait (loop unrolling is namelijk niet per se goedkoper - op systemen met een kleine instructie cache is het bijvoorbeeld beter om te loopen). Vandaar dat java bytecode bijna een 1:1 vertaling is van de sourcecode, wat ook meteen de reden is dat bytecode weer zo goed te decompilen is

Verwijderd schreef op donderdag 15 februari 2007 @ 23:50:
[...]


Een JIT compiler dient snel te zijn. Hij zal wel wat optimalisaties doen, maar het lijkt me niet de bedoeling dat eerst een minuut bezig is om vanalles en en nog wat te optimaliseren en vervolgens te compileren

Wel als dat gedeelte van de code vervolgens 3 uur achter elkaar moet draaien. Een JIT compiler kan dus optimizen naar gelang hoe vaak een deel van de code aangeroepen wordt.

Verwijderd schreef op vrijdag 16 februari 2007 @ 09:38:
[...]

Waarom zou het basis kennis zijn, kun je geen software schrijven als je dit niet weet

Je zou je natuurlijk af kunnen vragen waarom een primitieve zich anders gedraagt dan een object terwijl hij (volgens jou) ook gewoon op de heap staat . Daarnaast is het ook wel handig om te weten dat een int sneller performt dan een Integer.

[ Voor 8% gewijzigd door .oisyn op 16-02-2007 11:47 ]

[jan-marten]

Variabelennamen icm kolomnamen:
tblNaam.ID, tblNaam.id of tblNaam.NaamID?
$_REQUEST['id'], $_REQUEST['ID'] of $_REQUEST['NaamID']?

(eigen prutswerk overigens , ik ben de laatste vormen maar gaan gebruiken)

[ Voor 12% gewijzigd door jan-marten op 16-02-2007 12:31 ]

[GoodspeeD]

Volgens mij komt de garbage collector helemaal niet kijken bij het bevrijden van een int die je in een methode of een loop declareert, wel? De garbage collector is alleen voor dynamisch geheugen te bevrijden waarnaar niet meer gerefereerd wordt. Een variabele die gewoon gedeclareerd is in een methode of loop of iets dergelijks zal automatisch al op het juiste moment bevrijdt worden door de virtual machine. Dus zodra de variabele out of scope is.

[.oisyn]

Euh ja, wat al gezegd was dus

[Verwijderd]

PHP:

if ($array["Cache"] = "Yes"){
    echo"<small>(cache)</small>";
}

En je dan maar afvragen waarom hij altijd ^(cache) laat zien

[mithras]

[PHP]IE geeft problemen met inloggen dmv sessies: Elke keer dat ik ging testen was het met IE als browser, dus de schuld lag bij IE, nietwaar? Ik kon het me niet voorstellen en dacht dat ik gek werd. De query:

PHP:

$result = $database->Execute("SELECT S.user_id, S.last_visit, U.name, U.level 
        FROM plugin_user_session AS S, plugin_user_users AS U 
        WHERE S.user_id = U.id 
        AND S.ip='".$_SERVER["REMOTE_ADDR"]."' 
        AND S.hash='".$_SESSION["hash"]."'");

Wat is S.ip voor een veld? Een string(12), want een ip adres bestaat toch altijd uit vier groepen van maximaal drie cijfers
Gauw maar even veranderd naar string(15) en alles werkt weer, maar dit ontdek je dus echt niet zo snel

[ Voor 3% gewijzigd door mithras op 22-02-2007 13:40 ]

[mr_taipan]

wOOt daar kun je wel een week om zoeken

[InZane]

Kweenie wie het verzonnen heeft, maar ik kwam het net tegen

PHP:

$result = handleImageUpload('afbeelding', '/upload/', 'groep_', 460, 460);

copy($_SESSION['uploadPath'].$result, $_SESSION['uploadPath'].'222/'.$result);
resizeImage($_SESSION['uploadPath'].'222/'.$result, 222, 222);

if ($result != false) {
    $data['afbeelding'] = $result;
} else if (isset($_POST['afbeelding_bestaand']) and !empty($_POST['afbeelding_bestaand'])) {
    $data['afbeelding'] = $_POST['afbeelding_bestaand'];
}

Als $result false is de bestandsnaam opnieuw opslaan (afbeelding_bestaand is hidden form input met bestandsnaam uit DB), sowieso heel apart.

2e hele leuke is dat er geen bestaande afbeelding kan zijn, want $data wordt ge-insert en niet ge-update

[gorgi_19]

Verwijderd schreef op vrijdag 16 februari 2007 @ 09:36:
[...]


Hehe, ook lekker voor je achterliggende database.

Stel je voor dat je gastenboek enorm veel items heeft, en hij daar allemaal overheen loopt

ach, een paar checks en hij blaast z'n connectionpool op, met alle niet gesloten conneties. Geef je iedereen een IP-Ban

[mithras]

mr_taipan schreef op donderdag 22 februari 2007 @ 15:17:
wOOt daar kun je wel een week om zoeken

Het was ook toeval dat ik mn sessie tabel doorliep en een ip adres wat ik kende niet helemaal klopte (laatste cijfer miste). * mithras ging eens tellen en sloeg zichzelf voor het hoofd

[MBV]

mithras schreef op donderdag 22 februari 2007 @ 16:14:
[...]
Het was ook toeval dat ik mn sessie tabel doorliep en een ip adres wat ik kende niet helemaal klopte (laatste cijfer miste). * mithras ging eens tellen en sloeg zichzelf voor het hoofd

waarom zo'n grote verspilling? Sla het op z'n minst de string zonder puntjes op, of nog beter: sla het als integer op, met INET_ATON()
http://dev.mysql.com/doc/...cellaneous-functions.html
Iets zegt mij dat je comparisons wat sneller gaan met ints dan met strings

[gorgi_19]

MBV schreef op donderdag 22 februari 2007 @ 17:14:
[...]

waarom zo'n grote verspilling? Sla het op z'n minst de string zonder puntjes op, of nog beter: sla het als integer op, met INET_ATON()
http://dev.mysql.com/doc/...cellaneous-functions.html
Iets zegt mij dat je comparisons wat sneller gaan met ints dan met strings

Gaat alleen niet meer werken met IPv6

[mithras]

MBV schreef op donderdag 22 februari 2007 @ 17:14:
[...]

waarom zo'n grote verspilling? Sla het op z'n minst de string zonder puntjes op, of nog beter: sla het als integer op, met INET_ATON()
http://dev.mysql.com/doc/...cellaneous-functions.html
Iets zegt mij dat je comparisons wat sneller gaan met ints dan met strings

Ik dacht namelijk: een ip adres ab.c.d.e wordt met het schrijven als integer hetzelfde als a.bc.d.e. Vandaar dat ik dacht dat het met strings alleen kon. Maar dit kende ik niet en is uiteraard een stuk sneller. Dit ga ik wel even doen

gorgi_19 schreef op donderdag 22 februari 2007 @ 17:15:
[...]

Gaat alleen niet meer werken met IPv6

Is het dus alleen mogelijk met strings? Maar eigenlijk: IPv6 ben ik nog eigenlijk niet tegen gekomen...

[ Voor 17% gewijzigd door mithras op 22-02-2007 17:20 ]

[soulrider]

gorgi_19 schreef op donderdag 22 februari 2007 @ 17:15:
[...]

Gaat alleen niet meer werken met IPv6

gaat zowiezo niet meer werken met IPv6 als er een string van maar 15-tekens is gebruikt om dat op te slagen.

[ Voor 5% gewijzigd door soulrider op 22-02-2007 17:29 ]

[Pyrus]

Algemeen slechte praktijk bij PHP: vetrouwen op magic quotes (die uit staan by default) op een site (met database) gericht op informatica en informatiekunde studenten

[mulder]

Pyrus schreef op donderdag 22 februari 2007 @ 18:25:
Algemeen slechte praktijk bij PHP: vetrouwen op magic quotes (die uit staan by default) op een site (met database) gericht op informatica en informatiekunde studenten

Ow mijn god en die weten het al beter natuurlijk

[Jaap-Jan]

soulrider schreef op donderdag 22 februari 2007 @ 17:28:
[...]


gaat zowiezo niet meer werken met IPv6 als er een string van maar 15-tekens is gebruikt om dat op te slagen.

Inderdaad, je hebt 16 tekens (voor databases dus CHAR(16)) nodig om een 128- bits adres op te kunnen slaan .