[alg] Slechtste programmeervoorbeelden deel 4

[Grijze Vos]

Jan_V schreef op vrijdag 14 januari 2011 @ 17:55:
[...]

Blijft een slecht voorbeeld door het magic number 9

En de slechte functie naam. setSpeed impliceert dat je een speed parameter mee moet kunnen geven, imho.

[ikke007]

Ooit vond iemand het een goed plan om álles in XML op te slaan. Maarja, dat moet je weer ergens laten. Dus in de relationele database.

tabel foo

• id
• created
• xml

Later werd besloten dat het toch handig was om niet alles in XML te doen maar toch enige dingen in kolommen bij te houden.

tabel foo

• id
• created
• xml
• userid
• modified
• opmerkingen
• verwijziging

En vervolgens hadden we een programmeur die het handig vondt om zijn query resultaten direct te laten casten naar XML, omdat de output via een XSL werd geconverteerd.

C#:

XmlDocument xdoc = db.Query("select * from foo").ToXml();

De ToXml() functie geeft een XmlDocument met als root node 'foo' (tabelnaam) hierin alle kolommen als velden gemerged met de xml uit de xml kolom.

Nu zit je dus met totale spaghetti code omdat kolommen en xml in de uiteindelijke xml door elkaar lopen. Zoeken waar iets vandaan komt lukt niet (bv 'opmerkingen') door gebruik van de select * ipv select opmerkingen, xml, .... en dan nóg zijn er dingen die uit de xml kolom komen dus die je nooit gaat vinden.

Verder is door het ontbreken van domain objects maar directe cast van query's naar xml er geen enkele vorm van type safety noch de mogelijkheid om te zoeken naar references en ben je feitelijk aangewezen op gut feeling, zoek in alle bestanden en hopen dat het blijft werken.

En dan vinden ze het raar dat het oplossen van één bug meerdere uren kan duren.

[kenneth]

Tja, XML ... dat kan echt niet meer Gewoon alles omzetten naar JSON, opslaan in de cloud en het is weer buzzword compliant.

[WormLord]

kenneth schreef op zaterdag 15 januari 2011 @ 12:20:
Tja, XML ... dat kan echt niet meer Gewoon alles omzetten naar JSON, opslaan in de cloud en het is weer buzzword compliant.

Of, als je echt niet kan kiezen, je gebruikt beide. Zet je data in 2 JSON objecten en zet die dan vervolgens in XML om ze te verzenden.

[PiepPiep]

twiFight schreef op vrijdag 14 januari 2011 @ 14:53:
Ik ook, maar ik snap het nog niet

Er was eerst 1 functie die een specifiek iets moet doen maar de andere programmeur vond dat in sommige gevallen die functie 1 dingetje uit de lijst van dingen die hij moest doen niet moest doen.
In plaats van die functie uitbreiden met een parameter om aan te geven of datgene wel of niet gedaan moet worden had hij een kopie gemaakt van de functie en 1 regel eruit weggehaald.
Het probleem hiervan is dat wanneer er een bug in blijkt te zitten de kopie van de functie ook aangepast moet worden. Als je even niet ziet of niet weet dat er een kopie van is dan blijft daar de bug dus bestaan.

[Gomez12]

ikke007 schreef op zaterdag 15 januari 2011 @ 12:07:
Ooit vond iemand het een goed plan om álles in XML op te slaan. Maarja, dat moet je weer ergens laten. Dus in de relationele database.
...
Later werd besloten dat het toch handig was om niet alles in XML te doen maar toch enige dingen in kolommen bij te houden.
...
En vervolgens hadden we een programmeur die het handig vondt om zijn query resultaten direct te laten casten naar XML, omdat de output via een XSL werd geconverteerd.
...
En dan vinden ze het raar dat het oplossen van één bug meerdere uren kan duren.

Tja, als mensen na 3x niet inzien dat een andere aanpak beter zou zijn, dan verwacht ik van diezelfde mensen ook niet het inzicht om bug-tijden in te schatten...

[Erkens]

Gomez12 schreef op maandag 17 januari 2011 @ 00:51:
[...]

Tja, als mensen na 3x niet inzien dat een andere aanpak beter zou zijn, dan verwacht ik van diezelfde mensen ook niet het inzicht om bug-tijden in te schatten...

Beetje te gemakkelijk gezegd imo, over het algemeen heb/krijg je gewoon geen tijd om het geheel anders aan te pakken, je moet het doen met hoe het is. En dergelijke veranderingen kan je vaak alleen maar stukje voor stukje doen (waardoor de kans op fouten natuurlijk groter wordt).

[Gomez12]

Erkens schreef op maandag 17 januari 2011 @ 07:42:
[...]

Beetje te gemakkelijk gezegd imo, over het algemeen heb/krijg je gewoon geen tijd om het geheel anders aan te pakken, je moet het doen met hoe het is. En dergelijke veranderingen kan je vaak alleen maar stukje voor stukje doen (waardoor de kans op fouten natuurlijk groter wordt).

Tja, als er geen tijd is voor een goede oplossing dan kost gewoon tijd aan de bugfix-kant. Zo simpel is het imho gewoon.
Het kost linksom of rechtsom gewoon allebei extra tijd. Alleen met een betere aanpak heb je eenmalig grote pijn en daarna verlichting op je bugfixes. Zonder betere aanpak heb je doorlopend langere bugfixes en daarna komt ook nog eens een stukje grote pijn omdat dat stukje bij beetje ook gewoon tijd kost en daarna heb je nog langere bugfixes want het is het ook niet echt.

Maarja, dat is ook 1 van de redenen waarom ik voorstander ben van een programma circa 1x per 5 jaar te herschrijven

[Woy]

Gomez12 schreef op maandag 17 januari 2011 @ 08:53:
[...]
Maarja, dat is ook 1 van de redenen waarom ik voorstander ben van een programma circa 1x per 5 jaar te herschrijven

Code compleet herschrijven is meestal gewoon puur geld verspilling. In het bestaande programma zit al zo veel kennis geïmplementeerd, die vast niet allemaal goed gedocumenteerd is. Je doet sowieso een stap terug als je het opnieuw schrijft, ook al ga je er qua code kwaliteit wel op vooruit.

Het kan zeker geen kwaad om eens in de zoveel tijd stukken code opnieuw te evalueren, en eventueel te refactoren/herschrijven. Maar het is IMHO geen goed plan om elke keer maar weer opnieuw te beginnen met een programma.

[djluc]

Pas als je goede testcases e.d. hebt zou ik structureer stukken gaan refactoren. Geheel opnieuw beginnen is inderdaad vaak niet handig. Meestal worden dat soort besluiten genomen omdat de nieuwe partij die ergens aan gaat werken een andere technologie o.i.d. gebruikt maar veelal gaat het systeem er niet beter van worden.

Leuk artikel over het rewriten van software: http://www.joelonsoftware.com/articles/fog0000000069.html

[Grijze Vos]

Gomez12 schreef op maandag 17 januari 2011 @ 08:53:
[...]

