[Alg] Slechtste programmeervoorbeelden deel 3

[TeeDee]

Kwastie schreef op dinsdag 09 september 2008 @ 17:23:
[...]
Ze hadden om z'n minst een error handler kunnen instellen die bijvoorbeeld errors in een log schrijft. En sowieso wil je niet dat je gebruikers fouten (met "technische informatie") voorgeschoteld krijgt.

Wat dacht je van een config setting op 1 van de ~1500 webservers vergeten in te stellen en dit pure debuginformatie is voor de developers? Dat je dit soort info niet bij de client wel lijkt me logisch, maar zoals ik al zei: dit lijkt me een een kleine config settting vergeten.

[ Voor 12% gewijzigd door TeeDee op 09-09-2008 17:33 ]

[Grijze Vos]

Hmm, Hyves...

Doet me denken aan het screenshot wat ik laatst onder ogen kreeg waarbij Hyves crashte en de DB login/password outputte...

[Anoniem: 50825]

Ik heb geen codevoorbeeld maar een verhaaltje:

In een van de applicaties die hier gebruikt wordt, wordt maandelijks een tekstbestand ingelezen. Dit bestand wordt gemaakt door een andere applicatie en verrijkt met gegevens uit een andere database. Dit verrijken wordt handmatig getriggerd door een van de beheerders die hier rondlopen.

Op een gegeven moment hebben we een rfc ingeschoten omdat we wat extra gegevens uit de verrijking in het bestand wilden hebben. Dit werd geregeld. Netjes getest, goed bevonden, in productie gegaan en ook daar draaide het goed.

De volgende maand zou de vernieuwde verrijking weer gedraaid gaan worden. Wat blijkt, krijgen we ineens weer de verrijking zoals hij was voor de aanpassing!

Ik weet niet hoe jullie hierover denken, maar als iets in productie staat, dan blijft het daar staan, totdat er orders zijn gegeven dat het eruit moet of mag. Als we daar al niet eens meer vanuit kunnen gaan, dan kunnen we wel inpakken.

[Anoniem: 178962]

Anoniem: 140111 schreef op dinsdag 09 september 2008 @ 17:10:
Er kan altijd wat blijven steken, maar Hyves is juist een technisch hoogstandje op het gebied van webtechniek. Het is niet alsof er geen bugs in andere productiesoftware voorkomen, nietwaar

Jij vind Hyves een technisch hoogstandje op het gebied van webtechniek, dat is wat anders.

En ik ben het niet met je eens, qua techniek stelt het niet zoveel voor, er zijn qua techniek veel betere website. Wat juist laat zien dat techniek niet alles is, die technisch betere sites zijn lang niet zo populair. Je moet zelf de balans zoeken aangezien voorop lopen qua techniek bakken met geld kost.

Dit is meer dan een bug, dit is gewoon een enorme security flaw en eigenlijk wel een beetje PHP security 101. Hell het staat zelfs in de config file zelf dat je geen errors moet weergeven in productieomgevingen.

[BramFokke]

Het ministerie van VWS doet misschien anders denken, maar apotheken wisselen al jaren informatie over medicatiedossiers uit middels een systeem dat OZIS heet. OZIS wisselt deze informatie uit middels Edifact-berichten die in e-mailtjes verstuurd worden. Ik heb ooit zo'n koppeling moeten implementeren en om een of andere reden kwam zo af en toe een berichtje niet aan. Uit onze database bleek dat de berichten wel degelijk verstuurd waren. De mailserver was gewoon up en het probleem kwam zo heel af en toe voor.

Toen we gingen kijken bij welke patiënten het mis ging, kwam de aap uit de mouw. Het ging altijd om mannen, meestal wat ouder. En altijd gebruikers van de medicatie waar je liever geen mail over krijgt: Het bleek dat de mailserver standaard een spamfilter had en alle berichtjes met 'Viagra' of 'Cialis' erin werden als spam gemarkeerd en genegeerd.

[Webgnome]

BramFokke schreef op dinsdag 09 september 2008 @ 18:22:
Het ministerie van VWS doet misschien anders denken, maar apotheken wisselen al jaren informatie over medicatiedossiers uit middels een systeem dat OZIS heet. OZIS wisselt deze informatie uit middels Edifact-berichten die in e-mailtjes verstuurd worden. Ik heb ooit zo'n koppeling moeten implementeren en om een of andere reden kwam zo af en toe een berichtje niet aan. Uit onze database bleek dat de berichten wel degelijk verstuurd waren. De mailserver was gewoon up en het probleem kwam zo heel af en toe voor.

Toen we gingen kijken bij welke patiënten het mis ging, kwam de aap uit de mouw. Het ging altijd om mannen, meestal wat ouder. En altijd gebruikers van de medicatie waar je liever geen mail over krijgt: Het bleek dat de mailserver standaard een spamfilter had en alle berichtjes met 'Viagra' of 'Cialis' erin werden als spam gemarkeerd en genegeerd.

Wat heeft dat te maken met programming? Dat is toch gewoon een implementatiefout?

[PV85]

Webgnome schreef op woensdag 10 september 2008 @ 08:48:
[...]


Wat heeft dat te maken met programming? Dat is toch gewoon een implementatiefout?

Ach maak je niet zo druk. Ik vind het wel een leuk weetje en een giller van een fout.

[Kettrick]

TeeDee schreef op dinsdag 09 september 2008 @ 17:32:
[...]

Wat dacht je van een config setting op 1 van de ~1500 webservers vergeten in te stellen en dit pure debuginformatie is voor de developers?

Dat hoort het in [Alg] Slechtste beheervoorbeelden deel 1 thuis. Als je met zo'n hoeveelheid servers werkt moet je van de config files afblijven .

[flashin]

Hyves heeft technisch best wel leuke dingen. Maar om het nou ECHT een hoogstandje te noemen vind ik echt mijlen te ver.

Met een hele gang vol met servers in evoswitch kan ik zoiets ook wel draaien.

[roy-t]

Ik kwam laatst een leuk UML programme bezig, werkt erg leuk aan de voorkant maar na een uurtje of 2 tekenen heb ik het programma afgesloten *(natuurlijk toen en tussendoor opgeslagen)

Volgende dag probeer ik het bestand te openen: "corrupt file".

Ik het bestand maar openen in Notepad en is het gelukkig een leesbaar XML bestand, ik vergelijk het met een nog werkend bestand en de opzet is precies hetzelfde, ook kan ik geen rare tekens of niet gesloten tags vinden.

Dan maar de source code erbij vanaf sourceforge.

OMG het hoofd bestand is 900lijnen lang en dat duwt alleen maar een beetje alles heen en weer er zijn verder tig klassen die allemaal op een of andere manier van elkaar erven en ook tjokvol staan met regels tekst. Na een stevige debugsessie (door de rare foutafhandeling kan ik niet direct vinden waar mijn XML bestand geparsed wordt en in welke regel het fout gaat.)

Uiteindelijk wat controle code geschreven om uit te vinden welke weg nu genomen wordt (het is echt een doolhof v/e programma).

Uiteindelijk kom ik erachter dat er de volgende fout is gemaakt, tijdens het saven van een properties van een interface (in het UML zeg maar) wordt er geen spatie toegevoegd achter de naam, het zit namelijk zo, ondanks dat het XML is wordt er gebruik gemaakt van stringparseing om een ObjectType, naam en overloads (getters en setters in dit geval) van elkaar te onderscheiden (meteen het nut van XML deels kwijt maargoed).

