[alg] Slechtste programmeervoorbeelden deel 4

Woy schreef op dinsdag 15 december 2009 @ 13:31:
Via een post stuur je x gegevens naar de bank. Bijvoorbeeld DoelRekening/DoelRekeningHouder/Bedrag, om die gegevens te controleren tegen wijziging stuur je ook een op de server gegenereerde Hash( DoelRekening + DoelRekeningHouder + Bedrag + PrivateKey ( Alleen bij de bank en bij jou bekend ) ) mee. De bank weet al die gegevens, jij weet al die gegevens, en voor de rest niemand. Daar kun je toch perfect op valideren?

1
2
3
4

<!-- Letterlijke, hardcoded html ipv feitelijke hash ter controle -->
<INPUT type="hidden" NAME="SHASign" VALUE="<fill here your signature>">
<!-- Hoi preshared key -->
<INPUT type="hidden" NAME="PSPID" value="***removed***">

[ Voor 20% gewijzigd door BM op 15-12-2009 16:17 ]

1
2
3
4

for (zoekding in zoektermen)
  if zoekding = dingdatikzoek
    return dingdatikzoek
end for

1
2
3
4
5
6
7
8

mijnvar = null
for (zoekding in zoektermen)
  if zoekding == dingdatikzoek then
    mijnvar = zoekding
    break
  end if
end for
return mijnvar

1
2
3

if(len == 0) 
    return 'No tasks';
return len + ' Task' + (len == 1) ? 's' : '';

1

return ((len == 0) ? 'No' : len) + ' Task' + (len <= 1) ? 's' : '';

[ Voor 8% gewijzigd door YopY op 15-12-2009 16:30 ]

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

string label1 = "label1";
string label2 = "label2";
string label3 = "label3";
// etc tm 8

StringBuilder builder = new StringBuilder();
string value = string.Empty;
for (int i = 1; i <= 8; i++)
{
    if (i == 1) { value = label1; }
    if (i == 2) { value = label2; }
    if (i == 3) { value = label3; }
    // etc tm 8

    if (!string.IsNullOrEmpty(value))
    {
        builder.AppendFormat("{0}", value);
    }   
}

[ Voor 8% gewijzigd door Haan op 15-12-2009 16:52 ]

YopY schreef op dinsdag 15 december 2009 @ 16:25:
gelijk returnen heb je geen lokale var met een levensduur van 0.0001 seconde, dus, 0.0001 seconde winst!

[ Voor 97% gewijzigd door Verwijderd op 16-12-2009 17:57 ]

MBV schreef op woensdag 16 december 2009 @ 16:31:
waarom faalt die query?
"SELECT naam, script FROM tester"

[ Voor 9% gewijzigd door Manuel op 16-12-2009 18:33 ]

Manuel schreef op woensdag 16 december 2009 @ 18:33:
[...]

Hierdoor: WHERE naam = script

Een string moet je altijd een quote tekentje meegeven like 'string' :-)
*Het was eigenlijk bedoelt als string en niet als celnaam

Woy schreef op woensdag 16 december 2009 @ 19:09:
[...]

als zowel naam als script velden in de tabel tester zijn is het anders gewoon een valide query

Overigens vind ik 'm nou ook niet echt bepaald in de topic thuishoren. Als het een klasgenoot van je is (en volgens je profiel ben je 16) zal het ook geen professional zijn, en dat maakt de code die hij produceert dan ook niet heel erg bijzonder. Het is meer een "haha kijk nou wat deze n00b voor code schrijft"-post, ipv een "ok, zo moet het dus niet"-post. En tendens van de topic neigt toch wel meer naar die laatste categorie

[ Voor 98% gewijzigd door .oisyn op 16-12-2009 21:57 ]

[ Voor 5% gewijzigd door user109731 op 16-12-2009 21:51 ]