Tja, als er geen tijd is voor een goede oplossing dan kost gewoon tijd aan de bugfix-kant. Zo simpel is het imho gewoon.
Het kost linksom of rechtsom gewoon allebei extra tijd. Alleen met een betere aanpak heb je eenmalig grote pijn en daarna verlichting op je bugfixes.

Wat je omschrijft is technical debt.

[CodeCaster]

Bezig met onderhoud, alle forms in een handvol applicaties moeten we een beetje netter maken. Labels uitlijnen, textboxen gelijktrekken, Default / Cancel instellen op buttons, dat soort hersendodend werk. Wel fijn om er even snel doorheen te knallen om de klant blij te maken.

Soms bewerken we ook de caption van een label of form, bijvoorbeeld omdat er "Selecteer een datum." staat. Dan halen we de punt weg. Blijkt dat er bij één van de applicaties een vertalingentabel achter zit die de oorspronkelijke caption als input heeft.

Dat wordt dus niet alleen een executable opleveren, maar ook een update-script.

[Pkunk]

ikke007 schreef op zaterdag 15 januari 2011 @ 12:07:
Ooit vond iemand het een goed plan om álles in XML op te slaan. Maarja, dat moet je weer ergens laten. Dus in de relationele database.

tabel foo

• id
• created
• xml

Later werd besloten dat het toch handig was om niet alles in XML te doen maar toch enige dingen in kolommen bij te houden.

tabel foo

• id
• created
• xml
• userid
• modified
• opmerkingen
• verwijziging

En vervolgens hadden we een programmeur die het handig vondt om zijn query resultaten direct te laten casten naar XML, omdat de output via een XSL werd geconverteerd.

C#:

XmlDocument xdoc = db.Query("select * from foo").ToXml();

De ToXml() functie geeft een XmlDocument met als root node 'foo' (tabelnaam) hierin alle kolommen als velden gemerged met de xml uit de xml kolom.

Nu zit je dus met totale spaghetti code omdat kolommen en xml in de uiteindelijke xml door elkaar lopen. Zoeken waar iets vandaan komt lukt niet (bv 'opmerkingen') door gebruik van de select * ipv select opmerkingen, xml, .... en dan nóg zijn er dingen die uit de xml kolom komen dus die je nooit gaat vinden.

Verder is door het ontbreken van domain objects maar directe cast van query's naar xml er geen enkele vorm van type safety noch de mogelijkheid om te zoeken naar references en ben je feitelijk aangewezen op gut feeling, zoek in alle bestanden en hopen dat het blijft werken.

En dan vinden ze het raar dat het oplossen van één bug meerdere uren kan duren.

Gelukkig heb je een collega die je dat allemaal (of nouja.. te beginnen met kleine stukjes ) kan laten refactoren

[zzattack]

Onderstaande verschikking kwam ik vorige week woensdag tegen. Probeer je tranen binnen te houden.

code:

private void volgendeDag(int dag)
{
    String maand = "januari";
    if (dag > 31) {
    maand = "februari";
    dag -= 31;

    if (dag > 28) {
        maand = "maart";
        dag -= 28;

        if (dag > 31) {
        maand = "april";
        dag -= 31;

        if (dag > 30) {
            maand = "mei";
            dag -= 30;

            if (dag > 31) {
            maand = "juni";
            dag -= 31;

            if (dag > 30) {
                maand = "Juli";
                dag -= 30;

                if (dag > 31) {
                maand = "augustus";
                dag -= 31;

                if (dag > 31) {
                    maand = "september";
                    dag -= 31;

                    if (dag > 30) {
                    maand = "oktober";
                    dag -= 30;

                    if (dag > 31) {
                        maand = "november";
                        dag -= 31;

                        if (dag > 30) {
                        maand = "december";
                        dag -= 30;
                        }
                    }
                    }
                }
                }
            }
            }
        }
        }
    }
    }
    sendDate(dag.ToString(CIBase.Settings.notation) + " " + maand);
}

[.oisyn]

Werkt ook heel goed in een schrikkeljaar

[Woy]

Modbreak:

Ik heb de discussie over de lengte van code even afgesplitst naar: [alg]Optimale lengte van een methode/functie

[ Voor 3% gewijzigd door Woy op 17-01-2011 17:51 ]

[PiepPiep]

Maar die is makkelijk te fixen in vs, ctrl-k ctrl-d geloof ik zo uit mijn hoofd en je tabs staan weer goed

[!null]

Dat is wel een schoolvoorbeeld van hoe het niet moet

[gorgi_19]

zzattack schreef op maandag 17 januari 2011 @ 17:30:
Onderstaande verschikking kwam ik vorige week woensdag tegen. Probeer je tranen binnen te houden.

Het geintje om te kijken of een dag de laatste dag is van de maand levert soms ook prachtige stukken code op

[Woy]

gorgi_19 schreef op dinsdag 18 januari 2011 @ 08:33:
[...]

Het geintje om te kijken of een dag de laatste dag is van de maand levert soms ook prachtige stukken code op

Die is makkelijk

C#:

public bool IsLastDayOfMonth( this DateTime date )
{
    return date.Month != date.AddDays(1).Month;
}

[Davio]

Of eventueel, als dat logischer voor je is:

C#:

public bool IsLastDayOfMonth( this DateTime date )
{
    return date.Day == DateTime.DaysInMonth(date.Year, date.Month);
}

Edit: Werkt echter alleen voor de Gregoriaanse kalender, dus mocht je aan een exotische app werken met vreemde kalenders, dan de methode van bovenstaande post gebruiken.

[ Voor 31% gewijzigd door Davio op 18-01-2011 09:56 ]

[urk_forever]

Leuk stukje code uit een oud project:

C#:

(int)Convert.ToInt32(rs["Id"])

Weet je in ieder geval zeker dat het een int is

[!null]

Vaak kun je ook truucjes doen door de maand te verhogen en dan de dag op 0 te zetten. Zo krijg je bijvoorbeeld de laatste dag van de opgevraagde maand. Maar dan moet je wel een flexibele date en time structuur hebben. (die laat het dan ook toe dat je op maand 13 uitkomt, en dan weer de dag op 0 zet)

[BdR]

We maken en scannen hier allerlei vragenlijsten en de antwoordmogelijkheden worden gecodeerd zodat ze als getal kunnen worden opgeslagen. Bijvoorbeeld 0=Nee 1=ja of 1=nooit 2=soms 3=vaak en dergelijke.

Nu heb ik hier een paar vragenlijsten van een paar jaar geleden met een vraag "Hoevaak is dit de afgelopen 7 dagen voorgekomen?", en deze vraag is als volgt gecodeerd:

0 = 1 dag
1 = 2 dagen
2 = 3 dagen
3 = 4 dagen
4 = 5 dagen
5 = 6 dagen
6 = 7 dagen

echt, waarom?!

[CodeCaster]

En "nooit" wordt zeker opgeslagen als 7?

[.oisyn]

