[alg] Slechtste programmeervoorbeelden deel 4

[Verwijderd]

Bv202 schreef op zondag 08 augustus 2010 @ 01:44:
Nederlands-ogende syntax? Alleen het idee al

Ik schrijf alles gewoon in het Engels

Dat is puur het nationalistische idee wat je mist Als bv een Duitser een programmeertaal zal maken, zal hij zeer zeker twijvelen om alles in het Engels te doen, onze Nederlandse kijk op zaken is dan weer geheel anders.

Dit is eigenlijk ook waarom ik uiteindelijk nooit begonnen ben aan het ontwikkelen van de taal. (Hij bestaat enkel als een idee op papier)

[ Voor 38% gewijzigd door Verwijderd op 08-08-2010 11:07 ]

[RayNbow]

BarôZZa schreef op zondag 08 augustus 2010 @ 03:22:
Een 'return false' vind ik in de veel gevallen nog veel erger dan een die(). Een return false is leuk als je één check hebt, maar als je er meerdere hebt, dan is het een drama. Niks is erger dan een grote functie die simpelweg 'false' returnt.

Kwestie van een taal gebruiken waarin je de Maybe monad kunt gebruiken?

[codebeat]

BarôZZa, je snapt niet wat ik bedoel te zeggen. Jammer. Je plaatst het helemaal buiten de context.

Modbreak:

SNIP...
Als je het niet eens kan worden hoef je mensen niet belachelijk te gaan maken. Er mag hier best fanatiek gediscussierd worden, maar het is nogal zielig om meteen op de persoon te gaan spelen als anderen het even niet met je eens zijn!

[ Voor 62% gewijzigd door Woy op 08-08-2010 11:22 ]

[Matis]

Erwines schreef op zondag 08 augustus 2010 @ 11:05:
BarôZZa, je snapt niet wat ik bedoel te zeggen. Jammer. Je plaatst het helemaal buiten de context.

Erwines schreef op zondag 08 augustus 2010 @ 10:44:
Janoz, je snapt niet wat ik bedoel te zeggen. Jammer. Je plaatst het helemaal buiten de context.

Erwines schreef op zondag 08 augustus 2010 @ 10:05:
Beste BarôZZa, wat je hierboven schrijft kan ik opmerken dat je niet helemaal begrijpt wat het nut is van een return waarde en ook niet helemaal begrijpt wat ik met mijn uitleg bedoelde.

Erwines schreef op zondag 08 augustus 2010 @ 02:15:
Haha, grappig dat het wel het een en ander teweeg brengt, is goed. Maarre wat Kenneth zegt ga ik niet eens op in.

Plaats dan eens een functioneel voorbeeld, waarin jij haarfijn uitlegt waar het mank loopt. Gezien de ervaring van diverse posters in dit topic, denk ik niet dat het probleem ligt bij de ontvanger, maar bij de zender.

[Spockz]

Volgens mij gaan er hier nu een aantal zaken doorelkaar. Namelijk, Erwines beweert in eerste instantie dat je de tabelnaam niet nog eens hoeft te herhalen in de veldnaam omdat het duidelijk zou moeten zijn dat een veld `nummer' in de tabel `order' een ordernummer bevat.

Janoz zegt dat je soms wel Nederlandse terminologie moet gebruiken omdat die termen nou eenmaal gebruikelijk zijn, of zelfs niet te vertalen zijn naar een andere taal. Belangrijk hierbij is dus dat de termen consistent door de code gebruikt worden.

Je schreef ooK: "De die() is prima te gebruiken voor zaken die praktisch nooit voorkomen, maar waarbij je niet wilt dat het script doorloopt." Begrijp de redenering wel maar In het geval van het voorbeeld is dit zeer onwenselijk. Als het gaat om een plugin (bijvoorbeeld de gd lib) kan ik mij wel voorstellen dat je een die() gebruikt wanneer deze niet beschikbaar is omdat deze vereist is voor de functionaliteite die je bouwt.Wanneer je aan het bouwen bent kom je daar snel genoeg achter en dat is het ook het enige moment waarbij deze foutmelding mag voorkomen.

Zelfs in een dergelijk geval is die() misschien niet helemaal wenselijk. Van een exception kun je nog terugkomen. Dus stel dat je in je plugin een die() doet dan kan degene die de plugin gebruikt daar nooit meer van herstellen.

Kortom er wordt een beetje langs elkaar heen gepraat.

[codebeat]

Matis, LEZEN is het sleutelwoord. Ik weet ook wel dat het zondag is maar toch.enne Spockz slaat de spijker op de kop.


En de modbreak: Gaat nergens over.
Ben er wel klaar mee. Succes met de topic verder.

[ Voor 88% gewijzigd door codebeat op 08-08-2010 11:28 ]

[Woy]

Erwines schreef op zondag 08 augustus 2010 @ 11:20:
Matis, LEZEN is het sleutelwoord. Ik weet ook wel dat het zondag is maar toch.enne Spockz slaat de spijker op de kop.

Jij begint in het topic zelf met de volgende zin

Mensen die programmeren met nederlandse variabelenamen/functienamen neem ik over het algemeen niet serieus (Dan neem je het vak ook niet serieus). Dat zijn hobbyisten,immers is de taal in het engels dus doe je alles in het engels, logisch is dat.

Als je dan achteraf gaat beweren dat dat niet is wat je bedoeld had je misschien in eerste instantie wat anders moeten typen. Het is dan nogal jammer dat je andere mensen gaat beschuldigen van niet goed lezen!

[roy-t]

Misschien even leuk om er bij te vertellen dat er aardig wat libraries zijn die voor elke functie altijd een foutcode returnen of de dat doen via de laatste parameter (out/reference).

Zo uit mijn hoofd kan ik al Bada/MPI/OpenMP en pThreads opnoemen.

Wat wel vervelend is van deze manier is dat je bij veel code dit gaat doen:

code:

