[alg] Slechtste programmeervoorbeelden deel 4

[MBV]

Volgens mij moet jij op zoek naar een nieuwe uitdaging, als ik je post zo lees

Weet je wat pas leuk is? Van het oude platform (klinkt ongeveer zoals jouw post) naar een ander project op een nieuw platform gaan. Nagelnieuw, vorig jaar van de grond af aan opgetrokken. En dat is al net zo'n drama als het vorige Unit tests? Wordt aan gewerkt. Continuous integration? Wordt aan gewerkt. IDE openen? Kom morgen maar terug...

[ Voor 14% gewijzigd door MBV op 17-08-2011 22:19 ]

[YopY]

MBV schreef op woensdag 17 augustus 2011 @ 22:18:
Volgens mij moet jij op zoek naar een nieuwe uitdaging, als ik je post zo lees

Weet je wat pas leuk is? Van het oude platform (klinkt ongeveer zoals jouw post) naar een ander project op een nieuw platform gaan. Nagelnieuw, vorig jaar van de grond af aan opgetrokken. En dat is al net zo'n drama als het vorige Unit tests? Wordt aan gewerkt. Continuous integration? Wordt aan gewerkt. IDE openen? Kom morgen maar terug...

En daarom moet je CI in het begin opzetten, en unit tests constant. Definition of done enzo - het is gewoon niet klaar als er geen test voor is. Kost discipline natuurlijk.

* YopY gaat maar niet zeggen dat z'n CI afwezig is en z'n tests braq en grotendeels afwezig zijn .

[Avalaxy]

Het is pas lastig je echt disciplinair aan de TDD style te houden imho. De verleiding om eerst maar wat dingen aan te maken en te proberen of het werkt is te groot.

[Blokker_1999]

Weet je, wat muse betreft, er zijn mensen die ook zonder dat pakket zulke code kunnen schrijven, Ik heb hier een rapport dat ik regelmatig ophaal om dan gegevens uit te filteren en in een database te steken. Maar voordat dat in orde was heb ik eerst enkele uren nodig gehad om de html eens goed te bekijken. Dat was tabel->rij->cel->tabel->rij->cel->tabel->rij->cel->tabel->rij->cel->content . Dan werd de onderste tabel terug gesloten, ook de daarbovenliggende cel en rij om dan een nieuw rij aan te maken met weer een cel en een tabel.

[Grijze Vos]

Paul schreef op woensdag 17 augustus 2011 @ 16:50:
Bij een nieuw product wel. Bij een product dat al jaren in gebruik en in onderhoud is daarentegen ...

Wij kregen het in ieder geval bij hem niet voor elkaar ... 'Jaja, komt wel een keer, maak nu eerst $nieuwe functionaliteit maar ...'

Da's een kwestie van een lead developer met een backbone hebben. Ik zit ook vaak zat te twisten met mn baas over dat soort zaken. Paar keer laten zien dat er -wel- winst te halen is door je verbeteringen/upgrades op een overzichtelijke termijn, dan lukt het uiteindelijk wel.

Lukt het dan nog niet -> verkassen.

[Paul]

Grijze Vos schreef op donderdag 18 augustus 2011 @ 08:46:
Da's een kwestie van een lead developer met een backbone hebben.

Right, want die heeft uiteindelijk het laatste woord... Lead developer was ook wel teveel eer voor mijn functie hoor; we zaten daar met 2 developers en een verkoper.

Lukt het dan nog niet -> verkassen.

True, dat heb ik dan ook gedaan

[CodeCaster]

Paul schreef op donderdag 18 augustus 2011 @ 08:55:
[...]
Right, want die heeft uiteindelijk het laatste woord...

Precies, je kunt het nog zo goed verdedigen, als de opdrachtgever het niet accepteert en je werkgever wil het je niet in zijn tijd laten doen, hang je. Of je moet je 's avonds enorm vervelen...

[Grijze Vos]

Mja, als je baas een paar keer niet naar je luistert en ineens ziet dat ie ergens voor een bak geld het schip in gaat omdat hij het per se op de verkeerde manier wilde aanpakken dan leert ie best snel dat ie wel naar je moet luisteren.

Hier is nog een leuke:

C#:

if (project.ProjectStatusId == (int)ProjectStatus.Gewonnen)
{
}
else if (project.ProjectStatusId > (int)ProjectStatus.Gewonnen)
{
}

Die cast naar int van de enum moet omdat de O/R mapper geen enums snapt, maar dan is er vervolgens een of andere smartass die het handig lijkt om de numerieke waarde te gebruiken. Drie keer raden wat er gebeurt als er ooit een status bij komt. ><

[Alex)]

C#:

public enum ProjectStatus : int
{
    Gewonnen = 0,
    Verloren = 1,
    FileNotFound = 2
}

Zou toch gewoon moeten kunnen? Ho, wacht, ik had de ">" gelezen als "=="

[ Voor 15% gewijzigd door Alex) op 18-08-2011 16:12 ]

[Patriot]

Grijze Vos schreef op donderdag 18 augustus 2011 @ 15:40:
Mja, als je baas een paar keer niet naar je luistert en ineens ziet dat ie ergens voor een bak geld het schip in gaat omdat hij het per se op de verkeerde manier wilde aanpakken dan leert ie best snel dat ie wel naar je moet luisteren.

Dan moet je het vaak al zeer inzichtelijk maken. Als een opdrachtgever jouw bedrijf niet aanneemt dan is het meestal niet zo dat je werkgever zich dan direct realiseert dat je een maand terug nog zei dat dat zou kunnen gebeuren. Die zal de oorzaak eerder in de prijs zoeken, hij denkt dus eerder dat hij dan te duur is..

Pas als er echt iets mis is gegaan en je kunt dat inzichtelijk maken, en aantonen dat het voorkomen had kunnen worden, dan is er hoop. Maar dat zie ik meestal niet gebeuren.

[Paradox]

geen voorbeeld.. wel te testen in de praktijk...

Inloggen bij mijn.ing.nl ... Username is username.. en je wachtwoord CASE INSENSITIVE!

dus gebruik elke willekeurige hoofdletter tijdens je inlog DaTMaaKtNietuit!

[Avalaxy]

Dat is al ongeveer sinds het tijdperk van de dinosaurussen bekend.

[.oisyn]

En het erge is, je username is wél case sensitive

[Styxxy]

.oisyn schreef op donderdag 18 augustus 2011 @ 16:27:
En het erge is, je username is wél case sensitive

Waarschijnlijk iemand de twee omgedraaid .

Ik kan wel begrijpen dat de username case insensitive is (dat heeft ook mijn voorkeur), maar het paswoord zou wel case sensitive moeten zijn.

[ Voor 6% gewijzigd door Styxxy op 18-08-2011 16:52 ]

[Matis]

Tja, dat blijft telkens terugkomen.

Als je je gebruikersnaam ook voorziet van hoofd- en kleine letters, is het net zo veilig

[Alex)]

Ik vind 'm wel mooi anders, dat verwacht je niet

Overigens, wat is nog erger dan ongedocumenteerde code? Code die karig is gedocumenteerd en waarvan de documentatie niet eens overeenkomt met de werkelijkheid. In een soort-van God-class van 772 regels code...

[ Voor 10% gewijzigd door Alex) op 18-08-2011 16:55 ]

[Avalaxy]

Alex) schreef op donderdag 18 augustus 2011 @ 16:54:

Overigens, wat is nog erger dan ongedocumenteerde code? Code die karig is gedocumenteerd en waarvan de documentatie niet eens overeenkomt met de werkelijkheid. In een soort-van God-class van 772 regels code...

Classes van 772 regels code? Ik ben methods van 772 regels tegengekomen (ok, niet precies, maar die orde van grootte), en dan een stuk of 5 van dat soort gedrochten in 1 class. Geen enkele vorm van documentatie en ook nog heerlijk 9x diep geneste if/else, for/foreach en switch constructies

[kenneth]

Een klasse van 772SLOC is toch niet heel extreem? Zoja, dan ben ik de slechtste developer ter wereld.

[Alex)]

Het is niet heel erg extreem, neen. Maar ik kom wel iets te vaak steeds dezelfde dingen tegen.

23 methods waarvan 13 public. Mijn gevoel zegt me echt dat het met minder kan. Maar ik ga het niet zodanig refactoren, want ik ben functioneel niet tot in detail op de hoogte van wat het allemaal wel en niet hoort te doen.

[ Voor 54% gewijzigd door Alex) op 18-08-2011 17:07 ]

[Webgnome]

Alex) schreef op donderdag 18 augustus 2011 @ 16:54:
Ik vind 'm wel mooi anders, dat verwacht je niet

Overigens, wat is nog erger dan ongedocumenteerde code? Code die karig is gedocumenteerd en waarvan de documentatie niet eens overeenkomt met de werkelijkheid. In een soort-van God-class van 772 regels code...

Een class van 722 regels code is nou niet bepaald 'bad code'. Als deze class 722 regels bevat maar de content bestaat gewoon uit goed gestructureerde methodes en dergelijke is er niks mis. Als het één class met één methode is dan is het weer een heel ander verhaal natuurlijk.

[.oisyn]

* .oisyn kijkt naar zijn class
few, 713 regels, zit ik net safe

[Alex)]

Webgnome schreef op donderdag 18 augustus 2011 @ 17:10:
Een class van 722 regels code is nou niet bepaald 'bad code'.

Eens.

Als deze class 722 regels bevat maar de content bestaat gewoon uit goed gestructureerde methodes en dergelijke is er niks mis. Als het één class met één methode is dan is het weer een heel ander verhaal natuurlijk.

Het zijn wel verschillende methods. Maar ze hebben allemaal generieke namen die niet geheel matchen met de werkelijkheid (GetAllProducts terwijl je wel filters mee kunt geven), de documentatie van die methods is er niet, de namen van variabelen zijn overdadig verbose, veel is volledig in lowercase ipv camelCase, enz.