BdR schreef op woensdag 19 januari 2011 @ 14:34:
echt, waarom?!

Omdat de codering volledig arbitrair is en verder geen semantische betekenis heeft. Dat jij die vervolgens wel probeert toe te kennen ligt meer aan jou dan aan het systeem . De codering 0 staat gewoon voor het eerste antwoord in de lijst, niets meer en niets minder. Het eerste antwoord in de lijst is "1 dag".

[ Voor 18% gewijzigd door .oisyn op 19-01-2011 14:50 ]

[Gorion3]

#define SEL_ANIM(book) mAnims[ NR_BOOK_STATES * MATH_ILog2( mBooks[(book)].id ) + 0 ]
#define IDLE_ANIM(book) mAnims[ NR_BOOK_STATES * MATH_ILog2( mBooks[(book)].id ) + 1 ]

mAnims is 6 groot (3 verschillende boeken welke elke 2 anims (NR_BOOK_STATES) heeft). [0,1; 2,3; 4,5]. Waarom hier een logaritme werd gebruikt is totaal onnodig (werkte wel) (mBooks[].id was dus 1, 2 of 4).

Als dat id wordt gezet op 0, 2 of 4 dan heb je geen logaritme meer nodig.. de programmeur voor mij was een typische wiskunde man

[Vinnienerd]

.oisyn schreef op woensdag 19 januari 2011 @ 14:48:
[...]

Omdat de codering volledig arbitrair is en verder geen semantische betekenis heeft. Dat jij die vervolgens wel probeert toe te kennen ligt meer aan jou dan aan het systeem . De codering 0 staat gewoon voor het eerste antwoord in de lijst, niets meer en niets minder. Het eerste antwoord in de lijst is "1 dag".

Jij denkt veel te abstract en in termen van 0-based indexing. Nooit had namelijk prima aan 0 toegekend kunnen worden.

[.oisyn]

Jij denkt veel te abstract

Het is ook een abstract vraagstuk. De codering heeft niets, maar dan ook niets, met de betekenis van het antwoord te maken. Het is gewoon een id van een rij in een tabel. Bovendien staat "nooit" niet tussen de mogelijke antwoorden, en het is maar de vraag als ie dat wel had gestaan of de bedenker van de antwoorden had gewild dat ie bovenaan stond.

Hoe denk je dat die codering tot stand komt? Iemand vult gewoon een lijstje met antwoorden in, en het systeem gebruikt gewoon een opeenvolgende nummering voor elk antwoord. Waarschijnlijk heeft de invoerder nooit gezien dat de code van "dag 1" op die manier 0 werd, hij vulde gewoon het tabelletje in met antwoorden, met "dag 1" als eerste antwoord. Dat vervolgens afdoen als een slecht programmervoorbeeld slaat compleet nergens op.

[ Voor 36% gewijzigd door .oisyn op 19-01-2011 16:20 ]

[Hydra]

Vinnienerd schreef op woensdag 19 januari 2011 @ 16:12:
Jij denkt veel te abstract

Hij denkt zo abstract als een goeie dev dat zou doen. Die getallen hebben niks met de betekenis te maken. Het maakt geen fluit uit of "1 dag" nu 0, 1, of 2000 is. Dat iemand dat hier aandraagt is m.i. een grotere WTF.

[st0p]

yes, ik heb jarenlang in de online enquete branch gezeten, en je codering staat volstrekt los van de waarde. Het had even goed als 'A' (1 dag) .. 'G' (7 dagen), 'Z' (nooit) gecodeerd kunnen worden.

Los daarvan kun je tijdens de verwerking van je resultaten in SPSS of Excel natuurlijk makkelijkk 1 erbij optellen als jouw dat goed uitkomt.

[mocean]

ppx17 schreef op donderdag 06 januari 2011 @ 18:20:
[...]

Als we dan toch bezig zijn:

http://www.medicatieoverdracht.nl/Logging/message.asp?MessageID=998&MessageStr=%3Cscript%3Ealert%28%27hoi%27%29%3C/script%3E&button=none&url=

Wel heel basic...

En dat op een overheidswebsite over het EPD

[alex3305]

mocean schreef op woensdag 19 januari 2011 @ 17:08:
[...]

En dat op een overheidswebsite over het EPD

Zulke dingen kunnen op meerdere websites van de overheid. Zelfs op sommige ministeriesites. Ook Google-indexatie in combinatie met vertrouwelijke documenten schijnen ze weinig vanaf te weten .

[.oisyn]

Dat ze HTML toelaten is natuurlijk al een grove fout, maar je zou sowieso niet zelf content moeten kunnen genereren. Zelfs gewone tekst zou je al voor social engineering kunnen gebruiken. Klik.

[Freeaqingme]

Dat vind ik nou weer niet aardig van je .oisyn

't is wel een klassiek schoolvoorbeeld van hoe 't niet. Ik ben nu overtuigd, met dat EPD komt 't wel goed.

[Alex)]

Ook een mooi stukje kwaliteitscode trouwens:


Geeft me echt vertrouwen in die site.

Het klopt natuurlijk wel, maar geeft nou niet echt een idee van "Die site wordt vaak bijgewerkt". Sowieso kan ieder weldenkend mens wel bedenken wanneer de jaarwisseling is...

[ Voor 42% gewijzigd door Alex) op 19-01-2011 21:22 ]

[mithras]

Alex) schreef op woensdag 19 januari 2011 @ 21:20:
Ook een mooi stukje kwaliteitscode trouwens:
[afbeelding]

Geeft me echt vertrouwen in die site.

Het klopt natuurlijk wel, maar geeft nou niet echt een idee van "Die site wordt vaak bijgewerkt". Sowieso kan ieder weldenkend mens wel bedenken wanneer de jaarwisseling is...

Het doet me überhaupt heel erg denken aan allerlei 1999 sites:

"Het is nu: woensdag 19 januari 2011"
"De tijd is: 21:27"
"Deze pagina is opgebouwd in 0.4s met 41 database queries"
"U bent de 95773e bezoeker"
etc.

[PolarBear]

Het kan wel een functie hebben, zie http://www.webrichtlijnen.nl/ rechtsboven.

[Avalaxy]

mithras schreef op woensdag 19 januari 2011 @ 21:28:
[...]

"Deze pagina is opgebouwd in 0.4s met 41 database queries"

Dat is niet per definitie slecht. Doet google toch ook?

[hostname]

Avalaxy schreef op woensdag 19 januari 2011 @ 21:31:
[...]


Dat is niet per definitie slecht. Doet google toch ook?

Dus als Google iets doet is het goed? IMHO is het totaal onrelevante informatie voor de bezoeker en kan het dus gewoon weggelaten worden.

[Avalaxy]

hostname schreef op woensdag 19 januari 2011 @ 21:39:
[...]

Dus als Google iets doet is het goed? IMHO is het totaal onrelevante informatie voor de bezoeker en kan het dus gewoon weggelaten worden.