result r;
r = Function1();
if(isFailed(r)){ //sterf }
r = Function2();
if(isFailed(r)){//sterf}

Ik denk dat BarôZZa dat bedoelt. Op een gegeven moment kap je er gewoon mee en ga je het niet meer elke regel checken, maar alleen elke regel waarvan het waarschijnlijk is dat het fout gaat (IO code). Daarna ga je het bijna niet meer checken en ineens faalt een Math functie omdat je deelt door 0. Je ziet het niet want je vangt de return code niet af, en BOEM je applicatie gaat vrolijk door.

Effectief is het altijd maar returnen van die foutcode uiteindelijk gewoon het volgende statement (in exception termen) geworden:

Visual Basic:

On Error Resume Next

Ook merk je dit soort fouten pas veel te laat op omdat tijdens productie je nooit een knal voor je kop krijgt van je programma, dus als het een subtiele bug is vind je hem zo veel lastiger.

Nou zou je natuurlijk altijd alles kunnen checken, maarja wees eens heel eerlijk, doe je dat echt? En wordt je code er leesbaarder van?

Exceptions zijn dan 1000x makkelijker, voor een stukje code wat fout kan gaan zet je 1x try voor en aan het einde even een catch block. De code in het midden wordt er niet obscuurder van en je hoeft minder te typen ook is het duidelijker wat je met de fouten gaat doen omdat je expliciet opgeeft wat voor fouten je afvangt. Fouten die je niet afvangt stoppen netjes je programma en worden dus veel eerder gespot.

Aldus zo denk ik er over

[Devilly]

Bv202 schreef op zondag 08 augustus 2010 @ 01:44:
Twee jaar geleden moesten we Frontpage gebruiken om websites te maken. En liefst nog frames gebruiken ook, want die zijn toch zo handig

Wij mochten de frames maken m.b.v. Adobe Dreamweaver CS3 Toen iemand even later aan de leraar vroeg waarom we niet met divs werkten, bleek dat hij niet wist wat een div was. Een week later had hij dat uitgezocht en getest hoe je zo'n ding via Dreamweaver kon maken en liet dat aan ons zien, maar hij moest achteraf toch ook nog even zeggen dat frames veel handiger zijn.

[codebeat]

Modbreak:

Lees de vorige modbreak eens!

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

[Haan]

edit:
oh, intussen is e.e.a. al verwijderd zie ik

[ Voor 85% gewijzigd door Haan op 08-08-2010 11:43 ]

[Onbekend]

Devilly schreef op zondag 08 augustus 2010 @ 11:29:
Toen iemand even later aan de leraar vroeg waarom we niet met divs werkten, bleek dat hij niet wist wat een div was.

Was die leraar 60+ ofzo?
Dat is toch wel basiskennis wat je van zo'n een leraar mag verwachten.
Ik neem aan dat je meteen de school hebt aangeklaagd vanwege gebrekkige kennis bij de leraren.

[RayNbow]

roy-t schreef op zondag 08 augustus 2010 @ 11:25:
Wat wel vervelend is van deze manier is dat je bij veel code dit gaat doen:

code:

result r;
r = Function1();
if(isFailed(r)){ //sterf }
r = Function2();
if(isFailed(r)){//sterf}

Ik denk dat BarôZZa dat bedoelt. Op een gegeven moment kap je er gewoon mee en ga je het niet meer elke regel checken, maar alleen elke regel waarvan het waarschijnlijk is dat het fout gaat (IO code). Daarna ga je het bijna niet meer checken en ineens faalt een Math functie omdat je deelt door 0. Je ziet het niet want je vangt de return code niet af, en BOEM je applicatie gaat vrolijk door.

Of je gebruikt de Maybe monad? Zorg dat falende functies niet iets van type T retourneren, maar Maybe<T>. Wanneer je de Maybe-berekeningen aan elkaar rijgt, hoeft je niet na elke regel te controleren of het resultaat Nothing (failure) is of een Just-waarde (succes) is.

Talen als Haskell en C# ondersteunen dit.

[Janoz]

Erwines schreef op zondag 08 augustus 2010 @ 10:44:
Janoz, je snapt niet wat ik bedoel te zeggen. Jammer. Je plaatst het helemaal buiten de context.

Ik zie je schrijven dat mensen die nonengelse termen in hun code danwel commentaar opnemen amateurs zijn en ik verwijs naar eerdere argumentatie (en herhaal de argumentatie) om aan te geven dat dat een erg onprofessioneel standpunt is. Ik heb het niet over de andere discussie omtrent foutafhandeling (waar ik het ook niet helemaal mee eens ben. Nee, 'die()' is uber ranzig en wanneer dat ook nog eens in een lib gebruikt wordt moet de ontwikkelaar wel een heel uitgebreide argumentatie opvoeren wil hij niet standrechtelijk geexecuteerd worden), maar er is ook een reden dat we sinds C al compleet afgestapt zijn van returncodes)

Maar dan ben ik erg benieuwd waar het verschil in context zit.

[sub0kelvin]

Om ook maar even een duit in het Nederlands-is-zeker-niet-evil-zakje te doen: wij werken voor bedrijven in de zorg en als er iets doorspekt is met de meest bijzondere en starre (Nederlandstalige) domeinkennis, dan is het de zorg wel. Dat wil je niet gaan vertalen, want iedereen werkt met die terminologie. Inclusief jijzelf, omdat je met de klant of analist praat, FOs leest, bugreports ziet en meedenkt over hoe het domein in de architectuur gegoten kan worden. Als je dan bij alles wat je doet een vertaalslag moet gaan doen, dan gaat alles een stuk langzamer en het leidt ongetwijfeld tot verwarring of zelfs bugs.

Hoe vervelend het gebruiken van 2 sets aan terminologieën heb ik zelf mogen ervaren. Een van onze systemen is na ongeveer een jaar gekoppeld met een landelijk schakelbord via SOAP. Die gebruiken een andere terminologie dan wij (de terminologie was niet gestandaardiseerd) voor hetzelfde domein, maar ook nog eens met overlap. Dus 'melding' waar wij 'signaal' gebruiken, 'signaal' waar wij 'bericht' bedoelen, dat soort dingen. In de communicatie met hen passen wij ons aan hen aan want wij zijn wat flexibeler en zij hebben nog meer aangesloten partners met waarschijnlijk ook hun eigen terminologie. Maar de vertaalslag blijft na al die tijd nog steeds vermoeiend en onhandig en zeker in face2face besprekingen leidt dat af en toe tot vervelende verwarring waardoor dingen bijvoorbeeld soms 2x uitgelegd moeten worden.
2 vormen van terminologieën voor 1 set aan domeinkennis er op nahouden, in welke vorm dan ook, is echt onwenselijk in een bedrijfssituatie.

Daarentegen gebruiken we wel de woorden "get" en "set" e.d., omdat dit ingeburgerd is net als "for", "if", "catch", etc., en veel van onze gebruikte technieken (Spring, Hibernate, Wicket) en zelfs Eclipse gaan er van uit dat er getters en setters voor properties zijn. En niet 'krijgers' en 'zetters'.

[Verwijderd]

sub0kelvin schreef op zondag 08 augustus 2010 @ 12:15:
Daarentegen gebruiken we wel de woorden "get" en "set" e.d., omdat dit ingeburgerd is net als "for", "if", "catch", etc., en veel van onze gebruikte technieken (Spring, Hibernate, Wicket) en zelfs Eclipse gaan er van uit dat er getters en setters voor properties zijn. En niet 'krijgers' en 'zetters'.

Dat komt omdat Hibernate (etc) naar de syntax kijkt.

C#:

public string Naam //Benaming
{
get //Syntax
{
   return _naam;
}
set //Syntax
{
_naam = value;
}
}

public string krijgNaam() //Benaming!
{
return _naam;
}

[Woy]

Verwijderd schreef op zondag 08 augustus 2010 @ 12:48:
[...]

Dat komt omdat Hibernate (etc) naar de syntax kijkt.

C#:

public string Naam //Benaming
{
get //Syntax
{
   return _naam;
}
set //Syntax
{
_naam = value;
}
}

public string krijgNaam() //Benaming!
{
return _naam;
}

Maar in java ( Waar Hibernate voor is ), heb je geen properties, en dus gebruikt hij de benaming, waarmee je wel aan de conventie moet voldoen.

[Bv202]

Devilly schreef op zondag 08 augustus 2010 @ 11:29:
[...]


Wij mochten de frames maken m.b.v. Adobe Dreamweaver CS3 Toen iemand even later aan de leraar vroeg waarom we niet met divs werkten, bleek dat hij niet wist wat een div was. Een week later had hij dat uitgezocht en getest hoe je zo'n ding via Dreamweaver kon maken en liet dat aan ons zien, maar hij moest achteraf toch ook nog even zeggen dat frames veel handiger zijn.

Over div's heb ik hem ook ooit eens gevraagd, maar daar had hij nog nooit van gehoord. En hij deed geen moeite dat op te zoeken

Hij gaf ook java en had nog nooit van Swing gehoord

[Grijze Vos]

Er wordt niet voor niets vaak de volgende quote gebruikt:

"Those who can do, those who can't teach."

[.oisyn]

[.edit: oeps er was nog een nieuwe pagina]

[ Voor 90% gewijzigd door .oisyn op 08-08-2010 15:40 ]

[roy-t]

RayNbow schreef op zondag 08 augustus 2010 @ 11:48:
[...]

Of je gebruikt de Maybe monad? Zorg dat falende functies niet iets van type T retourneren, maar Maybe<T>. Wanneer je de Maybe-berekeningen aan elkaar rijgt, hoeft je niet na elke regel te controleren of het resultaat Nothing (failure) is of een Just-waarde (succes) is.

Talen als Haskell en C# ondersteunen dit.

Tsja, dat is een mooie tussen oplossing, maar het hoofd probleem blijft: het programma stopt niet als er iets fout gaat.

[Matis]

Het is toch aan de programmeur om te bepalen of een applicatie stopt of niet?

[RayNbow]

roy-t schreef op zondag 08 augustus 2010 @ 16:25:
[...]


Tsja, dat is een mooie tussen oplossing, maar het hoofd probleem blijft: het programma stopt niet als er iets fout gaat.

Het resultaat van de gehele berekening zelf heeft ook het type Maybe<T>. Dit dwingt je om uiteindelijk ooit te controleren of het resultaat een Nothing of een Just waarde is.

Daarnaast, een tussentijdse Nothing (=signalering van een fout) zorgt ervoor dat de uitkomst van de gehele berekening Nothing is.

C#:

var result = from r in function1()
             from s in function2()
             from t in function3(r,s)
             select t;

if (result.IsNothing()) {
    // die
}

Ter illustratie, stel dat function1 in bovenstaande code faalt en Nothing oplevert. In dat geval zullen function2 en function3 niet worden aangeroepen en geldt dat result = Nothing.

[Verwijderd]

Woy schreef op zondag 08 augustus 2010 @ 12:53:
[...]

Maar in java ( Waar Hibernate voor is ), heb je geen properties, en dus gebruikt hij de benaming, waarmee je wel aan de conventie moet voldoen.

Je kan Hibernate ook met ASP.Net gebruiken

[Alex)]

Correctie, bij .NET heb je te maken met NHibernate... dat is een port, en er zullen ongetwijfeld dingen anders zijn.

[Verwijderd]

Vast. Maar het idee is hetzelfde

[Matis]

@monad-verhaal

Als je het in een form van een ifstatement schrijft, dan evalueert dat toch ook van links naar rechts.

PHP:

if(funcA($a) && funcB($b) && funcC($a, $b)){print("Succes :)");}
else {print("Failed :'(");}

function funcA(&$var){
    $var = rand(0, 9);
    printf("funcA = %d \r\n", $var);
    return ($var < 5 ? false: true);
}
function funcB(&$var){
    $var = rand(0, 9);
    printf("funcB = %d \r\n", $var);
    return ($var < 5 ? false: true);
}
function funcC($a, $b){
    printf("Sum is: %d \r\n", ($a + $b));
    return (($a +$b) < 15 ? false: true);
}

Dan werkt dat toch *ongeveer* hetzelfde.

[RayNbow]

Matis schreef op zondag 08 augustus 2010 @ 19:10:
@monad-verhaal

Als je het in een form van een ifstatement schrijft, dan evalueert dat toch ook van links naar rechts.

PHP:

if(funcA($a) && funcB($b) && funcC($a, $b)){print("Succes :)");}
else {print("Failed :'(");}

function funcA(&$var){
    $var = rand(0, 9);
    printf("funcA = %d \r\n", $var);
    return ($var < 5 ? false: true);
}
function funcB(&$var){
    $var = rand(0, 9);
    printf("funcB = %d \r\n", $var);
    return ($var < 5 ? false: true);
}
function funcC($a, $b){
    printf("Sum is: %d \r\n", ($a + $b));
    return (($a +$b) < 15 ? false: true);
}

Dan werkt dat toch *ongeveer* hetzelfde.

Behalve dat je nu het resultaat van funcA en funcB niet kunt doorgeven aan bijv. funcC. Verder geeft het speciaal behandelen van een bepaald bestaand type (in dit geval boolean) het volgende probleem. Hoe maak je een functie die succesvol false teruggeeft?

Maar als je met "ongeveer hetzelfde" de shortcircuit-eigenschap bedoelt, dan is het antwoord ja.

[Devilly]

Onbekend schreef op zondag 08 augustus 2010 @ 11:42:
[...]

Was die leraar 60+ ofzo?
Dat is toch wel basiskennis wat je van zo'n een leraar mag verwachten.
Ik neem aan dat je meteen de school hebt aangeklaagd vanwege gebrekkige kennis bij de leraren.

Ik schat hem ergens hoog in de veertigers dus dat valt nog mee. Zoals je zelf wel kunt raden, waren niet veel studenten positief over hem te spreken. Veel klachten werden ook doorgegeven aan andere leraren, opleidingsbegeleiders, groepsbegeleiders en de persoon die de periodieke evaluaties met de studenten hield, maar uiteindelijk kwam het er vaak op neer dat het doen en laten van de leraar in kwestie werd verdedigd.

[Avalaxy]

Devilly schreef op zondag 08 augustus 2010 @ 19:50:
[...]

Veel klachten werden ook doorgegeven aan andere leraren, opleidingsbegeleiders, groepsbegeleiders en de persoon die de periodieke evaluaties met de studenten hield, maar uiteindelijk kwam het er vaak op neer dat het doen en laten van de leraar in kwestie werd verdedigd.

Tja, of ze sturen hem met vervroegd pensioen. Veel kunnen ze er niet aan doen

[Woy]

Verwijderd schreef op zondag 08 augustus 2010 @ 18:18:
Vast. Maar het idee is hetzelfde

Maar jij reageert in eerste instantie op iemand die het over Java en Hibernate heeft.

Verwijderd schreef op zondag 08 augustus 2010 @ 12:48:
[...]
Dat komt omdat Hibernate (etc) naar de syntax kijkt.

Het is dan nogal gek om het over NHibernate te gaan hebben!

[Otherside1982]

sub0kelvin schreef op zondag 08 augustus 2010 @ 12:15:
...
Daarentegen gebruiken we wel de woorden "get" en "set" e.d., omdat dit ingeburgerd is net als "for", "if", "catch", etc., en veel van onze gebruikte technieken (Spring, Hibernate, Wicket) en zelfs Eclipse gaan er van uit dat er getters en setters voor properties zijn. En niet 'krijgers' en 'zetters'.

Krijgers en Zetters klinkt toch ook leuk. Dan kunnen die Indiërs ook makkelijk Google Translate gebruiken:

BestandsNaamKrijger	File Name Warrior
BestandsNaamZetter	File Name Typesetter

Met al die Krijgers is je code meteen ook beter in staat zich te verdedigen tegen al de hackers

---

Ik schreef vroeger ook al mijn code in het Engels omdat dat in het algemeen wel vlotter leest tussen alle engelse keywords. Ik ben daarvan afgestapt in mijn huidige job omdat de bestaande code ook Nederlands gebruikt voor variabelen en functienamen. In het begin vond ik dat ook wat lastig maar er zitten ook zo veel specifieke termen in het domein dat het gewoon makkelijker en duidelijker is om Nederlands daarvoor te gebruiken.
Wat ik dan weer wel jammer vind is dat ook het volledige framework in het Nederlands is, en dan heb je dus zaken als

Delphi:

LaadListView(aSQL, aListview, aKolommen);
BewaarListViewVolgorde(qryDelete, qryInsert, ListView, MasterKey);

[ Voor 25% gewijzigd door Otherside1982 op 09-08-2010 16:25 . Reden: Nog wat ontopic praat er bij gezet :) ]

[Alex)]