Door de spatie toe te voegen werkt het allemaal weer goed, maar ik heb nog nooit zo'n doolhof gezien, en dat allemaal voor zo'n simpel programma wat alleen UML's weergeeft (en ok ook C# code ervan genereerd maar dat deel van de code stond in een appart project en heb ik niet eens aangeraakt).

Maargoed: doolhof+bestanden met 900+ regels code+vreselijk onoverzichtelijk parsepad+voor elke simpel stringetje dat veranderd wordt een heel eventmanager doorlopen maakt het in mijn oge een slecht programmeer voorbeeld.

(ook was het XML gedeelte erg slecht, Objecten hadden geen Uniek ID maar werden gewoon in volgorde geparsed terwijl relaties pas later op kwamen en dan alles weer in volgorde gingen aflopen om de goede lijntjes te vinden. Imho veel beter als je gewoon een Class hebt met Id=1 en dan een relatie die zegt van id=1 naar id=2. Ipv opvolgorde te parsen.)

[P.O. Box]

hmm, zo had ik laatst een webservice waarbij in de te sturen XML een optional field stond... maar je moest dit veld dan wel weer verplicht meesturen (maar dan wel leeg)... vonnik nou niet echt logisch...

[AtleX]

@Roy-t: StarUML?

[HawVer]

Anoniem: 50825 schreef op dinsdag 09 september 2008 @ 17:54:
Ik heb geen codevoorbeeld maar een verhaaltje:

In een van de applicaties die hier gebruikt wordt, wordt maandelijks een tekstbestand ingelezen. Dit bestand wordt gemaakt door een andere applicatie en verrijkt met gegevens uit een andere database. Dit verrijken wordt handmatig getriggerd door een van de beheerders die hier rondlopen.

Op een gegeven moment hebben we een rfc ingeschoten omdat we wat extra gegevens uit de verrijking in het bestand wilden hebben. Dit werd geregeld. Netjes getest, goed bevonden, in productie gegaan en ook daar draaide het goed.

De volgende maand zou de vernieuwde verrijking weer gedraaid gaan worden. Wat blijkt, krijgen we ineens weer de verrijking zoals hij was voor de aanpassing!

Ik weet niet hoe jullie hierover denken, maar als iets in productie staat, dan blijft het daar staan, totdat er orders zijn gegeven dat het eruit moet of mag. Als we daar al niet eens meer vanuit kunnen gaan, dan kunnen we wel inpakken.

Klinkt bekend, wij hebben hier ook wel eens dat een oudere versie ineens over een nieuwe heengezet wordt. Dat is vooral een kwestie van zorgvuldig werken en versie beheer goed inrichten.

[MBV]

Edwardvb schreef op vrijdag 12 september 2008 @ 12:18:
hmm, zo had ik laatst een webservice waarbij in de te sturen XML een optional field stond... maar je moest dit veld dan wel weer verplicht meesturen (maar dan wel leeg)... vonnik nou niet echt logisch...

Moet je eens een interface willen schrijven naar de verzendsoftware van TNT. Je mag een CSV of een fixed-width ASCII file naar dat ding sturen. Een van de velden die je erin mag zetten is een XML-bestand met opties. Als je dat ding in CSV zet moet je de quotes escapen met nog een quote... En dan dat XML formaat, echt om te janken! ALs je een pakket met handtekening retour wil hebben, krijg je zoiets:

XML:

<packages>
<package id="1337">
  <meer info, gewicht enzo....>
</package>
<package id="1234" />
</packages>

Ehm, juist, heel erg human readable En wat ik heel onhandig vond, was dat je zelf je hele bestandsformaat moest definieren, qua kolomindeling enzo. Geef dan gewoon een voorbeeldbestand en een standaardindeling waar je vanaf mag wijken

[Patriot]

MBV schreef op vrijdag 12 september 2008 @ 13:33:
[...]

Moet je eens een interface willen schrijven naar de verzendsoftware van TNT. Je mag een CSV of een fixed-width ASCII file naar dat ding sturen. Een van de velden die je erin mag zetten is een XML-bestand met opties. Als je dat ding in CSV zet moet je de quotes escapen met nog een quote... En dan dat XML formaat, echt om te janken! ALs je een pakket met handtekening retour wil hebben, krijg je zoiets:

XML:

<packages>
<package id="1337">
  <meer info, gewicht enzo....>
</package>
<package id="1234" />
</packages>

Ehm, juist, heel erg human readable En wat ik heel onhandig vond, was dat je zelf je hele bestandsformaat moest definieren, qua kolomindeling enzo. Geef dan gewoon een voorbeeldbestand en een standaardindeling waar je vanaf mag wijken

Mis ik nu iets aan dat stukje XML, dat zit toch niet zo bizar in elkaar? Ik moet zeggen dat ik niet vreselijk vaak met XML werk hoor, dus misschien staat hier iets wat onwijs tegen de standaard in druist. Kan iemand dat even duidelijk maken?

[riezebosch]

Patriot schreef op vrijdag 12 september 2008 @ 13:45:
[...]


Mis ik nu iets aan dat stukje XML, dat zit toch niet zo bizar in elkaar? Ik moet zeggen dat ik niet vreselijk vaak met XML werk hoor, dus misschien staat hier iets wat onwijs tegen de standaard in druist. Kan iemand dat even duidelijk maken?

Regel 3 (denk ik, bij nader inzien is dat misschien alleen ter illustratie).

[ Voor 8% gewijzigd door riezebosch op 12-09-2008 14:19 ]

[Anoniem: 175502]

gevonden op de php.net site http://php.net/manual/en/function.unset.php

Here's my variation on the slightly dull unset method. It throws in a bit of 80's Stallone action spice into the mix. Enjoy!

PHP:

<?php
/**
 * function rambo (first blood)
 *
 * Completely and utterly destroys everything, returning the kill count of victims
 *
 * @param    It don't matter, it&#8217;s Rambo baby
 * @return    Integer    Body count (but any less than 500 and it's not really worth mentioning)
 */
function rambo() {

    // Get the victims and initiate that body count status
    $victims = func_get_args();
    $body_count = 0;   
   
    // Kill those damn punks
    foreach($victims as $victim) {
        if($death_and_suffering = @unset($victim)) {
            $body_count++;
        }
    }
   
    // How many kills did Rambo tally up on this mission?
    return($body_count);
}
?>

[roy-t]

AtleX schreef op vrijdag 12 september 2008 @ 12:22:
@Roy-t: StarUML?

NClass

[YopY]

Ten eerste:

roy-t schreef op vrijdag 12 september 2008 @ 12:09:
[blabla] 900 regels [/blabla]

Het aantal regels in een bestand is niet een graadmeter voor kwaliteit, leesbaarheid, functionaliteit of wat dan ook - je kunt hele mooie code kwijt in 900 regels code. Als dat per functie (oid) is dan is het echter wel veel.

Ik heb volgens mij liever spaghetticode dan lasagnecode btw (om maar een pasta-analogie te noemen), bij spaghetti staat teminste alles bij elkaar.

Ten tweede:

Anoniem: 175502 schreef op maandag 15 september 2008 @ 23:09:

PHP:

<?php
function rambo() {
// bla

is win.

[RobIII]

YopY schreef op dinsdag 16 september 2008 @ 14:09:
Ik heb volgens mij liever spaghetticode dan lasagnecode btw (om maar een pasta-analogie te noemen), bij spaghetti staat teminste alles bij elkaar.

Bij spaghetticode staat het juist niet bij elkaar en ik zie de analogie met lasagne niet tenzij je een meerlaagse structuur bedoelt die er juist is om componenten functioneel van elkaar te scheiden en groeperen.

edit: oeh er is ook een lasagnacode artikel. Nog nooit van gehoord Effe lezen
edit2: LOL; dan begreep ik 'm dus intuïtief toch goed

Alleen snap ik dan nog steeds niet hoe je met droge ogen durft te beweren liever spaghetticode te hebben (mja, "smaken" verschillen )

[ Voor 23% gewijzigd door RobIII op 16-09-2008 14:15 ]

[.oisyn]

offtopic:
The Paste Theory of Software omvat ook nog Ravioli code

[MBV]

Patriot schreef op vrijdag 12 september 2008 @ 13:45:
[...]


Mis ik nu iets aan dat stukje XML, dat zit toch niet zo bizar in elkaar? Ik moet zeggen dat ik niet vreselijk vaak met XML werk hoor, dus misschien staat hier iets wat onwijs tegen de standaard in druist. Kan iemand dat even duidelijk maken?

Ik verstuur 1 pakket. Om aan te geven dat dit een gewoon pakket is, met als optie dat de handtekening retour moet, moet ik 2x een package in het XML bestand zetten, met een 'magic' id. Ik zou hem zo maken:

XML:

<packages>
  <package>
     <handtekeningRetour />
     <!--meer gegevens -->
  </package>
 </packages>

en voor een pallet:

XML:

<packages>
 <pallet>
     <!--meer gegevens -->
  </pallet>
</packages>

en sowieso alle gegevens in XML zetten, niet een XML in CSV

[ Voor 4% gewijzigd door MBV op 16-09-2008 15:13 ]

[daniëlpunt]

PHP:

foreach ($items as $key => $value) {
    if (is_null($temp)) {
        $temp = array();
        $temp[] = do_something($value);
    } else {
        $temp[] = do_something($value);
    }
}

Het doet zijn werk wel, maar hoe.

[Sebazzz]

Letterlijk samples overnemen

[ Voor 9% gewijzigd door Sebazzz op 18-09-2008 14:31 ]

[.oisyn]

Het doet z'n werk helemaal niet. Wat nou als $temp daarvoor de waarde 5 had oid?

[Peedy]

Ik kom regelmatig in oude code van mezelf nog wat artifacts tegen...

PHP:

echo "".$blaat."";

is zo'n bekende. Heeft waarschijnlijk ooit wat voor/achter gestaan, en na het debuggen oid haal je dat dan weg, maar ik was vroeger niet zo netjes en dan blijft dit achter Net als overal mysql_fetch_object gebruiken ipv mysql_fetch_assoc waardoor ik nu soms problemen heb met OOP classes die $blaat->whatever op een andere manier interpreteren

[ Voor 24% gewijzigd door Peedy op 18-09-2008 15:36 ]

[Anoniem: 26351]

.oisyn schreef op donderdag 18 september 2008 @ 14:33:
Het doet z'n werk helemaal niet. Wat nou als $temp daarvoor de waarde 5 had oid?

dan verandert $temp geheel in PHP-stijl automagisch van type

In dit geval (int -> array) krijgt de progger 'Warning: Cannot use a scalar value as an array' te zien.
Op zich goed dat PHP een warning gooit, maar imo moet de php-progger z'n types in de gaten houden zodat $temp = 5; $temp[] = <iets>; niet voorkomt

Maar dit korte stukje code is waarschijnlijk flink uit zn context gerukt...want met enkel dit stukje code is weinig mis, behalve dan dat $temp niet duidelijk geinitialiseerd is, voordat de foreach() uitgevoerd wordt, wat een E_NOTICE melding oplevert en dat de else wat overbodig is.

[Scharnout]

Het leukst is lachen om jezelf natuurlijk. Ik heb zelf mijn site van asp door asp2php in php laten overzetten en ben nu alles langzaam werkend aan het maken, omdat ik geen zin tijd had om het allemaal even overnieuw te doen. Dat doe ik later wel, maar de asp-code is van de tijd dat ik net leerde programmeren en ik kom nu toch een mooie tegen.

PHP:

$locatieID = $_POST["locatieID"]
if ($locatieID==0){
//doet hier iets om $locatieID te genereren
} else{
  $locatieID=$locatieID;
}

Ok, toegegeven. In asp zag het er wat beter uit en ik moet hem nog omschrijven in iets wat wel goed is, maar het gaat hier even om het else-statement en vooral die vind ik van mezelf toch wel legendarisch stupide!

asp2php heeft ook leuk vautmeldingen als hij de asp-functies niet kent

PHP:

$functie_die_asp2php_niet_kent; // asp2php says 'huh'?: 

[ Voor 0% gewijzigd door Scharnout op 18-09-2008 16:17 . Reden: tikvaut ]

[.oisyn]

Anoniem: 26351 schreef op donderdag 18 september 2008 @ 15:57:
[...]


dan verandert $temp geheel in PHP-stijl automagisch van type

In dit geval (int -> array) krijgt de progger 'Warning: Cannot use a scalar value as an array' te zien.
Op zich goed dat PHP een warning gooit, maar imo moet de php-progger z'n types in de gaten houden zodat $temp = 5; $temp[] = <iets>; niet voorkomt

Maar dit korte stukje code is waarschijnlijk flink uit zn context gerukt...want met enkel dit stukje code is weinig mis, behalve dan dat $temp niet duidelijk geinitialiseerd is, voordat de foreach() uitgevoerd wordt, wat een E_NOTICE melding oplevert en dat de else wat overbodig is.

Ik denk helemaal niet dat deze code uit context is gehaald, en dat het juist om tracht te gaan met een ongeïntialiseerde $temp. Anders is de is_null() compleet nutteloos - de bug is dan ook dat er een is_array() mist:

PHP:

foreach ($items as $key => $value) { 
    if (is_null($temp) || !is_array($temp)) {  // nu werkt het wel
        $temp = array(); 
        $temp[] = do_something($value); 
    } else { 
        $temp[] = do_something($value); 
    } 
}

Echter, de code blijft natuurlijk een beetje loos zo. Doe dan gewoon:

PHP:

if (is_null($temp) || !is_array($temp))
    $temp = array();

foreach ($items as $key => $value)
    $temp[] = do_something($value); 
}

Of nog beter, iets met array_values().

[Anoniem: 26351]

.oisyn schreef op donderdag 18 september 2008 @ 16:43:
[...]

Echter, de code blijft natuurlijk een beetje loos zo. Doe dan gewoon:

PHP:

if (is_null($temp) || !is_array($temp))
    $temp = array();

foreach ($items as $key => $value)
    $temp[] = do_something($value); 
}

Of nog beter, iets met array_values().

Zonder een !isset($temp) levert dit nog steeds een E_NOTICE op
Ben het met je eens dat de originele code qua structuur nogal loos is.

[.oisyn]

Het ging me er niet om de notice weg te werken. Ik dacht eerlijk gezegd dat een [] op een int oid gewoon niet werkte.
.edit: en daarin had ik dus gelijk. Dus: right back at ya

[ Voor 21% gewijzigd door .oisyn op 18-09-2008 17:30 ]

[Anoniem: 26351]

.oisyn schreef op donderdag 18 september 2008 @ 17:25:
Het ging me er niet om de notice weg te werken. Ik dacht eerlijk gezegd dat een [] op een int oid gewoon niet werkte.
.edit: en daarin had ik dus gelijk. Dus: right back at ya

Inderdaad, dat postte ik ook al....zo'n 3 kwartier eerder