Tsja, Google heeft een heel leger aan mensen met een academisch diploma die daar ongetwijfeld een stuk meer over hebben nagedacht dan jij. Ik vertrouw er dan maar op dat daar kennelijk toch een reden voor is.

[.oisyn]

Het is profiling informatie, totaal oninteressant voor de generieke bezoeker, alleen voor de developer en statsgeile lui. Dat t.net het doet snap ik dus wel.

[ Voor 25% gewijzigd door .oisyn op 19-01-2011 21:45 ]

[alex3305]

Google doet het IMHO alleen nog maar vanwege historische redenen. Vroegah wilde Google gewoon bewijzen dat het de snelste was van alle zoekmachines, met de meeste resultaten. Toen stond ook de grote van de index op de hoofdpagina, wat nu allang en breed weg is.

Overigens vind ik het ook niets toevoegen.

[kenneth]

Avalaxy schreef op woensdag 19 januari 2011 @ 21:42:
[...]


Tsja, Google heeft een heel leger aan mensen met een academisch diploma die daar ongetwijfeld een stuk meer over hebben nagedacht dan jij. Ik vertrouw er dan maar op dat daar kennelijk toch een reden voor is.

Mooie argumentum ad verecundiam

[BdR]

.oisyn schreef op woensdag 19 januari 2011 @ 16:17:
[...]

Het is ook een abstract vraagstuk. De codering heeft niets, maar dan ook niets, met de betekenis van het antwoord te maken. Het is gewoon een id van een rij in een tabel. Bovendien staat "nooit" niet tussen de mogelijke antwoorden, en het is maar de vraag als ie dat wel had gestaan of de bedenker van de antwoorden had gewild dat ie bovenaan stond.

Hoe denk je dat die codering tot stand komt? Iemand vult gewoon een lijstje met antwoorden in, en het systeem gebruikt gewoon een opeenvolgende nummering voor elk antwoord. Waarschijnlijk heeft de invoerder nooit gezien dat de code van "dag 1" op die manier 0 werd, hij vulde gewoon het tabelletje in met antwoorden, met "dag 1" als eerste antwoord. Dat vervolgens afdoen als een slecht programmervoorbeeld slaat compleet nergens op.

Soms moet je verder kijken dan je neus lang is...

Met de uitslagen van deze vragenlijsten wordt nog jaren gewerkt, ze worden gedeeld en gekopieerd naar andere databases etc. Bovendien was in ditzelfde onderzoek op een later tijdstip inderdaad de optie "0=nooit" toegevoegd gevolgd door 1=1 dag 2=2 dagen etc.

Je kan dan als databaseontwerper wel bij hoog en bij laag volghouden dat het een codering is en niets met de betekenis van het antwoord te maken heeft.. maar bij deze vraag ("hoeveel dagen?") is het gewoon smeken om fouten.

[.oisyn]

BdR schreef op woensdag 19 januari 2011 @ 23:51:
maar bij deze vraag ("hoeveel dagen?") is het gewoon smeken om fouten.

Smeken om fouten? Degene die denkt dat de codering iets zegt over het antwoord is dit topic waardig. Zolang je dat in je achterhoofd houdt, weet je dat je de codering eerst moet converteren naar een waarde waar je iets mee kan.

Overigens

Je kan dan als databaseontwerper

Ik redeneerde niet vanuit de rol als databaseontwerper, maar idd, dan geldt het ook.

[Verwijderd]

Ik zie het probleem niet zo. Wat maakt de inhoud van de data uit als programmeur zijnde? Ik zou me daar zeker niet druk om maken. De structuur moet dusdanig zijn dat je niets te maken hebt met de inhoud van de applicatie, maar puur met de werking.

De inhoud is vaak ook een zaak van de beheerder, oftewel een eindgebruiker vanuit het standpunt van de programmeur. Wat die beheerder doet moet hij lekker zelf weten, zo lang het binnen de scope van de applicatie valt moet de applicatie er gewoon netjes mee om kunnen gaan.

[!null]

Iemand die later 0=nooit toevoegt had beter 7=nooit kunnen toevoegen, want anders moet je de oude waardes allemaal converteren naar de nieuwe waardes.
Ik ben het er wel mee eens, de key / codering zegt niks over de betekenis. Ik kan me wel voorstellen dat een programmeur denkt dat de waardes overeen komen met aantal dagen, maar dat zou feitelijk nergens op gebaseerd zijn, het zou dus een aanname zijn. En aannames...

[Zyppora]

Ik kan me best voorstellen dat in beginsel de indexing van een array niets met de values van die array te maken moet hebben. Echter zijn er voorbeelden te bedenken waarbij een bepaalde overeenkomst daarin wenselijk is, bijvoorbeeld wanneer er gerekend moet worden in een agenda of zo. Het leven van de developer wordt dan een stuk makkelijker als '1 dag' de index 1 heeft, '2 dagen' index 2, etc.

Als je het echt puristisch wil doen, moet je gebruik maken van een tweede array die de integer-waarde waarmee gerekend moet worden, opslaat. Maar da's moeilijk doen terwijl het ook makkelijk kan

[EddoH]

Zyppora schreef op donderdag 20 januari 2011 @ 08:45:
Ik kan me best voorstellen dat in beginsel de indexing van een array niets met de values van die array te maken moet hebben. Echter zijn er voorbeelden te bedenken waarbij een bepaalde overeenkomst daarin wenselijk is, bijvoorbeeld wanneer er gerekend moet worden in een agenda of zo. Het leven van de developer wordt dan een stuk makkelijker als '1 dag' de index 1 heeft, '2 dagen' index 2, etc.

Als je het echt puristisch wil doen, moet je gebruik maken van een tweede array die de integer-waarde waarmee gerekend moet worden, opslaat. Maar da's moeilijk doen terwijl het ook makkelijk kan

Sorry maar dit slaat natuurlijk helemaal nergens op.
Een indexering in een array heeft gewoon per definitie niets met de waarden die deze bevat te maken. Als per toeval de data samenvalt met het arrayindex, so be it, maar dan nog mag je daar geen gebruik van maken.
Het heeft niets met moeilijk doen of puristisch te maken, het gaat om fundamentele verschillen.

Het voorbeeld van je agenda snap ik niet helmaal. Hoezo sla je in een agenda ' 2 dagen' op?

[jip_86]

BdR schreef op woensdag 19 januari 2011 @ 23:51:
[...]

Soms moet je verder kijken dan je neus lang is...

Met de uitslagen van deze vragenlijsten wordt nog jaren gewerkt, ze worden gedeeld en gekopieerd naar andere databases etc. Bovendien was in ditzelfde onderzoek op een later tijdstip inderdaad de optie "0=nooit" toegevoegd gevolgd door 1=1 dag 2=2 dagen etc.

Je kan dan als databaseontwerper wel bij hoog en bij laag volghouden dat het een codering is en niets met de betekenis van het antwoord te maken heeft.. maar bij deze vraag ("hoeveel dagen?") is het gewoon smeken om fouten.

Dat is dan niet zo slim om de waarden van de antwoorden te veranderen.