Site.to.Make schreef op woensdag 16 december 2009 @ 22:43:
Gezien het om mensen gaat die PHP leren lijkt het me nu niet echt HEEL handig om met PDO te gaan werken... PDO is toch flink wat complexer als de gewone mysql functie's en opzich werken die prima. Buiten het feit dat zowel MySQLi als PDO momenteel nog enkele hele wazige bugs hebben (als ik het me goed herinner oa in de afhandeling van connectie fouten) en je die niet met de MySQL extensie hebt.

JanDM schreef op woensdag 16 december 2009 @ 21:48:
Een grotere WTF is misschien wel het gebruik van de mysql_ functies. Het blijft een raadsel dat die functies nog enthousiast aangeleerd worden, terwijl PDO sinds PHP 5.1 meegeleverd wordt (en er zijn tig andere libraries die hetzelfde doen). Veiliger, sneller, database-onafhankelijk, mooiere api.

[ Voor 10% gewijzigd door TeeDee op 16-12-2009 22:57 ]

JanDM schreef op woensdag 16 december 2009 @ 21:48:
Een grotere WTF is misschien wel het gebruik van de mysql_ functies. Het blijft een raadsel dat die functies nog enthousiast aangeleerd worden, terwijl PDO sinds PHP 5.1 meegeleverd wordt (en er zijn tig andere libraries die hetzelfde doen). Veiliger, sneller, database-onafhankelijk, mooiere api.

JanDM schreef op woensdag 16 december 2009 @ 21:48:
Een grotere WTF is misschien wel het gebruik van de mysql_ functies. Het blijft een raadsel dat die functies nog enthousiast aangeleerd worden, terwijl PDO sinds PHP 5.1 meegeleverd wordt (en er zijn tig andere libraries die hetzelfde doen). Veiliger, sneller, database-onafhankelijk, mooiere api.

quote: http://nl2.php.net/manual/en/pdo.connections.php

Warning

If your application does not catch the exception thrown from the PDO constructor, the default action taken by the zend engine is to terminate the script and display a back trace. This back trace will likely reveal the full database connection details, including the username and password. It is your responsibility to catch this exception, either explicitly (via a catch statement) or implicitly via set_exception_handler().

Site.to.Make schreef op woensdag 16 december 2009 @ 23:02:
Veiliger? Neehoor. Je zal nog steeds prepared statements of escaped variabeles moeten gebruiken.

Sneller? Heb jed aar benchmarks van? Ik kan ze zo snel niet vinden.

Database onafhankelijk? Hoe vaak switch jij? Sowieso zal je meestal alsnog je query's moeten aanpassen.

Mooiere api? Dat is maar relatief.

Erkens schreef op woensdag 16 december 2009 @ 23:08:
Veiliger?
Het eerste wat me opvalt als ik die documentatie lees is een grote warning:

Woy schreef op dinsdag 15 december 2009 @ 16:31:
[...]

Dat argument gaat echter niet op. Het betekent niet dat als jij geen variabele ziet dat er onderwater geen geheugen voor gebruikt word. De waarde zal alsnog ergens opgeslagen/bewaard moeten worden. Dus stellen dat je 0.0001 seconde winst hebt is wat overdreven.

Daarbij wil ik niet zeggen dat er geen winst kan zijn door voortijdig te returnen, maar dat is waarschijnlijk niet zozeer doordat je een variabele minder declareert.

Verwijderd schreef op donderdag 17 december 2009 @ 08:14:
[...]

optimaliseert je compiler die variabele dan niet weg?

JanDM schreef op woensdag 16 december 2009 @ 21:48:
Een grotere WTF is misschien wel het gebruik van de mysql_ functies. Het blijft een raadsel dat die functies nog enthousiast aangeleerd worden, terwijl PDO sinds PHP 5.1 meegeleverd wordt (en er zijn tig andere libraries die hetzelfde doen). Veiliger, sneller, database-onafhankelijk, mooiere api.

1
2
3
4
5
6
7
8
9

//hoe heet die veilige functie op dit moment?
$sql = "SELECT * FROM table WHERE id = " + mysql_real_escape_all_evil($_GET[id]);
mysql_query($sql);

//of:

$stmt = $dbh->prepare("SELECT * FROM table WHERE id = :id");
$stmt->bindParam(":id", $_GET[id]);
$stmt->execute();