Ik heb per ongeluk wel eens een stuk voorbeeldcode met VB.NET door Google Translate gehaald... ik wilde de pagina bekijken maar in Google klikte ik per ongeluk op "Translate this page". Dat ziet er best wel hilarisch uit eigenlijk.

[Michali]

RayNbow schreef op zondag 08 augustus 2010 @ 19:45:
[...]

Behalve dat je nu het resultaat van funcA en funcB niet kunt doorgeven aan bijv. funcC.

Kan wel, via een global.

[Verwijderd]

Ik denk persoonlijk dat het prima verantwoord is om bepaalde termen uit het Nederlands over te nemen in de code. Zeker aangezien zoals al wordt opgemerkt je vaak te maken krijgt met vaktermen binnen een bepaald domein waar niet zomaar een Engelse vertaling voor is.

Ik probeer het dan altijd zo in te pakken dat de Nederlandse term wordt gezien als de naam van iets. Net als dat je bijvoorbeeld een onzinnaam in je code kunt hebben (denk aan een Tweet) heb je dan een Nederlands woord.

Zodoende kan een Engelstalige programmeur nog prima lezen wat er staat en zal hij niet zomaar over de code vallen.

Maar meningen hierover verschillen natuurlijk en gelukkig.

[RayNbow]

Michali schreef op maandag 09 augustus 2010 @ 16:37:
[...]