Maar vragen om fouten? Waarom zou het hier ineens fout gaan omdat je de index ook als de waarde van het antwoord zou kunnen interpreteren? Bij antwoorden 0=vaak 1=af en toe 2=soms gaat het dan nooit fout Ik neem aan dat je daar ook niet ineens 0=nooit gaat maken. En dan hoef je ook nog niet eens de antwoorden aan het inverteren zoals dat bij psychologische vragenlijsten wel gebruikelijk is.

[BdR]

Wat Zyppora zegt.

Een groot systeem maak je niet in je eentje, er zijn altijd andere programmeurs en users die met jouw code en data moeten werken. En je maakt jezelf niet populair binnen zo'n team als je de Sheldon-achtige purist gaat uithangen (Big Bang Theory ).

EddoH schreef op donderdag 20 januari 2011 @ 09:31:
Het voorbeeld van je agenda snap ik niet helmaal. Hoezo sla je in een agenda ' 2 dagen' op?

Het maakt rekenen met datums makkelijker, datum+aantaldagen is makkelijker dan datum+aantaldagen+1, tenzij aantaldagen=7 dan datum (o.i.d.).

[EddoH]

Maar je mist het principe helemaal.
Het gaat er niet om purist/makkelijke samenwerking/leesbaarheid.

Dat er data als volgt opgeslagen is:
[0] -> 1
[1] -> 2
[3] -> 3

is niet vreemd/onlogisch/onleesbaar of wat dan ook: de index is per definitie niet verbonden met de data.
Dat er gevallen zijn dat ze wel 1 op 1 overeenkomen doet daar niets aan af.

[PiepPiep]

1 = 1 seconde
60 = 1 minuut
3600 = 1 uur
86400 = 1 dag, oeps, we moeten van 16 bits naar 32 bits overgaan.
31536000 = 1 jaar
Dan is het opeens wel logisch om 1 2 3 4 5 te gebruiken. (of 0 1 2 3 4)
Wat mij betreft is zelf het volgende goed :
1 = 1 dag
2 = 4 dagen
3 = 2 dagen
5 = 7 dagen
6 = 6 dagen
10 = 3 dagen
11 = 5 dagen
20 = nooit

[ValHallASW]

BdR schreef op donderdag 20 januari 2011 @ 10:18:
Het maakt rekenen met datums makkelijker, datum+aantaldagen is makkelijker dan datum+aantaldagen+1, tenzij aantaldagen=7 dan datum (o.i.d.).

Je moet dan ook rekenen met de waarden, niet met de sleutels. De sleutels hadden evengoed a=1 dag, b=2 dagen, c=3 dagen, ... kunnen zijn, of αβγ, of абв. Dat ze in dit geval toevallig beiden binnen het domein {0..7} vallen doet daar niets aan af.

BdR schreef op woensdag 19 januari 2011 @ 23:51:
et de uitslagen van deze vragenlijsten wordt nog jaren gewerkt, ze worden gedeeld en gekopieerd naar andere databases etc. Bovendien was in ditzelfde onderzoek op een later tijdstip inderdaad de optie "0=nooit" toegevoegd gevolgd door 1=1 dag 2=2 dagen etc.