1
2
3
4
5
6
7
8

$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (:name, :value)");
$stmt->bindParam(':name', $name);
$stmt->bindParam(':value', $value);

// insert one row
$name = 'one';
$value = 1;
$stmt->execute();

Manuel schreef op woensdag 16 december 2009 @ 23:12:
@.oisyn Hehe, nee logisch maar aangezien ik nergens de term professioneel voorbij zag komen dacht ik laat ik hem maar eens even posten, bedoelde het wat dat betreft ook niet met kwaad in de zin

[ Voor 11% gewijzigd door MBV op 17-12-2009 10:47 ]

MBV schreef op donderdag 17 december 2009 @ 10:44:
TS niet gezien?

MBV schreef op donderdag 17 december 2009 @ 10:44:
OMG, de variabele wordt by reference meegegeven aan bindParam Welke idioot heeft dat verzonnen

Waarom niet de java-manier?

Waarom niet gewoon laten werken als OO method call? WHY!!

[ Voor 11% gewijzigd door .oisyn op 17-12-2009 11:18 ]

MBV schreef op donderdag 17 december 2009 @ 10:44:

PHP:

1 2 3 4 5 6 7 8 9

//hoe heet die veilige functie op dit moment? $sql = "SELECT * FROM table WHERE id = " + mysql_real_escape_all_evil($_GET[id]); mysql_query($sql); //of: $stmt = $dbh->prepare("SELECT * FROM table WHERE id = :id"); $stmt->bindParam(":id", $_GET[id]); $stmt->execute();

1

Csql_query(m_database, "select * from table where id = ?").p(id).execute();

JanDM schreef op woensdag 16 december 2009 @ 23:40:
Dat is een FAIL idd. Het probleem is ook dat exceptions/errors in PHP standaard (?) met stacktrace geprint worden. Dat zou je alleen in 'ontwikkeling' moeten hebben imho.

[ Voor 26% gewijzigd door Olaf van der Spek op 17-12-2009 14:47 ]

MBV schreef op donderdag 17 december 2009 @ 10:44:
[...]

Wie weet, kans bestaat van niet. Welke taal en welke compiler gebruik je?

MBV schreef op donderdag 17 december 2009 @ 10:44:
[edit]
Ik blijk dat zelf niet eens te snappen. Dit is het voorbeeld van PHP.net:

PHP:

1 2 3 4 5 6 7 8

$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (:name, :value)"); $stmt->bindParam(':name', $name); $stmt->bindParam(':value', $value); // insert one row $name = 'one'; $value = 1; $stmt->execute();

OMG, de variabele wordt by reference meegegeven aan bindParam Welke idioot heeft dat verzonnen

Olaf van der Spek schreef op donderdag 17 december 2009 @ 14:43:
[...]

Ik ga toch voor mijn eigen variant...

C++:

1	Csql_query(m_database, "select * from table where id = ?").p(id).execute();

[...]

In productie zet je het printen van errors toch zoiezo uit? De 'FAIL' is dat dat niet de PHP default is.

1