Anoniem: 26351 schreef op donderdag 18 september 2008 @ 15:57:
[...]

In dit geval (int -> array) krijgt de progger 'Warning: Cannot use a scalar value as an array' te zien.

kleffe boel hier

[Tanuki]

.oisyn schreef op donderdag 18 september 2008 @ 16:43:
[...]


Ik denk helemaal niet dat deze code uit context is gehaald, en dat het juist om tracht te gaan met een ongeïntialiseerde $temp. Anders is de is_null() compleet nutteloos - de bug is dan ook dat er een is_array() mist:

PHP:

foreach ($items as $key => $value) { 
    if (is_null($temp) || !is_array($temp)) {  // nu werkt het wel
        $temp = array(); 
        $temp[] = do_something($value); 
    } else { 
        $temp[] = do_something($value); 
    } 
}

Echter, de code blijft natuurlijk een beetje loos zo. Doe dan gewoon:

PHP:

if (is_null($temp) || !is_array($temp))
    $temp = array();

foreach ($items as $key => $value)
    $temp[] = do_something($value); 
}

Of nog beter, iets met array_values().

In PHP kijk je met isset() of een variabele al bestaat, niet met is_null().

Dus de correcte code is:

PHP:

foreach ($items as $key => $value)
{ 
    if (!isset($temp) || !is_array($temp))
    {
        $temp = array(); 
    } 
    $temp[] = do_something($value); 
}

En ik zou dan liever die if nog boven de foreach zetten.

[Anoniem: 178962]

Checken op null en kijken of een variabele geset is is natuurlijk compleet iets anders.

Welke er 'correct' is hangt helemaal van de situatie af, in PHP maakt het geen drol uit, zie ook: http://nl.php.net/manual/en/types.comparisons.php

Het voordeel wat is_null dan heeft is dat het ook op functies gebruikt kan worden.

[ Voor 17% gewijzigd door Anoniem: 178962 op 23-09-2008 23:43 ]

[TeeDee]

Uhm, volgens mij is !isset hetzelfde als is_null. Als we dan toch gaan zeveren: volgens mij kan je dat weer verder evalueren naar === null.

Anoniem: 178962 schreef op woensdag 24 september 2008 @ 00:03:
[...]

Jup, daarom zeg ik: Onder PHP maakt het geen drol uit.

Zoals staat op de pagina waarvan ik een link gaf

Och, tijdstip en niet refreshen

[ Voor 49% gewijzigd door TeeDee op 24-09-2008 15:59 ]

[Anoniem: 178962]

TeeDee schreef op dinsdag 23 september 2008 @ 23:47:
Uhm, volgens mij is !isset hetzelfde als is_null. Als we dan toch gaan zeveren: volgens mij kan je dat weer verder evalueren naar === null.

Jup, daarom zeg ik: Onder PHP maakt het geen drol uit.

Zoals staat op de pagina waarvan ik een link gaf

[Michali]

Maakt toch zeker wel een drol uit. Als je is_null over een daadwerkelijk niet bestaande variabel heen haalt, dan krijg je een warning notice. Dat is met isset niet het geval.

Verder is isset een taalconstructie, en geen functie. Je kunt hem dus alleen direct gebruiken, en niet als callback gebruiken of als variabele functie aanroepen. Ook kun je als waarde alleen een variabel meegeven, niet bijvoorbeeld de returnwaarde van een functie. Dit kan bij is_null wel.

[ Voor 47% gewijzigd door Michali op 24-09-2008 09:01 ]

[Anoniem: 260596]

Mogen domme foutjes ook?

Heb ik 2 dagen zitten zoeken op wat de fout hier kon zijn;

Delphi:

tempString := MidStr(tempString, nameIndex1, (nameIndex2 - nameIndex2));

Dat was een tijdrovende typo

Ook vergeet ik regelmatig de result op het einde va neen functie, en ik maar debuggen.

[Anoniem: 178962]

Anoniem: 260596 schreef op woensdag 24 september 2008 @ 14:45:
Ook vergeet ik regelmatig de result op het einde va neen functie, en ik maar debuggen.

Dat doet iedereen volgens mij wel eens, een geniale functie schrijven en dan de return vergeten

[RobIII]

Anoniem: 178962 schreef op woensdag 24 september 2008 @ 15:13:
[...]

Dat doet iedereen volgens mij wel eens, een geniale functie schrijven en dan de return vergeten

Een beetje IDE waarschuwt dan ook dat er geen return value is

[Sebazzz]

RobIII schreef op woensdag 24 september 2008 @ 15:14:
[...]

Een beetje IDE waarschuwt dan ook dat er geen return value is

Sterker nog: Een C# code zal niet eens compileren. Raar dat Java dat wel doet dan

[ Voor 6% gewijzigd door Sebazzz op 24-09-2008 15:22 ]

[Hydra]

Sebazzz schreef op woensdag 24 september 2008 @ 15:21:
Sterker nog: Een C# code zal niet eens compileren. Raar dat Java dat wel doet dan

Java compiled zeer zeker niet met een niet-void functie zonder return waarde.

[Robtimus]

Dit is dan ook een Delphi functie, maar ook Delphi hoort gewoon te waarschuwen (nadruk op waarschuwen, het compilet wel). Dat doet hij bij mij iig wel.

[Sebazzz]

Ow, Delphi dan...

[Erkens]

