[Alg] Slechtste programmeervoorbeelden deel 3

[Mawlana]

Ik heb laatst een quick&dirty-applicatie gemaakt om dagelijks wat bestanden te downloaden. Indien het downloaden om wat voor een reden dan ook niet is gelukt, moet het bestand een minuut later alsnog getracht gedownload te worden. Althans, dat was de bedoeling.

Voor het opnieuw proberen te downloaden maakte ik gebruik van een Timer. Blijkbaar was ik vergeten erbij te zetten dat deze timer moest stoppen wanneer het bestand bij de volgende poging goed was gedownload. Resultaat (na een dag): 78GB aan dubbele bestanden.

Ik heb die applicatie maar volledig herschreven opdat zoiets niet meer kan voorkomen...

[vorlox]

Tjonge jonge me eigen blind zitten staren waarom onderstaand niet werkte wanneer path NULL was .

PHP:

/* OUD */
function getPackageFile($file,$path=NULL)
{
    //Main query
    $query = 'SELECT * FROM s_fil WHERE file = :file AND path = :path';
    //Bind query values
    $query = bindQueryValues($query,array('file'=>$file,'path'=>$path));
    //Exec
    return execQuery($query);
}

/* NIEUW */

function getPackageFile($file,$path=NULL)
{
    //Main query
    $query = 'SELECT * FROM s_fil WHERE file = :file';
    //Test null for path
    if(is_null($path))
        $query .= ' AND path IS NULL';
    else
        $query .= ' AND path = :path';
    //Bind query values
    $query = bindQueryValues($query,array('file'=>$file,'path'=>$path));
    //Exec
    return execQuery($query);
}

zucht

[ Voor 41% gewijzigd door vorlox op 12-02-2008 23:24 . Reden: Ok, code aamgepast anders staat het zo rommelig, is wel ff samengestelde code.. geen zin om alles te posten, echter zou mijn fout duidelijk moeten maken ]

[Verwijderd]

vorlox schreef op dinsdag 12 februari 2008 @ 20:37:
Tjonge jonge me eigen blind zitten staren waarom onderstaand niet werkte wanneer path NULL was .

code:

function getPackageFile($file,$path=NULL)
{
    $q = 'SELECT * FROM s_fil WHERE file = :file AND path = :path';
    $q = bindQueryValues(array('file'=>$file,'path'=>$path))
   return execQuery($q);
}

zucht maar ff veranderd naar

code:

function getPackageFile($file,$path=NULL)
{
    $q = 'SELECT * FROM s_fil WHERE file = :file';

    if(is_null($path)
        $q .= ' AND path IS NULL';
    else
        $q .= ' AND path = :path ';
    $q = bindQueryValues(array('file'=>$file,'path'=>$path))
   return execQuery($q);
}

zucht

Weet je zeker dat deze code werkt.. ik zie nm nog een foutje!

[Herko_ter_Horst]

riezebosch schreef op dinsdag 12 februari 2008 @ 14:53:
[...]

Ok, geschreven in c#, but you get the idea
[...]

En wat wil je hier nou mee zeggen? Dat je niet begrepen hebt waar het over gaat? Om nog maar te zwijgen van het feit dat je een custom class gebruikt i.p.v. Object (of hoe de top-level class in C# ook moge heten).

Of is dit jouw manier om uit te leggen waarom mensen denken dat er call-by-reference plaatsvindt terwijl dat niet zo is?

Nog even voor de zekerheid: dat je het object waar een reference naar wijst kunt modificeren wil nog niet zeggen dat je call-by-reference semantiek hebt aangetoond, verre van. De vraag is of je de reference zelf kunt modificeren, zodanig dat die modificatie ook in de aanroepende scope zichtbaar is. Dat is iets heel anders dan het object waar de reference naar wijst modificeren.

[.oisyn]

Verwijderd schreef op dinsdag 12 februari 2008 @ 20:45:
[...]

Weet je zeker dat deze code werkt.. ik zie nm nog een foutje!

Ik zie er wel meerdere, ik gok dat het geen letterlijke copy/paste is

Herko_ter_Horst schreef op dinsdag 12 februari 2008 @ 21:30:

En wat wil je hier nou mee zeggen? Dat je niet begrepen hebt waar het over gaat?

Volgens mij begrijp jij de code niet, want hij doet precies dat - pass by reference
Sorry, ik keek verkeerd

[ Voor 40% gewijzigd door .oisyn op 13-02-2008 11:00 ]

[flowerp]

.oisyn schreef op dinsdag 12 februari 2008 @ 22:44:
Volgens mij begrijp jij de code niet, want hij doet precies dat - pass by reference

Uhm, ik ken de syntax van C# niet exact, maar zoals marcj ook al opmerkt is dit geen voorbeeld van pass by reference:

C#:

static void Swap(ByRef a, ByRef b)
    {
        string t = a.value;
        a.value = b.value;
        b.value = t;
    } 

Ook al zouden a en b by-reference worden doorgegeven (wat blijkbaar niet zo is, gegeven het ref keyword wat gebruikt wordt in TeeDee in "[Alg] Slechtste programmeervoorbeelden d...") dan nog is het een extreem slecht voorbeeld.

Dit is namelijk juist het klassieke tegen voorbeeld wat mensen die het net niet helemaal snappen gebruiken om zogenaamd te bewijzen dat iets wat eigenlijk call-by-value is, volgens hen toch call-by-reference is. Ze hebben dan namelijk simpelweg geleerd dat je met call-by-value een kopie mee krijgt en het origineel dus niet kan veranderen en bij call-by-reference het origineel wel kan veranderen. Vervolgens maken ze een verandering aan het object in de functie, zien dat het buiten de functie ook is veranderd, en dus is het volgens hen meteen call-by-reference.

De hele redenering loop natuurlijk fout wanneer het 'origineel' een name is voor een pointer en niet direct een name is voor het object.

Zoals al eerder opgemerkt: met call-by-value kun je het object zelf waar een pointer heen wijst wel wijzigen, maar je kunt de pointer niet naar een ander object laten wijzen.

Voor hele hardnekkige gevallen gebruik ik zelf ook wel eens de analogie met een index in een globale array die je doorgeeft aan een functie (via call-by-value). Via deze index kun je een array element bereiken en DIE kun je veranderen. De index is gewoon een int, en alleen het toevallige feit dat deze int wordt gebruikt om een object in een array te bereiken, maakt het niet opeens op magische wijze dat er call-by-reference wordt gebruikt. Deze analogie vind je ook in 1 van de links die ik eerder opgaf.

[kenneth]

Is het niet inmiddels tijd voor Het grote call-by-value-topic deel 1?

[riezebosch]

flowerp schreef op woensdag 13 februari 2008 @ 00:01:
[...]


Uhm, ik ken de syntax van C# niet exact, maar zoals marcj ook al opmerkt is dit geen voorbeeld van pass by reference:

C#:

static void Swap(ByRef a, ByRef b)
    {
        string t = a.value;
        a.value = b.value;
        b.value = t;
    } 

Ook al zouden a en b by-reference worden doorgegeven (wat blijkbaar niet zo is, gegeven het ref keyword wat gebruikt wordt in TeeDee in "[Alg] Slechtste programmeervoorbeelden d...") dan nog is het een extreem slecht voorbeeld.

Dit is namelijk juist het klassieke tegen voorbeeld wat mensen die het net niet helemaal snappen gebruiken om zogenaamd te bewijzen dat iets wat eigenlijk call-by-value is, volgens hen toch call-by-reference is. Ze hebben dan namelijk simpelweg geleerd dat je met call-by-value een kopie mee krijgt en het origineel dus niet kan veranderen en bij call-by-reference het origineel wel kan veranderen. Vervolgens maken ze een verandering aan het object in de functie, zien dat het buiten de functie ook is veranderd, en dus is het volgens hen meteen call-by-reference.

De hele redenering loop natuurlijk fout wanneer het 'origineel' een name is voor een pointer en niet direct een name is voor het object.

Zoals al eerder opgemerkt: met call-by-value kun je het object zelf waar een pointer heen wijst wel wijzigen, maar je kunt de pointer niet naar een ander object laten wijzen.

Voor hele hardnekkige gevallen gebruik ik zelf ook wel eens de analogie met een index in een globale array die je doorgeeft aan een functie (via call-by-value). Via deze index kun je een array element bereiken en DIE kun je veranderen. De index is gewoon een int, en alleen het toevallige feit dat deze int wordt gebruikt om een object in een array te bereiken, maakt het niet opeens op magische wijze dat er call-by-reference wordt gebruikt. Deze analogie vind je ook in 1 van de links die ik eerder opgaf.

De grap van het voorbeeldje wat ik gaf was dat ik zelf het object wrap in een reference en zo een call-by-reference simuleer

Toch vind ik het wel nog lastig. Want ik begreep altijd uit de analogie met pointers in C++ dat bij call-by-reference een reference naar het object werd doorgegeven waardoor in de methode de inhoud van het object (de members) dus gewijzigd kunnen worden. En omdat alles behalve de value/simple types standaard een reference is dit ook by-reference doorgegeven werd. Maar dan wordt het natuurlijk wel weer een vreemd verhaal als parameters met "ref" doorgegeven worden in C#.

Herko_ter_Horst schreef op dinsdag 12 februari 2008 @ 21:30:
[...]


En wat wil je hier nou mee zeggen? Dat je niet begrepen hebt waar het over gaat? Om nog maar te zwijgen van het feit dat je een custom class gebruikt i.p.v. Object (of hoe de top-level class in C# ook moge heten).

Of is dit jouw manier om uit te leggen waarom mensen denken dat er call-by-reference plaatsvindt terwijl dat niet zo is?

Nog even voor de zekerheid: dat je het object waar een reference naar wijst kunt modificeren wil nog niet zeggen dat je call-by-reference semantiek hebt aangetoond, verre van. De vraag is of je de reference zelf kunt modificeren, zodanig dat die modificatie ook in de aanroepende scope zichtbaar is. Dat is iets heel anders dan het object waar de reference naar wijst modificeren.

Het ging me er dus niet om aan te tonen dat het call-by-reference zou zijn. Het was gewoon een grapje door het object te wrappen in een class die dan als reference dient. Dat ik daar strings gebruikt heb ipv object maakt voor het voorbeeld niet uit. Het was maar een grapje...

[ Voor 17% gewijzigd door riezebosch op 13-02-2008 11:23 ]

[.oisyn]

flowerp schreef op woensdag 13 februari 2008 @ 00:01:
[...]


Uhm, ik ken de syntax van C# niet exact, maar zoals marcj ook al opmerkt is dit geen voorbeeld van pass by reference:

d'Oh, ik dacht dat het over de post van Marcj ging die eronder staat, die gewoon de 'ref' syntax gebruikt

[Verwijderd]

Misschien goed om weer on topic te gaan, deze hele discussie is nou wel een beetje klaar

[ Voor 11% gewijzigd door Verwijderd op 13-02-2008 11:11 ]

[.oisyn]

Verwijderd schreef op woensdag 13 februari 2008 @ 11:11:
Misschien goed om weer on topic te gaan, deze hele discussie is nou wel een beetje klaar

"ontopic"? Je bedoelt het opsommen van slechte codevoorbeelden? Het is niet alsof de discussie die posts in de weg staat oid

[Verwijderd]

.oisyn schreef op woensdag 13 februari 2008 @ 11:28:
[...]

"ontopic"? Je bedoelt het opsommen van slechte codevoorbeelden? Het is niet alsof de discussie die posts in de weg staat oid

Een beetje wel hoor, de discussie overspoelt alles. Er zijn verschillende codevoorbeelden gepost waar haast niet op gereageerd is.

Misschien moet je een nieuw topic maken?

[flowerp]

riezebosch schreef op woensdag 13 februari 2008 @ 09:48:
[...]
De grap van het voorbeeldje wat ik gaf was dat ik zelf het object wrap in een reference en zo een call-by-reference simuleer

Dat is inderdaad wel grappig bedoeld ja. Misschien had je dus even aan moeten geven dat de code een grap was en dus helemaal geen call-by-reference?

Toch vind ik het wel nog lastig. Want ik begreep altijd uit de analogie met pointers in C++ dat bij call-by-reference een reference naar het object werd doorgegeven waardoor in de methode de inhoud van het object (de members) dus gewijzigd kunnen worden.

Dat is dus de simpele gedachtegang, waardoor veel mensen in de war raken tussen de 2 begrippen. Call-by-reference geeft een referentie naar de variable mee die je gebruikt voor de call. Is die variable dan een pointer, dan kun je er in de called function een nieuwe pointer aan toe kennen, of je kunt de pointer dereferencen en het object waar de pointer naar wijst veranderen.

Of je nu de oorspronkelijke variable gebruikt om het object te bereiken of dat je een kopie van de pointer zelf gebruikt om het object te bereiken maakt voor de 2de usecase niets uit. In alle twee de gevallen kom je bij hetzelfde object uit. Echter, voor de 1ste usecase maakt het wel degelijk uit. Met een kopie van de pointer kun je natuurlijk never nooit de oorspronkelijke variable bereiken.

[.oisyn]

Verwijderd schreef op woensdag 13 februari 2008 @ 11:37:
[...]


Een beetje wel hoor, de discussie overspoelt alles. Er zijn verschillende codevoorbeelden gepost waar haast niet op gereageerd is.

Daar waren er voor de discussie ook voldoende van, dus ik vraag me af hoeveel dat met de discussie te maken heeft. Niet alle codevoorbeelden zijn interessant om op te reageren. Maar het staat je natuurlijk vrij een topicreport aan te maken met het verzoek om te splitsen.

riezebosch schreef op woensdag 13 februari 2008 @ 09:48:

Want ik begreep altijd uit de analogie met pointers in C++ dat bij call-by-reference een reference naar het object werd doorgegeven waardoor in de methode de inhoud van het object (de members) dus gewijzigd kunnen worden.

De analogie met pointers in C++ is een verkeerde. De analogie die je moet hebben zijn references. Een pointer is ook een object, net als een int en een MyClass, en die worden gekopieerd als je ze aan een functie geeft. Die functie kan de oorspronkelijke variabele dus niet wijzigen. Dat een pointer ergens naar wijst die die functie wel kan wijzigen doet er niet toe.

Je kunt natuurlijk wel call-by-ref simuleren middels pointers, door een pointer te maken naar de variabele die gewijzigd moet worden. Dit gebeurt in C veel, omdat die het concept van references niet kent. Als je een int hebt die gewijzigd moet worden, geef je een pointer naar die int mee aan de functie. Als het een pointer is die naar een object wijst die gewijzigt moet worden, dan geef je de functie een pointer naar die pointer mee. Het is echter geen call-by-ref: de pointer wordt gekopieerd, en een l-value (kort door de bocht: een variabele) is niet vereist (het kan dus ook het resultaat van een berekening zijn).

Jouw codevoorbeeld is in feite ook zo'n simulatie. Je creëert een object die de te wijzigen variabele in zich heeft. Omdat je een referentie naar zo'n object meegeeft kan de aangeroepen functie dat object wijzigen.

[ Voor 5% gewijzigd door .oisyn op 13-02-2008 12:04 ]

[PrisonerOfPain]

Waarom moeilijk doen als het makkelijk kan? Het initialiseren van de hoeken van een kubus doen we zo:

C++:

class cube{
public:
    // more here
private:
    // more here
    Vec3f m_Corners[8];

    void corners(float a_Size){
        for(size_t i = 0; i < 8; i++){
            m_Corners[i]  = a_Size * Vec3f(axis(i, Vec3f::X), axis(i, Vec3f::Y), axis(i, Vec3f::Z));
        }
    }

    float axis(size_t a_Corner, int a_Axis) const{
        return ((a_Corner >> a_Axis) & 1) == 1
            ? -.5f
            : +.5f;
    }
};

_{Soms heb je nu eenmaal wat afleiding nodig van je huiswerk.}

[TeeDee]

.oisyn schreef op woensdag 13 februari 2008 @ 12:02:
[...]
...

Daar ik geen ervaring heb met C++ pointers kan ik daar niet over mee kletsen. Even kijken of ik het e.e.a nu begrijp door in kinderbipsen taal het e.e.a. te verwoorden.

Denkend vanuit mijn C# kennis:

Een call-by-value geeft een waarde (value) aan een method/function als 'voer' voor de method/function om iets mee te doen.

Een call-by-reference (in c# dus iets als ref meegeven in de calling method en als signature voor deze method) zorgt ervoor dat je de parameter kan gebruiken zonder er een 'kopie' van hoeft te instantiëren.

Hmm, het concept begrijp ik wel, alleen het verwoorden gaat lastig

[.oisyn]

PrisonerOfPain schreef op woensdag 13 februari 2008 @ 12:12:
Waarom moeilijk doen als het makkelijk kan? Het initialiseren van de hoeken van een kubus doen we zo:

zo doe ik dat ook altijd, maar dan door die axis functie gewoon uit te schrijven

[PrisonerOfPain]

.oisyn schreef op woensdag 13 februari 2008 @ 12:26:
[...]

zo doe ik dat ook altijd, maar dan door die axis functie gewoon uit te schrijven

Daar gaat je onderhoudbaarheid

[.oisyn]

't Is een fucking cube, wat moet je daar in hemelsnaam aan onderhouden?

't Is nog meestal debug code ook, want voor het echte werk sla ik alleen het centrum en de extents op, da's genoeg om alle berekeningen mee te doen.

[ Voor 50% gewijzigd door .oisyn op 13-02-2008 12:51 ]

[PrisonerOfPain]

.oisyn schreef op woensdag 13 februari 2008 @ 12:50:
't Is een fucking cube, wat moet je daar in hemelsnaam aan onderhouden?

My point exactly

't Is nog meestal debug code ook, want voor het echte werk sla ik alleen het centrum en de extents op, da's genoeg om alle berekeningen mee te doen.

In dit geval gaat het om een simpele physics simulatie waarbij de kubussen op een realistische manier de collision met de floor-plane af moeten handelen terwijl ze onderling verbonden zijn met een mass-spring systeem. De hoekpunten zijn nodig om de collision detection makkelijk af te kunnen handelen.

[.oisyn]

Daar heb je dus geen hoekpunten voor nodig, dat kost alleen maar extra berekeningen . Je moet een box kunnen projecteren op een as. Als je daar een center vector en 3 extents vectoren (de x, y en z van de box in world space) hebt, dan doe je gewoon

C++:

void ProjectOnAxis(Vector3 dir, float & min, float & max)
{
    float c = m_center * dir;
    float e = Abs(m_extentsX * dir) + Abs(m_extentsY * dir) + Abs(m_extentsZ * dir);
    min = c - e;
    max = c + e;
}

Als je floor-plane een normaal heeft van n, en een afstand tot de oorsprong van d, dan projecteer je de box op n en controleer je of het resulterende minimum kleiner is dan d. Zo ja, dan snijdt de box de plane of ligt hij eronder (als max < d ligt hij eronder, anders snijdt ie)

[ Voor 22% gewijzigd door .oisyn op 13-02-2008 13:36 ]

[CodeCaster]

Een kwartiertje debuggen later...

PHP:

  $user = new User();
(...)
  $user = $db->escape($_POST['username']);
  $pass = $db->escape($_POST['password']);
(...)  
  if (!$user->login($user, $pass)) {

  }

Het duurde even tot ik doorhad waar de non-object-error op $user vandaan kwam

[paulh]

Laat maar.

[ Voor 93% gewijzigd door paulh op 14-02-2008 21:24 ]

[Verwijderd]

CodeCaster schreef op donderdag 14 februari 2008 @ 16:42:
Een kwartiertje debuggen later...

PHP:

  $user = new User();
(...)
  $user = $db->escape($_POST['username']);
  $pass = $db->escape($_POST['password']);
(...)  
  if (!$user->login($user, $pass)) {

  }

Het duurde even tot ik doorhad waar de non-object-error op $user vandaan kwam

Variable-prefixen!

$input_user, $input_pass, $object_user.

[flowerp]

Verwijderd schreef op donderdag 14 februari 2008 @ 22:02:
[...]
Variable-prefixen!

$input_user, $input_pass, $object_user.

Yugh! Doet me een beetje aan het niet al te geliefde Hungarian notation denken.

Kun je niet gewoon veel beter types gebruiken? Dan waarschuwt de compiler je tenminste

[Voutloos]

Gewoon var_dump($user) doen. Goh, een username, oorzaak gevonden. Als je niet binnen een kwartier var_dump() doet op een variabele waar je een fout op hebt, debug je niet handig.

Maar er zit nog iets wat dodgy is in dat script: escapen doe je voor een bepaalde context en dit lijkt mij de verkeerde plek om een db-context escape functie eroverheen te gooien.

[Robtimus]

CodeCaster schreef op donderdag 14 februari 2008 @ 16:42:
Een kwartiertje debuggen later...

PHP:

  $user = new User();
(...)
  $user = $db->escape($_POST['username']);
  $pass = $db->escape($_POST['password']);
(...)  
  if (!$user->login($user, $pass)) {

  }

Het duurde even tot ik doorhad waar de non-object-error op $user vandaan kwam

Een bekende van mij, alleen heb ik er wel wat langer opgezeten.

Stukje van een simpel client-server model:

Python:

function do_something(..., socket, ...):
    ...
    socket = socket.socket(...)
    ....

De bedoeling: de socket parameter is de server socket, en in de code maak ik een client socket aan. En ik me maar afvragen waarom mijn server socket dichtgegooid werd...

Daarom ben ik ook meer fan van strong-typed talen en talen waarbij je je variabelen moet declareren. Scheelt heel wat fouten.

[YopY]

CodeCaster schreef op donderdag 14 februari 2008 @ 16:42:
Een kwartiertje debuggen later...

PHP:

  $user = new User();
(...)
  $user = $db->escape($_POST['username']);
  $pass = $db->escape($_POST['password']);
(...)  
  if (!$user->login($user, $pass)) {

  }

Het duurde even tot ik doorhad waar de non-object-error op $user vandaan kwam

Ziehier een punt waarop typeless talen tekort komen ^_^.

[ValHallASW]

@IcemanX: Python *is* strongly typed, maar dynamic. Python cast niets (dus strongly typed), maar het type van een variabele ligt niet vast (dus dynamic).

@YopY: Dit heeft al helemaal niets met typeless talen te maken, voor zover die bestaan. PHP ondersteunt wel types, maar is weak (doet automatische casts) en dynamically typed.

Wat in het algemeen wél werkt (en meestal ook geen problemen oplevert) is het verbieden van een nieuwe assignment binnen dezelfde scope. Zeker met objecten komt het weinig voor dat je een andere waarde aan een variabele wilt toekennen. Ja, in lussen wel, maar dan zit je niet meer in dezelfde scope in principe

[FTL]

TeeDee schreef op woensdag 13 februari 2008 @ 12:14:
[...]

Een call-by-value geeft een waarde (value) aan een method/function als 'voer' voor de method/function om iets mee te doen.

Een call-by-reference (in c# dus iets als ref meegeven in de calling method en als signature voor deze method) zorgt ervoor dat je de parameter kan gebruiken zonder er een 'kopie' van hoeft te instantiëren.

Hmm, het concept begrijp ik wel, alleen het verwoorden gaat lastig

Heel simpel gezegd: parameters van een function zijn altijd by value, ook met referencetype parameters.
Bij referencetype parameters is de referentie zelf de value die wordt meegegeven.

Pas je de referentie van een referentietype (zonder ref) aan in de function (door een nieuw object eraan te hangen of een andere object eraan toe te wijzen) zal dit NIET zichtbaar zijn in de functie 1 stapje hoger in de callstack (caller): immers de orginele referentie naar referentietype wordt niet aangepast.

Uitzondering:
ref: zorgt dat dit gedrag anders wordt; je werkt daadwerkelijk met de value / reference (van de referencetype) die ook door de caller wordt gebruikt.

out: zelfde als ref behalve dat in de caller de value/reference niet geinstantieerd hoeft te zijn.
(hij zal de value / reference in de caller zetten overschrijven).

[ Voor 15% gewijzigd door FTL op 15-02-2008 20:34 ]

[flowerp]

FTL schreef op vrijdag 15 februari 2008 @ 19:56:
out: zelfde als ref behalve dat in de caller de value/reference niet geinstantieerd hoeft te zijn.
(hij zal de value / reference in de caller zetten overschrijven).

Voor de hand leggend, maar eerder nog vergeten op te merken; het hele concept van output parameters kan dus ook niet in Java. Daar is namelijk call-by-reference voor nodig.

Java:

public void testOutputParams(Long a, Long b) {
  a = 1;
  b = 1;
}

Long a = 0;
Long b = 0;

testOutputParams(a,b);

// Prints of course 0 0 and not 1 1
System.out.println( a + " " + b );
}

[dev10]

Zit ik voor een schoolopdracht een PHP-syteem door te lopen, kom ik dit tegen:

PHP:

    $i=0;
        while ($i < $num){

            $id=mysql_result($result,$i,"id");
            $naam=mysql_result($result,$i,"product_naam");
            $code=mysql_result($result,$i,"product_code");

            echo '<tr>';
                echo '<td>'.$naam.'</td>';
                echo '<td>'.$code.'</td>';
                echo '<td><a href="index.php?pag=prod_edit&prod_id='.$id.'">Aanpassen</td>';
                echo '<td><a href="index.php?pag=prod_del&prod_id='.$id.'">Verwijderen</td>';
            echo '<tr>';
    $i++;
}

[Verwijderd]

Stukkie COBOL om jullie vooroordelen maar weer eens te bevestigen:
Jaren terug een staigiere zoiets zien produceren:

code:

dinges section.
     move zero to subscrib-je.
     perform dinges-init 3 times.
dinges-init.
     add 1 to subscrib-je.
     move zero to array-veldje (subscrib-je).
dinges-exit.
    exit.

Het array-veldje had dus 4 occurences. De paragraaf werd 3x aangeroepen en de 4e keer was een z.g. "fall true".
Dus perfecte code omdat het precies doet wat de bedoeling is..... Maar je kl*ten gaan in de bankschroef als je zoiets oplevert

[.oisyn]

Bedoel je een "fall through"?

[bouvrie]

letinon schreef op maandag 18 februari 2008 @ 10:53:
Zit ik voor een schoolopdracht een PHP-syteem door te lopen, kom ik dit tegen:

PHP:

    $i=0;
        while ($i < $num){

            $id=mysql_result($result,$i,"id");
            $naam=mysql_result($result,$i,"product_naam");
            $code=mysql_result($result,$i,"product_code");

            echo '<tr>';
                echo '<td>'.$naam.'</td>';
                echo '<td>'.$code.'</td>';
                echo '<td><a href="index.php?pag=prod_edit&prod_id='.$id.'">Aanpassen</td>';
                echo '<td><a href="index.php?pag=prod_del&prod_id='.$id.'">Verwijderen</td>';
            echo '<tr>';
    $i++;
}

Is dit slecht omdat ipv een for-loop, een while-loop wordt gebruikt? Of omdat de variabele $num niet gedeclareerd is?

[Voutloos]

Het is waarschijnlijk slecht omdat het met een mysql_fetch_* call de helft korter kan, met wellicht ook betere performance. Is gewoon een luie lampie geweest welke enkel mysql_query() kent.

[.oisyn]

En ook alleen een while() en geen for(;;)

[FragFrog]

Mwoach, een while(hasResults) heeft in mijn opinie ook wel wat boven een mysql_num_rows en dan for(i < num_rows), maar dan moet je het natuurlijk niet op die manier doen

* FragFrog vindt de geindente echo's bij td's ook wel origineel trouwens

[Verwijderd]

.oisyn schreef op maandag 18 februari 2008 @ 11:39:
Bedoel je een "fall through"?

Oeps! Ja, dat bedoel ik.

[dev10]

bouvrie schreef op maandag 18 februari 2008 @ 11:44:
[...]
Is dit slecht omdat ipv een for-loop, een while-loop wordt gebruikt? Of omdat de variabele $num niet gedeclareerd is?

De variabele $num wordt wel gedeclareerd, maar dat is eerder in het bestand.

Ik zou zelf noch een for-loop, noch een while-loop gebruiken. Zelf gebruik ik altijd een eigen functie om data uit de database te halen. En dan kan ik lekker met een foreach-loop werken.

PHP:

    function doQuery($query) {
        $result = mysql_query($query);
        $result_array = array();

        if ($result) {
            while ($row = mysql_fetch_assoc($result)) {
                $result_array[] = $row;
            }
            return $result_array;
        }
        else {
            return false;
        }
    }

[ Voor 42% gewijzigd door dev10 op 18-02-2008 12:23 ]

[Dido]

Rare loop-constructies zijn soms gewoon nodig

code:

do_while(Pasen *ne Pinksteren)
  set_ref #node to #nodelist.nextchild
  if_ref #node is_not(*null)
    [verwerk node en roep zelf aan om children te verwerken]
  else
    return
  endif
end_do

Bonuspunten voro wie de taal herkent. Waarom geen do_while(#node not NULL)? Omdat dat niet kan

Oh, ja. Een for each Node in Nodelist kan ik ook shaken. Nodelist is in deze taal geen collection. (Zowel nodes als nodelists komen van een ingepakte msxml, overigens).

[ Voor 18% gewijzigd door Dido op 18-02-2008 12:26 ]

[FragFrog]

letinon schreef op maandag 18 februari 2008 @ 12:19:
Ik zou zelf noch een for-loop, noch een while-loop gebruiken.
[...]

PHP:

while ($row = mysql_fetch_assoc($result)) {
                $result_array[] = $row;

Hopelijk zie je nu zelf waarom je in mijn opinie zojuist een vermelding in dit topic hebt verdient

Alhoewel, het is niet zozeer een slecht programmeervoorbeeld natuurlijk, eerder gevalletje maandagochtend

[ Voor 13% gewijzigd door FragFrog op 18-02-2008 13:53 ]

[Woy]

FragFrog schreef op maandag 18 februari 2008 @ 13:50:
[...]

Hopelijk zie je nu zelf waarom je in mijn opinie zojuist een vermelding in dit topic hebt verdient

Alhoewel, het is niet zozeer een slecht programmeervoorbeeld natuurlijk, eerder gevalletje maandagochtend

Je bedoelt de missende } neem ik aan

[Jaap-Jan]

Die $result_array[] = $row vond ik zelf ook behoorlijk ranzig. Ze hebben niet voor niets array_push() uitgevonden.

[Verwijderd]

Jaap-Jan schreef op maandag 18 februari 2008 @ 14:17:
Die $result_array[] = $row vond ik zelf ook behoorlijk ranzig. Ze hebben niet voor niets array_push() uitgevonden.

Is $result_array[] niet veel sneller dan array_push()? Verder vind ik het ook nog eens een mooie optie voor als je af en toe met een index-key werkt.

[Voutloos]

Letinon zei geen while loop te willen gebruiken. Maar letinon bedoelt gewoon dat hij lekker in de rest van de code met foreach kan werken als hij kant en klare arrays uit zijn query functie krijgt.

Lekker boeiend. For is logisch als je het aantal iteraties weet, while($row = mysql_fetch_iets($rs)) is zo'n beetje de meest populaire regel php en foreach is gewoon heerlijk als je een complete array af wil gaan. Maak vervolgens lekker zelf de geschikte keus...

Jaap-Jan schreef op maandag 18 februari 2008 @ 14:17:
Die $result_array[] = $row vond ik zelf ook behoorlijk ranzig. Ze hebben niet voor niets array_push() uitgevonden.

En dan lees je de manual en zie je

Note: If you use array_push() to add one element to the array it's better to use $array[] = because in that way there is no overhead of calling a function.

[.oisyn]

Jaap-Jan schreef op maandag 18 februari 2008 @ 14:17:
Die $result_array[] = $row vond ik zelf ook behoorlijk ranzig. Ze hebben niet voor niets array_push() uitgevonden.

Even zonder er een inhoudelijk waarde-oordeel aan te koppelen draai ik nu even de argumentatie om:
array_push() vind ik zelf behoorlijk ranzig. Ze hebben niet voor niets de [] notatie uitgevonden.

Welke van de twee is nu waar?

[ Voor 3% gewijzigd door .oisyn op 18-02-2008 14:42 ]

[dev10]

Voutloos schreef op maandag 18 februari 2008 @ 14:18:
Letinon zei geen while loop te willen gebruiken. Maar letinon bedoelt gewoon dat hij lekker in de rest van de code met foreach kan werken als hij kant en klare arrays uit zijn query functie krijgt.

Precies.

[.oisyn]

Geen slecht programmeervoorbeeld, maar wel een slecht documentatievoorbeeld. Uit de Cg manual, voor een bepaalde functie

Return value
- An error code.

[Jaap-Jan]

.oisyn schreef op maandag 18 februari 2008 @ 14:42:
[...]

Even zonder er een inhoudelijk waarde-oordeel aan te koppelen draai ik nu even de argumentatie om:
array_push() vind ik zelf behoorlijk ranzig. Ze hebben niet voor niets de [] notatie uitgevonden.

Welke van de twee is nu waar?

Ik denk wel dat je gelijk hebt, die constructie zit er niet voor niets in, het blijft er raar uit zien. Maar als het gebruikelijk is in PHP, wie ben ik dan om te zeggen dat het raar is.

.oisyn schreef op maandag 18 februari 2008 @ 18:24:
Geen slecht programmeervoorbeeld, maar wel een slecht documentatievoorbeeld. Uit de Cg manual, voor een bepaalde functie


[...]

Zo heb ik ook een bug gevonden in Rhythmbox met betrekking tot het weergeven van Cover Art. Nou wilde ik weten wat een bepaald attribuut (path) in gnomevfs.URI bevatte:

path Read/Write The full path name.

Waarom wordt daar geen voorbeeld gegeven, want het URI scheme en de hostname wordt gestript, waardoor cover art op Samba shares niet weergegeven kunnen worden. Sowieso is 'path' een term die behoorlijk veel betekenissen heeft, dus maak dan duidelijk wat precies de betekenis is.

[Dido]

.oisyn schreef op maandag 18 februari 2008 @ 18:24:
Geen slecht programmeervoorbeeld, maar wel een slecht documentatievoorbeeld. Uit de Cg manual, voor een bepaalde functie
[...]

Zo kent de taal waarin ik mag coden geen echte boolean. Er is wel een std_bool type. Dat is gedefinieerd als alpha 5. Waarom? Omdat dan de waardes "TRUE" en "FALSE" er precies inkunnen

Maar goed, definieer een returncode als bool, en geef "MAYBE" mee terug. Ja, dat mag. Werkt het? Maybe.

[Snake]

letinon schreef op maandag 18 februari 2008 @ 12:19:
Ik zou zelf noch een for-loop, noch een while-loop gebruiken.
[...]

PHP:

while ($row = mysql_fetch_assoc($result)) {
                $result_array[] = $row;

Wat gij doet is assignment in condition, mag niet! Ge hebt gewoon geluk dat mysql_fetch_assoc false returned als ge op het einde van u resultset zit.

Ge moet het dus zo doen:

PHP:

while (($row = mysql_fetch_assoc($result)) !== false) {
                $result_array[] = $row;

[FragFrog]

Snake schreef op maandag 18 februari 2008 @ 20:21:
Ge hebt gewoon geluk dat mysql_fetch_assoc false returned als ge op het einde van u resultset zit.

Hoezo geluk? Is keurig gedocumenteerd gedrag hoor

Return Values
Returns an associative array of strings that corresponds to the fetched row, or FALSE if there are no more rows.

Dat gemiereneuk soms hier..

[PrisonerOfPain]

Snake schreef op maandag 18 februari 2008 @ 20:21:
[...]


Wat gij doet is assignment in condition, mag niet! Ge hebt gewoon geluk dat mysql_fetch_assoc false returned als ge op het einde van u resultset zit.

Het mag prima, het is anders goed gespecificeerd gedrag.

[Robtimus]

.oisyn schreef op maandag 18 februari 2008 @ 18:24:
Geen slecht programmeervoorbeeld, maar wel een slecht documentatievoorbeeld. Uit de Cg manual, voor een bepaalde functie

[...]

Hou daar alsjeblieft over op.

Ik ben de laatste tijd bezig in zowel Linux als Windows, om tegen de system libs te proggen. Dan gebruik je natuurlijk man cq MSDN voor de documentatie, en de verschillen zijn overduidelijk.

Bij man zie je bij bijna elke functie exact welke foutcodes er gereturned kunnen worden, of anders welke er in errno kunnen worden gezet.
Bij MSDN is het standaard antwoord in bijna alle gevallen: de functie returned 0 / ERROR_SUCCESS, en anders kijk je maar in GetLastError. ARGH!


Verder nog een handige in Log4J, in NullAppender. Die heeft een public constructor, en een method getInstance(), met als commentaar:

Whenever you can, use this method to retreive an instance instead of instantiating a new one with new.

Prima zou je denken, totdat je de signature ziet:

Java:

public NullAppender getInstance()

[.oisyn]

IceManX schreef op maandag 18 februari 2008 @ 20:52:
Bij man zie je bij bijna elke functie exact welke foutcodes er gereturned kunnen worden, of anders welke er in errno kunnen worden gezet.
Bij MSDN is het standaard antwoord in bijna alle gevallen: de functie returned 0 / ERROR_SUCCESS, en anders kijk je maar in GetLastError. ARGH!

Nou zie ik niet wat er mis is met GetLastError() tov errno, maar bij de meeste functies staan toch wel gewoon de mogelijke fouten die je na de aanroep met GetLastError() zou kunnen krijgen.

Snake schreef op maandag 18 februari 2008 @ 20:21:
[...]


Wat gij doet is assignment in condition, mag niet!

Het resultaat van een assignment is de waarde die je zojuist geassigned hebt (of eigenlijk specifieker de variabele zelf die je zojuist geassigned hebt, in PHP maakt die nuancering geen verschil maar in de meeste andere C-achtige dialecten wel). En dat is een niet-lege array als er nog een resultaat is (wat true oplevert na conversie naar boolean), en anders false.

[ Voor 8% gewijzigd door .oisyn op 18-02-2008 21:44 ]

[Robtimus]

.oisyn schreef op maandag 18 februari 2008 @ 21:42:
[...]

Nou zie ik niet wat er mis is met GetLastError() tov errno, maar bij de meeste functies staan toch wel gewoon de mogelijke fouten die je na de aanroep met GetLastError() zou kunnen krijgen.

Er is geen verschil tussen errno en GetLastError, maar ik heb een aardig deel van de Platform SDK door zitten kijken en maar weinig echte errors worden expliciet vermeld.

Bv de registry functies. Bijna overal staat het volgende:

If the function succeeds, the return value is ERROR_SUCCESS.

If the function fails, the return value is a nonzero error code defined in Winerror.h. You can use the FormatMessage function with the FORMAT_MESSAGE_FROM_SYSTEM flag to get a generic description of the error.

of

If the function succeeds, the return value is ERROR_SUCCESS.

If the function fails, the return value is a system error code.

Ok, er zijn een paar uitzonderingen voor fouten die maar halve fouten zijn, zoals ERROR_NO_MORE_ITEMS en ERROR_MORE_DATA, maar dat is bijna alleen bij de RegEnum* en RegQuery* functies. RegQueryMultipleValues is de enige die exact de foutcodes beschrijft.

Ik heb net zitten controleren, en van de ruim 40 registry functies hebben er hooguit 10 een andere omschrijving van de return waarde dan degene die ik hierboven gequote heb. En de registry functies zijn niet de enige functies waarbij de return waarden zo beschreven zijn.

[Marcj]

Ik ben op het moment met de Android SDK bezig en was een aantal ongedocumenteerde classen aan het uittesten. Toen kreeg ik in de debugger het volgende te zien:



Ik hoop dat dit door een obfuscator komt, maar dit maakt het debuggen een heel stuk moeilijker. (En het geeft geen hoop dat de source nog ooit openbaar wordt)

[.oisyn]

Dat lijkt me overduidelijk een obfuscator, maar ik vraag me af waarom de source dan ineens nooit openbaar zal worden? Het is niet alsof je je source zelf gaat obfuscaten en daar vervolgens verder mee gaat werken

[Marcj]

.oisyn schreef op dinsdag 19 februari 2008 @ 11:25:
Dat lijkt me overduidelijk een obfuscator, maar ik vraag me af waarom de source dan ineens nooit openbaar zal worden? Het is niet alsof je je source zelf gaat obfuscaten en daar vervolgens verder mee gaat werken

Nee, maar blijkbaar willen ze bij Google niet hebben dat we weten hoe de boel intern werkt. Hoewel ik al tig keer een NPE heb gekregen in de gesloten code die er nu is. Er wordt gewoon veel te weinig parameters gecontroleerd, plus dat de documentatie bar slecht is. Er staan op zoveel plekken codevoorbeelden die niet (meer) werken of gewoon incompleet zijn. Javadoc die niets meer zegt dan de functienaam zelf. Voorbeeld:

quote: http://code.google.com/an...talkservice/Presence.html

public Presence(int status, String customStatus)
Constructor

Parameters:
status the status value for the presence.
customStatus user settable text status.

of

quote: http://code.google.com/an...ephony/gsm/SmsHeader.html

public void add(Element element)
Add an element to the SmsHeader.
Parameters:
element to add.

public ArrayList getElements()
Returns the list of SmsHeader Elements that make up the header.
Returns
the list of SmsHeader Elements.

public static SmsHeader parse(byte[] data)
Creates an SmsHeader object from raw user data header bytes.
Parameters:
data is user data header bytes
Returns
an SmsHeader object

public String toString()
Answers a string containing a concise, human-readable description of the receiver.

[Herko_ter_Horst]

Obfuscation kan op het soort devices waar Android voor bedoeld is ook dienen om de footprint (zowel on disk als in memory) te verkleinen.

[flowerp]

.oisyn schreef op dinsdag 19 februari 2008 @ 11:25:
Dat lijkt me overduidelijk een obfuscator

Als ze willen obfuscaten, zouden ze dan niet gewoon de symbols ook weglaten in de gecompileerde versie?

Sun doet dat overigens ook altijd met de JDK classes, zodat je deze niet netjes kunt debuggen (lokale variabelen zie je niet, en method parameters worden arg0 en arg1 etc, ondanks dat ze wel een source attachment meeleveren)

[.oisyn]

flowerp schreef op woensdag 20 februari 2008 @ 10:34:

Als ze willen obfuscaten, zouden ze dan niet gewoon de symbols ook weglaten in de gecompileerde versie?

Hoe kun je class names en members weglaten dan? Imho de enige symbols die je weg kunt laten zijn die van lokale variabelen en parameters, maar dat is niet wat je hier ziet.

[flowerp]

.oisyn schreef op woensdag 20 februari 2008 @ 11:11:
[...]
Hoe kun je class names en members weglaten dan? Imho de enige symbols die je weg kunt laten zijn die van lokale variabelen en parameters, maar dat is niet wat je hier ziet.

Hmmm, ik moet eerst koffie drinken voor ik reageer 's ochtends Je hebt gelijk, ik keek niet goed naar het plaatje.

[LuCarD]

code:

     LOOP
         I ++
         OPENSEQ "./syscontrols/parmsstat" TO PStatFD LOCKED
             CONTINUE
         END THEN
             StatMssg = "Wrote parmsbackup on ":TimeDate:@VM:LOWER(results)
              WRITESEQ StatMssg APPEND ON PStatFD THEN
                 BREAK
              END
         END ELSE                                 ;* we create a new file called parmsstat
             WRITE "" ON FD,"parmsstat"      
         END
         IF I > 20 THEN
             LogRec = ""
             LogRec = "Could not open the parmsstat file"
             CALL syswritelog(LogRec)
             BREAK
         END
 
     REPEAT

Deze code zat in ons live systeem. En aangezien deze routine elke keer werd aangeroepen bij elke pageview op de server en daardoor groeide deze file tot een kleine 1,6 Gb.

Niet echt bevorderlijk voor de performance.

Verder werd deze backup file nergens anders gebruikt, of uitgelezen. Hij werkt alleen dagelijks geleegd door een vage subroutine.

En dan heb ik nog niet eens over de 20keer proberen te schrijven naar de file

Leuk dit soort undocumented features...

[Mastermind]

Een THEN en ELSE zonder IF? Wat is dat voor taal?

[ZaZ]

Volgens mij is dat Jbase

[LuCarD]

ZaZ schreef op zaterdag 08 maart 2008 @ 16:11:
Volgens mij is dat Jbase

Correct... Ben je ook een JBase programmeur?

[ZaZ]

LuCarD schreef op zaterdag 08 maart 2008 @ 18:14:
[...]


Correct... Ben je ook een JBase programmeur?

offtopic:
Neen.
Wel eens wat mee gedaan, meer niet.

[mosymuis]

Van een collega, in een ajax request script:

code:

$sSQL = 'SELECT Rater FROM tblUserRating Where UserMessageID = '.$MessageID;
$GLOBALS['oDB']->Exec($sSQL);
for($i=0; $aFields=$GLOBALS['oDB']->GetFields(); $i++){
    if($aFields['tblUserRating_Rater'] == $_SESSION['uid']){
        print '7';
        exit;
    }
}

Dit had prima in één query gekund zonder verdere PHP controle... De "7" is volstrekt willekeurig gekozen, de programmeur in kwestie wist al niet meer waarop dat was gebaseerd. En kan je bovendien met exit() al niet direct een string ter output meegeven?

[Verwijderd]

PHP:

$GLOBALS['oDB']->Exec($sSQL);

?

[Icelus]

Verwijderd schreef op woensdag 12 maart 2008 @ 15:03:

PHP:

$GLOBALS['oDB']->Exec($sSQL);

?

Databaseobject dat globaal te gebruiken is.

[AW_Bos]

Wat dacht je dan een forum die topics en berichten opslaat in 1 tabel?
Waarom zou een bericht dan een topic-type moeten krijgen? En heeft de 'subfora' veld per bericht (first post) of reactie dan de ID van een forum of een topic.

Programmeer-verbod voor diegene die dit voor mij gemaakt heeft. Maar gelukkig heb ik een (ietswat ranzige) SQL converter geschreven die het goed zet, zoals het hoort .

En dan nog hele vieze niet uitgelijnde of gecommentariseerde PHP4-code verder.. wat ik nu laate tijd herschreven heb from scratch naar PHP5..

[Verwijderd]

Ariën Clay schreef op woensdag 12 maart 2008 @ 15:08:
Wat dacht je dan een forum die topics en berichten opslaat in 1 tabel?
Waarom zou een bericht dan een topic-type moeten krijgen? En heeft de 'subfora' veld per bericht (first post) of reactie dan de ID van een forum of een topic.

Programmeer-verbod voor diegene die dit voor mij gemaakt heeft. Maar gelukkig heb ik een (ietswat ranzige) SQL converter geschreven die het goed zet, zoals het hoort .

En dan nog hele vieze niet uitgelijnde of gecommentariseerde PHP4-code verder.. wat ik nu laate tijd herschreven heb from scratch naar PHP5..

Mijn ideaal beeld:

-1 tabel voor posts. Een ingevuld parent_id wijst naar of een fora of een andere post. Door naar de eerste post te kijken is dit te zien, of afgedwongen met een "level" integer.
-1 tabel voor fora. Fora krijgen een parent-id, 0 staat gelijk aan top-level.

Want wat maakt een topic anders dan een post?

[ Voor 6% gewijzigd door Verwijderd op 12-03-2008 15:16 ]

[Verwijderd]

Icelus schreef op woensdag 12 maart 2008 @ 15:07:
[...]
Databaseobject dat globaal te gebruiken is.

Zo ver was ik ook
Globals vies?

[Verwijderd]

Verwijderd schreef op woensdag 12 maart 2008 @ 15:13:
[...]

Zo ver was ik ook
Globals vies?

Waarom zouden globals vies zijn? Zelf gebruik ik ze maar wat vaak om applicatie settings overal toegankelijk te maken. Al moet ik wel zeggen dat ik dan liever constants gebruik.

[T-MOB]

Verwijderd schreef op woensdag 12 maart 2008 @ 15:13:
Globals vies?

Waarom zou dat vies zijn, omdat mensen op internet zeggen dat globals vies zijn?
Zeker wanneer het volledig wordt uitgeschreven zoals hier $_GLOBALS['oDB'] is het vrij helder wat er gebeurt. Het enige risico dat je neemt is dat $oDB in de globale scope een keer overschreven wordt. In kleinere applicaties valt dat best mee en is het imho prima te verdedigen om het zo te doen en daarmee de overhead van een Registry-, Singleton- of andere afgeschermde implementatie te besparen.

[ouicestmoi]

Ik gebruik een library zziplib en daar kom ik onder meer het volgende tegen:

code:

#define ___ {
#define ____ }

Niet nodig te zeggen dat de werking van sommige onderdelen heel lastig te doorgronden is! Ik ben overtuigd geraakt dat #define's zoveel mogelijk vermeden moeten worden.

[Verwijderd]

Tja, ik vind het vies: leesbaarheid, onderhoudbaarheid, herbruikbaarheid.

Waarom zou dat vies zijn, omdat mensen op internet zeggen dat globals vies zijn?

Jij zit ook op internet en zegt dat ze niet vies zijn, wat is dat nou voor redenatie

[ Voor 56% gewijzigd door Verwijderd op 12-03-2008 15:44 ]

[RobIII]

Verwijderd schreef op woensdag 12 maart 2008 @ 15:12:
[...]


Mijn ideaal beeld:

* -1 tabel voor posts. Een ingevuld parent_id wijst naar of een fora of een andere post. Door naar de eerste post te kijken is dit te zien, of afgedwongen met een "level" integer.
* -1 tabel voor fora. Fora krijgen een parent-id, 0 staat gelijk aan top-level.

Want wat maakt een topic anders dan een post?

Nee dat is ideaal
In je eerste geval* heb een een FK die verwijst naar een forum of een post (een FK hoort te verwijzen naar 1, en en dus niet meer dan 1, tabel)
In je tweede geval* maak je een dummy parent (0) die helemaal niet nodig is en niet bestaat waardoor je FK's niet kunt afdwingen (tenzij je ook daadwerkelijk een "root" record met id 0 en naar zichzelf verwijzend maakt) terwijl je daar prima NULL voor kunt gebruiken (=geen parent). Maak je een 'dummy' record met id 0 en naar zichzelf verwijzend dan moet je dat weer overal in je (recursieve) BL oplossen.

[ Voor 9% gewijzigd door RobIII op 12-03-2008 16:36 ]

[NielsNL]

Verwijderd schreef op woensdag 12 maart 2008 @ 15:12:
[...]


Mijn ideaal beeld:

-1 tabel voor posts. Een ingevuld parent_id wijst naar of een fora of een andere post. Door naar de eerste post te kijken is dit te zien, of afgedwongen met een "level" integer.
-1 tabel voor fora. Fora krijgen een parent-id, 0 staat gelijk aan top-level.

Want wat maakt een topic anders dan een post?

Een topic heeft bijvoorbeeld een titel, en waarschijnlijk staat die nu in iedere post vermeld. En wat als je een topic wilt sluiten? Alle rows aanpassen?

[.oisyn]

ouicestmoi schreef op woensdag 12 maart 2008 @ 15:28:
Ik gebruik een library zziplib en daar kom ik onder meer het volgende tegen:

code:

#define ___ {
#define ____ }

Niet nodig te zeggen dat de werking van sommige onderdelen heel lastig te doorgronden is! Ik ben overtuigd geraakt dat #define's zoveel mogelijk vermeden moeten worden.

Bliep, names containing consecutive underscores are reserved for the implementation . Maar idd, #defines zijn primair handig voor conditional code op basis van bepaalde configuraties en bepaalde helper constructs (zoals het verkrijgen van file+regel informatie bij allocaties, of bij profiling).

[Lister]

Verwijderd schreef op woensdag 12 maart 2008 @ 15:21:

Waarom zouden globals vies zijn? Zelf gebruik ik ze maar wat vaak om applicatie settings overal toegankelijk te maken. Al moet ik wel zeggen dat ik dan liever constants gebruik.

Ik gebruik ook alleen globale variabelen als het niet anders kan, maar ik ga me ook niet meer in bochten wringen om ervoor te zorgen dat ik ze niet hoef te gebruiken. Inderdaad voor applicatie settings e.d. is het wel handig om ze te gebruiken.
Maar ik vond laatst onderstaande declaratie van globale variabelen in de code van een leverancier en daar gingen mijn nekharen toch wel van overeind staan.

code:

NUMBER i;(* general number *)
BOOL b;  (* general boolean *)

Het is een beetje apart taaltje waarin je sowieso een hoop moet doen met globale variabelen maar dit vond ik toch wel redelijk erg, het mooie is dan wel dat het er op lijkt dat die variabelen verder helemaal niet gebruikt worden

[roy-t]

Ik weet niet wat voor taal het is, maar misschien is het speciaal voor for loopjes e.d? (geen declaraties in een for loop mogenlijk?)

[GrooV]

Marcj schreef op dinsdag 19 februari 2008 @ 11:38:
[...]

Nee, maar blijkbaar willen ze bij Google niet hebben dat we weten hoe de boel intern werkt. Hoewel ik al tig keer een NPE heb gekregen in de gesloten code die er nu is. Er wordt gewoon veel te weinig parameters gecontroleerd, plus dat de documentatie bar slecht is. Er staan op zoveel plekken codevoorbeelden die niet (meer) werken of gewoon incompleet zijn. Javadoc die niets meer zegt dan de functienaam zelf. Voorbeeld:


[...]

of

[...]

Google doet dit ook bij hun javascripts van bijv. google.com & adsense, veel plezier om daar eens door heen te lezen

[Verwijderd]

GrooV schreef op woensdag 12 maart 2008 @ 23:35:
[...]


Google doet dit ook bij hun javascripts van bijv. google.com & adsense, veel plezier om daar eens door heen te lezen

Misschien om hun Javascripts zo compact mogelijk te houden. Waarschijnlijk een van de weinige scenario's waar compacte, onleesbare code verdedigd kan worden.

[YopY]

Verwijderd schreef op woensdag 12 maart 2008 @ 15:21:
[...]


Waarom zouden globals vies zijn? Zelf gebruik ik ze maar wat vaak om applicatie settings overal toegankelijk te maken. Al moet ik wel zeggen dat ik dan liever constants gebruik.

Omdat je, in de meeste gevallen, dat soort dingen niet globaal nodig hebt als je een goed ontwerp hebt. In een ideale situatie zijn de enige objecten (of 'eenheden' in je programma, om het algemeen te houden) die toegang tot een database of databaseverbinding nodig hebben diegenen die ook echt die gegevens eruithalen. De rest van je programma, de controllers, de viewlaag, en weet ik veel wat je nog meer hebt, hebben simpelweg geen database nodig. Nu maakt dit op zich niet zoveel uit, maar idealiter wil je de scope van je vars zo klein mogelijk houden - ook zodat je je overzicht kunt bewaren. Als je globals gebruikt voor je database-object kun je of een andere programmeur dat misbruiken om databasequeries uit te voeren in, bijvoorbeeld, je viewlaag, wat niet bevorderlijk is voor de onderhoudbaarheid van je programma.

Veel van dit soort 'regels' hebben functioneel gezien geen goeie reden, maar zijn meer voor het hoog houden van onderhoudbaarheid en overzichtelijkheid van je programma. Vooral bij grotere programma's is dat belangrijk, waar je in een team met die zooi bezig bent.

Google doet dit ook bij hun javascripts van bijv. google.com & adsense, veel plezier om daar eens door heen te lezen

Klopt, maar bij Javascript heeft dit meestal een goeie reden: hoe minder karakters in je javascript, hoe minder gegevens en hoe minder load op je servers. Dit voordeel is er (lijkt mij) minder in gecompileerde talen en dergelijke, maar ik weet niet in hoeverre identifiers daarin gebruikt worden (intern dus, lijkt mij dat ze gegenereerde identifiers gebruiken ipv functie / variabelenamen).

[Depress]

Ik moest een aantal dagen bij een datum optellen in een forloopje. Maar moest natuurlijk wel de datum correct worden weer gegeven met maanden en jaren. Nu was ik even vergeten dat ik gewoon de time() + dagen had kunnen doen.

Heb ik dit gefabriceerd:

PHP:

$Display = ($vDag + $i > $monthLength[$vMaand] ? abs($monthLength[$vMaand] - ($vDag + $i))." - ".($vMaand + 1 > 12 ?  "1 - ".($vYear + 1) : ($vMaand + 1)." - ".$vYear) : ($vDag + $i)." - ".$vMaand." - ".$vYear);

Heerlijk die single-line if's

[.oisyn]

Dat zijn conditional expressions. Dit is een single-line if:

PHP:

if ($bla) doeIets(); else doeIetsAnders();

Daarnaast vind ik het idd een slecht programmeervoorbeeld. Niet zozeer omdat het met time() makkelijker kan, maar om de manier hoe je het hebt opgeschreven. Dat had wel een stuk duidelijker gekund, zonder de functionele stappen te wijzigen bedoel ik dus.

[ Voor 59% gewijzigd door .oisyn op 13-03-2008 12:43 ]

[Voutloos]

Hele volkstammen denken handig te zijn en 'ff snel' zelf een berekening met datums te doen en dat is zeker een bron van menig bug, want het is gewoon niet triviaal.

Deze code is naast lelijk ook gewoon buggy, aangezien er bijv. niet met schrikkeljaren rekening gehouden is.

[DamadmOO]

Vandaag zag ik ook een leuke query tegen waarbij er tijdens het maken 2 tabellen gebruikt waren die achteraf dus toch niet nodig waren. Ze hadden de join tussen de tabellen wel weggehaald maar ze stonden nog netjes in het FROM gedeelte van de SQL query. De tabellen hadden respectievelijk 20k en 8k records.

En hier op de afdeling vroegen ze zich maar af waarom de statistieken zo sloom waren, want volgens hun waren het zowat de makkelijkste statistieken die er waren terwijl ze de meeste tijd in beslag namen.

Gelukkig heeft degene die dat gemaakt heeft hier niet zo lang gewerkt

[PrisonerOfPain]

T-MOB schreef op woensdag 12 maart 2008 @ 15:26:
[...]

Waarom zou dat vies zijn, omdat mensen op internet zeggen dat globals vies zijn?

Globals zijn gewoon vies, die discussie is vaak genoeg gevoerd. Net als met alles wil het echter niet zeggen dat je ze nooit of te nimmer moet gebruiken. Er zijn voldoende cases te bedenken waarbij ze wel nuttig zijn. Singletons en constants hebben dezelfde nadelen; en daarvoor geld eigenlijk dezelfde regel: wees op de hoogte van wat je doet en ben je bewust van de mogelijke problemen.

Depress schreef op donderdag 13 maart 2008 @ 12:37:
Nu was ik even vergeten dat ik gewoon de time() + dagen had kunnen doen.

PHP:

$time = strtotime('+5 days', $time);

[ Voor 17% gewijzigd door PrisonerOfPain op 13-03-2008 13:12 ]

[TeeDee]

DamadmOO schreef op donderdag 13 maart 2008 @ 13:08:
Vandaag zag ik ook een leuke query tegen waarbij er tijdens het maken 2 tabellen gebruikt waren die achteraf dus toch niet nodig waren. Ze hadden de join tussen de tabellen wel weggehaald maar ze stonden nog netjes in het FROM gedeelte van de SQL query. De tabellen hadden respectievelijk 20k en 8k records.


Gelukkig heeft degene die dat gemaakt heeft hier niet zo lang gewerkt

Hoezo gelukkig? Als er achteraf iets aangepast wordt aan de specs is het niet zo vreemd dat een table overbodig raakt. Dus om daarom 'gelukkig' te zeggen als iemand iets wat achteraf niet meer relevant is vind ik vreemd. Imo gewoon een gevalletje trap na geven. Verder heb je het over 'ze' en als laatst geef 1 iemand de 'schuld'.

Verder vraag ik me ook af waarmee je de statistieken maakt. Een View? Sproc?* Dat zijn imo precies de juiste elementen om een statistiek mee te maken en daardoor is het ook vrij gemakkelijk om overbodige tables te verwijderen.

*Of andere dingen als Crystal Reports...

DamadmOO schreef op donderdag 13 maart 2008 @ 13:29:
[...]
...

Ietwat duidelijker

[ Voor 8% gewijzigd door TeeDee op 13-03-2008 13:41 ]

[DamadmOO]

TeeDee schreef op donderdag 13 maart 2008 @ 13:19:
[...]

Hoezo gelukkig? Als er achteraf iets aangepast wordt aan de specs is het niet zo vreemd dat een table overbodig raakt. Dus om daarom 'gelukkig' te zeggen als iemand iets wat achteraf niet meer relevant is vind ik vreemd. Imo gewoon een gevalletje trap na geven. Verder heb je het over 'ze' en als laatst geef 1 iemand de 'schuld'.

Verder vraag ik me ook af waarmee je de statistieken maakt. Een View? Sproc? Dat zijn imo precies de juiste elementen om een statistiek mee te maken en daardoor is het ook vrij gemakkelijk om overbodige tables te verwijderen.

View,Sproc en caching hadden de programmeurs die het systeem opgezet hadden toen nog nooit van gehoord volgens mij. Ik kan je voor de gein wel het huidige databaseschema geven maar ik denk niet dat je daar vrolijk van wordt. Het is een groot wonder dat de huidige database uberhaupt nog werkt (zolang je maar niet naar de performance kijkt).

Misschien had ik het eerst anders moeten verwoorden maar tijdens het schrijven van de query waren ze erachter gekomen dat de tabellen die ze gebruikt hadden toch niet nodig hadden. Één van de programmeurs heeft toen die join eruit gehaald maar de tabellen in de FROM laten staan met als gevolg een query die dus echt totaal niet performed (even 160k miljoen keer de waardes ophalen die je eigenlijk nodig hebt is niet echt optimaal). Overbodige tabellen en velden zijn trouwens uberhaupt nog nooit uit die database gehaald.

Gelukkig wordt er nu eindelijk een begin gemaakt aan het totaal opnieuw ontwerpen van de database.

[ Voor 2% gewijzigd door DamadmOO op 13-03-2008 13:57 . Reden: 20k * 8k is geen 160k O-) ]

[Voutloos]

DamadmOO schreef op donderdag 13 maart 2008 @ 13:29:
Misschien had ik het eerst anders moeten verwoorden maar tijdens het schrijven van de query waren ze erachter gekomen dat de tabellen die ze gebruikt hadden toch niet nodig hadden. Één van de programmeurs heeft toen die join eruit gehaald maar de tabellen in de FROM laten staan

Klinkt op zich als een, uiteraard slordige, eenmalige fout bij het doorvoeren van de wijziging.

met als gevolg een query die dus echt totaal niet performed (even 160k keer de waardes ophalen die je eigenlijk nodig hebt is niet echt optimaal).

160 miljoen keer. Wellicht was je verhaal gewoon een stuk duidelijker als je direct "een prutser heeft een onnodig cartesisch product van 160M rijen in een query achtergelaten" had gezegd. Laat je meteen blijken dat jij wel weet wat een cartesisch product is.

[Jewest]

VB:
dim cCol as Collection
dim lCounter as long

set cCol = new collection

for lCounter = 1 to cCol.Count
'iets zinvols als er items in de collectie staan
next lCounter

[ Voor 0% gewijzigd door Jewest op 13-03-2008 13:54 . Reden: type o ]

[LuCarD]

<SNIP>
Hier stond onzin.

[ Voor 95% gewijzigd door LuCarD op 13-03-2008 14:00 ]

[Verwijderd]

RobIII schreef op woensdag 12 maart 2008 @ 16:34:
[...]

Nee dat is ideaal
In je eerste geval* heb een een FK die verwijst naar een forum of een post (een FK hoort te verwijzen naar 1, en en dus niet meer dan 1, tabel)
In je tweede geval* maak je een dummy parent (0) die helemaal niet nodig is en niet bestaat waardoor je FK's niet kunt afdwingen (tenzij je ook daadwerkelijk een "root" record met id 0 en naar zichzelf verwijzend maakt) terwijl je daar prima NULL voor kunt gebruiken (=geen parent). Maak je een 'dummy' record met id 0 en naar zichzelf verwijzend dan moet je dat weer overal in je (recursieve) BL oplossen.

In een ideale database zou ik zelfs zo ver gaan als de fora en posts in dezelfde tabel te zetten. Het is een treeview met items, waarom zou je voor verschillende items verschillende tabellen op gaan zetten? Daar heb je OO voor, dan extend je een bepaald object van een item. Iets dat je niet in je database doet.

Iets in de trant van "ID, ParentID, Level, Titel, Inhoud" zou voldoende moeten zijn.

[Voutloos]

Verwijderd schreef op donderdag 13 maart 2008 @ 14:00:
In een ideale database zou ik zelfs zo ver gaan als de fora en posts in dezelfde tabel te zetten.

In een ideale wereld zou ik liever geen datamodel van jou moeten onderhouden.

Niet alle entiteiten zijn hetzelfde. Eigenschappen verschillen, relaties verschillen, je krijgt redundantie en wazige checks overal etc. etc.
Met jouw logica is een DB met maar 1 tabel {id, object_type, blob} voldoende. En dergelijke tabellen heeft iedereen wel eens gemaakt cq. over nagedacht, maar gelukkig hebben de meesten daarvan geleerd.

Daar heb je OO voor, dan extend je een bepaald object van een item

Een post object is geen speciaal forum object (of vice versa, of met een gedeelde superclass), dus qua OO is dit niet imo ook geen briljant idee.

[ Voor 15% gewijzigd door Voutloos op 13-03-2008 14:18 ]

[Verwijderd]

Voutloos schreef op donderdag 13 maart 2008 @ 14:07:
[...]
In een ideale wereld zou ik liever geen datamodel van jou moeten onderhouden.

Niet alle entiteiten zijn hetzelfde. Eigenschappen verschillen, relaties verschillen, je krijgt redundantie en wazige checks overal etc. etc.
Met jouw logica is een DB met maar 1 tabel {id, object_type, blob} voldoende. En dergelijke tabellen heeft iedereen wel eens gemaakt cq. over nagedacht, maar gelukkig hebben de meesten daarvan geleerd.

[...]
Een post object is geen speciaal forum object (of vice versa, of met een gedeelde superclass), dus qua OO is dit niet imo ook geen briljant idee.

En hoe denk je dat Unix werkt? Elke directory is een file, en dat is exact hoe ik een forum-database zie: Als een tree-view.

Ik werk nu al weer vele jaren met databases, ik kan begrijpen dat je met een traditionele blik inderdaad het op jouw manier zult doen, maar als je echt vooruitstrevend bent ben je naar mijn mening beter uit met een enkele tabel.