Kan wel, via een global.

Als je die global $EAX noemt, dan vind ik het best.

[Janoz]

Verwijderd schreef op maandag 09 augustus 2010 @ 16:39:
Ik denk persoonlijk dat het prima verantwoord is om bepaalde termen uit het Nederlands over te nemen in de code. Zeker aangezien zoals al wordt opgemerkt je vaak te maken krijgt met vaktermen binnen een bepaald domein waar niet zomaar een Engelse vertaling voor is.

Ik probeer het dan altijd zo in te pakken dat de Nederlandse term wordt gezien als de naam van iets. Net als dat je bijvoorbeeld een onzinnaam in je code kunt hebben (denk aan een Tweet) heb je dan een Nederlands woord.

Zodoende kan een Engelstalige programmeur nog prima lezen wat er staat en zal hij niet zomaar over de code vallen.

Maar meningen hierover verschillen natuurlijk en gelukkig.

Mwah, dit is de enige jusite benadering

maar het kan natuurlijk ook komen omdat we het volkomen met elkaar eens zijn

[FragFrog]

*schopje*

Kwam vandaag een erg leuke tegen in een vrij oude code-base:

PHP:

switch($_REQUEST["weblog"]) 
{    
  case "1":     
    $weblog = 1;    
  default:     
    $weblog = 0;   
}


if (isset($_REQUEST["weblog"]))   
{    
  $weblog = 1;   
}
else
{
  $weblog = 0;
}