Als je eerst het raamwerk (iets wat veel IDE's ook doen) van je functie maakt heb je dus al "een" return-value en zal je dus ook geen warnings/errors krijgen hierover

[kenneth]

Het kan best hoor

C#:

        public bool AreWeHappy(string foo)
        {
            bool retval = false;

            if (String.IsNullOrEmpty(foo))
            {
                return retval;
            }

            if (foo == "bar")
            {
                // Do some magic

                retval = true;
            }

            if (foo.Length == 3)
            {
                // Do some more magic

                // forget to set retval
            }

            return retval;
        }

[glmona]

kenneth schreef op woensdag 24 september 2008 @ 15:35:
Het kan best hoor

C#:

        public bool AreWeHappy(string foo)
        {
            bool retval = false;

            if (String.IsNullOrEmpty(foo))
            {
                return retval;
            }

            if (foo == "bar")
            {
                // Do some magic

                retval = true;
            }

            if (foo.Length == 3)
            {
                // Do some more magic

                // forget to set retval
            }

            return retval;
        }

Deze returned toch gewoon 'false"

[kenneth]

Maar als je wil dat bij een drieletterige waarde in foo hij true retourneert, dan gaat hij fout bij iedere string, behalve "bar"

[glmona]

Hoezo retVal is toch al gezet op false, dat er daarna niks mee gebeurt is toch geen probleem?

Edit:
Laat maar, ligt er natuurlijk aan wat je verwacht, maar er is wel een return value... Alleen niet de 'true' die je verwacht...

[ Voor 44% gewijzigd door glmona op 24-09-2008 15:43 ]

[kenneth]

Ja okay, syntactisch is er een return, maar semantisch niet ... ligt net aan hoe je het interpreteert

[glmona]

kenneth schreef op woensdag 24 september 2008 @ 15:44:
Ja okay, syntactisch is er een return, maar semantisch niet ... ligt net aan hoe je het interpreteert

Daar ging het toch over hierboven. Dat java dit niet accepteert als er geen waarde is...

[Anoniem: 178962]

Inderdaad, menig programmeur zal werken met een retval variabele welke een default waarde mee krijgt. Op die manier kan de IDE en de compiler je niet redden als de return waarde dan niet geset wordt.

Maar goed, als je van jezelf weet dat je zoiets vaak vergeet ben je er met debuggen ook heel snel achter.

[HawVer]

Dat komt omdat Delphi de return waarde als een variabele (Result) behandelt. De result waarde kun je instellen zonder meteen uit de functie te springen. De praktijk wijst uit dat dit erg vaak spaghetti code oplevert. Zonder de result waarde te initialiseren kan er van alles in terecht komen. Dat kan erg interessante bugs opleveren.

[kenneth]

Net als in VB dus, waar de returnvalue de naam van de functie is

[Hydra]

kenneth schreef op woensdag 24 september 2008 @ 15:35:
Het kan best hoor

Er wordt gewoon nogsteeds een waarde geretourneerd. Dus syntactics is er niks mis met de code. Dat je een stuk 'vergeet' is compleet wat anders.

Anoniem: 178962 schreef op woensdag 24 september 2008 @ 15:48:
Inderdaad, menig programmeur zal werken met een retval variabele welke een default waarde mee krijgt. Op die manier kan de IDE en de compiler je niet redden als de return waarde dan niet geset wordt.

Dan is die mijnheer 'menig' danook gewoon fout bezig. Het is gewoon fout een default waarde in te stellen als deze niet nodig is/gebruikt wordt.

[ Voor 45% gewijzigd door Hydra op 24-09-2008 19:02 ]

[Anoniem: 178962]

Mwah, daar ben ik het niet mee eens.

Zoals het voorbeeld van kenneth vind ik gewoon nette code.
Het is dan ook zeker nodig en wordt gewoon gebruikt.

[ Voor 21% gewijzigd door Anoniem: 178962 op 24-09-2008 19:05 ]

[Creepy]

Anoniem: 178962 schreef op woensdag 24 september 2008 @ 19:04:
Mwah, daar ben ik het niet mee eens.

Zoals het voorbeeld van kenneth vind ik gewoon nette code.
Het is dan ook zeker nodig en wordt gewoon gebruikt.

Dat vindt je nette code? Of return direct, of gebruik een return variabele en return alleen aan het einde van je functie, maar ga dat niet door elkaar gebruiken (wat in het voorbeeld gebeurd).

[MBV]

Ach, als dat het voorbeeld van slecht programmeerwerk is, dan kan ik hier de hele PHP-codebase van mijn werkgever wel dumpen. En dan maak ik me totaal geen zorgen over de manier van returnen, ik weet nog wel wat ergere dingen

[Creepy]

Je mag inderdaad blij zijn als dat alles is ja

[418O2]

PHP is sowieso een slecht programmeervoorbeeld

[Jasperrr]

418O2 schreef op woensdag 24 september 2008 @ 20:31:
PHP is sowieso een slecht programmeervoorbeeld

Dus jij hebt liever ASP?

[418O2]

werk ik nu wel mee (de .net variant). Ik vond php altijd heel geslaagd, maar nu ik met C# en asp.net werk begin ik wel steeds meer te zien dat php niet 100% een programmeertaal is. Ik programmeerde vrij laks in php, maar dat kan ook en daardoor maak je rare constructies die later niet blijken te werken.

[prototype]

Return gewoon direct mensen, het is leesbaarder (+ makkelijker te debuggen) en scheelt een lokale variabele en jump instructie

[ Voor 12% gewijzigd door prototype op 24-09-2008 21:10 ]

[Sebazzz]

418O2 schreef op woensdag 24 september 2008 @ 20:39:
werk ik nu wel mee (de .net variant). Ik vond php altijd heel geslaagd, maar nu ik met C# en asp.net werk begin ik wel steeds meer te zien dat php niet 100% een programmeertaal is. Ik programmeerde vrij laks in php, maar dat kan ook en daardoor maak je rare constructies die later niet blijken te werken.

Ja. Dat ben ik het ook mee eens. Ik vond PHP echt de heilige graal wat webprogrammeren betreft, en ASP een achterlopertje (niet .NET). Maar nu ik steeds meer met C#/.NET werk ben ik wel teleurgesteld in PHP, bijvoorbeeld dat er standaard geen MySQL object is en dat soort dingen. Met ASP.NET kunnen dat soort dingen prima en kan je ook nog eens C# gebruiken, wat wil je nog meer...

prototype schreef op woensdag 24 september 2008 @ 21:10:
makkelijker te debuggen

Met Visual Studio is geen code niet te debuggen (maar je punt staat hoor )

[ Voor 16% gewijzigd door Sebazzz op 24-09-2008 21:42 ]

[Anoniem: 178962]

Creepy schreef op woensdag 24 september 2008 @ 20:03:
[...]

Dat vindt je nette code? Of return direct, of gebruik een return variabele en return alleen aan het einde van je functie, maar ga dat niet door elkaar gebruiken (wat in het voorbeeld gebeurd).

Mwah dat voorbeeld is natuurlijk erg kort door de bocht, maar stel je hebt zoiets:

code:

function foo(bar) {
 retval = 0
 if (bar > 5) {
  // extreem ingewikkelde formules die retval setten adhv bar ofzo
 }
 if (retval < 5) {
  // nog wat extreme formules met retval en andere zaken
 }
 if (retval == 0) {
  // shit 0 is een probleem
  return retval // <--- vergeet je dan bijvoorbeeld
 }
 // nog wat moeilijks wat niet gedaan mag worden als retval 0 is
 if (retval > 5) {
  // doe nog iets met retval
  return retval
 }
 // nog iets
 return retval
}

Dan vind ik dat een goede manier om het op te lossen, het hangt nogal van de situatie af natuurlijk.

[ Voor 7% gewijzigd door Anoniem: 178962 op 24-09-2008 21:45 ]

[kenneth]

Creepy schreef op woensdag 24 september 2008 @ 20:03:
[...]

Dat vindt je nette code? Of return direct, of gebruik een return variabele en return alleen aan het einde van je functie, maar ga dat niet door elkaar gebruiken (wat in het voorbeeld gebeurd).

Wat zou jij dan doen met guard clauses? Ik ben op zich voor één return punt, maar ik ga niet een hele functie doorlopen als ik al weet dat ik niks heb aan een null value, anders krijg je van die nutteloze nesting:

C#:

public int functie(string a, string b)
{
    int retval;
    
    if (!(a.IsNullOrEmpty() && b.IsNullOrEmpty))
    {
        // functie

        // ...

        // nog meer regels

        // ....
        
        retval = 42;
    }
    else
    {
        // ohja, we moeten die nullwaardes nog afhandelen ...

        retval = 0;
    }
    
    return retval;
}

Dan heb ik liever:

C#:

public int functie(string a, string b)
{
    int retval;
    
    if (a.IsNullOrEmpty() || b.IsNullOrEmpty)
    {
        return 0;
    }
    
    // zo, checks gehad, we kunnen nu gewoon verder
    
    // ...
    
        retval = 42;
    
    // ...
    
    return retval;
}

Even los van het feit dat je in dit specifieke geval misschien een ArgumentException zou gebruiken.

Waar je wel meerdere exit points hebt, maar toch een mooie scheiding tussen je guard clauses en de feitelijke functie.

[Anoniem: 178962]

Of de situatie waarbij retval een verzameling is die je op meerdere manieren vanuit meerdere bronnen moet vullen.

Tis toch wel een vrij standaard iets zegmaar.

[prototype]

@Kenneth die zogenaamde guard clauses die jij noemt zijn (vaak) gewoon precondities. Met design by contract en met seperations of concern in 't achterhoofd zou je die niet moeten verweven in je business logics om mee te beginnen. In plaats daarvan zou je moeten overwegen om het mee te nemen als meta data of als een aspect die dient gedraaid te worden voordat de methode aangeroepen wordt.

In het algemeen echter, als je uiteindelijk toch eindigt met meerdere clausules die verschillende returns kunnen opwekken, zou je kritisch naar je code moeten kijken om te zien of je niet het e.e.a. kan refactoren naar hulp methoden. ipv:

C#:

public int foo(string a, string b) {
    if(someguard) {
        //hele lap code
        return retval;
    } else {
        //hele lap code
        return retval + 1;
    }
}

doe je:

C#:

public int foo(string a, string b) {
    if(someguard) {
        return this.someFoo();
    }

   return this.someOtherFoo();
}

Code dien je gewoon zo georganiseerd en kort (niet te natuurlijk) mogelijk te houden om 't leesbaar en onderhoudbaar te houden. Om het nogmaals te benadrukken, dat direct returnen maakt een stacktrace bestuderen vele malen eenvoudiger. Als je een single return gebruikt binnen elke functie is 't nog steeds niet deterministisch welke branch die return heeft veroorzaakt als je de stacktrace bekijkt en op regelnummer afgaat (je krijgt altijd diezelfde return regel en moet zelf nagaan welke guards zijn getriggered om tot die value te komen). Vele malen lastiger om te debuggen imho dan gewoon meteen zien op welke regel de meer deterministische directe return staat.

[Patriot]

Ok, ik ben vandaag toch iets tegengekomen. Kijk dit eens:

PHP:

<?php

$sqlstring = "UPDATE `" . mysession("targettable") . "` SET ";
$sqlboolean = " ";

//print_r($_POST);

foreach($_POST as $colname => $value){
   if (substr(strtolower($colname), 0, 3) == "col") {
      $sqlstring .= $sqlboolean . " `" . substr($colname, 6) . "` = " . savesql(substr($colname,3,3), $value);
      $sqlboolean = ", ";
   }
}
$sqlstring .= " WHERE id=" . $targetid;

?>

Dat is overigens niet alles, de gehele website is echt één grote What The Fuck. Ik ben nog NOOIT zulke troep tegen gekomen.

[ Voor 9% gewijzigd door Patriot op 29-09-2008 19:31 ]

[Megamind]

Dat is wel erg algebra ja Lekker veilig ook...

[Anoniem: 178962]

Vooral nog ff die safvesql aanroepen

[Patriot]

Nog wat leuke voorbeeldjes.

PHP:

function cstr($val) {
  return (isset($val)) ? $val : "";
}

Wat zou hij gedacht hebben toen hij dit schreef..

PHP:

function notnull($thisinput){
   if (isset($thisinput)) {
      return $thisinput;
   } else {
      return '';
   }
}

Nog één, en hier gebruikt hij hem:

PHP:

function myhtml($thisinput){
   $thisinput = NotNull($thisinput);
   $thisinput = str_replace("'", 'html_entity_voor_enkele_quote', $thisinput);
   return str_replace('"', 'html_entity_voor_dubbele_quote', $thisinput);
}

Euhh..?

offtopic:
Hij gebruikt de echte entities, maar dat vind GoT niet leuk

Nouja, dacht alles wel gehad te hebben: Wat rare functies, en een zeer vreemde manier van updaten van tabellen. Die manier was dan wel onveilig, maar dat gebeurde in een redelijk goed beveiligde omgeving dus zo erg was het niet.

Even verder gekeken snapte ik er echter ook geen snars van. Het openen van databases (althans, naar de functienamen gekeken) gebeurde echt de vreemdste dingen. Variabelen die uit het niets leken te verschijnen, en vreemde functies: Ik volgde het niet. Toch eens kijken hoe hij dat geregeld heeft. Ah, een bestandje db_utils.php, eens zien. Kijkt en huiver over wat ik aantrof:

In de algemene config:

PHP:

$RS = ''; 
$RSARRAY = ''; 
$CONN = '';

En vervolgens dan db_utils.php:

PHP:

function Db_Open($sqlstring) {
   Db_OpenY($sqlstring, true);
}

function Db_OpenW($sqlstring) {
   Db_OpenY($sqlstring, false);
}

function Db_OpenReturnResultset($sqlstring) {
   global $RS, $CONN, $DSNNAAM;
   $rs2 = Db_OpenX($CONN, $DSNNAAM, $sqlstring);
   
   return $rs2;
}

function Db_OpenY($sqlstring, $do_open) {
   global $RS, $CONN, $DSNNAAM, $rs;
   $RS = Db_OpenX($CONN, $DSNNAAM, $sqlstring);
   if ((mysql_num_rows($RS) != 0) && ($do_open)){
      $rs = mysql_fetch_assoc($RS);
   }
}

function Db_OpenX($connname, $srcname, $sqlstring) {
   Db_OpenConn($connname, $srcname);
   $hulp = mysql_query($sqlstring);
   if (!$hulp) {
      die("ongeldige query met sqlstring <br>$sqlstring");
   }
   return $hulp;
}

function Db_OpenConn($connname, $srcname) {
   global $DBUN, $DBPW, $DBHOST;
   $connname = mysql_connect($DBHOST, $DBUN, $DBPW) or die("Kan geen verbinding maken<br>");
   mysql_select_db($srcname, $connname) or die("Kan database '$srcname' niet selecteren<br>");
}

function Db_GetNewId($tablename) {
   global $DSNNAAM;
   return Db_GetNewIdSource($DSNNAAM, $tablename);
}

function Db_GetNewIdSource($srcname, $tablename) {
   $tempconn = '';
   Db_OpenConn($tempconn, $srcname);
   mysql_query("INSERT INTO `$tablename` (id) VALUES (NULL)");
   return mysql_insert_id();
}

function Db_OpenArray($sqlstring){
   global $DSNNAAM, $RSARRAY;
   $RSARRAY = Db_OpenArraySource($DSNNAAM, $sqlstring);
}

function Db_OpenArraySource($srcname, $sqlstring){
   global $CONN;
   return Db_OpenArrayX($CONN, $srcname, $sqlstring);
}

function Db_OpenArrayX($connname, $srcname, $sqlstring){
   $tempopenrsarray = Db_OpenX($connname, $srcname, $sqlstring);
   if (mysql_num_rows($tempopenrsarray) == 0) {
      $thisarray = array();
   } else {
      while($row = mysql_fetch_assoc($tempopenrsarray)) {
         $thisarray[] = $row;
      }
   }
   return $thisarray;
}

function Db_Get_Value_X($srcname, $sqlstring, $thisfield) {
   $newconn = '';
   $NEWRS = Db_OpenX($newconn, $srcname, $sqlstring);
   if (mysql_num_rows($NEWRS) != 0) {
      $newrs = mysql_fetch_assoc($NEWRS);
      return $newrs[$thisfield];
   }
   return Null;
}

Ik weet dat het een flinke brok is, maar wilde het toch echt allemaal even laten zien. Er moet toch iemand wel zwaar aan de hallucinerende middelen geweest zijn om dit soort zooi te produceren

[Anoniem: 156876]

Haha, dat is wel héééél erg.

Kan nu zo 1-2-3 niks vinden van mezelf, weet wel dat 'k een aantal jaar geleden flink wat grappige "php"-code gemaakt heb. Zal binnenkort eens mijn archief opentrekken, dan kunnen we ook weer lachen.

[Anoniem: 178962]

WTF echt... dan ben je echt ver weg inderdaad.

[Wijnbo]

Vooral:

PHP:

function Db_GetNewIdSource($srcname, $tablename) { 
   $tempconn = ''; 
   Db_OpenConn($tempconn, $srcname); 
   mysql_query("INSERT INTO `$tablename` (id) VALUES (NULL)"); 
   return mysql_insert_id(); 
}

Jezus! !

[Sebazzz]

Ik heb een keer een complete website voor mezelf (portofolio, index, gastenboek, nieuwsberichten) gemaakt in één php pagina gemaakt. Inclusief data opslag in PHP commentaar Jammer dat ik niet de code meer heb maar ik vond het een prachtig stukje slim én dom programmeren.

[Anoniem: 156876]

Sebazzz schreef op maandag 29 september 2008 @ 21:28:
Ik heb een keer een complete website voor mezelf (portofolio, index, gastenboek, nieuwsberichten) gemaakt in één php pagina gemaakt. Inclusief data opslag in PHP commentaar Jammer dat ik niet de code meer heb maar ik vond het een prachtig stukje slim én dom programmeren.

Zou je dat even toe kunnen lichten? en dan vooral dat slimme gedeelte

[StephanVierkant]

PHP:

<?php
if ($page == "gastenboek")
{
echo "welkom in mijn gastenboek!";
}
elseif($page == "contact")
{
echo "contactpagina";
}
?>

zoiets?

[SyphOn]

Kwam ik laatst tegen

PHP:

function db_foo ($query, $join = "")  {
 //Hele $query werd uit elkaar gesloopt, vervolgens de join er bij in gefrut, dan weer in elkaar gezet en aan mysql gevoerd
}

[ Voor 6% gewijzigd door SyphOn op 29-09-2008 22:26 ]

[Anoniem: 156876]

Stephan4kant schreef op maandag 29 september 2008 @ 21:55:

PHP:

<?php
if ($page == "gastenboek")
{
echo "welkom in mijn gastenboek!";
}
elseif($page == "contact")
{
echo "contactpagina";
}
?>

zoiets?

En het is slim om alle code in één file te gooien?

[Sebazzz]

Het slimme eraan vind ik dat ik het voor elkaar kreeg om alles inclusief data opslag in één php bestand te krijgen.
Bovenaan het bestand stond een simpele HTML header, daaronder een switch die calls naar functies deed die de pagina verzorgden. En onderaan de footer.

[Webgnome]

Sebazzz schreef op dinsdag 30 september 2008 @ 07:53:
Het slimme eraan vind ik dat ik het voor elkaar kreeg om alles inclusief data opslag in één php bestand te krijgen.
Bovenaan het bestand stond een simpele HTML header, daaronder een switch die calls naar functies deed die de pagina verzorgden. En onderaan de footer.

Dat is toch niet slim? Zo heel erg lastig is dat helemaal niet. Dus ik zie niet in wat er slim aan is? Al zou ik wel kunnen indenken dat dit soort code in een controller object komt wat de juiste url aan de juiste objeten knoopt.

[!null]

Daar heb je juist includes voor om dingen maar 1 keer te schrijven (want dat is wat je wil) en je files toch overzichtelijk te houden.

[Anoniem: 84120]

Sebazzz schreef op maandag 29 september 2008 @ 21:28:
... maar ik vond het een prachtig stukje slim én dom programmeren.

Volgens mij had Sebazzz wel door dat het wat onoverzichtelijker was. Wat ook wel te verwachten is dat iet iets door heeft (Slechtste topic ).

[Anoniem: 156876]

Anoniem: 84120 schreef op dinsdag 30 september 2008 @ 09:27:
Volgens mij had Sebazzz wel door dat het wat onoverzichtelijker was. Wat ook wel te verwachten is dat iet iets door heeft (Slechtste topic ).

Dat domme was iedereen het wel over eens, denk ik, waar ik het over had is:

Sebazzz schreef op maandag 29 september 2008 @ 21:28:
... maar ik vond het een prachtig stukje slim én dom programmeren.

Het slimme ervan, dat begreep ik even niet...

[Anoniem: 178962]

Het slimme was dat ie een bizarre rommelcode had geschreven maar het resultaat uiteindelijk wel werkte.

Hoe erge rommel het was kun je natuurlijk niet zomaar weergeven in een simpel voorbeeld omdat dat zegmaar simpel is

[Anoniem: 156876]

Anoniem: 178962 schreef op dinsdag 30 september 2008 @ 22:00:
Het slimme was dat ie een bizarre rommelcode had geschreven maar het resultaat uiteindelijk wel werkte.

Hoe erge rommel het was kun je natuurlijk niet zomaar weergeven in een simpel voorbeeld omdat dat zegmaar simpel is

Dan is 95% van de dingen die in dit topic voorkomt "slim"..?

[terabyte]

Ik blader door dit topic, en mijn ogen beginnen spontaan te bloeden.
Wat zijn programmeertalen zoals PHP toch ontzettend vies, als je de elegantie van Python of Haskell gewend bent.
En dan te bedenken dat er dagelijks duizenden mensen bezig zijn met het produceren van dergelijke code en gewoon niet beter weten

[MueR]

Wat heeft je opmerking weinig toe te voegen aan dit topic, als je de gemiddelde user gewend bent.

Of, om het anders te zeggen, lul niet. De taal heeft er geen bal mee te maken. Het feit dat sites als phpfreakz en weet ik wat nog meer voor slechte sites mensen "php leren" , in cursussen geschreven door mensen die net hun "PHP in 24 uur" uit hebben, is hier debet aan. Sommige mensen houden nou eenmaal van toegankelijke talen. Anderen houden van python of haskell en verkloten het daar ook grandioos mee. De kwaliteit en kennis van de programmeur is niet gerelateerd aan de taal waarmee gewerkt wordt.

[Anoniem: 178962]

Anoniem: 156876 schreef op dinsdag 30 september 2008 @ 22:03:
[...]

Dan is 95% van de dingen die in dit topic voorkomt "slim"..?

Sommige dingen zijn misschien wel geniaal, ze zeggen altijd dat de grens tussen krankzinnig en geniaal maar heel klein is

@Terabyte:
Boehoe, dat komt omdat de taal er geen zak mee te maken heeft zoals hier al gezegd wordt. Daarnaast boeit het geen flikker hoe de code eruit ziet, het gaat om het eindresultaat. Al zou het in PHP alleen mogelijk zijn om lelijke en brakke code te produceren (wat ik dus niet geloof) dan is de site waar je nu op zit al het bewijs dat het niets boeit voor het eindresultaat.

Beter een goed uitgedachte website met een strak design, goede flow, goede content en brakke code dan een website met mooie code maar verder niets. De gebruiker kan je code niet zien ofzo hoor...

[ Voor 48% gewijzigd door Anoniem: 178962 op 30-09-2008 22:20 ]

[terabyte]

Anoniem: 178962 schreef op dinsdag 30 september 2008 @ 22:17:
[...]

Beter een goed uitgedachte website met een strak design, goede flow, goede content en brakke code dan een website met mooie code maar verder niets. De gebruiker kan je code niet zien ofzo hoor...

Zo'n website met veel flash ('strak design'), lage performance ('brakke code'), ononderhoudbaar (''Beter een goed uitgedachte website met [...] brakke code') en alleen werkend in IE ('Beter een goed uitgedachte website met [...] brakke code')?