Die conversie is een probleem dat je vaker zult tegenkomen. Namelijk ook wanneer je antwoorden {'s ochtends, 's middags, 's avonds} waren en iemand daar {'s nachts, 's ochtends, 's middags, 's avonds} van maakt. Dan moet je óók converteren, en dat staat helemaal los van of de data en de sleutels in hetzelfde domen vallen.

[ Voor 39% gewijzigd door ValHallASW op 20-01-2011 10:33 ]

[Puc van S.]

ValHallASW schreef op donderdag 20 januari 2011 @ 10:30:
[...]

Je moet dan ook rekenen met de waarden, niet met de sleutels. De sleutels hadden evengoed a=1 dag, b=2 dagen, c=3 dagen, ... kunnen zijn, of αβγ, of абв. Dat ze in dit geval toevallig beiden binnen het domein {0..7} vallen doet daar niets aan af.

En wat te bedenken als er een 8 = meer dan 7 dagen bijkomt?

[BdR]

M1lamb3r schreef op donderdag 20 januari 2011 @ 10:50:
[...]


En wat te bedenken als er een 8 = meer dan 7 dagen bijkomt?

Als je aan de vraag "Hoevaak is dit de afgelopen 7 dagen voorgekomen?" de antwoordmogelijkheid "meer dan 7 dagen" toevoegd, dan heb je een probleem van een heel andere orde.

Maar hoe dan ook, I've made my point. Degenen die cijferreeksen zoals 1..7 willen opslaan als 1=1, 2=4, 3=2 etc. moeten dat vooral doen.

[Zyppora]

EddoH schreef op donderdag 20 januari 2011 @ 10:29:
Maar je mist het principe helemaal.
Het gaat er niet om purist/makkelijke samenwerking/leesbaarheid.

Dat er data als volgt opgeslagen is:
\[0] -> 1
\[1] -> 2
\[3] -> 3

is niet vreemd/onlogisch/onleesbaar of wat dan ook: de index is per definitie niet verbonden met de data.
Dat er gevallen zijn dat ze wel 1 op 1 overeenkomen doet daar niets aan af.

Uiteraard kun je de volgorde/waarde/type van de index naar eigen believen kiezen, met de values zou dan nog niets mogen gebeuren. Ik zeg ook absoluut niet dat je ervan moet uitgaan dat er enige correlatie is tussen indexes en values, behalve dat ze consistent door het systeem gebruikt worden.

Ik zeg alleen dat het in sommige situaties praktischer is om daar wel enige correlatie tussen te hebben.

PHP:

// Array met te kiezen dagen
$dagen = array(
  1 => '1 dag',
  2 => '2 dagen',
  3 => '3 dagen'
);

// code om de dropdown box te laten zien met de waarden
foreach ($dagen as $key => $value) {
  echo "<option value=".$key.">".$value."</option>";
}

En dan in de vervolgpagina laat je daadwerkelijk de afspraken voor die dagen zien:

PHP:

$query = "SELECT * FROM afspraken WHERE date >= ".$vandaag." AND date <= ".$vandaag + $_POST['dagen'];

Even puur ter illustratie in semi-pseudocode zonder verdere checks of SQL injectie e.d.

Misschien dat je liever zoiets had gezien?

PHP:

// Array met te kiezen dagen
$dagen = array(
  0 => '1 dag',
  1 => '2 dagen',
  2 => '3 dagen'
);

// Index - value mapping die nodig is omdat er geen verband is tussen index en value
$dagen_index_mapping = array(
  0 => 1,
  1 => 2,
  2 => 3
);

// code om de dropdown box te laten zien
foreach ($dagen_index_mapping as $key => $value) {
  echo "<option value=".$key.">".$dagen[$value]."</option>";
}

PHP:

// Index - value mapping die nodig is omdat er geen verband is tussen index en value
$dagen_index_mapping = array(
  0 => 1,
  1 => 2,
  2 => 3
);

$query = "SELECT * FROM afspraken WHERE date >= ".$vandaag." AND date <= ".$vandaag + $dagen_index_mapping[$_POST['dagen']];

Is politiek correct, maar (zeker in kleinere projecten/scripts) niet echt praktisch als je het mij vraagt.

[EddoH]

Het ging origineel om coderingen van waarden.

De codering zegt niets over de waarde die erbij hoort.
Dat je nu een stukje PHP post waarin je 3 regels kan besparen omdat het aantal dagen toevallig overeenkomen met de index van de array doet er niets aan af.

Als je je voorbeeld nu met weken, jaren, datums zou implementeren, dan gaat die hele vlieger toch niet op?
Oftewel: in dit ene specifieke voorbeeld komt het toevallig goed uit dat het aantal dagen ook de index van de array is. Dat zegt toch niets over de codering van waarden, en je originele ' slechtste programmeervoorbeeld' ?

[ Voor 63% gewijzigd door EddoH op 20-01-2011 11:20 ]

[jip_86]

Sowieso heb je voor een systeem waarin je vragenlijsten kan maken en beantwoorden natuurlijk een generieke oplossing bedacht

[ValHallASW]

Zyppora schreef op donderdag 20 januari 2011 @ 11:03:
// Index - value mapping die nodig is omdat er geen verband is tussen index en value
$dagen_index_mapping = array(
0 => 1,
1 => 2,
2 => 3
);

*facepalm*

Je hébt de values al, alleen ben je zo stom geweest om ze als string op te slaan. Je moet die waardes gebruiken, niet een extra mapping maken of weet ik veel wat. De situatie is namelijk de volgende:

code:

$dagen = array("1 dag", "2 dagen", "3 dagen");

terwijl het logischer was geweest om dat op te slaan als

code:

$dagen = array(1,2,3);

dan wordt je output

code:

foreach ($dagen as $key => $value) { 
  echo "<option value=".$key.">".$dagen[$value]. "dag(en) </option>"; 
}

waardoor je gewoon in je SQL had kunnen doen:

code:

$query = "SELECT * FROM afspraken WHERE date >= ".$vandaag." AND date <= ".$vandaag + $dagen[$_POST['dagen']];

En eventueel had je natuurlijk die $dagen array anders op kunnen maken, door er een (ID, getalswaarde, displaywaarde)-tuple van te maken. Dan vang je het dag(en) wat netter af (of je gebruikt je favoriete i18n-lib daarvoor)

[ Voor 10% gewijzigd door ValHallASW op 20-01-2011 13:26 ]

[jip_86]

De eventueel die je noemt is beter. Je wilt bij de volgende vraag namelijk gewoon weer andere antwoordmogelijkheden tonen.

[!null]

Je hebt drie dingen. Een index, een waarde, en een caption/weergave string. Vaak worden de index en waarde op een hoop gegooid, maar het zijn wel verschillende dingen. En als je gaat rekenen, ga je dat niet met de index doen, en ook niet met de caption string. Je doet dat met de waarde.
Als je een vragen lijst hebt waar de drie genoemde elementen de hele tijd gescheiden zijn, moet je niet ineens de index en waarde gaan combineren omdat dat toevallig even handiger is. Dat zou ik wel doen als je een klein formpje moet maken, maar een systeem vol met vragenlijsten ga je eerder naar een generieke oplossing.

Edit: wat je dus in je toevoeging (vanaf 'eventueel') beschrijft..

[ Voor 5% gewijzigd door !null op 20-01-2011 13:47 ]

[MBV]

Ik snap werkelijk niet waar deze discussie heengaat. Er is kennelijk iets van een database met vragen voor een enquete. Daarin heeft iemand 7 waardes toegevoegd: 1 dag, 2 dagen, .... 7 dagen. Die hebben een automatisch gegenereerd uniek id. Wat is daar het grote probleem van?

[Caelorum]

MBV schreef op donderdag 20 januari 2011 @ 16:35:
Ik snap werkelijk niet waar deze discussie heengaat. Er is kennelijk iets van een database met vragen voor een enquete. Daarin heeft iemand 7 waardes toegevoegd: 1 dag, 2 dagen, .... 7 dagen. Die hebben een automatisch gegenereerd uniek id. Wat is daar het grote probleem van?

Geen probleem, totdat iemand besluit dat de id en de waarden overeen moeten komen (zoals hier gebeurde). Ik denk echter dat de meeste mensen het met jou eens zullen zijn, MBV.

[Avalaxy]

Heeft iemand ervaring met de voteitup plugin van Wordpress? Man, ik heb nog nooit zulke bagger code gezien

[YopY]

Avalaxy schreef op maandag 24 januari 2011 @ 19:54:
Heeft iemand ervaring met de voteitup plugin van Wordpress? Man, ik heb nog nooit zulke bagger code gezien

Niet veel code gezien zeker, .

* YopY projecteert.

[Avalaxy]

YopY schreef op maandag 24 januari 2011 @ 20:47:
[...]


Niet veel code gezien zeker, .

* YopY projecteert.

Voornamelijk zelfbouw

Maar nee, dit is echt bizar gewoon... Wtf

[MBV]

@Avalaxy: waar dan? Ik heb net even door de SVN heen gebladerd, en zie niet echt schokkende WTF's. Behalve dan de extreem slechte indentation, verder is het 'gewoon' PHP, niet bijzonder.
http://plugins.trac.wordpress.org/browser/vote-it-up/trunk

[ Voor 3% gewijzigd door MBV op 24-01-2011 22:49 ]

[RobIII]

MBV schreef op maandag 24 januari 2011 @ 22:48:
@Avalaxy: waar dan? Ik heb net even door de SVN heen gebladerd, en zie niet echt schokkende WTF's. Behalve dan de extreem slechte indentation, verder is het 'gewoon' PHP, niet bijzonder.
http://plugins.trac.wordpress.org/browser/vote-it-up/trunk

Ik zie hier wel wat amusants... Maar, inderdaad, voor de korte indruk die ik er van heb niet heel erg afwijkend van "gewoon php".

[ Voor 9% gewijzigd door RobIII op 24-01-2011 23:00 ]

[Verwijderd]

Mwah, het is wel slechte PHP, helaas is dat voor PHP gelijk aan 'normale' PHP. Of op z'n minst meestvoorkomende PHP.

[Avalaxy]

MBV schreef op maandag 24 januari 2011 @ 22:48:
@Avalaxy: waar dan? Ik heb net even door de SVN heen gebladerd, en zie niet echt schokkende WTF's. Behalve dan de extreem slechte indentation, verder is het 'gewoon' PHP, niet bijzonder.
http://plugins.trac.wordpress.org/browser/vote-it-up/trunk

Als ik voor het gemak even naar voteitup.php kijk:

- Idd zuigende indenting
- Zwaar gebrek aan OOP
- Functies van >200 regels lang, die écht heel veel meer doen dan de functienaam doet vermoeden
- Megamengsel van presentatie en logica door elkaar heen
- Geen enkele vorm van inline documentatie (dat gedeelte helemaal bovenaan kan ik geen documentatie noemen)
- PHP globals?
- Een switch statements met een hele zooi geneste if / else statements (niet eens elseif) waarvan ik denk... okeeeeeeeeee?
- Er is geen enkele vorm van codeconventie te vinden (geen spaties voor/na operators vs. wel spaties voor/na operators, haakjes die telkens weer anders staan (de ene keer op de Java manier, de andere keer op de C# manier).
- Het gebruik maken van deprecated methodes.

En dan heb ik het nog niet gehad over de "library" van >1000 regels code waar ook geen touw aan vast te knopen valt, de compleet onoverzichtelijke database die er achter hangt, de "magische" methodes die maar "iets" doen zonder dat dat ook maar enigszins duidelijk wordt uit de naam wat dat precies is...

Zoiets als dit kan echt 100x makkelijker

[alex3305]

Klinkt als een uit de hand gelopen hobby project. Werk bijvoorbeeld maar eens met CMS Made Simple, krijg je hetzelfde idee, alhoewel ze nu wel aan de weg aan het timmeren zijn. Overigens vind ik de punten die je aanhaalt niet bijster bijzonder voor PHP... Eigenlijk best triest .

[Avalaxy]

alex3305 schreef op maandag 24 januari 2011 @ 23:10:
Klinkt als een uit de hand gelopen hobby project. Werk bijvoorbeeld maar eens met CMS Made Simple, krijg je hetzelfde idee, alhoewel ze nu wel aan de weg aan het timmeren zijn. Overigens vind ik de punten die je aanhaalt niet bijster bijzonder voor PHP... Eigenlijk best triest .

Gelukkig dan maar dat ik niet van plan ben mezelf nog meer dan 5 jaar bezig te houden met PHP Als ik full-time aan dit soort code moet gaan timmeren heb ik er al snel geen zin meer in ben ik bang.

[afraca]

Tja, timmeren aan dergelijke bende is inderdaad niet goed voor de bloeddruk (alhoewel, komisch is het als je een optimist bent wel) , maar als je zelf van scratch kan beginnen en je doet alles met Zend Framework en Zend certified modules (bestaan die? ) houd je het prima uit. En type juggling houd je ook een beetje jong

[mithras]

Nou, heel Wordpress wordt gemaakt op de manier als die plugin hoor

Het is daar gewoon een zooitje en plugins schrijven kán bijna alleen op die manier. Eén keer heb ik iets in Wordpress moeten doen, daarna meteen maar afgesproken dat we nooit meer Wordpress aanbieden, wat een ramp was dat

[YopY]

Stiekem moet er gewoon een club doorgewinterde ontwikkelaars zich op PHP (OS) projecten storten en al die dingen in één keer oplossen. Goed voorbeeld doet goed volgen. Liefst ook het hele internet omgooien, er wordt veel onzin en suboptimale zooi verkondigd als je naar PHP tutorials zoekt. Klein willekeurig voorbeeld: eerste hit op 'php tutorials' is het bekende w3schools. Wat leren ze je aan bij de eerste les if / else?

PHP:

<html>
<body>

<?php
$d=date("D");
if ($d=="Fri") echo "Have a nice weekend!";
?>

</body>
</html>

De wijze les: Je controleert dat het vrijdag is door de datum te nemen, te converteren naar een locale-afhankelijke drie-letterige string, en te vergelijken met een stringwaarde. Indentatie en whitespace is niet belangrijk, en je zou code en HTML door elkaar heen moeten gebruiken.

Dat is het eerste dat een verse PHP-er leert, en dat blijft nog lange tijd hangen.

En Wordpress is een mooi product... aan de voorkant, ik durf de code niet te bekijken .

Edit @ V: Excuus, my bad . "Fri" ziet er iig niet 'taalonafhankelijk' uit, was mijn punt.

[ Voor 4% gewijzigd door YopY op 25-01-2011 20:46 ]

[OnTracK]

psst. date is niet locale-afhankelijk, dat is strftime. Hoewel ik toch de ISO numerieke dag van de week zou gebruiken, voor het geval men bedenkt voortaan twee-letterige dagcodes te gaan gebruiken in het Engels.

[Alex)]

C#:

protected override void OnPreRender(EventArgs e)
{
    if(DateTime.Now.DayOfWeek == DayOfWeek.Friday)
    {
        someLiteral.Text = "Have a nice weekend!";
    }
}

Way better.

[Verwijderd]

YopY schreef op dinsdag 25 januari 2011 @ 11:34:
Stiekem moet er gewoon een club doorgewinterde ontwikkelaars zich op PHP (OS) projecten storten en al die dingen in één keer oplossen. Goed voorbeeld doet goed volgen. Liefst ook het hele internet omgooien, er wordt veel onzin en suboptimale zooi verkondigd als je naar PHP tutorials zoekt. Klein willekeurig voorbeeld: eerste hit op 'php tutorials' is het bekende w3schools. Wat leren ze je aan bij de eerste les if / else?

PHP:

<html>
<body>

<?php
$d=date("D");
if ($d=="Fri") echo "Have a nice weekend!";
?>

</body>
</html>

De wijze les: Je controleert dat het vrijdag is door de datum te nemen, te converteren naar een locale-afhankelijke drie-letterige string, en te vergelijken met een stringwaarde. Indentatie en whitespace is niet belangrijk, en je zou code en HTML door elkaar heen moeten gebruiken.

Dat is het eerste dat een verse PHP-er leert, en dat blijft nog lange tijd hangen.

En Wordpress is een mooi product... aan de voorkant, ik durf de code niet te bekijken .

Op zich heb je wel gelijk, alleen als je met slechte code aankomt bij een forum(tweakers bv) en een topic opent dan wordt je toch wel gelijk de grond in gemept

Al doende leert men ** Zwijmelt weg bij de gedachte van scripts waarin de helft was gekopieerd omdat functies nog niet bestonden in mijn wereld **

[mithras]

Alex) schreef op dinsdag 25 januari 2011 @ 11:46:

C#:

protected override void OnPreRender(EventArgs e)
{
    if(DateTime.Now.DayOfWeek == DayOfWeek.Friday)
    {
        someLiteral.Text = "Have a nice weekend!";
    }
}

Way better.

PHP:

if (Zend_Date::now()->equals(5, Zend_Date::WEEKDAY_8601)) {
}

Kan net zo goed hoor

En ook met Cake, Symphony of CodeIgniter, dat werkt soortgelijk

[ Voor 8% gewijzigd door mithras op 25-01-2011 11:54 ]

[kenneth]

Wat is 5?

[EddoH]

kenneth schreef op dinsdag 25 januari 2011 @ 12:00:
Wat is 5?

Gokje: vrijdag?

[kenneth]

EddoH schreef op dinsdag 25 januari 2011 @ 12:06:
Gokje:

Dat dus.

[Jaap-Jan]

Een magic number die eigenlijk in een constante zou moeten zitten.

Maar zo te zien is het de vijfde dag van de week (vrijdag dus).

Edit: en iemand was mij al weer voor.

[ Voor 13% gewijzigd door Jaap-Jan op 25-01-2011 12:14 ]

[mithras]

kenneth schreef op dinsdag 25 januari 2011 @ 12:00:
Wat is 5?

De ISO 8601 nummering van dagen van de week (voorbeeld).

Je had ook Zend_Date::WEEKDAY_NARROW kunnen gebruiken ("F") of Zend_Date::WEEKDAY_NAME ("Friday") maar die zijn localized en dat is niet handig in je i18n app

[kenneth]

Nouja, ik ben in ieder geval blij dat ik DayOfWeek.Friday kan gebruiken ...

[_js_]

Maar zelfs al gebruik je DayOfWeek.Friday dan ben je nog niet van je locale-afhankelijkheid af. Een weekend kan immers op donderdag en vrijdag vallen, op vrijdag en zaterdag, alleen vrijdag, of op zaterdag en zondag.

[Davio]

_js_ schreef op dinsdag 25 januari 2011 @ 12:57:
Maar zelfs al gebruik je DayOfWeek.Friday dan ben je nog niet van je locale-afhankelijkheid af. Een weekend kan immers op donderdag en vrijdag vallen, op vrijdag en zaterdag, alleen vrijdag, of op zaterdag en zondag.

Tja, voor een berichtje als "Have a nice weekend" is het natuurlijk voldoende om aan te nemen dat het weekend op zaterdag en zondag valt.

Je kan ook te nitpickerig zijn.

[Bv202]

YopY schreef op dinsdag 25 januari 2011 @ 11:34:
Klein willekeurig voorbeeld: eerste hit op 'php tutorials' is het bekende w3schools. Wat leren ze je aan bij de eerste les if / else?

PHP:

<html>
<body>

<?php
$d=date("D");
if ($d=="Fri") echo "Have a nice weekend!";
?>

</body>
</html>

De wijze les: Je controleert dat het vrijdag is door de datum te nemen, te converteren naar een locale-afhankelijke drie-letterige string, en te vergelijken met een stringwaarde. Indentatie en whitespace is niet belangrijk, en je zou code en HTML door elkaar heen moeten gebruiken.

Dat is het eerste dat een verse PHP-er leert, en dat blijft nog lange tijd hangen.

Tjah, w3schools... het wordt dringend tijd dat die website offline wordt gehaald of helemaal wordt aangepast.

http://www.w3fools.com

[Verwijderd]

YopY schreef op dinsdag 25 januari 2011 @ 11:34:
Stiekem moet er gewoon een club doorgewinterde ontwikkelaars zich op PHP (OS) projecten storten en al die dingen in één keer oplossen. Goed voorbeeld doet goed volgen. Liefst ook het hele internet omgooien, er wordt veel onzin en suboptimale zooi verkondigd als je naar PHP tutorials zoekt. Klein willekeurig voorbeeld: eerste hit op 'php tutorials' is het bekende w3schools. Wat leren ze je aan bij de eerste les if / else?

PHP:

<html>
<body>

<?php
$d=date("D");
if ($d=="Fri") echo "Have a nice weekend!";
?>

</body>
</html>

De wijze les: Je controleert dat het vrijdag is door de datum te nemen, te converteren naar een locale-afhankelijke drie-letterige string, en te vergelijken met een stringwaarde. Indentatie en whitespace is niet belangrijk, en je zou code en HTML door elkaar heen moeten gebruiken.

Dat is het eerste dat een verse PHP-er leert, en dat blijft nog lange tijd hangen.

En Wordpress is een mooi product... aan de voorkant, ik durf de code niet te bekijken .

Ik moet zeggen, tijdens het leren van SQL, PHP en Html heb ik in het begin veel gekeken naar W3Schools, ik dacht eigenlijk dat het van het W3C was. Ik snap nu wel dat het niet zo is, maar toch als beginnend programmeur kijk je op tegen zo'n website.

Misschien is het een idee om een keer collectief zelf zo'n website op te zetten. Met tutorials op dit gebied.

[Davio]

Misschien dat een aantal Tweakers-mods het leuk vinden om dit als onderdeel van Tweakers te doen, maar je moet er maar zin in hebben...

[mithras]

Er zijn binnen Tweakers.net eerder mensen geweest die een nieuwe leersite hebben opgezet, met de focus op frontend development. Dus een inleiding in html+css met daarna tutorials over allerlei (beginners)zaken.

Maar wie dat was en welke site dat betrof, ik heb geen idee meer

[YopY]

1. W3Schools heeft broodnodig een overname en volledige revisie nodig. Ze staan bovenaan de resultaten bij de meeste HTML / PHP / CSS zoekopdrachten, maar inhoudenlijk (en geld-verdien-technisch) laten ze veel kansen liggen.

2. Nog een tutorial site? . Lijkt me beter om een bestaande tutorialsite, je weet, één die al reputatie e.d. opgebouwd heeft, te versterken met den collectieve kennis der Tweakerts.

áls er een tutorialsite zou komen zou ik het opzetten als een verzameling regelmatig voorkomende tutorials / FAQs die regelmatig opnieuw nagekeken worden op actualiteit, correctheid, nieuwe inzichten, ontwikkelde best practices, en gewoon Verbeteringen. Een sociale variant zou een pagina zijn met een aantal tutorials die de gebruikers omhoog kunnen stemmen, maar dat zou iets teveel content en keuze op één pagina hebben (en last krijgen van papegaaistemmen). Nog een variant zou een openbare wiki zijn, maar dan heb je weer het risico dat er misinformatie inkomt als het niet strak gemodereerd wordt door experts.

[RambOe]

Nu we het over W3Schools hebben: http://w3fools.com/

Edit: ah was al gepost

[ Voor 21% gewijzigd door RambOe op 25-01-2011 21:02 ]

[.oisyn]

Nou ja, daar heb ik ook wel wat op aan te merken:

quote: http://w3fools.com/#js_statements

www.w3schools.com/JS/js_statements.asp.
[JavaScript code (or just JavaScript) is a sequence of JavaScript statements.]
Apparently declarations and expressions can go right to hell (since JavaScript only is a sequence of statements).

Een expression gebruikt als statement ís gewoon een statement.

[Jan_V]

Niet zo negatief he, je kunt je wel W3Schools certificeren, dus het is goed

[Bv202]

Ik vraag me nu wel af wat zo'n w3schools-examen inhoudt

[alex3305]

Jan_V schreef op dinsdag 25 januari 2011 @ 21:52:
Niet zo negatief he, je kunt je wel W3Schools certificeren, dus het is goed

Een rijbewijs halen geeft niet de garantie van een goede chauffeur .

[Freeaqingme]

Wat dat w3schools betreft, ik vind 't wel handig om zo af en toe te gebruiken als referentie materiaal als ik even niet op een css/html tag kan komen...