Ja, dit stond letterlijk zo onder elkaar My best guess is dat de originele autheur maar niet voor elkaar kreeg om de switch goed te laten werken (not surprised aangezien'ie een break mist) en er daarom maar andere code onder heeft gezet, waarop hij prompt vergat om de niet werkende variant eruit te gooien

De bende maar door welgeteld 1 regel code vervangen

[ Voor 4% gewijzigd door FragFrog op 10-08-2010 21:22 ]

[Kalentum]

FragFrog schreef op dinsdag 10 augustus 2010 @ 21:21:
*schopje*

Kwam vandaag een erg leuke tegen in een vrij oude code-base:

Better safe than sorry

[Matis]

FragFrog schreef op dinsdag 10 augustus 2010 @ 21:21:
De bende maar door welgeteld 1 regel code vervangen

Na een default hoort ook een break

[FragFrog]

rutgerw schreef op dinsdag 10 augustus 2010 @ 21:23:
[...]


Better safe than sorry

Erm, nee. Als je een if / else gebruikt met een assignment in beide gevallen wordt de waarde altijd overschreven. Het is onmogelijk dat de switch enig invloed whatsoever heeft

Matis schreef op dinsdag 10 augustus 2010 @ 21:32:
[...]

Na een default hoort ook een break

Dat is wat je opvalt aan de code?

[ Voor 62% gewijzigd door FragFrog op 10-08-2010 21:36 ]

[Matis]

FragFrog schreef op dinsdag 10 augustus 2010 @ 21:33:
Erm, nee. Als je een if / else gebruikt wordt de waarde altijd overschreven. Het is onmogelijk dat de switch enig invloed whatsoever heeft

In dat geval wil ik weten met welke regel jij dat voor elkaar hebt gekregen

[FragFrog]

PHP:

$weblog = (int) isset($_REQUEST["weblog"]);

In het true equivalent levert dit altijd 1 op, voor false altijd 0. Ergo, exact hetzelfde als die if/else

Heb nog overwogen die int conversie eruit te laten, maar inderdaad, better safe than sorry

[ Voor 22% gewijzigd door FragFrog op 10-08-2010 21:35 ]

[Matis]

Oh, je draagt zelf een slecht programmeervoorbeeld aan

[FragFrog]

Verklaar je nader? De casting is gewoon een gedocumenteerde feature, dat ik hem er uberhaupt in laat komt doordat er nog een paar honderd regels code meer in die functie stonden en het me niet geheel zou verbazen als er anders dingen stuk gaan.

[Matis]

FragFrog schreef op dinsdag 10 augustus 2010 @ 21:40:
Verklaar je nader? De casting is gewoon een gedocumenteerde feature, dat ik hem er uberhaupt in laat komt doordat er nog een paar honderd regels code meer in die functie stonden en het me niet geheel zou verbazen als er anders dingen stuk gaan.

Ik ben niet zo'n fan van type-juggling in een loose-typed taal.

[dragontje124]

Matis schreef op dinsdag 10 augustus 2010 @ 21:43:
[...]

Ik ben niet zo'n fan van type-juggling in een loose-typed taal.

zo kan het ook:

PHP:

$weblog = (isset($_REQUEST["weblog"]) ? 1 : 0);

[boe2]

Al 2 jaar geen php meer aangeraakt, maareuh

PHP:

<?php 
$weblog = isset($_REQUEST["weblog"]);
?>

niet eenvoudiger?

[dragontje124]

Boeboe schreef op dinsdag 10 augustus 2010 @ 23:20:
Al 2 jaar geen php meer aangeraakt, maareuh

PHP:

<?php 
$weblog = isset($_REQUEST["weblog"]);
?>

niet eenvoudiger?

dan krijg je true/false ipv 1/0

[DutchCommando]

Is er een 2..n? Als dat niet het geval is dan is het gewoon een vermomde boolean. Dus dat is waarschijnlijk de echte fail van de code.

[RetroTycoon]

In php is 1 of true toch gelijk aan elkaar? (uitgesloten ===-vergelijkingen)

[.oisyn]

boolean is een apart type in PHP.

Matis schreef op dinsdag 10 augustus 2010 @ 21:36:
Oh, je draagt zelf een slecht programmeervoorbeeld aan

Ik zie daar niets slechts aan

Matis schreef op dinsdag 10 augustus 2010 @ 21:43:
[...]

Ik ben niet zo'n fan van type-juggling in een loose-typed taal.

Er worden geen types gejuggled. Het is een expliciete cast.

[DutchCommando]

Geen idee, ik ben zelf nooit met PHP bezig. Maar we kunnen het voorbeeld gewoon abstraheren en mijns inziens de concluderen dat:

(1) Het datatype geretourneerd uit een functie welke bepaald of een waarde is toegekend aan een variabele/hashmap boolean is.
(2) Boolean de beste representatie is in deze situatie, omdat het hier een logische conditie betreft.

Oftewel, alle verdere conversieslagen qua type zijn onnodig en maken de code niet duidelijker.

[FragFrog]

DutchCommando schreef op dinsdag 10 augustus 2010 @ 23:34:
Oftewel, alle verdere conversieslagen qua type zijn onnodig en maken de code niet duidelijker.

Helemaal correct en ik ben het ook absoluut met je eens dat die int cast in theorie overbodig is. Echter, zoals gezegd was dit een erg lange functie en zitten er verderop ook juweeltjes in als "ja" / "nee", "true" / "false", "1" / "0". Er zijn situaties waarin 1 / 0 niet gelijk is aan true / false in PHP, ik loop liever niet het risico iets stuk te maken

[ Voor 13% gewijzigd door FragFrog op 10-08-2010 23:44 . Reden: Leesbaarheid :X ]

[.oisyn]

Op zich ben ik het daar helemaal mee eens, tenzij je je zoals FragFrog in een al bestaande codebase bevindt. Simpelweg er een boolean van maken omdat jij vind dat het in eerste plaats een boolean had moeten zijn kan grote gevolgen hebben.

.edit: ik bedoel maar

[ Voor 5% gewijzigd door .oisyn op 10-08-2010 23:40 ]

[boe2]

dragontje124 schreef op dinsdag 10 augustus 2010 @ 23:21:
[...]

dan krijg je true/false ipv 1/0

en wat is er mis mee? Je wil het toch sowieso als boolean gebruiken?

[dragontje124]

Boeboe schreef op woensdag 11 augustus 2010 @ 00:06:
[...]


en wat is er mis mee? Je wil het toch sowieso als boolean gebruiken?

ja maar in dit geval wilde FragFrog dat dus niet

[Sebazzz]

Alex) schreef op maandag 09 augustus 2010 @ 16:30:
Ik heb per ongeluk wel eens een stuk voorbeeldcode met VB.NET door Google Translate gehaald... ik wilde de pagina bekijken maar in Google klikte ik per ongeluk op "Translate this page". Dat ziet er best wel hilarisch uit eigenlijk.

Ik vind Visual Basic zo'n onoverzichtelijke taal dat je het gebruik ervan bijna een slecht voorbeeld kan noemen. C-stijl talen, daarbij doorzie je gelijk het programma, maar Basic-stijl talen moet je daadwerkelijk lezen. Die verbosity vind ik niet prettig, niet te lezen, niet te typen.

[Dido]

Boeboe schreef op woensdag 11 augustus 2010 @ 00:06:
En wat is er mis mee? Je wil het toch sowieso als boolean gebruiken?

Says who? Straks heeft dezelfde jojo die de oorspronkelijke code gefabriceerd had er ergens een juweeltje staan waar hij gaat rekenen met die 0 of 1?