Dus ik gooi er nu een kleine refactorronde overheen.

[CodeCaster]

Refactoren kan prima, zolang de unit tests maar blijven werken. Oh, wacht.

[Alex)]

CodeCaster schreef op donderdag 18 augustus 2011 @ 17:17:
Refactoren kan prima, zolang de unit tests maar blijven werken. Oh, wacht.

Welke?

[MBV]

Avalaxy schreef op donderdag 18 augustus 2011 @ 17:02:
[...]


Classes van 772 regels code? Ik ben methods van 772 regels tegengekomen (ok, niet precies, maar die orde van grootte), en dan een stuk of 5 van dat soort gedrochten in 1 class. Geen enkele vorm van documentatie en ook nog heerlijk 9x diep geneste if/else, for/foreach en switch constructies

Als de 3 grootste bestanden ongeveer 15000 regels lang zijn, zijn we misschien collega's Oh wacht, je zegt een stuk of 5 gedrochten, na 10 ben ik gestopt te tellen...

[Ram0n]

Styxxy schreef op donderdag 18 augustus 2011 @ 16:51:
[...]

Waarschijnlijk iemand de twee omgedraaid .

Ik kan wel begrijpen dat de username case insensitive is (dat heeft ook mijn voorkeur), maar het paswoord zou wel case sensitive moeten zijn.

Niet alleen verhoogt case insensitiveness het aantal combinaties dat goed is, het geeft ook nog eens aan dat er geen hashing algo wordt gebruikt dat case sensitive is (en verreweg de meeste zijn dat wel)... Maar goed, dat is hier al vaker besproken inderdaad

[bindsa]

Ram0n schreef op donderdag 18 augustus 2011 @ 20:51:
[...]

Niet alleen verhoogt case insensitiveness het aantal combinaties dat goed is, het geeft ook nog eens aan dat er geen hashing algo wordt gebruikt dat case sensitive is (en verreweg de meeste zijn dat wel)... Maar goed, dat is hier al vaker besproken inderdaad

Niet per se toch? Het kan toch ook zijn dat ze voordat er gehashed wordt de string lowercase maken?

[HeSitated]

kenneth schreef op donderdag 18 augustus 2011 @ 17:03:
Een klasse van 772SLOC is toch niet heel extreem? Zoja, dan ben ik de slechtste developer ter wereld.

Vandaag hoorde ik iemand vlak naast me zeggen dat "Step 17 van een SQL-job was gefaild"...

Nog even volhouden....

[Ram0n]

T.H. Lassche schreef op donderdag 18 augustus 2011 @ 20:58:
[...]


Niet per se toch? Het kan toch ook zijn dat ze voordat er gehashed wordt de string lowercase maken?

True, je zou theoretisch gezien eerst een stringtolower o.i.d. kunnen toepassen voordat je gaat hashen, maar als je dat implementeert is het helemaal erg met je gesteld. Ik vrees niet dat dat hier aan de hand is...

[MBV]

Ik verwacht het wel: vroeger werd een veel te simpele hashing gebruikt voor het password. Daarna is de zoekterm 'backwards-compatible'.

[Full_hyperion]

Alex) schreef op donderdag 18 augustus 2011 @ 17:19:
[...]

Welke?

Alle unit tests natuurlijk.

Gelukkig is een voor-alle quantificatie over een leeg domein altijd true, dus er kan je niks gebeuren. Gewoon refactoren die hap

[BarôZZa]

Paradox schreef op donderdag 18 augustus 2011 @ 16:17:
geen voorbeeld.. wel te testen in de praktijk...

Inloggen bij mijn.ing.nl ... Username is username.. en je wachtwoord CASE INSENSITIVE!

dus gebruik elke willekeurige hoofdletter tijdens je inlog DaTMaaKtNietuit!

Ik kan me dat goed voorstellen.

Als je dat niet doet, dan wordt je helpdesk bestookt met mensen die hun capslock aan hebben staan.

Na 3x wordt je account toch geblokkeerd, al kan je daarmee weer de accounts van willekeurige mensen blokkeren.

[YopY]

Ik moet toch mijn collega even de gek aansteken, .

Wat doet onderstaand: In het object zit een array van string booleans (1 voor elke dag). De functie moet de afkorting van elke 'true' dag in een string pleuren, met een komma als het niet de laatste dag is.

C:

// noot: code is objective-c, maar GoT kan dat niet parsen of ik ken de code daarvoor niet.

typedef enum {
    DAYOFWEEK_MONDAY,
    DAYOFWEEK_TUESDAY,
    DAYOFWEEK_WEDNESDAY,
    DAYOFWEEK_THURSDAY,
    DAYOFWEEK_FRIDAY,
    DAYOFWEEK_SATURDAY,
    DAYOFWEEK_SUNDAY
} DayOfWeek;

-(BOOL)day:(DayOfWeek)dayOfWeek {
    return ([@"YES" isEqualToString:[repeatedDaysOfWeek objectAtIndex:dayOfWeek]]);
}

-(NSString *)dayOfWeekAsString {
    NSMutableString *toReturn = [NSMutableString stringWithString:@""];
    BOOL appendCommaSpace = NO;
    for (int i = 0; i < 7; i++) {
        switch (i) {
            case DAYOFWEEK_MONDAY:
                if ([self day:DAYOFWEEK_MONDAY]) {
                    [self addDayOfWeekToString:(NSMutableString *)toReturn appendCommaSpace:appendCommaSpace dayOfWeek:DAYOFWEEK_MONDAY];
                    appendCommaSpace = YES;
                }
                break;
            case DAYOFWEEK_TUESDAY:
                if ([self day:DAYOFWEEK_TUESDAY]) {
                    [self addDayOfWeekToString:(NSMutableString *)toReturn appendCommaSpace:appendCommaSpace dayOfWeek:DAYOFWEEK_TUESDAY];
                    appendCommaSpace = YES;
                }
                break;
            case DAYOFWEEK_WEDNESDAY:
                if ([self day:DAYOFWEEK_WEDNESDAY]) {
                    [self addDayOfWeekToString:(NSMutableString *)toReturn appendCommaSpace:appendCommaSpace dayOfWeek:DAYOFWEEK_WEDNESDAY];
                    appendCommaSpace = YES;
                }
                break;
            case DAYOFWEEK_THURSDAY:
                if ([self day:DAYOFWEEK_THURSDAY]) {
                    [self addDayOfWeekToString:(NSMutableString *)toReturn appendCommaSpace:appendCommaSpace dayOfWeek:DAYOFWEEK_THURSDAY];
                    appendCommaSpace = YES;
                }
                break;
            case DAYOFWEEK_FRIDAY:
                if ([self day:DAYOFWEEK_FRIDAY]) {
                    [self addDayOfWeekToString:(NSMutableString *)toReturn appendCommaSpace:appendCommaSpace dayOfWeek:DAYOFWEEK_FRIDAY];
                    appendCommaSpace = YES;
                }
                break;
            case DAYOFWEEK_SATURDAY:
                if ([self day:DAYOFWEEK_SATURDAY]) {
                    [self addDayOfWeekToString:(NSMutableString *)toReturn appendCommaSpace:appendCommaSpace dayOfWeek:DAYOFWEEK_SATURDAY];
                    appendCommaSpace = YES;
                }
                break;
            case DAYOFWEEK_SUNDAY:
                if ([self day:DAYOFWEEK_SUNDAY]) {
                    [self addDayOfWeekToString:(NSMutableString *)toReturn appendCommaSpace:appendCommaSpace dayOfWeek:DAYOFWEEK_SUNDAY];
                }
                break;
            default:
                break;
    }
    return toReturn;
}

-(void)addDayOfWeekToString:(NSMutableString *)string appendCommaSpace:(BOOL)appendCommaSpace dayOfWeek:(DayOfWeek) dayOfWeek {
    if (appendCommaSpace) [string appendFormat:@"%@", @", "];
    [string appendFormat:@"%@", [Date shortWeekdayForDate:[StoredTrip dateForWeekday:dayOfWeek]]];
}

Heb het maar even vervangen met iets korters. Mogelijk kan het nog beterder.

C:

-(NSString *)selectedDaysAsAbbreviatedCsvString {
    NSMutableString *result = [NSMutableString stringWithString:@""];
    for (NSInteger weekDay = 0; weekDay < [repeatedDaysOfWeek count]; weekDay++) {
        if (![self day:weekDay]) continue;
        if ([result length] > 0) {
            [result appendString:@", "];
        }
        [result appendString:[Date shortWeekdayForDate:[StoredTrip dateForWeekday:weekDay]]];
    }
    
    return result;
}

[Verwijderd]

Dit vond ik jaren geleden in de code van A2-racer IV: De politie slaat terug. Deze waarden gaan over de posities van de wielen van de auto's, die dus ook stabieler gemaakt konden worden door de wielen wat wijder uit elkaar te plaatsen. Strikt genomen heeft het niet zoveel met programmeren te maken, het is zelfs niet perse slechte code (ik heb daar geen verstand van) maar misschien toch grappig vanwege het informele gechat tussen de programmeurs dat uiteindelijk blijkbaar in de definitieve versie terecht is gekomen:

; ===================================
; === Car configuration info ========
; ===================================
; front (x,y,z) rear (x,y,z)

[wheel_positions]
; Checker Cab
0 = 8.64,0.0,17.11,8.64,0.0,-16.05
; Hotrod wheels
1 = 7.82,0.0,18.35,8.72,0.0,-15.54
; Humvee wheels
2 = 11.56,5.27,25.03,11.56,5.27,-9.89
; Mercedes SLK
3 = 7.708,0.0,14.197,7.949,0.0,-14.033
; Buggy
4 = 6.59,0.0,11.76,7.76,0.0,-9.73
; Countach
5 = 8.39,0.0,12.36,8.91,0.0,-13.23
; politie/polizei
6 = 6.55,0.0,12.919,-6.19,0.0,-13.073
7 = 6.55,0.0,12.919,-6.19,0.0,-13.073
8 = 7.54,0.0,17.14,7.11,0.0,-11.47
9 = 7.5,0.0,13.13,7.5,0.0,-15.82
10 = 7.5,0.0,13.13,7.5,0.0,-15.82
11 = 7.5,0.0,13.13,7.5,0.0,-15.82
12 = 7.5,0.0,13.13,7.5,0.0,-15.82
13 = 7.5,0.0,13.13,7.5,0.0,-15.82
14 = 7.5,0.0,13.13,7.5,0.0,-15.82
15 = 7.5,0.0,13.13,7.5,0.0,-15.82
; BMW Z3... dus, dan weet je dat
16 = 8.68,0.0,14.08,8.68,0.0,-13.75
; Aston Martin db7, geen commentaar
17 = 8.47,0.0,15.08,8.53,0.0,-13.87
; TVR, het lijkt mij op dit moment onverstandig om mij hierover uit te laten
18 = 7.50,0.0,15.76,8.21,0.0,-15.52
; Rolls Royce, deze auto's worden dus niet echt gebruikt in A2 IV.. waar ze vandaan komen, Joost mag 't weten
19 = 6.98,0.0,12.38,6.98,0.0,-10.58
; Lamborghini Diablo, maar ik ga ze niet verwijderen want wie weet wat er dan allemaal mis gaat
20 = 7.11,0.0,13.9,70.93,0.0,-14.93
; Jetski, vandaar dat ik gewoon voor de light positions allemaal nieuwe entries heb gemaakt
21 = 6.81,0.0,-0.55,6.81,0.0,-0.55
; Crappy Wohnwagen, zoals je ziet
22 = 7.99,0.0,0.0,7.99,0.0,0.0
; Hippie Wohnwagen, nou veel plezier ermee hoor
23 = 7.99,0.0,0.0,7.99,0.0,0.0
; Supercop (with HUMVEE_ANIM)
24 = 11.56,5.27,25.03,11.56,5.27,-9.89

[mcDavid]

.oisyn schreef op donderdag 18 augustus 2011 @ 16:27:
En het erge is, je username is wél case sensitive

Je username is tegenwoordig ook belangrijker dan je password voor de identificatie. Ieder malloot die je telefoon jat kan namelijk je wachtwoord via SMS opvragen. Je username niet.

[Verwijderd]

function doFoo()
{
while ( true) doFoo();
}

doFoo();

[ThaNOD]

Alex) schreef op donderdag 18 augustus 2011 @ 16:54:
Ik vind 'm wel mooi anders, dat verwacht je niet