[writser]

terabyte schreef op dinsdag 30 september 2008 @ 22:09:
Ik blader door dit topic, en mijn ogen beginnen spontaan te bloeden.
Wat zijn programmeertalen zoals PHP toch ontzettend vies, als je de elegantie van Python of Haskell gewend bent.

Tja. De leercurves voor die talen zijn nou eenmaal wat hoger (in elk geval als je er iets nuttigs mee wil maken).

[ Voor 6% gewijzigd door writser op 30-09-2008 22:51 ]

[!null]

PHP kan heel smerig gebruikt worden, maar als je een beetje je best doet kan je er prima nette code mee schrijven en de boel structureel goed in delen, en het ook nog snel laten zijn. Verder snap ik niet wat dingen zoals strak design en IE-only rotzooi met PHP te maken heeft.

[Anoniem: 178962]

terabyte schreef op dinsdag 30 september 2008 @ 22:48:
[...]

Zo'n website met veel flash ('strak design'), lage performance ('brakke code'), ononderhoudbaar (''Beter een goed uitgedachte website met [...] brakke code') en alleen werkend in IE ('Beter een goed uitgedachte website met [...] brakke code')?

Leg me geen woorden in de mond aub. Dat jij er rare definities op nahoudt moet je helemaal zelf weten.