Vertel me niets over rare impliciete zogenaamde boolean die je niet even kunt vervangen door echte booleans
Ik werk in een taal waarin dit kan:

code:

define #MyBoolean reffld(#std_bool)
#MyBoolean := true

Weinig mis mee, totdat je je realiseert dat dit ook kan:

code:

#MyBoolean := maybe

Want, ja, het is een string

Vandaar dat veelal enkele karakters werden gebruikt, maar ja, gebruik je dan Y/N, J/N, 0/1, T/F? Of, nog mooier, blank = true, elke andere waarde = false.

Dat heeft iemand opgelost door twee systeemvariabelen te definieren (met het idee dat ze multilingual konden zijn, een idee dat uiteraard nergens toe geleid heeft omdat het wat lastig wordt als een Engelse gebruiker een "Y" in de database zet, waarna een Nederlandse gebruiker gaat kijken of er een "J" staat.

In plaats van simpelweg af te spreken dat we overal 1/0, of T/F, of J/N gebruiken hebben we dus nu

code:

*STD_BOOLEAN_TRUE
*STD_BOOLEAN_FALSE

Die altijd en overal evalueren naar "J" en "N"

(Oh, ja, een "boolean" veld in de database is nu ook gedefinieerd als 1 lang, alphanumeriek, met als toegestane waarden " ", "J", of "N".

Ik ben soms jaloers op de "luxeproblemen" die ik hier soms voorbij zie komen

[dragontje124]

Dido schreef op woensdag 11 augustus 2010 @ 00:22:
[...]

Says who? Straks heeft dezelfde jojo die de oorspronkelijke code gefabriceerd had er ergens een juweeltje staan waar hij gaat rekenen met die 0 of 1?

dat werkt in PHP ook gewoon

PHP:

$myBoolean = false;
echo 4*$myBoolean; //echo't 0

en

PHP:

$myBoolean = true;
echo 4*$myBoolean; //echo't 4

of het netjes is, is een ander verhaal

[Verwijderd]

dragontje124 schreef op woensdag 11 augustus 2010 @ 00:46:
[...]

dat werkt in PHP ook gewoon

PHP:

$myBoolean = false;
echo 4*$myBoolean; //echo't 0

en

PHP:

$myBoolean = true;
echo 4*$myBoolean; //echo't 4

of het netjes is, is een ander verhaal

Op het moment dat je ergens mee rekent, parsed hij het zodat je er mee kan rekenen. Lijkt me opzicht niet heel veel mis mee, dat past wel PHP. Is in ieder geval geen onverwachte uitkomst in PHP.

[RayNbow]

Sebazzz schreef op woensdag 11 augustus 2010 @ 00:14:
[...]

Ik vind Visual Basic zo'n onoverzichtelijke taal dat je het gebruik ervan bijna een slecht voorbeeld kan noemen. C-stijl talen, daarbij doorzie je gelijk het programma, maar Basic-stijl talen moet je daadwerkelijk lezen. Die verbosity vind ik niet prettig, niet te lezen, niet te typen.

Meestal als ik code lees, "lees" ik de whitespace en niet de braces of de Then-End If tokens.

[Alex)]

Verwijderd schreef op woensdag 11 augustus 2010 @ 01:01:
[...]

Op het moment dat je ergens mee rekent, parsed hij het zodat je er mee kan rekenen. Lijkt me opzicht niet heel veel mis mee, dat past wel PHP. Is in ieder geval geen onverwachte uitkomst in PHP.

Dat het kan betekent niet dat het juist is.

C#:

bool b = true;
int i = b * 4;

Console.WriteLine(i);

Dit geeft meteen een foutmelding: Operator '*' cannot be applied to operands of type 'bool' and 'int' Wanneer ik de 'bool' vervang door 'dynamic' compileert het wel, maar krijg ik alsnog een exception op het moment dat ik het programma start.

Dit werkt wel, maar hier laat ik hem expliciet converteren. Een cast ("(int)b") werkt ook niet.

C#:

bool b = true;
int i = Convert.ToInt32(b) * 4;

Type juggling is evil.

[PiepPiep]

Ik kom hier weer functies tegen in de volgende vorm

code:

private bool functieNaam(argumenten ...)
{
   try
   {
      veel code ....
      return true;
   }
   catch
   {
      return false;
   }
}

En dan bij het aanroepen zeggen dat er 'iets fout gegaan is' als je false terug krijgt.

[Reptile209]

PiepPiep: hangt er een beetje van af, vind ik. Als het gebruik van je functie triviaal is en goed gedocumenteerd, kan ik me goed voorstellen dat je niet de ballast van allerlei checks wil meenemen. Dan is het gewoon een programmer's error, want hij/zij had deze checks zelf vooraf moeten doen. Aan de andere kant: dan is een return false ook nauwelijks een zinnige constructie, want dan wordt daar waarschijnlijk ook niet op gecontroleerd.
Met IO-zaken, div/0, enz. is dit inderdaad een (te) lazy oplossing, ook al omdat veel checks dan niet eens vooraf gedaan kunnen worden.

[RedHat]

In mijn PHP script definieer ik altijd of iets een bool is of een int. Is dit echt nodig in PHP?

Wat ik altijd doe is:

PHP:

<?php

$array = (array) blaaat

?>

[Voutloos]

Het is niet nodig, maar soms wel netter.

[.oisyn]

Alex) schreef op woensdag 11 augustus 2010 @ 09:24:
[...]

Dat het kan betekent niet dat het juist is.

C#:

bool b = true;
int i = b * 4;

Console.WriteLine(i);

Dat C# dat vind betekent niet dat het de absolute waarheid is

C++ definieert bijvoorbeeld dat een bool converteerbaar is naar int. De waarde false wordt dan 0, de waarde true wordt 1. Maar goed, C++ heeft wel meer last van impliciete conversies.

[OnTracK]

RedHat schreef op woensdag 11 augustus 2010 @ 11:03:
In mijn PHP script definieer ik altijd of iets een bool is of een int. Is dit echt nodig in PHP?

Wat ik altijd doe is:

PHP:

<?php

$array = (array) blaaat

?>

Dat lijkt me geen geldige language construct. Ik vermoed dat bovenstaande code een Notice oplevert "undefined constant 'blaat' ...".

Vanwege die notice, wordt de constant blaat omgezet in de string 'blaat', en deze cast je naar een array.

edit:

PHP:

<?php

error_reporting(E_ALL | E_STRICT);

$array = (array) blaaat;

print_r($array);

?>

levert

code:

Notice: Use of undefined constant blaaat - assumed 'blaaat' in D:\wamp\htdocs\array-cast.php on line 5

Array
(
    [0] => blaaat
)

Als de constant wel bestaat heb je weer een ander resultaat.

[ Voor 61% gewijzigd door OnTracK op 11-08-2010 11:22 ]

[.oisyn]

RedHat bedoelt uiteraard dat op de plek van "blaaat" een geldige expressie moet staan

[ Voor 5% gewijzigd door .oisyn op 11-08-2010 11:54 ]

[OnTracK]

Maar dan cast je alsnog iets naar een array, wat andere dingen doet bij een object dan bij een primitive.
Waarom zou je dan niet array('iets') doen. (vind ik een stuk netter)

[FragFrog]

Er is wel degelijk een voordeel uit die cast te halen: functies als foreach geven een error als wat je erin stopt geen array is.

Geen big deal, right? Tot je bedenkt dat een functie als mysql_fetch_assoc of een array teruggeeft bij results, of false bij geen results. Ergo, als er een rij gevonden is werkt je code, als er geen rij terugkomt krijg je een fijne foutmelding

Door er dan een (array) van te casten wordt die false omgezet naar een lege array en skipt die foreach er overheen zonder te mekkeren.

Afhankelijk van de situatie is het netter om er een check omheen te zetten, maar zeker bij mijn eigen functies wil ik gewoon een vast return-type hebben - en als die dan het resultaat van een PHP functie returnen die ofwel een array, ofwel iets anders is scheelt die cast je weer hoofdpijn later

[PiepPiep]

Reptile209 schreef op woensdag 11 augustus 2010 @ 10:59:
PiepPiep: hangt er een beetje van af, vind ik. Als het gebruik van je functie triviaal is en goed gedocumenteerd, kan ik me goed voorstellen dat je niet de ballast van allerlei checks wil meenemen. Dan is het gewoon een programmer's error, want hij/zij had deze checks zelf vooraf moeten doen. Aan de andere kant: dan is een return false ook nauwelijks een zinnige constructie, want dan wordt daar waarschijnlijk ook niet op gecontroleerd.
Met IO-zaken, div/0, enz. is dit inderdaad een (te) lazy oplossing, ook al omdat veel checks dan niet eens vooraf gedaan kunnen worden.

Het kan wel ja, maar dat was hier zeker niet het geval.
Slechte documentatie en nouwelijks foutafhandeling.
Halverwege het try blok worden gegevens in de database weggeschreven die dus corrupt raakt als na die acties en voor de volgende wegschrijf acties een exception optreed.

[roy-t]

Net uitgevonden, je hebt geen fall trough switch cases in C#, maar je kunt wel dit doen:

C#:

int myState = 0;
            switch (myState)
            {
                case 0:
                    case0:
                    //DoSomething();
                    goto case1;
                case 1:
                    case1:
                    //DoMore();
                    goto case2;
//etc
            }

Ja dit compiled .

[Alex)]

Dat klopt, C# heeft ondersteuning voor goto (helaas).

[Haan]

Interessant, de cases worden dus eigenlijk als label gezien.

[TheRookie]

@roy-t: It's not a bug, it's a feature
@Haan: nee, hij zet een label onder de case

[boe2]

roy-t schreef op donderdag 12 augustus 2010 @ 10:07:
Net uitgevonden, je hebt geen fall trough switch cases in C#, maar je kunt wel dit doen:
...
Ja dit compiled .

Je beseft zelf toch wat je daarmee riskeert?

[ValHallASW]

@Haan: in het voorbeeld dat roy-t geeft niet, maar...:

roy-t schreef op donderdag 12 augustus 2010 @ 10:07:

C#:

int myState = 0;
            switch (myState)
            {
                case 0:
                    //DoSomething();
                    goto case 1;
                case 1:
                    //DoMore();
                    goto case 2;
//etc
            }

FTFY.

Verder: geklaag over goto . Als het de structuur van je programma duidelijker maakt - kleine kans, maar /als/ - dan moet je het gewoon gebruiken. Een expliciete fallthrough bij een switch is imo duidelijker. Met een goto uit vijf geneste lussen springen: by all means (tenzij je taal daar een andere feature voor heeft). En vergeet niet, een exception is ook niets anders dan een goto. Of eigenlijk: een catch is een comefrome

[ Voor 34% gewijzigd door ValHallASW op 12-08-2010 10:17 ]

[MBV]

En dat schijnt niet eens nodig te zijn, op internet staan zat code-voorbeelden met 'goto default' en 'goto case 5'
Zelfs op MSDN: http://msdn.microsoft.com.../06tc147t%28VS.71%29.aspx

[roy-t]

MBV schreef op donderdag 12 augustus 2010 @ 10:19:
En dat schijnt niet eens nodig te zijn, op internet staan zat code-voorbeelden met 'goto default' en 'goto case 5'
Zelfs op MSDN: http://msdn.microsoft.com.../06tc147t%28VS.71%29.aspx

Oh wow dat wist ik niet.

Boeboe schreef op donderdag 12 augustus 2010 @ 10:14:
[...]


Je beseft zelf toch wat je daarmee riskeert?
[afbeelding]

Haha, gelukkig schrijf ik alleen zulke code in dit topic.

Haan schreef op donderdag 12 augustus 2010 @ 10:13:
Interessant, de cases worden dus eigenlijk als label gezien.

Ja maar dat blijkt alleen uit het MSDN artikel, niet uit wat ik schreef. Wat wel blijkt is dat goto statements net zo behandeld worden als breaks en returns. (Misschien is het onderwater juist andersom, een break is natuurlijk een soort van goto).

[ Voor 25% gewijzigd door roy-t op 12-08-2010 10:30 ]

[PiepPiep]

Achja, goto's... http://kerneltrap.org/node/553/2131

Uitspraak van Linus

Of course, in stupid languages like Pascal, where labels cannot be
descriptive, goto's can be bad. But that's not the fault of the goto,
that's the braindamage of the language designer.

Ik ben het eigenlijk wel met hem eens.

[.oisyn]

Ach ja, wat meneertje Linus weer eens niet snapt is dat als mensen roepen dat goto "evil" is dat ze niet bedoelen dat, zoals met elke "evil" programmeerconstructie, goto niet per definitie slecht is, maar dat het iets is wat een ervaren programmeur best bij tijd en wijlen kan gebruiken. Waarbij het handiger is om te verkondigen dat het gebruik van goto niet handig is zodat nieuwe programmeurs het in eerste instantie (hopelijk) uit de weg zullen gaan, totdat de dag komt dat ze zich gaan realiseren dat het af en toe best zinnig ingezet kan worden. Echter kijkt Linus zoals gewoonlijk niet verder buiten zijn eigen belevingswereld, en omdat hij zelf wel weet wanneer hij goto kan gebruiken zegt hij dat er niets mis is met goto.'