Overigens, wat is nog erger dan ongedocumenteerde code? Code die karig is gedocumenteerd en waarvan de documentatie niet eens overeenkomt met de werkelijkheid. In een soort-van God-class van 772 regels code...

Je mag je zelf een mazzelaar noemen als dat de ergste code is die je moet onderhouden. Ik zit met een applicatie waar ik 1 enkele pl/sql routine van uitgeprint 10 pagina's a4 , en een ander project in vb6 waar 1 enkel timer1_timer event 73! Pagina's is. Die zichzelf aan het begin uitzet en nog niet bij elk exit path zich zelf weer aanzet.

Zullen we ruilen? (Het aanbod geld trouwens niet als jou case in php is ) )

[sfranken]

PHP:

<?php
for($i = 0; $i <= 0; $i++)
{
 // MySQL afhandeling
}
?>

In mijn laatste samenwerkingsverband. Kerel snapte niet wat er nou niet werkte. Moet zeggen dat ik ooit ook zo begonnen ben

[Alex)]

ThaNOD schreef op vrijdag 19 augustus 2011 @ 21:03:
[...]


Je mag je zelf een mazzelaar noemen als dat de ergste code is die je moet onderhouden. Ik zit met een applicatie waar ik 1 enkele pl/sql routine van uitgeprint 10 pagina's a4 , en een ander project in vb6 waar 1 enkel timer1_timer event 73! Pagina's is. Die zichzelf aan het begin uitzet en nog niet bij elk exit path zich zelf weer aanzet.

Yuck, yuck en nog meer yuck.

Zullen we ruilen? (Het aanbod geld trouwens niet als jou case in php is ) )

Het is C#

[Jegorex]

sfranken schreef op vrijdag 19 augustus 2011 @ 21:12:

PHP:

<?php
for($i = 0; $i <= 0; $i++)
{
 // MySQL afhandeling
}
?>

In mijn laatste samenwerkingsverband. Kerel snapte niet wat er nou niet werkte. Moet zeggen dat ik ooit ook zo begonnen ben

Als de MySQL afhandeling maar 1x hoeft te worden uitgevoerd dan werkt het toch gewoon?

[sfranken]

Jegorex schreef op vrijdag 19 augustus 2011 @ 21:19:
[...]

Als de MySQL afhandeling maar 1x hoeft te worden uitgevoerd dan werkt het toch gewoon?

haha ja inderdaad, maar waarom dan in een for loop? En deze code moest x keren uitgevoerd worden (x is afhankelijk van het aantal leden die actief wat gepost hebben op de FP van het project).

[Reptile209]

Jegorex schreef op vrijdag 19 augustus 2011 @ 21:19:
[...]

Als de MySQL afhandeling maar 1x hoeft te worden uitgevoerd dan werkt het toch gewoon?

En je kunt toch binnen de lus $i op -1 zetten voor een rondje van de zaak? Of trapt PHP daar niet in?

[sfranken]

I op -1 lijd (geloof ik) tot een oneindige loop

[Aloys]

Verwijderd schreef op vrijdag 19 augustus 2011 @ 20:38:
function doFoo()
{
while ( true) doFoo();
}

doFoo();

Dat duurt niet zo lang hoor, je krijgt toch vrij vlot een StackOverflowException

[sfranken]

Dat is ook weer zo. Nu ik toch aan het kijken was.. mijn manier van "debuggen" om te kijken wanneer een mail aan zou komen met PHP:

PHP:

<?php
while(true)
{
    mail("[e-mail]", "TEST", "Dit is een test", "From: sfranken");
}
?>

[Aloys]

En toen heb je in Gmail maar even een smart-filter gemaakt om alles tegelijk te kunnen verwijderen? Of staat je server nu op de blacklist?

[Verwijderd]

Of beide

[Aloys]

Misschien had ie die while(true) wel gedaan omdat er nooit wat aan kwam door een verkeerd mailadres. Zal wel iemand heel pissig zijn over z'n mailbom .

[jip_86]

In Lion kan je de magic mouse gestures voor pagina terug wel iets van drie opties instellen. Een daarvan is de standaard ook de gesture voor switchen tussen full screen aps. Als je die kiest word die bij de andere optie weggehaald, wat logisch is. Maar waarom hebben ze bij die optie maar een mogelijkheid gezet

[Aloys]

Ach wat nostalgisch, 5 jaar geleden was ik ook heerlijk aan het commenten in de code:

PHP:

            //Check of de image in de lengte of breedte moet worden geresized
            if($_ImgSize[0] >= $_ImgSize[1]) {
            
                // geef de breedte de maximale waarde
                $_ThumbNewX = $this->Photo_ThumbSize;
                
                // kijk wat voorn deelverhouding genomen moet worden
                $_verhouding = $_ImgSize[0] / $this->Photo_ThumbSize;
                
                // verkrijg de waarde van Y
                $_ThumbNewY = $_ImgSize[1] / $_verhouding;
                
            }
            else {
            
                // geef de wijdte de maximale waarde
                $_ThumbNewY = $this->Photo_ThumbSize;
                
                // kijk wat voorn deelverhouding meot worden genomen
                $_verhouding = $_ImgSize[1] / $this->Photo_ThumbSize;
                
                // verkrijg de waarde van X
                $_ThumbNewX = $_ImgSize[0] / $_verhouding;
                
            }

Zo gaat het dus een complete CMS door (gelukkig al wel OO). Het leuke is dat het spul opzicht wel prima te onderhouden is en te begrijpen, en mijn Jip-en-Janneke redeneringen staan vaak prachtig in de comments .

Overigens zal het wel enorm schelen om alle commentaar weg te gooien, passen de functies weer eens op het scherm, maar das toch zonde?!

[WernerL]

Ik ben nu bezig met een webshop. HTML code schrijven en wat PHP dingen aanpassen.
Maar mijn god zeg... wat een troep is dit.

Echt alle slechte programmeervoorbeelden die je je maar kunt verzinnen zitten er in.
index.php is bijna 1000 regels lang met een berg PHP en HTML code kris kras door elkaar. Vervolgens is er een file class.php waarin echt ALLE classes staan gedefinieerd. Is dus een file geworden van een 1000e regels lang

En nette duidelijke code maken zat er voor deze meneer blijkbaar ook niet in.
Veel van dit soort dingen:

PHP:

$query = sprintf('SELECT
                                *
                             FROM
                                cms
                             WHERE
                                %s = "%s"
                                ' . ($exclude_standby ? ' AND standby = 0 ' : ''), ($url_text ? '`url-text`' : 'titel'), mysql_real_escape_string($naam));

Noteer dit dan even deftig en netjes ofzo.

Ik doe nooit meer aanpassingen aan bestaande PHP systemen...

[ZpAz]

Ik doe nooit meer aanpassingen aan bestaande PHP systemen...

Hier ook, bij elke klant die ik krijg waar er al een 'eigen systeem is' (wat niet gebaseerd is op Wordpress of Magento ofzo) zeg ik. Nee, daar begin ik niet meer aan.

Ik houd er niet zo van om in ranzige code rond te zitten struinen.

[Bee.nl]

Aloys schreef op zaterdag 20 augustus 2011 @ 01:56:
Ach wat nostalgisch, 5 jaar geleden was ik ook heerlijk aan het commenten in de code:

PHP:

// snip

Zo gaat het dus een complete CMS door (gelukkig al wel OO). Het leuke is dat het spul opzicht wel prima te onderhouden is en te begrijpen, en mijn Jip-en-Janneke redeneringen staan vaak prachtig in de comments .

Overigens zal het wel enorm schelen om alle commentaar weg te gooien, passen de functies weer eens op het scherm, maar das toch zonde?!

Dat zijn wel erg obvious comments ja, maar beter te veel dan te weinig. In principe probeer ik de code zoveel mogelijk voor zich te laten spreken. Te veel comments betekent vaak (maar niet altijd) dat je code niet goed geschreven is.

Btw, je hebt eigenlijk wel dubbele code he Je draait alleen de indices om en past zo de x- of de y-dimensie aan. Omdat ik zin had om het te proberen heb ik hier een kortere versie

PHP:

$dim = $this->getResizedImage($_ImgSize)

function getResizedImage($_ImgSize) {

   $dim = array();
   $dim[0] = $this->Photo_ThumbSize; // max dimensie
   $dim[1] = min($_ImgSize) / max($_ImgSize) * $this->Photo_ThumbSize; // geschaalde dimensie

   return ($_ImgSize[0] > $_ImgSize[1]) ? $dim : array_reverse($dim); // draai om indien portrait formaat
}

[MBV]

maak 2 variabelen: $longSide en $shortSide, en return array($longSide, $shortSide) of anders array($shortSide, $longSide). Maakt het 10x beter leesbaar, en dan kan je de comments ook weggooien

[Bee.nl]

MBV schreef op zaterdag 20 augustus 2011 @ 21:55:
maak 2 variabelen: $longSide en $shortSide, en return array($longSide, $shortSide) of anders array($shortSide, $longSide). Maakt het 10x beter leesbaar, en dan kan je de comments ook weggooien

Te verwachten natuurlijk, heb ik zelf (expres natuurlijk) overbodige comments geplaatst

Het ging me om het idee dat het wel in een functie te proppen is, waarbij je het algoritme maar 1x definieert. Als ik iets wel hinderlijk vind, is het wel dat hetzelfde algoritme op verschillende plaatsen staat. Happy debugging wanneer er een wijziging is

_{maar je hebt wel gelijk}

[Aloys]

Ik post het ook meer als lachertje van, hé kijk eens hoe goed ik vroeger nadacht over wat ik deed

[MBV]

Dat snap ik, Aloys. @Bee: 2x is nog wel te doen, zeker als het nog in de buurt van elkaar staat. Pas bij 3x gaan bij mij alarmbellen af. Maar soms moet je om 3x copy/paste weg te halen zoveel moeite doen, dat het eigenlijk de moeite niet waard is. Ik zit bijvoorbeeld met zoiets:

C++:

struct incomingMessages {
  std::queue<std::string> queue;
  boost::mutex queueMutex;
  boost::condition_variable condition;
  boost::mutex  conditionMutex;
};

Daar hoort code bij om een nieuw bericht aan te maken(lock verkrijgen, item toevoegen aan queue, lock op de condition, notify op de condition), en code voor blocking-wait tot er een item in de queue zit.
Dat was voor 1 ding geschreven, is min-of-meer gecopy/paste naar een andere klasse die het net anders doet, en heb ik vorige week letterlijk gecopy/paste. Dat wil ik dus in een ThreadSafeQueue gooien, enig probleem: ik heb eigenlijk maar half een idee hoe het werkt, en ik ben eergisteren erachter gekomen dat ik geen idee heb hoe je zo'n ding netjes moet deleten Da's altijd mooi: fix de bug dat geheugen wordt gealloceerd, maar niet wordt vrijgegeven, krijg je er een keiharde crash voor terug
_{lijkt verdacht veel op dit. Als iets een mutex vasthoudt terwijl je de struct delete krijg je een terechte assert in boost. En aangezien het consequent gebeurt, denk ik dat datgene wat de queue moet deleten wordt aangeroepen als reactie op een event uit die queue...}

[Bee.nl]

Aloys schreef op zaterdag 20 augustus 2011 @ 23:01:
Ik post het ook meer als lachertje van, hé kijk eens hoe goed ik vroeger nadacht over wat ik deed

Het was ook niet vervelend bedoeld hoor. Het ging over onnodige comments en toen dacht ik van hey dat past toch ook wel in één functie? En toen nam ik de 'uitdaging' met mezelf aan

MBV schreef op zaterdag 20 augustus 2011 @ 23:28:
@Bee: 2x is nog wel te doen, zeker als het nog in de buurt van elkaar staat. Pas bij 3x gaan bij mij alarmbellen af. Maar soms moet je om 3x copy/paste weg te halen zoveel moeite doen, dat het eigenlijk de moeite niet waard is.

Ja het hangt natuurlijk ook wel van de context af. Als het veel tijd (en dus geld) kost om een universele (helper)functie te bouwen, is het soms goedkoper om de boel te copy-pasten. Maar als de tijd er is dan vind ik het altijd leuk om de code zo schoon mogelijk te houden.

MBV schreef op zaterdag 20 augustus 2011 @ 23:28:
ik heb eigenlijk maar half een idee hoe het werkt, en ik ben eergisteren erachter gekomen dat ik geen idee heb hoe je zo'n ding netjes moet deleten

Troost je, ik heb helemaal geen idee hoe het werkt

[ Voor 0% gewijzigd door Bee.nl op 21-08-2011 00:01 . Reden: woordje vergeten ]

[MBV]

Als je de code 2 weken lang tegenkomt vallen er af en toe puzzelstukjes op hun plaats Maar code die ik niet 100% snap ga ik niet refactoren, zeker niet als het met multi-threading te maken heeft. Dus staat de code om een nieuw berichtje in de queue te krijgen er nu vrolijk 3x, tot ik wat beters verzin

[bobo1on1]

WernerL schreef op zaterdag 20 augustus 2011 @ 20:57:
En nette duidelijke code maken zat er voor deze meneer blijkbaar ook niet in.
Veel van dit soort dingen:

PHP:

$query = sprintf('SELECT
                                *
                             FROM
                                cms
                             WHERE
                                %s = "%s"
                                ' . ($exclude_standby ? ' AND standby = 0 ' : ''), ($url_text ? '`url-text`' : 'titel'), mysql_real_escape_string($naam));

Noteer dit dan even deftig en netjes ofzo.

Volgens mij moet jij je editor instellen op 2 spaces per tab ipv 4 of 8, dan ziet het er stukken netter uit

[WernerL]

bobo1on1 schreef op zondag 21 augustus 2011 @ 03:07:
[...]

Volgens mij moet jij je editor instellen op 2 spaces per tab ipv 4 of 8, dan ziet het er stukken netter uit

Dat is een optie.. Maar als alle parameters van een functie zoveel tekens in beslag nemen vind ik het persoonlijk netter om de parameters in aparte variabelen te zetten:

PHP:

$bla = "iets";
$iets = "bla";
$str = "SELECT * FROM table WHERE %s = \"%d\"";
$query = sprintf($str, $bla, $iets);

Is toch stukken beter leesbaar?

[YopY]

Ja, maar nog steeds fout . Prepared statements > elke vorm van string concatenation, mysql_real_escape, frameworks, escape-functies, en noem zo maar op. Ik begrijp eerlijk gezegd niet waarom mensen nog steeds concats en escape-functies gebruiken om hun queries op te bouwen... zijn prepared statements echt zo obscuur of apart of zijn alle tutorials op het internets nog gewoon slecht?

[Dipsausje]

Prepared statements, ik had er nog nooit van gehoord maar ziet er handig uit. Volgens mij is het probleem met veel tutorials dat Google je al gauw dingen uit 2001 ed voorschotelt als je iets zoekt, vaak hopeloos achterhaalt. Zelf zoek ik altijd op z'n minst naar dingen uit 2010-2011 maar ik kan me voorstellen dat veel mensen graag de eerste oplossing pakken.

[Avalaxy]

Daarom kun je beter gewoon een goed (up-to-date) boek lezen ipv halfbakken tutorials op internet die bomvol staan met fouten, gedateerde code en weet ik het wat.

Kijk ook gelijk eens naar ORM, voor PHP heb je bijvoorbeeld Doctrine of RedBean. Maakt achter de schermen doorgaans ook gebruik van prepared statements en maakt het leven nóg makkelijker (zeker als je MVC gebruikt kun je vaak heel gemakkelijk models genereren en dergelijken).

[ Voor 46% gewijzigd door Avalaxy op 21-08-2011 14:30 ]

[BarôZZa]

Lekker boeiend hoe je een query opbouwt. Als je geen veilige query met concats kan bouwen, dan is dat een groter probleem. Voor de rest scheelt het typwerk. Prepared statements zijn prima, daar niet van, maar als queries goed opgebouwd zijn met concats is je winst 0.0 als je het om gaat gooien en kost het alleen maar tijd.
Kan me daar niet echt druk om maken. Er valt in de meeste gevallen meer winst te behalen door databases/queries te optimaliseren, de queries zo snel mogelijk achter elkaar uit te voeren (ik zie nog wel eens sql-verbindingen die continu open blijven staan) en caching.

[Infinitive]

BarôZZa schreef op zondag 21 augustus 2011 @ 14:33:
Lekker boeiend hoe je een query opbouwt.

Dat doet het wel! Wanneer je argumenten handmatig aan een query vastplakt is de kans groot dat je een keer vergeet de juiste encoding vergeet - met potentieel vervelende gevolgen. Wanneer je gebruik maakt van een library die dit voor je doet kun je eenvoudig aantonen dat er geen sql exploits in de code aanwezig zijn. Je hoeft dan alleen maar te kijken of je toch niet stiekem user-input in je query embed - wat voor de meeste queries eenvoudig te controleren is. In sommige programmeertalen kan zoiets dynamisch (e.g. taint-checking in Perl) of statisch (e.g. flow analyses) afgedwongen worden.

Dit staat los van het gebruiken van prepared statements. Als je op een dergelijke manier je queries opbouwt dan is je query als prepared statement uit te voeren met bijkomende performancevoordelen (query hoeft niet geparsed te worden, executieplannen kunnen gedeeltelijk hergebruikt worden, etc.). Echter, dat is een bonus en niet de hoofdmotivatie.

Uit luiheid bouw ik in simple php-files ook de queries zelf met string-concatenation en dat is gewoon erg fout en dom om te doen. Daarvoor zou je eigenlijk door de programmeertaal op je flikker moeten krijgen. Als er nu een sql exploit mogelijk is met mijn code dan kan ik niet zoals iedereen mijn schouders ophalen en zeggen dat dit niet te voorkomen is - dat is het dus wel...

[ Voor 25% gewijzigd door Infinitive op 21-08-2011 15:06 ]

[BarôZZa]

Luiheid? Ik noem het snelheid

Ik weet wat de risico's zijn als je het verkeerd doet. Mijn punt is dat als mensen het goed doen, dat het geen nut heeft om te switchen of het als heilige graal te zien. Alle userinput wordt hier standaard gecontroleerd in PHP. $_P=array_walk($_POST,'mooie_veilige_functie');

Waarna altijd $_P gebruikt wordt, tenzij je in de originele var wil hebben, maar dan ben je daar bewust mee bezig. Scheelt ook weer een berg typwerk en werkt als een tiet. Kan het mooier? Ongetwijfeld. Zorgt het ervoor dat ik sneller werk of m'n apps veiliger worden? Neuh.

[Nactive]

Indien je een bepaalde query 2 x gebruikt zal die ook iets sneller zijn met prepared statements omdat de query maar 1 x moet geoptimaliseerd worden.

[Avalaxy]

Volgens mij is het sowieso sneller omdat de query gewoon al ingeladen staat.

[BarôZZa]

Ik zou niet weten waarom een prepared statement sneller zou zijn wanneer een query twee keer gebruikt wordt. Naast het feit dat je volgens mij zelden twee keer dezelfde query wil uitvoeren. Dat is juist iets wat ik deed wanneer ik een beetje lui was (select -> update -> select).

[DEiE]

BarôZZa schreef op zondag 21 augustus 2011 @ 16:02:
Naast het feit dat je volgens mij zelden twee keer dezelfde query wil uitvoeren.

Queries meerdere keren uitvoeren is juist iets wat heel vaak gebeurd:

SQL:

SELECT * FROM Cars;

/* for each car */
SELECT * FROM Wheel WHERE CarId = ?

Dit staat overigens bekend als het N+1-probleem

[ Voor 41% gewijzigd door DEiE op 21-08-2011 16:05 ]

[Matis]

DEiE schreef op zondag 21 augustus 2011 @ 16:04:
Queries meerdere keren uitvoeren is juist iets wat heel vaak gebeurd:

SQL:

SELECT * FROM Cars;

/* for each car */
SELECT * FROM Wheel WHERE CarId = ?

Kun je dan niet beter:

SQL:

SELECT CarId FROM Cars;

Doen? Of is het juist een slecht programmeervoorbeeld?

[DEiE]

Dit voorbeeld stond in een van de eerste hits bij googlen naar N+1 query, het was om het probleem aan te tonen, niet om daadwerkelijk als goeie query gebruikt te worden. In de praktijk gebruik je natuurlijk enkel de velden die je nodig hebt .

[Nactive]

BarôZZa schreef op zondag 21 augustus 2011 @ 16:02:
Ik zou niet weten waarom een prepared statement sneller zou zijn wanneer een query twee keer gebruikt wordt.

Omdat ze de eerste keer worden gecompileerd en vervolgens altijd de compilatie kan worden gebruikt.

Dit verschil is natuurlijk niet zeer groot maar op een groot aantal query's kan dit wel tellen.

[BarôZZa]

Ik dacht dat hij bedoelde dezelfde query met dezelfde parameters (dus twee identieke queries). Maar je kan dus meerdere keren de parameter veranderen zonder dat de databaseserver belast wordt. Dat is uiteraard handig in sommige gevallen.

[mcDavid]

BarôZZa schreef op zondag 21 augustus 2011 @ 15:33:
Luiheid? Ik noem het snelheid

Ik weet wat de risico's zijn als je het verkeerd doet. Mijn punt is dat als mensen het goed doen, dat het geen nut heeft om te switchen of het als heilige graal te zien.

Grote denkfout: Er vanuit gaan dat iemand/jijzelf het altijd goed doet.

Fouten worden altijd gemaakt. Als er manieren zijn om de kans op fouten te verkleinen is dat gewoon rechtstreekse profit.

[BarôZZa]

Zoals ik al zei valideer ik alle userinput al lang en breed voordat het ook maar in de buurt van de query komt. Daarnaast zitten er logischerwijs ook nog checks zodat je bijvoorbeeld geen string in een integer-veld gaat proberen te proppen. De concat pas het allerlaatste eindstation.

Alles wordt bovendien getest voordat het online gaat en veiligheid is juist iets waar ik me al vanaf het begin der tijden mee bezig hou. Ik ben er 100% zeker van dat mijn apps niet gevoelig zijn voor SQL injections en dat is simpelweg noodzaak met het aantal gebruikers dat ik heb. Het is nog eerder zo dat ik een aantal grote sites(denk aan de dertig grootste sites in Nederland) erop heb geattendeerd dat de veiligheid niet in orde was.

De denkfout is eerder dat je er gelijk vanuit ga dat ik de veiligheid niet op een ander punt gereld heb.

[Nactive]

Het idee is normaal dat indien je externe libarys gebruikt of in dit geval een prepared statement, dat die al veelvuldig gebruikt en getest zijn, en dat daar dus normaal gezien weinig of geen fouten in zitten.

Indien je uw eigen methode hiervoor gaat ontwikkelen moet je het testen zelf doen, ook vereist dit meer kennis van de persoon zelf, misschien kent die persoon überhaupt niet wat een sql injectie is.

Daarom wordt (zo heb ik het toch geleerd op het school) als goede programmeer gewoonte genomen om zoveel mogelijk reeds gebruikte / geteste code te gebruiken.

In dit geval dus prepared statements.

Dit neemt natuurlijk niet weg dat uw code niet perfect veilig is. Maar voor Jan met de pet is een prepared statement eenvoudiger en veiliger.

[BarôZZa]

Als ik iets heb geleerd op de universiteit, dan was het wel dat ik vooral niet blindelings moest geloven wat zei me vertelden. Want die lui hadden dus zelf blijkbaar niet gehoord van SQL-injections. 'MD5-encryptie'(ja encryptie) op de wachtwoorden (zonder salt) zou het wonderbaarlijk allemaal veilig maken.

Veelgebruikte libraries/software hebben hun voordelen en nadelen. Vooral veelgebruikte PHP-software, zoals Wordpress, Joomla, PHPBB etc. Het probleem is niet zozeer dat ze méér lekken hebben dan zelf ontwikkelde software, maar dat ze door hun populariteit juist een enorm gewild doelwit zijn. Komt er dan eens een lek om de hoek kijken, dan zou het niet de eerste keer zijn dat er in één klap duizenden sites gedefaced(of erger) worden.

[Verwijderd]

Een van de oplossingen kan zijn om te verbergen dat je Joomla gebruikt door bijvoorbeeld de /administrator te hernoemen naar iets anders, een .htaccess wachtwoord op het /administrator gedeelte te zetten, en/of de meta-generator tag weg te halen.

[Ventieldopje]

Voor kleine projectjes met kleine database gebruik ik gewoon lekker prepared statements maar voor grotere projecten gebruik ik toch echt liever Doctrine zodat je alleen de mappings maar hoeft te schrijven en de entities en database kan laten genereren aan de hand van die mappings

[mcDavid]

BarôZZa schreef op zondag 21 augustus 2011 @ 23:12:
Als ik iets heb geleerd op de universiteit, dan was het wel dat ik vooral niet blindelings moest geloven wat zei me vertelden. Want die lui hadden dus zelf blijkbaar niet gehoord van SQL-injections. 'MD5-encryptie'(ja encryptie) op de wachtwoorden (zonder salt) zou het wonderbaarlijk allemaal veilig maken.

Veelgebruikte libraries/software hebben hun voordelen en nadelen. Vooral veelgebruikte PHP-software, zoals Wordpress, Joomla, PHPBB etc. Het probleem is niet zozeer dat ze méér lekken hebben dan zelf ontwikkelde software, maar dat ze door hun populariteit juist een enorm gewild doelwit zijn. Komt er dan eens een lek om de hoek kijken, dan zou het niet de eerste keer zijn dat er in één klap duizenden sites gedefaced(of erger) worden.

Wel grappig dat je software die door duizenden zo niet miljoenen mensen dagelijks gecontroleerd wordt, niet vertrouwt, maar zelfgemaakte software die je alleen zelf controleert, wel 100% vertrouwt.

Niets ten nadele van jou hoor, ik geloof best dat je de veiligheid goed op orde hebt, maar het blinde vertrouwen vind ik misplaatst.

[C0rnelis]

Ik heb bijvoorbeeld een class DatabaseRecord met o.a. de functies getWhereClause(), getDeleteSQL() en getInsertOrUpdateSQL(). Elk entiteit in dit systeem extends deze class voor de database functies en is/wordt uiteraard uitgebreid met entiteit-specifieke functies. De genoemde functies zijn zodanig afhankelijk van de waarden dat ik nog niet heb kunnen uitdenken hoe ik prepared statements kan toepassen (misschien zegt dat meer iets over mij.. )..

Je kan voor een DatabaseRecord primary keys en/of identifiers instellen. In een voorbeeld van de WordPress-tabel 'usermeta' tabel gebruik ik de kolom 'umeta_id' als primary key en de kolommen 'user_id' + 'meta_key' als identifier.

Voorbeeld van mijn getWhereClause()

PHP:

    /**
     * Construeer de WHERE CLAUSE op basis van de primary keys of identifiers.
     */
    private function getWhereClause() {
        $where_clause = null;
        $use_pk = false;
        $identifiers = array();
        
        // controleer of de primary keys zijn ingesteld en deze gebruikt kunnen
        // worden als identifier 
        if(isset($this->primary_key)) {
            foreach($this->primary_key as $primary_key) {
                if(isset($this->values[$primary_key])) {
                    $use_pk = true;
                } else {
                    $use_pk = false;
                }
                
                // als er een primary key ontbreekt in een multi-primary key tabel, dan
                // kan er niet geselecteerd worden op basis van de primary keys
                if($use_pk === false) {
                    break;
                }
            }
        }
        
        if($use_pk) {
            // gebruik de primary keys als identifier
            foreach($this->primary_key as $primary_key) {
                $identifiers[$primary_key] = $this->values[$primary_key];
            }
        } else if(!$use_pk && isset($this->identifiers)) {
            // bij het ontbreken van primary_key gebruik de opgegeven identifiers
            $identifiers = $this->identifiers;
        }
        
        // bouw de where clause
        $count = 0;
        foreach($identifiers as $field => $value) {
            if($count < count($identifiers) && $count > 0) {
                $where_clause .= " AND ";
            }
            
            $where_clause .= $field . " = " . $this->db->escape($value);
            
            $count++;
        }
        
        // voeg enkel WHERE toe als de clause niet leeg is
        if(isset($where_clause)) {
            $where_clause = " WHERE " . $where_clause;
        }
        
        return $where_clause;
    }

values kunnen niet zomaar in $this->values gekwakt uiteraard, maar via een setValueForField methode die (op het moment) nog niets afvangt. Values worden ge-escaped bij het genereren van de sql. De overvloed aan in-line commentaar (wat ik eigenlijk sowieso bijna automatisch doe, maar dit is een gevalletje extra) komt omdat ik nu als stagiaire bezig ben bij een erg klein bedrijf (< 5 vaste medewerkers), waarvan eigenlijk niemand kaas gegeten heeft van PHP.

Ik was op zich best tevreden met deze code, maar wordt dit nu allemaal (in zekere mate) voor je gedaan door een orm zoals doctrine? , fyi: ik ben geen professioneel php-developer, maar slechts een student (gezien het woord stagiaire, mocht dat helpen )

[BarôZZa]

mcDavid schreef op zondag 21 augustus 2011 @ 23:50:
[...]


Wel grappig dat je software die door duizenden zo niet miljoenen mensen dagelijks gecontroleerd wordt, niet vertrouwt, maar zelfgemaakte software die je alleen zelf controleert, wel 100% vertrouwt.

Niets ten nadele van jou hoor, ik geloof best dat je de veiligheid goed op orde hebt, maar het blinde vertrouwen vind ik misplaatst.

Dan moet je goed lezen. Ik had het over dat ik er 100% zeker van ben dat het bestand is tegen SQL-injections. Dat is iets wat je gewoon kan testen en waar iedereen met een basiscursus PHP(nooit gevolgd overigens) toch wel tegen bestand moet zijn. Of je nu prepared statements gebruikt of niet.

Ik ben me er prima van bewust waar de zwakkere plekken zitten, maar dat zijn overwegingen die je zelf maakt.

[Patriot]

BarôZZa schreef op zondag 21 augustus 2011 @ 22:44:
Zoals ik al zei valideer ik alle userinput al lang en breed voordat het ook maar in de buurt van de query komt. Daarnaast zitten er logischerwijs ook nog checks zodat je bijvoorbeeld geen string in een integer-veld gaat proberen te proppen. De concat pas het allerlaatste eindstation.

Dat is in feite al 'fout'. Je moet gegevens niet blindelings om gaan zetten/veranderen voordat dat echt noodzakelijk is. Als je bijvoorbeeld gegevens hebt die van HTML gestript moeten worden, dan doe je dat niet al voordat je het in de database stopt: Je doet dat pas als je de gegevens in een HTML-context moet laten zien, waar dat dan dus problemen op kan leveren.

Alles wordt bovendien getest voordat het online gaat en veiligheid is juist iets waar ik me al vanaf het begin der tijden mee bezig hou. Ik ben er 100% zeker van dat mijn apps niet gevoelig zijn voor SQL injections en dat is simpelweg noodzaak met het aantal gebruikers dat ik heb. Het is nog eerder zo dat ik een aantal grote sites(denk aan de dertig grootste sites in Nederland) erop heb geattendeerd dat de veiligheid niet in orde was.

De denkfout is eerder dat je er gelijk vanuit ga dat ik de veiligheid niet op een ander punt gereld heb.

Vat dit niet op als persoonlijke aanval, maar je komt nogal arrogant over. Die arrogantie kan je parten gaan spelen als je daardoor dingen mist omdat je zo prat gaat op de veiligheid van jouw applicaties. De veronderstelde onmogelijkheid om fouten te maken is imo geen reden om dan maar een methode te gebruiken waarvan duidelijk is dat het potentieel veel gevaarlijker is..

[BarôZZa]

Wel grappig dat ik arrogant word genoemd, aangezien ik dus nergens beweer dat iemand anders iets verkeerd doet. Mijn punt is dat het het gebruik van bepaalde functies niet fout is, maar het gaat om hoe die functies gebruikt worden. Dat je bij een bepaalde functie mogelijk minder fouten kan maken betekent nog niet dat het gebruik van een andere functie per definitie fout is. Ik reken code af op of het aantoonbaar gevaarlijk is, niet omdat een gebruikte methode potentieel gevaarlijk is wanneer het verkeerd wordt gebruikt. Ik vind de 'deze manier is het best en alle andere manieren zijn gemaakt door prutsers'-houding meestal wat arroganter.
In mijn optiek leiden meerdere wegen naar Rome en als jij liever een prepared statement gebruikt van tig regels code, omdat je dan zeker geen fouten maakt, dan moet je dat vooral doen. Ik los het liever op met een kortere manier en als er een fout in zit dan mag iedereen me daarop afrekenen, al heb ik vooral mezelf ermee.

Voor de rest heb ik inderdaad vertrouwen in de dingen die ik maak. Dat maakt me verder niet minder kritisch, al richt ik me meer op de zaken die in mijn ogen belangrijker zijn, zoals snelheid (zowel qua ontwikkeling als uitvoer) en gebruiksvriendelijkheid, dan of iets mogelijk mooier of netter gecode had kunnen worden terwijl het prima en veilig draait. Wat zelfvertrouwen (of arrogantie in de ogen van sommige anderen) is trouwens wel iets wat ik miste bij veel informatica-studenten (Matis, ik heb het niet over jou ). Zonde, want dat is iets wat veel IT-kopstukken juist wel hebben. Vaar eens lekker tegen de stroming in, zoek je eigen oplossingen en probeer zelf te innoveren. Als je een fout maakt, dan ga je op je bek en leer je ervan. Alles beter dan de grijze meute codekloppers. Sommige lui zijn zo gefocust op nette code dat ze soms vergeten waar het om draait: mooie applicaties maken waar veel mensen met plezier gebruik van maken.

HTML-code vis ik er trouwens nog niet uit voordat ik het in de database plemp, maak je niet druk

[Avalaxy]

Als je je op performance zou richten zou je niet kiezen voor de oplossing die je nu gebruikt.

Verder snap ik geen drol van je punt dat je kennelijk een beter programmeur bent als je zelf het wiel opnieuw uitvindt.

[BarôZZa]

Een prepared statement zou dus alleen merkbaar sneller draaien wanneer er meerdere keren dezelfde query moet worden uitgevoerd. In ander gevallen maakt het dus geen drol uit en kan je je pijlen beter op andere zaken richten. Tenzij je denkt dat je de meeste apps een flinke boost geeft door de concat-queries te vervangen door prepared statements.

Over het wiel opnieuw uitvinden. Tsja, je kan gewoon een wiel gaan bouwen of honderd boeken kan lezen over hoe je een ronde vorm kan maken dat dienst kan doen als wiel. Mijn punt is meer: is de beste programmeur diegene die de beste apps bouwt of diegene die de mooiste code fabriceert?

[alwinuzz]

Nouja een kant-en-klare fietsband is leuk, maar een zelf in elkaar geknutselde band is natuurlijk veel beter!

Totdat achteraf blijkt dat de zelfgemaakte band nogal vaak lek gaat, een stuk vaker dan de prefab band.

[BarôZZa]

Breek me de bek niet open over prefab fietsbanden

Maar excuses voor de offtopic discussie. Ik hoop dat er weer echte mooie WTF's geplaatst worden. Concat queries vind ik eigenlijk minder interessant. De leukste zijn gewoon de mooie denkfouten of enorm omslachtige zaken.

Edit: ik bekijk nu pas de lap code van C0nelis en het roept alleen een berg vragen bij me op. Meerdere primary keys bij een record? Wat doet het in hemelsnaam en waarom? Je haalt een record op en kan vervolgens de WHERE-clause achterhalen waarmee je dat record weer krijgt? En je hebt getDeleteSQL? Waarom niet gewoon DatabaseRecord->Delete()? En een getInsertOrUpdateSQL() bij een record? Ik heb een paar biertjes op en het is laat, dus het kan aan mij liggen. Of het is geniaal of het is een enorme wtf. Wie helpt me uit de brand?

[ Voor 49% gewijzigd door BarôZZa op 22-08-2011 04:06 ]

[Twazerty]

Enkele jaren geleden zat ik nog maar in het eerste jaar van mijn opleiding. Toen ben ik gestart met mijn videoconverter. Ik had een arraylist met elementen die allemaal uitgevoerd moeten worden, maar tijdens dit uitvoeren kan de inhoud van de lijst veranderen van volgorde en aantal. Items mogen niet dubbel uitgevoerd worden en als een element voor in de lijst wordt ingevoegd dan moet deze ook uitgevoerd worden. De volgorde van de lijst bepaald in welke volgorde de elementen uitgevoerd moeten worden. Rond die tijd heb ik dit geproduceerd:

Java:

    private ArrayList<DiscModel> discs;
    private boolean shutDown = false;
    private boolean exitAVCHDCoder = false;
    private Queue queueView;
    private Status status = Status.STOPPED;

    public void run(){
        try{
            //Oneindig blijven loopen
            while(true){
                if(getStatus() == Status.RUNNING){
                    if(!Globals.ELAPSEDTIME.isRunning()){
                        Globals.MULTITHREADING.execute(Globals.ELAPSEDTIME);
                    }else{
                        Globals.ELAPSEDTIME.resetStartTime();
                    }

                    int waargebleven = 0;
                    int aantaljobs = discs.size();
                    
                    while(getStatus() == Status.RUNNING){
                        //Job uitgevoerd: else
                        //Als die nog niet done is: uit gaan voeren.
                        if(discs.get(waargebleven) != null && discs.get(waargebleven).getStatus() == Status.STOPPED){
                            queueView.setCurrentConverting(discs.get(waargebleven));
                            try{
                                DiscExecuter de = new DiscExecuter(discs.get(waargebleven));
                                de.executeItems();
                            }catch(ConvertException e){
                                if(getStatus() != Status.STOPPED){
                                    setStatus(Status.FAILED);
                                    discs.get(waargebleven).setStatus(Status.FAILED);
                                    queueView.errorOccured(e);
                                }

                            }catch(Exception e){
                                e.printStackTrace();
                            }
                            //omdat het aantal discs in de queue kan wijzigen word
                            //waargebleven op 0 gezet en het aantaljobs word opnieuw opgehaald.
                            waargebleven = 0;
                            aantaljobs = discs.size();
                        }else{
                            //loop erdoorheen om te kijken of alle jobs gedaan zijn.
                            aantaljobs = discs.size();
                            for(int index = 0; index < aantaljobs; index++){
                                //kijk of hij done is.
                                if(discs.get(index).getStatus() == Status.SUCCESS){
                                    //als het het laatste element is finished op true zetten.
                                    //else waargebleven verhogen.
                                    if(index == aantaljobs-1){
                                        setStatus(Status.SUCCESS);
                                        break;
                                    }else{
                                        waargebleven++;
                                    }
                                }else{
                                    break;
                                }
                            }
                        }
                    }

                    if(getStatus() == Status.SUCCESS){
                        queueView.queueExecuted(shutDown, exitAVCHDCoder);
                    }
                }
                Thread.sleep(500);
            }
        }catch(Exception e){
            e.printStackTrace();  
        }
    }

Tijdje ervoor maakte ik niet eens gebruik van Enums. Toen was het nog een stuk onleesbaarder met allerlei vage combinaties van checks om te bepalen welke actie uitgevoerd moet worden. Vandaag de dag zou ik bovenstaande op zijn minst in meerdere functies zetten. De hoeveelheid keer dat ingesprongen wordt is gewoon om misselijk van te worden

Dit is tevens een van de allerlei belangrijkste stukken code uit mijn applicatie. Ik ga het ook niet aanpassen voordat ik nog wat sloop

[Patriot]

BarôZZa schreef op maandag 22 augustus 2011 @ 03:02:
Wel grappig dat ik arrogant word genoemd, aangezien ik dus nergens beweer dat iemand anders iets verkeerd doet. Mijn punt is dat het het gebruik van bepaalde functies niet fout is, maar het gaat om hoe die functies gebruikt worden. Dat je bij een bepaalde functie mogelijk minder fouten kan maken betekent nog niet dat het gebruik van een andere functie per definitie fout is.

Nouja, het op 'jouw manier' (het concatten van strings, ik noem het maar even zo voor de duidelijkheid) doen is natuurlijk ook niet fout. Dat is ook niet echt wat ik wil zeggen. Het is alleen nodeloos minder effectief dan het gebruiken van prepared statements. Het scheelt geen bergen, maar waarom zou je het niet gebruiken? Die regels extra code waar je het over hebt vallen over het algemeen ook wel mee. Sterker nog, als je zelf een functie maakt die bepaalde input saniteert durf ik te wedden dat je effectief meer code extra hebt dan wanneer je prepared statements zou gebruiken.

Ik reken code af op of het aantoonbaar gevaarlijk is, niet omdat een gebruikte methode potentieel gevaarlijk is wanneer het verkeerd wordt gebruikt.

Dat is enigszins logisch, maar een aantoonbaar gevaarlijke mogelijkheid gebruik je sowieso niet. Waarom zou je dan niet kiezen voor de optie met het minste potentie voor gevaarlijke situaties?

Ik vind de 'deze manier is het best en alle andere manieren zijn gemaakt door prutsers'-houding meestal wat arroganter.

Dat is ook wel een beetje overdreven Het is ook niet dat we onbeargumenteerd jouw methode aan het afvallen zijn. Waarom we het een betere manier vinden is duidelijk. Het is ook niet zoeer dat jij een prutsmethode hanteert, ik (en ik denk dat ik voor meerdere mensen spreek) kan me gewoon niet zo goed verplaatsen in het bewust kiezen van een optie die bepaalde voordelen mist. Wat is volgens jou eigenlijk het voordeel van het zelf saniteren van user input, zelf de query bouwen en zonder parameterized queries en (sortof) transactions te werken?

In mijn optiek leiden meerdere wegen naar Rome en als jij liever een prepared statement gebruikt van tig regels code, omdat je dan zeker geen fouten maakt, dan moet je dat vooral doen. Ik los het liever op met een kortere manier en als er een fout in zit dan mag iedereen me daarop afrekenen, al heb ik vooral mezelf ermee.

Je hebt het hier over een verondersteld voordeel van jouw manier, namelijk dat het korter is dan prepared statements met hun 'tig regels code'. Dan vraag ik me af welke prepared statements jij gezien hebt. Als je bijvoorbeeld PDO gebruikt, dan is dit wat je nodig hebt om een query uit te voeren:

PHP:

$sth = $dbh->prepare('SELECT name, colour, calories FROM fruit WHERE calories < :calories AND colour = :colour');
$sth->execute(array(':calories' => 150, ':colour' => 'red'));

Dat komt effectief neer op dit:

PHP:

$sth = mysql_query(sprintf("SELECT name, colour, calories FROM fruit WHERE calories < %d AND colour = '%s'", 150, 'red'));

Dat is dus maar 1 regeltje extra, met als voordeel dat je een snelheidsverhoging hebt als je deze query meerdere keren wilt uitvoeren. Toegegeven, dat doe je zeker niet bij iedere query, maar je gaat me ook niet vertellen dat het nooit voorkomt.

Daarnaast heb je het voordeel dat je geen escape functies langs hoeft te zien komen (is in dit voorbeeld niet het geval omdat er geen user input gebruikt wordt), waardoor je code overzichtelijker en

Voor de rest heb ik inderdaad vertrouwen in de dingen die ik maak. Dat maakt me verder niet minder kritisch, al richt ik me meer op de zaken die in mijn ogen belangrijker zijn, zoals snelheid (zowel qua ontwikkeling als uitvoer) en gebruiksvriendelijkheid, dan of iets mogelijk mooier of netter gecode had kunnen worden terwijl het prima en veilig draait.

Je mag wel vertrouwen hebben in wat je doet, maar een opmerking als 'bij mij zitten er geen fouten in de applicaties die ik maak, op gebied X' is wel even wat anders. Dat klinkt heel anders dan wanneer je bijvoorbeeld zou zeggen: 'Ik heb vertrouwen in mijn applicatie, ik let goed op de beveiliging en weet praktisch zeker dat er geen SQL injection mogelijk is!'. Je sluit compleet uit dat het mogelijk is dat je ergens een foutje gemaakt kan hebben. Dat is toch niet reëel?

Wat zelfvertrouwen (of arrogantie in de ogen van sommige anderen) is trouwens wel iets wat ik miste bij veel informatica-studenten (Matis, ik heb het niet over jou ). Zonde, want dat is iets wat veel IT-kopstukken juist wel hebben. Vaar eens lekker tegen de stroming in, zoek je eigen oplossingen en probeer zelf te innoveren. Als je een fout maakt, dan ga je op je bek en leer je ervan. Alles beter dan de grijze meute codekloppers.

Ghehe, ik denk niet dat een opdrachtgever er blij van wordt als hij een belangrijke order misloopt omdat een bedrijfskritische applicatie crashte/een fout maakte omdat je je eigen oplossing hebt gezocht en daarbij een foutje hebt gemaakt.

Sowieso vraag ik me af wat je bedoelt met de grijze meute codekloppers. Zoals ik programmeren ervaar is het altijd in essentie een relatief creatieve bezigheid. Dat je bepaalde richtlijnen hanteert heeft daar weinig mee te maken.

Sommige lui zijn zo gefocust op nette code dat ze soms vergeten waar het om draait: mooie applicaties maken waar veel mensen met plezier gebruik van maken.

Ik denk dat dat wederom vooral gevoelsmatig is van jouw kant. Iemand die zich bezig houdt met hoe zijn code er uitziet is daarom niet bezig met de applicatie?

HTML-code vis ik er trouwens nog niet uit voordat ik het in de database plemp, maak je niet druk

Het was een voorbeeld, ging me er meer om dat je een bewerking doet op die gegevens (je saniteert ze voor gebruik in een query) voordat dat nodig is. Voor jouw situatie maakt dat echter niet zoveel uit, je bewaart de originele gegevens namelijk nog wel. Ik zou het nog steeds niet zo doen, maar dat is meer een kwestie van voorkeur.

EDIT:
Eigenlijk had ik moeten reageren op deze reactie, want die vat mooi samen wat ik bedoel:

BarôZZa schreef op maandag 22 augustus 2011 @ 03:18:
Een prepared statement zou dus alleen merkbaar sneller draaien wanneer er meerdere keren dezelfde query moet worden uitgevoerd. In ander gevallen maakt het dus geen drol uit en kan je je pijlen beter op andere zaken richten. Tenzij je denkt dat je de meeste apps een flinke boost geeft door de concat-queries te vervangen door prepared statements.

Als het niet uitmaakt, dan leer je jezelf toch gebruik te maken van het gereedschap wat in de meeste situaties effectief is?

Over het wiel opnieuw uitvinden. Tsja, je kan gewoon een wiel gaan bouwen of honderd boeken kan lezen over hoe je een ronde vorm kan maken dat dienst kan doen als wiel. Mijn punt is meer: is de beste programmeur diegene die de beste apps bouwt of diegene die de mooiste code fabriceert?

Die twee hebben niets met elkaar te maken. Een programmeur kan een goede applicatie bouwen met slechte code, en een ander kan een slechte applicatie afleveren met mooie code. Maar je streeft toch naar perfectie, je wilt toch een goede applicatie met mooie code? Of niet?

[ Voor 9% gewijzigd door Patriot op 22-08-2011 04:57 ]

[BarôZZa]

Heel lang verhaal, maar je laatste zinnen vatten het mooi samen. Ik ben totaal niet op zoek naar perfectie, maar naar rendement. Ik probeer mijn energie zo goed mogelijk te verdelen tussen kwaliteit van de code, research, kwaliteit van de applicatie, gebruiksvriendelijkheid en veiligheid. Perfectioneren is zelden nodig en kost emorm veel tijd. Vaak is het ook een keuze tussen leren hoe je dingen die je al kan anders kan doen of gewoon iets nieuws leren. De een krijgt jeuk van concat-queries, de ander gaat huilen bij het gebruik van GD om een plaatje te resizen en weer een ander bibbert wanneer je een html/xml bestand inlaadt als tekst en er een paar string/regex functies op loslaat. Valt allemaal wat voor te zeggen, maar in veel gevallen is het ook sneller om bestaande kennis toe te passen dan research te moeten plegen. En als het dan ook nog eens gewoon prima blijkt te werken, zonder merkbare(iets anders dan meetbare) performance issues... tsja.

Bij bepaalde bedrijfskritische processen is dat natuurlijk een ander verhaal is, maar ik heb het over veel algemene zaken. Hyves is aan elkaar gehackt. Facebook is een bende. Zelfs bij Tweakers.net is het bekend dat bepaalde onderdelen wat minder robuust in elkaar steken. Kritische onderdelen moeten goed in elkaar steken, maar bij veel andere zaken is de foutmarge veel groter en hangt succes eigenlijk maar weinig af van hoe goed het op technisch vlak in elkaar steekt.

En ja, ik ben me ervan bewust dat de echte perfectionistische programmeurs walgen van mijn verhaal en het de grootste onzin van de wereld vinden .

Moet zeggen dat ik het soms ook heerlijk vind om een zo'n gelikt en efficiënt mogelijk stukje code te schrijven, maar meestal weet ik stiekem wel dat ik mijn tijd beter had kunnen besteden aan iets nieuws oid.

[RayNbow]

Patriot schreef op maandag 22 augustus 2011 @ 04:48:
[...]


Nouja, het op 'jouw manier' (het concatten van strings, ik noem het maar even zo voor de duidelijkheid) doen is natuurlijk ook niet fout.

Het concatten van strings is m.i. een fout van de database API. Die zou zo'n interface in de eerste plaats niet moeten blootstellen. Het is eigenlijk van de zotte dat de programmeur in de applicatie de query eerst moet plat slaan naar een ongestructureerd zooitje van characters, vervolgens de boel over de heg gooit naar het databasesysteem, die uiteindelijk het ongestructureerde zooitje weer moet parsen naar een gestructureerde query.

[C0rnelis]

BarôZZa schreef op maandag 22 augustus 2011 @ 03:30:
[..]
Edit: ik bekijk nu pas de lap code van C0nelis en het roept alleen een berg vragen bij me op. Meerdere primary keys bij een record? Wat doet het in hemelsnaam en waarom? Je haalt een record op en kan vervolgens de WHERE-clause achterhalen waarmee je dat record weer krijgt? En je hebt getDeleteSQL? Waarom niet gewoon DatabaseRecord->Delete()? En een getInsertOrUpdateSQL() bij een record? Ik heb een paar biertjes op en het is laat, dus het kan aan mij liggen. Of het is geniaal of het is een enorme wtf. Wie helpt me uit de brand?

In een koppeltabel heb je meerdere kolommen die ingesteld kunnen zijn als gezamenlijke primary key. Elke waarde in de array primary_keys komt overeen met 1 zo'n kolom.

getWhereClause() wordt o.a. gebruikt door getDeleteSQL() en bij het ophalen van alle andere velden. Simpelste voorbeeld:

PHP:

// User extends DatabaseRecord
$user = new User(10);

De constructor van User stuurt het id en de primary key kolom door naar DatabaseRecord die overduidelijk de onderstaande query moet uitvoeren. In de constructor van DatabaseRecord wordt de methode getValues aangeroepen als er een identifier is doorgegeven.

SQL:

SELECT * FROM wp_user WHERE ID = '10';

Ik heb een delete() functie die getDeleteSQL() aanroept en execute . De getInsertOrUpdateSQL() gebruik ik bijvoorbeeld op de volgende manier:

Als ik een gebruiker heb met ID = 10 (kolom 'user_id' in de tabel 'wp_usermeta') en ik voeg een meta_key toe aan deze gebruiker dan wordt het id meegegeven aan dit nieuwe object + de waarde ingesteld voor de velden 'meta_key' en 'meta_value'. De getInsertOrUpdateSQL() genereert dan bijvoorbeeld onderstaande code

SQL:

INSERT INTO wp_usermeta (`user_id`, `meta_value`, `meta_key`) VALUES ('10', 'C0rnelis', 'nickname') ON DUPLICATE KEY UPDATE user_id = VALUES(user_id), meta_value = VALUES(meta_value), meta_key = VALUES(meta_key);

Zo hoef ik geen aparte query te draaien om te kijken of de combinatie van 'user_id' + 'meta_key' al bestaat.

't Enige is dat hij niet controleert welke kolommen echt van waarde zijn veranderd, maar of dat de performance verbeterd vraag ik me af.

[YopY]

Een class die zijn eigen data uit de DB ophaalt is vanuit OO-puristen-perspectief natuurlijk 'not done', aangeizen je het meer dan 1 verantwoordelijkheid geeft - User data opslaan (en waarschijnlijk ook transformeren enzo), maar ook SQL queries opbouwen. Deze twee kun je eenvoudig scheiden dmv het DAO-pattern.

PHP:

$user = $userDao->findById(1337);
$userDao->delete($user);

Een functie 'getWhereClause' bindt ook gelijk je datamodel aan een specifieke implementatie van data-opslag, dwz SQL. Als je er een cachinglaag tussen wilt stoppen (zoals Memcache) ben je de sjaak.

Ook het initialiseren van een User object door een ID naar de constructor te sturen is niet helemaal logisch - geef in zo'n geval de voorkeur aan een Factory Method met een begrijpelijke naam. Men kan uit de regel 'new User(10)' nl niet opmaken dat er verbinding met een database gemaakt wordt etc.

PHP:

$user = User::fetchById(10);

is bijvoorbeeld al duidelijker.

[Keiichi]

Bij ons is laatst wat software geinstalleerd, die wel heel vaag in elkaar zit.

Op elke PC waarbij het gebruikt moet worden moet op een vaste locatie op de C: schijf wat bat scripts staan. Die bat scripts zorgen ervoor dat een PDF bestand geopend word (niets meer en niets minder). Die bat script worden gelanceerd door een daemon proces op de PC. Hier zit verder geen enkele authenticatie of verificatie op (Ik kan bij wijze van spreke ook gewoon 'format c:' naar een PC toesturen). Deze daemon word aangeroepen van een server die doorgeeft welk PDF bestand geopend moet worden op een share.

Misschien niet zo zeer een stukje slechte programmeercode, maar heel het idee is omslachtig, onveilig en eigenlijk ook onstabiel (Die daemon proces werkt maar in 50% van de gevallen)

[phex]

Mwah, ik zou wel ff naar de techsupport bellen over de backdoor die op elke workstation staat Format c zou waarschijnlijk niet werken als de gebruikersrechten niet goedstaan, maar je kan er genoeg andere ongein mee uithalen.

[lupus9537]

Een tijdje terug heeft een Pools bedrijf voor ons een Outlook plugin ontwikkeld die via een web service planning synchroniseert met een webbased planning tool.

De plugin en webservice werden ontwikkeld en opgeleverd. Ik lachtte mij een breuk toen ik de code zag:
- De Outlook plugin maakt contact met de web service (toen nog ASMX). Deze bevat één method die niets anders doet dan de SQL connection string doorgeven.
- Vervolgens tracht de plugin rechtstreeks verbinding te maken met de SQL server (over het internet) om zo rechtstreeks de synchronisatie uit te voeren.

Dan maar beter opnieuw beginnen en zelf doen ?

[Keiichi]

phex schreef op maandag 22 augustus 2011 @ 14:42:
Mwah, ik zou wel ff naar de techsupport bellen over de backdoor die op elke workstation staat Format c zou waarschijnlijk niet werken als de gebruikersrechten niet goedstaan, maar je kan er genoeg andere ongein mee uithalen.

Het is van een nieuw ingekocht pakket (buiten mij om, omdat ik veel andere dingen te doen heb), maar ik ga eens kijken tot hoe ver ik er mee gaan f*cken. Alle systeem draaien gebruikers met Administrator rechten (Dat is voor een ander topic )