[TeeDee]

terabyte schreef op dinsdag 30 september 2008 @ 22:48:
[...]

Zo'n website met veel flash ('strak design'), lage performance ('brakke code'), ononderhoudbaar (''Beter een goed uitgedachte website met [...] brakke code') en alleen werkend in IE ('Beter een goed uitgedachte website met [...] brakke code')?

If you assume, you make an ass out of you and me. Of, assumption is the mother of all... etc.

Beter gezegd, en ik zie dat TRRoads dat al aangeeft: waar haal je flash, IE, performance, onderhoudbaar en weet ik veel wat nog meer uit zijn reactie weg?

[Anoniem: 59888]

Wat terabyte m.i. bedoelt (verbeter me als ik er naast zit) is dat nette code net zo goed deel uitmaakt van een goede applicatie als de interface en de flow. Ter vergelijking: een automobilist hoeft ook niet onder de motorkap te kijken. Je kunt een auto nog zo mooi maken en het interieur nog zo comfortabel, maar als de motor niet presteert en om de haverklap afslaat dan koop je toch liever een auto waar wel een goede motor in zit. Het ontwerp kan nog zo mooi zijn maar als de code slecht is dan merkt de eindgebruiker dat heus wel.

[Nick_S]

Vandaag ook weer tegen een stukje ononderhoudbare code aangelopen:

code:

public void process(com.example.bla.Type type1, com.example.foo.Type type2) {
   if (type1 != null) {
        //zo'n 200 regels code
    } else if (type2 != null) {
        // zo'n 200 regels code, met heel veel code copy en weinig overzicht wat er nu anders is als type1.
    }
}

Een klein beetje refactoren mag op z'n tijd wel...

Of nog een ander diamantje:

Java:

Map<String, String> aMap = new HashMap<String, String>();
aMap = callMethodWhichReturnsAMap();

[ Voor 15% gewijzigd door Nick_S op 01-10-2008 00:47 ]

[Anoniem: 178962]

Anoniem: 59888 schreef op woensdag 01 oktober 2008 @ 00:36:
Wat terabyte m.i. bedoelt (verbeter me als ik er naast zit) is dat nette code net zo goed deel uitmaakt van een goede applicatie als de interface en de flow. Ter vergelijking: een automobilist hoeft ook niet onder de motorkap te kijken. Je kunt een auto nog zo mooi maken en het interieur nog zo comfortabel, maar als de motor niet presteert en om de haverklap afslaat dan koop je toch liever een auto waar wel een goede motor in zit. Het ontwerp kan nog zo mooi zijn maar als de code slecht is dan merkt de eindgebruiker dat heus wel.

Mwah, het is maar de vraag in hoeverre de eindgebruiker iets merkt natuurlijk.

Je hebt code die gewoon echt fout is en niet werkt, maar die code komt meestal niet in dit topic terecht (immers zien zelfs de slechtste programmeurs wel dat code echt niets doet).

De code in dit topic bevat meestal wel bugs (vooral beveiligingslekken), maar ook super goede code bevat vaak bugs. Sterker nog, neem even een kijkje in het LD forum en zie dat zelfs de (IMHO goede) programmeurs van t.net en React bugs in hun software hebben.

De performance van brakke code zal niet 100% optimaal zijn, maar echt heel slecht performance zal het ook weer niet (dat merkt de slechte programmeur immers ook wel). Echt heel spannend zijn de database zaken die de slechte programmeurs doen ook weer niet dus de performance zal daar over het algemeen te doen zijn.

Kijk bijvoorbeeld even naar FoK, op zich prima code (denk ik, ik kan het niet zien natuurlijk), maar door de groei werd het op een gegeven moment onwerkbaar traag. Maakte dat de gebruikers iets uit? Nee, FoK groeide maar door en door.

Om de analogie met auto's even door te trekken: Hoeveel mensen rijden er wel niet in oude rotte bakken die op een koude ochtend een half uur doen om te starten, amper wegkomen bij het stoplicht etc. Het boeit mensen simpelweg niet, als het doet wat het moet doen is het prima.

Zodoende boeit het mensen ook echt niet als de performance niet optimaal is en zelfs het design komt niet heel kritisch (soms zie je sites die echt lelijk zijn maar toch mega populair, kijk bijvoorbeeld even naar xtremesystems.org).

Er zijn natuurlijk extremen, als je site echt onwerkbaar is vanwege de bugs of een week aan een stuk eruit ligt (hoewel t.net ook 36 uur eruit lag bij BC3?), dan kan het wel killing zijn. Maar over het algemeen zijn het toch hele andere zaken die een site een hit or miss maken.

Het is dan dus ook zinloos om super veel moeite te stoppen in de code als de rest niet in orde is (als je alles in orde kunt krijgen is het natuurlijk wel goed, maar dat is een utopie). Dat maakt het dat PHP wel gebruikt wordt , inclusief alle brakke code gemaakt door dwalende programmeurs, voor heel erg succesvolle websites.

Zaken als performance, onderhoudbaarheid etc zijn zaken waar iedereen tegenaan loopt als de site aan het groeien is. Daar weten ze hier bij t.net alles vanaf, naarmate je groter wordt wordt het gewoon allemaal steeds moeilijker en moet je er steeds meer resources in stoppen. Dan pas is het cruciaal dat performance en onderhoudbaarheid wel in orde zijn aangezien de gevolgen dan ook veel groter zijn.

Let wel dat ik hier speciek praat over websites, (web)applicaties en dan vooral gericht op bedrijven gelden natuurlijk hele andere regels.

[ Voor 8% gewijzigd door Anoniem: 178962 op 01-10-2008 01:43 ]

[Guillome]

`t Lijkt me alleen een compleet verkeerde insteek als je zo begint met programmeren Maar dat snap jij vast ook wel.

[!null]

Het geldt altijd dat je je structuur en code goed moet uitdenken, en daarmee juist dit soort problemen in te toekomst wil voorkomen (door schaalbaarheid, niet gaan coden van ach.. resources genoeg). Dat dat best moeilijk is, je goed voorbereiden op de toekomst, dat is wel waar. Maar aan de andere kant, als jij gewoon een efficiënt geschreven site hebt, en je implementeert bijvoorbeeld een structuur waardoor de site uitbreidbaar is over meerdere servers, dan hoef je er alleen maar meer geld (en dus resources) tegen aan te gooien, en heeft het weinig meer met programmeren te maken. Even simpel gezegd dan he. En je moet de boel ook zo bouwen dat je makkelijk functionaliteit kunt toevoegen.