Granted, in die specifieke thread heeft hij dan wel weer te maken met mensen die het wél per definitie slecht vinden.

Overigens is hij gewoon een van de grootste trollers op deze aardbol, en dat geeft ie zelf ook toe

[ Voor 26% gewijzigd door .oisyn op 12-08-2010 12:02 ]

[YopY]

Reptile209 schreef op woensdag 11 augustus 2010 @ 10:59:
PiepPiep: hangt er een beetje van af, vind ik. Als het gebruik van je functie triviaal is en goed gedocumenteerd, kan ik me goed voorstellen dat je niet de ballast van allerlei checks wil meenemen. Dan is het gewoon een programmer's error, want hij/zij had deze checks zelf vooraf moeten doen.

Dat hoeft ook niet (ballast van allerlei checks) - als hij een unchecked exception teruggeeft (die je niet expliciet hoeft af te vangen) heeft de client er helemaal geen moeite mee. Overigens kun je programmer's errors ook afvangen dmv asserts, die zijn uitgeschakeld in productiecode - en zo voorkom je rans.

RedHat schreef op woensdag 11 augustus 2010 @ 11:03:
In mijn PHP script definieer ik altijd of iets een bool is of een int. Is dit echt nodig in PHP?

Wat ik altijd doe is:

PHP:

<?php
$array = (array) blaaat

Eigenlijk niet, alleen bij variabelen die van buitenaf komen (user input e.d.) of degenen die een grote scope hebben - maar eigenlijk wil je een typesafe taal .

Arrays kun je overigens met type hinting ook 'controleren'. Objecten en objecttypes ook.

Linus

[Strikeman225]

Waarschijnlijk is dit wel eens eerder gepost, maar tijdens het debuggen van wat sharepoint javascript code kreeg ik de volgende error (deze is 'geleend' van google pictures, de fout is hetzelfde):


Heeft iemand een t-shirt bedrijf om dit in massa productie naar de hoge heren van microsoft op te sturen (MS IE6, 7 en 8 ).

^{[offtopic]Dit is niet bedoeld als flame, ben eigenlijk op zoek naar een t-shirt die dit erop heeft staan [/offtopic]}

[kenneth]

En in ANSI SQL is null weer niet gelijk aan null. Ingewikkeld gedoe altijd

[Noxious]

Overigens, C# doet geen fall trough, maar wel dubbele labels:

C#:

case "-help":
case "-HELP":
case "/?":
case "/h":
case "/help":
    DoeIets();
    break;

[kenneth]

C# doet wel expliciete fall through:

C#:

            switch (i)
            {
                case 1:
                    Console.WriteLine("een");
                    break;
                case 2:
                    Console.WriteLine("twee");
                    goto case 3;
                case 3:
                    Console.WriteLine("drie");
                    break;
                default:
                    Console.WriteLine("onbekend");
                    break;
            }

[Verwijderd]

vandaag een stukje ranzige code geproduceerd

code:

select * from blaat where datepart(dd,StartTime) = DAY(GETDATE()-1) and datepart(mm,StartTime) = 
MONTH(GETDATE()-1) and datepart(yyyy,StartTime) = YEAR(GETDATE()-1)

om alle records van gisteren te krijgen. het zal 10* simpeler kunnen met een enkele getdate maar kreeg dat niet werken

[Vinnienerd]

-verkeerde topic-

[ Voor 89% gewijzigd door Vinnienerd op 16-08-2010 18:10 ]

[boe2]

Verwijderd schreef op maandag 16 augustus 2010 @ 17:38:
vandaag een stukje ranzige code geproduceerd

code:

select * from blaat where datepart(dd,StartTime) = DAY(GETDATE()-1) and datepart(mm,StartTime) = 
MONTH(GETDATE()-1) and datepart(yyyy,StartTime) = YEAR(GETDATE()-1)

om alle records van gisteren te krijgen. het zal 10* simpeler kunnen met een enkele getdate maar kreeg dat niet werken

en welk dialect spreekt jouw sql databank? Op ms-sql kan je gewoon dit doen om de datum van gisteren te krijgen:

SQL:

dateadd(dd, -1, getdate())

[Verwijderd]

Die is gemeen

[Verwijderd]

kenneth schreef op maandag 16 augustus 2010 @ 16:12:
C# doet wel expliciete fall through:

Eigenlijk best duf dat het jump-statement verplicht is zonder dat je fall-through toestaat. Nu moet je dus een redundante break toevoegen.

[YopY]

Verwijderd schreef op maandag 16 augustus 2010 @ 17:38:
vandaag een stukje ranzige code geproduceerd

code:

select * from blaat where datepart(dd,StartTime) = DAY(GETDATE()-1) and datepart(mm,StartTime) = 
MONTH(GETDATE()-1) and datepart(yyyy,StartTime) = YEAR(GETDATE()-1)

om alle records van gisteren te krijgen. het zal 10* simpeler kunnen met een enkele getdate maar kreeg dat niet werken

Tijd voor pseudoSQL waar je je eigen variabelen kunt definieren - SELECT * FROM blaat WHERE StartTime = YESTERDAY

Overigens lijkt dit (corrigeer me als ik het verkeerd heb) de records van gisteren, vorige maand, vorig jaar terug te geven .

[CoolGamer]

GETDATE()-1 lijkt mij gewoon gisteren teruggeven. Waarna vervolgens de delen worden gesplitst met datepart. Zo klopt het ook zodra je gisteren neemt op de eerste dag van de maand of het jaar.

[Verwijderd]

YopY schreef op maandag 16 augustus 2010 @ 19:00:
[...]


Tijd voor pseudoSQL waar je je eigen variabelen kunt definieren - SELECT * FROM blaat WHERE StartTime = YESTERDAY

Overigens lijkt dit (corrigeer me als ik het verkeerd heb) de records van gisteren, vorige maand, vorig jaar terug te geven .

hij geeft netjes de rows van gisteren weer en idd ook als de maand veranderd.

[Voutloos]

Over welk rdbms hebben we het hier, want dat moet ook gewoon wel met een enkele datumvergelijking kunnen.

[Verwijderd]

ms sql 2005

[Haan]

Ik gebruik zelf altijd datediff hiervoor.

SQL:

select * 
from blaat
where (datediff(d, starttime, getdate()) = -1)

[Tubby]

Modbreak:

Lees de Topicwaarschuwing nog eens door!

[ Voor 86% gewijzigd door Woy op 17-08-2010 10:43 ]