<?php if ($task == 'bewerkinfo') {}else{if ($task == 'toevoegen') {}else{if ($task == 'bewerken') {}else{if ($task == 'info') {}else{if ($task == 'bewerkinfo') {}else{?>

1
2

<?php
if($task != 'bewerkinfo' && $task != 'toevoegen' && $task != 'bewerken' && $task != 'info' && $task != 'bewerkinfo') {

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

    if ($cat == ''){}
    else {
        if ($cat == 'media'){echo '<div id="onderdeel">In de media</div><br />';}
        else{
            if ($cat == 'over'){echo '<div id="onderdeel">Over ons</div><br />';}
            else{
                if ($cat == 'disney'){echo '<div id="onderdeel">Disney Couture</div><br />';}
                else{
                    if ($cat == 'ahj'){echo '<div id="onderdeel">AH Jewelry</div><br />';}
                    else{
                        if ($cat == 'mb'){echo '<div id="onderdeel">Mischa Barton</div><br />';}
                        else{
                            if ($cat == 'outlet'){echo '<div id="onderdeel">Sale</div><br />';}
                            else{
                                echo '<div id="onderdeel">'.$cat.'</div><br />';
                            }
                        }
                    }
                }
            }
        }
    }

[ Voor 3% gewijzigd door chielsen op 17-12-2009 19:16 ]

Verwijderd schreef op donderdag 17 december 2009 @ 18:51:
En verder is jouw voorbeeld ook niet bepaald overzichtelijk, vind je wel?

Ik vind het persoonlijk overzichtelijker om ":id" te gebruiken dan om "?" te gebruiken en dan maar hopen dat je de de parameters in juiste volgorde toewijst en een jaar later als je wat moet wijzigen ook...

[ Voor 5% gewijzigd door Olaf van der Spek op 17-12-2009 20:21 ]

Olaf van der Spek schreef op donderdag 17 december 2009 @ 20:21:
Welke voordelen van prepared statements mist mijn voorbeeld trouwens?

Janoz schreef op donderdag 17 december 2009 @ 20:33:
Het voordeel dat een statement ge-'prepared' wordt en daarna meerdere keren gebruikt kan worden.

[ Voor 9% gewijzigd door Olaf van der Spek op 17-12-2009 21:03 ]

Maghiel schreef op vrijdag 18 december 2009 @ 04:37:
Al die voorbeelden hierboven...ik prefereer dan toch:

PHP:

1 2 3 4 5 6 7

$db = Zend_Db::factory(// Je adapter en configuratie); $query = $db->select() ->from('table') ->where('id = ?', $_GET['id']); // Al zou ik natuurlijk never een get zo uitlezen :p $result = $db->fetchAll($query);

Denk ook dat dit voor beginners helemaal niet moeilijker is om aan te leren dan een sql dialect wat toch 9 van de 10 keer mysql is, en dan leren ze het gelijk goed

chielsen schreef op donderdag 17 december 2009 @ 19:13:
Nog nooit van switch gehoord blijkbaar, of elseif of uberhaupt van normale flowcontrol.

chielsen schreef op donderdag 17 december 2009 @ 19:13:
Nog nooit van switch gehoord blijkbaar, of elseif of uberhaupt van normale flowcontrol.

Maghiel schreef op vrijdag 18 december 2009 @ 04:37:
Al die voorbeelden hierboven...ik prefereer dan toch:

PHP:

1 2 3 4 5 6 7

$db = Zend_Db::factory(// Je adapter en configuratie); $query = $db->select() ->from('table') ->where('id = ?', $_GET['id']); // Al zou ik natuurlijk never een get zo uitlezen :p $result = $db->fetchAll($query);

Denk ook dat dit voor beginners helemaal niet moeilijker is om aan te leren dan een sql dialect wat toch 9 van de 10 keer mysql is, en dan leren ze het gelijk goed

Olaf van der Spek schreef op donderdag 17 december 2009 @ 20:21:
[...]

Ik vind mijn voorbeeld prima werken. Je hebt wel een goed punt, maar of het met ":id" zoveel beter werkt weet ik niet. Ook dan moeten wijzigingen op meerdere plaatsen worden doorgevoerd.

1
2
3
4
5
6
7

select iets from wat
join piet on piet.henk = henk.piet and henk.durk = ?
where henk = ?
and piet = ?
and durk = ?
and foppe = ?
and klaas = ?

ZpAz schreef op vrijdag 18 december 2009 @ 11:16:
[...]


Die $_GET daar zo uitlezen zal niet zo veel uitmaken, aangezien het toch wordt ge-escaped door de Zend DB Adapter.

[ Voor 9% gewijzigd door mathijs92 op 18-12-2009 16:06 ]

Janoz schreef op vrijdag 18 december 2009 @ 11:53:
[...]


Het gaat niet om het escapen, maar om het scheiden van verantwoordelijkheden. Als er UI code in je databasecode staat is de kans groot dat je project een keurige 1-laagsspaghettibende is.

ZpAz schreef op vrijdag 18 december 2009 @ 17:24:
[...]


Kan je uit die 4 regels halen dat er UI code bij staat?

ZpAz schreef op vrijdag 18 december 2009 @ 17:24:
[...]


Kan je uit die 4 regels halen dat er UI code bij staat?

Woy schreef op vrijdag 18 december 2009 @ 17:44:
[...]

GET is input en dus onderdeel van de UI!

MBV schreef op donderdag 17 december 2009 @ 10:44:
OMG, de variabele wordt by reference meegegeven aan bindParam Welke idioot heeft dat verzonnen Waarom niet de java-manier? Waarom niet gewoon laten werken als OO method call? WHY!!

[ Voor 13% gewijzigd door armageddon_2k1 op 19-12-2009 12:38 ]

armageddon_2k1 schreef op zaterdag 19 december 2009 @ 12:09:
[...]


Even uit pure interesse, maar wat is er eigenlijk zo slecht aan het passen van variables by reference?

armageddon_2k1 schreef op zaterdag 19 december 2009 @ 12:09:
[...]


Even uit pure interesse, maar wat is er eigenlijk zo slecht aan het passen van variables by reference? Het feit dat het tot PHP 5.3.0 heeft geduurt totdat dit deprecated was betekent dus dat er heeeeel veel idioten hebben rondgelopen.

armageddon_2k1 schreef op zaterdag 19 december 2009 @ 12:09:
[...]


Even uit pure interesse, maar wat is er eigenlijk zo slecht aan het passen van variables by reference? Het feit dat het tot PHP 5.3.0 heeft geduurt totdat dit deprecated was betekent dus dat er heeeeel veel idioten hebben rondgelopen.

1
2
3
4
5
6
7
8
9

<?php

function foo($bar) { $bar++; return $bar; }

$val = 0;
echo foo(&$val);
echo $val;

?>

1
2
3
4
5
6
7
8
9

<?php

function foo(&$bar) { $bar++; return $bar; }

$val = 0;
echo foo($val);
echo $val;

?>

[ Voor 3% gewijzigd door Patriot op 19-12-2009 14:14 ]

Haan schreef op zaterdag 19 december 2009 @ 19:50:
Ben ik nou kippig, of staat er 2x precies hetzelfde?

1
2

foo(&$bar)
foo($bar)

Haan schreef op zaterdag 19 december 2009 @ 19:50:
Ben ik nou kippig, of staat er 2x precies hetzelfde?

quote: http://www.voip-info.org/wiki/view/Asterisk+RealTime+Sip

NOTE: Column order is important!! If you place "ipaddr" before "host" (in the case of dynamic), you will never load the public IP address of your sip device, as it will be overwritten when "host" is encountered. allow/disallow and permit/deny, the order of these statements is crucial in the config file, as they are applied in order. In the realtime db, the order is determined by the order of the columns in the table. You will note that the deny/disallow entries come before the allow/permit entries, to support the common usage of 'deny all', then permit '192.168.....'.

RobIII schreef op woensdag 23 december 2009 @ 10:58:
Zoals sommigen van jullie misschien wel weten werk ik bij een bedrijf waar we veel met Asterisk doen en daar onze eigen producten op/om heen bouwen. Nu rant ik met regelmaat Asterisk want het stikt van de WTF's (ondanks dat 't product in z'n geheel overigens best goed werkt). Vandaag kwam ik weer een juweeltje tegen...

Onderstaande quote gaat, kort-door-de-bocht, over een (database) tabel welke als alternatief dient voor .conf bestanden (en dus feitelijk gewoon configuratiemeuk bevat):


[...]


Zo kom ik er wel meer tegen, als in: op dagelijkse basis, maar deze kon ik jullie niet onthouden

Sibylle schreef op woensdag 23 december 2009 @ 14:38:

Of mis ik nu iets ?

Standeman schreef op woensdag 30 september 2009 @ 12:10:
[...]

Dat is net zoiets als een datum opslaan als met de kolommen dag, maand, jaar, uur, minuut. Wat ik ooit ook wel eens ben tegengekomen

.oisyn schreef op vrijdag 18 december 2009 @ 10:31:
[...]

Waar heb je elseif in dit geval voor nodig dan? Je kunt ook gewoon "else if" schrijven. Grammaticaal is dat exact hetzelfde als wat jij post, met het verschil dat je niet een compound statement gebruikt per if.

jvdmeer schreef op woensdag 23 december 2009 @ 22:21:
Was weer eens mijn achterstand in dit topic aan het inhalen en liep tegen deze opmerking aan:


[...]


Ik vond het dus alleen maar handig. Vooral omdat MS SQL 2000 geen echt datum-veld ondersteunde en dus ook berekeningen van de tijd lastige queries opleverden.

chielsen schreef op donderdag 24 december 2009 @ 23:07:
[...]


Ik zei alleen dat diegene die het gemaakt heeft dat niet kent, anders schrijf je niet zo else ifs op.
Het voorbeeld maakt volgens mij duidelijk genoeg dat er nog nooit van iets anders dan if en else is gehoord.

In elk geval kan je elseif vervangen door else if, het is juist in het leven geroepen om wanneer je else if gebruikt de statements wat korter en duidelijker te maken.

chielsen schreef op donderdag 24 december 2009 @ 23:07:
In elk geval kan je elseif vervangen door else if, het is juist in het leven geroepen om wanneer je else if gebruikt de statements wat korter en duidelijker te maken.

[ Voor 18% gewijzigd door Onbekend op 25-12-2009 15:59 ]

1
2
3
4
5
6

$res = unlink($directory);
if($res) {
   return true;
} else {
   return false;
}

1
2
3
4
5
6
7
8

class zus {  /* ... */ }
class zo { /* ... */ }
$zus = new zus;
$zo = new zo;
function doeDit() {
  global $zus, $zo;
  $zus->doe($zo);
}

[ Voor 44% gewijzigd door hostname op 25-12-2009 17:36 ]

MBV schreef op vrijdag 25 december 2009 @ 20:57:
die eerste vind ik niet zo'n ramp: dan weet je tenminste zeker dat het een boolean is. Ja, 'return $res == true' doet hetzelfde, maar PHP is nogal irritant wat dat betreft.

Maar ja, die 2e...

1

return unlink($directory);

LuCarD schreef op vrijdag 25 december 2009 @ 12:16:
[...]


Mis ik iets?

[...]

jvdmeer schreef op vrijdag 25 december 2009 @ 21:44:
[...]

Yep, dat zijn combivelden van tijd en datum. terwijl ik makkelijk wilde groeperen op dag/maand of jaar en dan de tijden optellen. Dat lukt niet echt met een datumtijd-veld. Helaas...

Janoz schreef op zaterdag 26 december 2009 @ 08:47:
[...]

huh? mssql kent MONTH, DAY en YEAR toch wel?

1
2
3
4
5
6
7
8
9
10
11
12

CREATE VIEW dbo.V_JaarOverzicht
AS
SELECT TOP 100 PERCENT dbo.MaxUren.Maand, dbo.MaxUren.TotaalUren, SUM(dbo.Tijden.MinutenEffectief) AS Expr1, dbo.MaxUren.WerknID,  dbo.MaxUren.Jaar
     FROM dbo.MaxUren 
     FULL OUTER JOIN dbo.Tijden ON 
          dbo.MaxUren.WerknID = dbo.Tijden.WerknID AND 
          dbo.MaxUren.Maand = dbo.Tijden.Maand AND
          dbo.MaxUren.Jaar = dbo.Tijden.Jaar
    GROUP BY 
          dbo.MaxUren.Maand, dbo.MaxUren.TotaalUren, dbo.MaxUren.WerknID, dbo.MaxUren.Jaar
     HAVING (dbo.MaxUren.WerknID IS NOT NULL)
     ORDER BY dbo.MaxUren.Maand

Janoz schreef op zaterdag 26 december 2009 @ 09:19:
mssql hadden we het over

Woy schreef op zaterdag 26 december 2009 @ 22:42:
[...]

MONTH en YEAR volgens mij wel, DAY volgens mij niet. Maar je kunt het in ieder geval wel met DATEPART bereiken

1
2
3

select day(getdate())
select month(getdate())
select year(getdate())

Soultaker schreef op dinsdag 05 januari 2010 @ 01:41:
Dat voorbeeld komt anders letterlijk uit de MySQL documentatie:
http://dev.mysql.com/doc/refman/5.1/en/select.html
LIMIT simpelweg weglaten, zoals jij suggereert, is geen optie als je wél een offset hebt maar geen totaal.

1

$query .= "\n LIMIT " . ((!empty($offset)) ? $offset . ', ' . $total : $total);

ZpAz schreef op dinsdag 15 december 2009 @ 15:50:
Of het het slechste voorbeeld is, tsja.. maar waarom die if-statements zo onlogisch verpakken.

code:

1 2 3 4 5 6

if (len && len > 0) ret = len === 1 ? "1 task" : "%@ tasks".fmt(len); else ret = "No tasks"; return ret;

Of hoe ik het zou doen:

code:

1 2 3 4 5 6

if(len == 0) return 'No tasks'; if(len == 1) return '1 Task'; else return len + ' Tasks';

Vind ik imho toch een stuk duidelijker.

1
2
3
4
5

if(len == 0) 
    return 'No tasks';
if(len == 1)
    return '1 Task';
return len + ' Tasks';

1
2
3
4
5
6
7
8

if(len == 0) 
    str = 'No';
else
    str = len;
str .= ' Task';
if(len != 1)
    str .= 's';
return str;

Verwijderd schreef op dinsdag 05 januari 2010 @ 02:03:
Moet je de code beter lezen:

PHP:

1	$query .= "\n LIMIT " . ((!empty($offset)) ? $offset . ', ' . $total : $total);

Als de offset leeg is, wordt er toch een limit meegegeven.

Jaap-Jan schreef op dinsdag 05 januari 2010 @ 02:08:

PHP:

1	$query .= !empty($offset) ? "\n LIMIT " . $offset . ', ' . $total : '';

whoami schreef op zaterdag 26 december 2009 @ 23:00:
[...]

* whoami mept Woy naar de BOL (als dat nog bestaat).

code:

1 2 3

select day(getdate()) select month(getdate()) select year(getdate())

Onbekend schreef op woensdag 27 januari 2010 @ 00:03:
[...]

Leuk die code. Meestal gaat dat wel goed, maar soms ook niet. Op 31 januari 2010 om 23:59.59 uur kan, als hij net naar de volgende dag springt, de volgende uitkomst krijgen:
Day = 31
Month = 2
En reken maar dat weinig programma's met 31 februari kunnen werken.

[ Voor 10% gewijzigd door Gamebuster op 27-01-2010 05:10 ]

.oisyn schreef op woensdag 27 januari 2010 @ 10:48:
Is het niet gegarandeerd dat als je het in 1 query doet (dus select day(getdate()), month(getdate()), year(getdate())), dat ze dan allemaal dezelfde tijd teruggeven? Zou wat zijn als dat niet zo was eigenlijk...

1

select datepart(ms, getdate()), getdate()

kenneth schreef op woensdag 27 januari 2010 @ 10:58:
[...]

SQL:

1	select datepart(ms, getdate()), getdate()

Geeft steeds dezelfde resultaten.

Maar het EP zegt meer:

[afbeelding]

Slechts 1 execution maar wel 2 resultaten.

MBV schreef op woensdag 27 januari 2010 @ 14:10:
Ik ben wel benieuwd naar het execution plan hiervan:

SQL:

1 2	SELECT getdate() as firstdate, seconddate FROM (SELECT getdate() as seconddate)

1

SELECT getdate() as firstdate, (SELECT getdate()) as seconddate

Otherside1982 schreef op woensdag 27 januari 2010 @ 10:56:
Ik heb samen met een collega een toepassing gemaakt voor een klant. Die collega werkt nu ergens anders aan een ander project en ik volg het project verder op bij de klant en doe bugfixes.