[alg] Slechtste programmeervoorbeelden deel 4

[lier]

Maar dat kon ik (inderdaad) niet weten...

[Davio]

lier schreef op dinsdag 19 oktober 2010 @ 08:44:
[...]

Het is nog vroeg, maar je had het willen optimaliseren naar:

SQL:

WHERE   LN_LINETYPE_ID > 9
                AND LN_LINETYPE_ID < 20 

of zoiets:

SQL:

WHERE   LN_LINETYPE_ID BETWEEN 9 AND 20

Komt daar via de (JIT) compiler niet overal dezelfde machinecode uit?

[Noxious]

Misschien is er bewust ruimte voor uitbreiding?

[Wijnbo]

Davio schreef op dinsdag 19 oktober 2010 @ 09:11:
[...]

Komt daar via de (JIT) compiler niet overal dezelfde machinecode uit?

Vast, maar dat wil niet zeggen dat het brakke code is.

Anders zou je ook hele lappen dezelfde geneste if statements kunnen schrijven "omdat de compiler het toch wel optimaliseert"

[.oisyn]

418O2 schreef op vrijdag 15 oktober 2010 @ 11:06:
Ah, heb er zelf ook 1 op mijn naam zie ik net

C#:

        public virtual void Birthday(Employee em, DateTime date)
        {
            this.date = new DateTime(2009, date.Month, date.Day);
            this.message = em.FullName + " wordt " + this.getAge(date);
            this.employee = em;
        }

Mijn eerste C# project, zon 2 jaar gelden. Nu bezig met een revisie.

Vroeg me al of waarom die set niet goed werd gesorteerd.

Wijnbo schreef op dinsdag 19 oktober 2010 @ 08:35:

SQL:

WHERE   LN_LINETYPE_ID >= 10
                AND LN_LINETYPE_ID < 20

Is het vandaag glazen-bollen-dag ofzo?

[YopY]

.oisyn schreef op dinsdag 19 oktober 2010 @ 12:14:
[...]


[...]

Is het vandaag glazen-bollen-dag ofzo?

JaH vandaag ook weer eentjeuh:

code:

Bol bol = new GlazenBol(1337);

[Wijnbo]

.oisyn schreef op dinsdag 19 oktober 2010 @ 12:14:
[...]


[...]

Is het vandaag glazen-bollen-dag ofzo?

Had er al een toevoeging bij gezet he

[PiepPiep]

YopY schreef op dinsdag 19 oktober 2010 @ 12:36:
[...]


JaH vandaag ook weer eentjeuh:

code:

Bol bol = new GlazenBol(1337);

code:

Bol bol = new (Bol)GlazenBol(1337);

[boe2]

Waarom de cast?

[Avalaxy]

Glazenbol is een child van Bol, dan hoef je niet te casten

[!null]

Waarom moet je hem typecasten als ie overerft? (aanname)
Of was het grappig bedoelt, en niet als verbetering?

Edit: Spuit 94358304

[ Voor 9% gewijzigd door !null op 19-10-2010 16:19 ]

[Verwijderd]

Zelfs zn cast is fout XD

C#:

Bol bol = (Bol)new GlazenBol(1337);

Maar ja, echt nodig is het niet.

[kenneth]

C#:

Bol bol = bol; Bol punt = com;

[Sebazzz]

Verwijderd schreef op dinsdag 19 oktober 2010 @ 17:13:
Zelfs zn cast is fout XD

C#:

Bol bol = (Bol)new GlazenBol(1337);

Maar ja, echt nodig is het niet.

ReSharper zal dan ook aangeven dat het een overbodige cast is.
R#

[Alex)]

Helemaal mee eens! En ook "part of method body can be converted to LINQ expression"

[YellowOnline]

Ik moest hardop lachen met deze op TheDailyWTF:

Java:

private void SetAccount(RequisitionData.RequisitionItem requisitionItem, 
                        AccountData.Account account, bool automation)
{
    bool allowSetAccount = false;

    if(account != null)
    {
        // if the account entry is being set by automation, ensure that 
    // the user hasn't already set a value
        if (automation)
        {
            if (!requisitionItem.IsAccountCodeNull())
            {
                if (requisitionItem.AccountCode == string.Empty)
                    allowSetAccount = true;
                else
                    allowSetAccount = true;
            }
            else
                allowSetAccount = true;
        }
        else
            allowSetAccount = true;

        if (allowSetAccount)
        {
            requisitionItem.AccountID = account.ID;
            requisitionItem.AccountCode = account.Code;
        }
    }
}

Er ontspon wel een discussie dat het misschien opzettelijk was met het oog op toekomstige wijzigingen en dan niet zo gek was.

[Silentuz]

Ik kwam laatst iets aparts tegen:
Opgave was om te kijken of een bepaalde lijst getallen allen gelijk waren
Simplified code die er dan als oplossing gegeven was:

Los van de paar schoonheidsfoutjes die erin zitten, is het hele concept wat hier gebruikt wordt nogal vaag....

Java:

public boolean allEqual(List<Integer> numbers){
    int first = numbers.get(0);
    int counter = 1;
    while(counter < numbers.size() && numbers.get(counter) == first){   
        counter++;
    }
    return counter == numbers.size();
}

[Verwijderd]

Ik ben nu even heel erg in de war of allEqual ongedefiniëerd mag zijn voor lege lijsten. Verder vind ik het een geweldig voorbeeld hoe je een oplossing niet moet uitleggen

[Silentuz]

Dat vind ik (grove) schoonheidsfout, net als de herhaalde aanroep van numbers.size().

Maar vooral het aparte gebruik van de counter vond ik wel een pareltje

[Snake]

Verwijderd schreef op dinsdag 19 oktober 2010 @ 23:00:
Ik ben nu even heel erg in de war of allEqual ongedefiniëerd mag zijn voor lege lijsten. Verder vind ik het een geweldig voorbeeld hoe je een oplossing niet moet uitleggen

.get(0) op een lege lijst throws NullReferenceException (oid, weet de Java term niet)

[CoolGamer]

Ik denk dat het beter was als er gebruik gemaakt werd van equals i.p.v. == (dan moet je wel in het geval van null afvangen).
Het zijn allemaal integers, dus equals is niet echt nodig (tenzij de List ook null elements kan bevatten).

Herhaaldelijk aanroepen van size() is meestal niet inefficiënt, dus kan geen kwaad. Voor de rest vind ik het wel een goede code, al had het ook met een for-loop gekund.

[ Voor 15% gewijzigd door CoolGamer op 19-10-2010 23:18 ]

[iBasch]

Java:

public boolean allEqual(List<Integer> numbers)
{
    if (numbers == null || numbers.size() == 0)
        return false;

    int first = numbers.get(0);
    
    for (int i : numbers)
    {
        if (i != first)
            return false;
    }

    return true;
}

Zo zou ik 'm dan doen, is denk ik iets logischer.

@ Silentuz; even m'n IndexOutOfBoundsException gefixed in dat geval. Dank u.

[ Voor 14% gewijzigd door iBasch op 19-10-2010 23:19 ]

[Silentuz]

Snake schreef op dinsdag 19 oktober 2010 @ 23:07:
[...]

.get(0) op een lege lijst throws NullReferenceException (oid, weet de Java term niet)

Op een null variable krijg je NullPointerException.
Op een lege lijst vraag je gewoon een element buiten de index range op, en krijg je dus een IndexOutOfBoundsException.

@iBasch

Dat kan nog steeds een IndexOutOfBoundsException opleveren op een lege lijst, je moet daar expliciet de size voor checken.


edit:
Maar wat mij betreft is dat allemaal standaard lelijk programmeren wat er fout is. Het hele concept van je counter gebruiken om te kijken of je sequence van gelijke getallen even lang is als je lijst, vind ik nogal bizar.

[ Voor 33% gewijzigd door Silentuz op 19-10-2010 23:18 ]

[YopY]

YellowOnline schreef op dinsdag 19 oktober 2010 @ 18:56:
Er ontspon wel een discussie dat het misschien opzettelijk was met het oog op toekomstige wijzigingen en dan niet zo gek was.

Mja, dan voeg je 'YAGNI' toe, en implementeer je pas op het moment dat het nodig is (en de requirements daadwerkelijk afgemaakt / duidelijk worden). Voor hetzelfde veranderen die requirements nooit, en dan zie je vijf jaar terug je code terug op TDWTF.

En dan hadden ze dat er als commentaar bij moeten zetten, eventueel met een opmerking richting degene die de requirements maakt (of niet afgemaakt heeft) en degene die besloten heeft dat ze een overbodig stuk code uit moeten werken ;D.

.get(0) op een lege lijst throws NullReferenceException (oid, weet de Java term niet)

Bijna goed, het is NullPointerException.

En een controle daarvoor is dodelijk eenvoudig:

Java:

if (numbers == null) return true; // niks == niks, ;D

of beter nog:

Java:

/**
 * (bla bla bla)
 * @param numbers The numbers to check. Please don't pass nulls, unless you actually enjoy NPE's.
 */
public boolean allEqual(List<Integer> numbers){ 

wat ook nog kan:

Java:

public boolean allEqual(List<Integer> numbers){ 
   assert numbers != null : "The Numbers list cannot be null";

waar je java in development omgevingen met -ae (asserts enabled) laat draaien. Zo krijg je alleen controles tijdens het ontwikkelen, en als het goed is is dat de enige keer dat iemand nulls naar zo'n functie stuurt (als het geen publieke API is). Als het wél een publieke API is doe je

Java:

if (numbers == null) throw new IllegalArgumentException("Numbers cannot be null");

of

Java:

Validator.notNull(numbers)

(apache commons validator, op zich eenvoudig stukje code, maar toch).

[Verwijderd]

Het ging me eerder om de opdrachtspecificatie. Als een lijst leeg is, wat moet allEqual dan teruggeven? Mag allEqual dan wel gebruikt worden? Als allEqual per definitie gegarandeerd een niet-lege List krijgt, mag je gewoon .get(0) zeggen en de caller met eventuele exceptions om laten gaan. Natuurlijk is het netter om even op die preconditie te controleren en alsnog een NullPointerException of een IllegalArgumentException te throwen.

offtopic:
En null moet gewoon dood. Ik heb veel liever een expliciete nullability (zoals in C#) of een apart type (de Maybe monad in Haskell) dan het "is m'n parameter misschien null?"-feest dat Java heet. Wat dat betreft hoort heel Java in dit topic thuis.

[ Voor 3% gewijzigd door Verwijderd op 19-10-2010 23:27 ]

[TJHeuvel]

Ik zou hem zo doen:

C#:

public static bool areEqual(List<int> numbers)
{
 if(numbers == null || numbers.count <= 0)
   return true; 
 
 for(int i = 1; i < numbers.count; i++)
   if(numbers[i] != numbers[i-1])
    return false;

 return true;

}

[Verwijderd]

wat heeft die

code:

|| numbers.count <= 0

eigenlijk voor zijn? betere leesbaarheid?

[Verwijderd]

Ik denk voor lijsten met negatieve lengte.

[Verwijderd]

hoezo dat? ook met een lijst van negatieve lengte (kan dat?) word de for lus geskipt omdat i (= 1) kleiner is dan numbers.count, idem bij alle waarden onder de 2.

C#:

public static bool areEqual(List<int> numbers)
{
 if(numbers == null)
   return true; 
 
 for(int i = 1; i < numbers.count; i++)
   if(numbers[i] != numbers[i-1])
    return false;

 return true;

}

zo werkt hij precies hetzelfde.

waarschijnlijk kan je die == null ook wel weghalen, afhankelijk van wat numbers.count teruggeeft als numbers niet bestaat (een error?)

[ Voor 58% gewijzigd door Verwijderd op 19-10-2010 23:42 ]

[TJHeuvel]

Ik probeer altijd wel defensief te programmeren. In dit voorbeeld zal het inderdaad weinig voor komen, maar bij andere cases weer wel.

Je kan beter een scenario teveel meenemen dan te weinig (Mits je binnen de specificaties blijft)

**edit, over die for lus skippen.
Daar had ik niet eens over nagedacht

[ Voor 13% gewijzigd door TJHeuvel op 19-10-2010 23:43 ]

[Verwijderd]

Het was uiteraard sarcastisch bedoeld, darkstone

Mijn punt blijft dat het niet juist gespecificeerd is wat het gedrag moet zijn als de lijst leeg is. Je kunt namelijk beredeneren dat er in een lege lijst geen getallen zijn, dus ze kunnen ook nergens aan gelijk zijn, dus mag je geen lege lijsten meegeven.

Niet dat dit in dit geval een probleem is, maar het is wel het soort fouten die toekomstige Climate Orbiters op Mars laten neerstorten, simpelweg omdat verschillende programmeurs verschillende invullingen geven aan gaten in een specificatie.

[ Voor 9% gewijzigd door Verwijderd op 19-10-2010 23:50 ]

[yade]

Een List kan theoretisch negatief zijn omdat de size() method, ik kan de de documentatie geen count vinden, een signed integer teruggeeft. Dat is volgens mij wel vaker het geval, hoewel onlogisch, omdat java, naar mijn weten, geen unsigned types kent.

Maar qua leesbaarheid zou ik de isEmpty() method gebruiken.

http://download.oracle.com/javase/6/docs/api/index.html

Edit: Oh wacht, men gaat ineens over op C#. Wie begint een method nou met een lowerCase in c#?

[ Voor 12% gewijzigd door yade op 20-10-2010 00:01 ]

[Verwijderd]

List.size() geeft de kardinaliteit van de lijst terug. Lists zijn wiskundig gezien rijen en dus aftelbare verzamelingen. De kardinaliteit van een aftelbare verzameling is nul, een natuurlijk getal of alef-nul. Theoretisch gezien kan List.size() dus geen negatief getal teruggeven. Het ligt er maar aan wat je 'theoretisch' noemt

En het gebruik van isEmpty en iterators is inderdaad een heel stuk leesbaarder dan het gebruik van size en get. Maar het gaat in dit topic niet om leesbaarheid, maar om hele foute voorbeelden

[CodeCaster]

yade schreef op dinsdag 19 oktober 2010 @ 23:52:
Edit: Oh wacht, men gaat ineens over op C#. Wie begint een method nou met een lowerCase in c#?

Niemand.

[yade]

Het is meer net hóe je er naar kijkt. Ik speelde advocaat van de duivel. Ook ik ga er niet vanuit dat een collection ooit een negatieve count / size() waarde teruggeeft.

[Verwijderd]

C#:

if (foo.count() < 0)
 World /= 0;

[yade]

C#:

        public static bool AreEqual( List<int> list)
        {
            return list == null || list.TrueForAll(x => x == list.First());
        }

Zo kan hij ook nog.

[.oisyn]

Verwijderd schreef op woensdag 20 oktober 2010 @ 00:15:

C#:

if (foo.count() < 0)
 World /= 0;

Da's een goed stukje code. Alleen Chuck Norris heeft lijsten met negatieve lengte. En laat het nou net ook Chuck Norris zijn die wél door 0 kan delen.

[RayNbow]

Verwijderd schreef op dinsdag 19 oktober 2010 @ 23:49:
Mijn punt blijft dat het niet juist gespecificeerd is wat het gedrag moet zijn als de lijst leeg is. Je kunt namelijk beredeneren dat er in een lege lijst geen getallen zijn, dus ze kunnen ook nergens aan gelijk zijn, dus mag je geen lege lijsten meegeven.

Redelijkerwijs kun je echter het gedrag vinden voor een lege lijst. Als je de volgende twee functies hebt:

Haskell:

allElementsAreEqual :: [a] -> Bool
containsDifferentElements :: [a] -> Bool

Dan wil je dat de volgende vergelijking geldt:

Haskell:

allElementsAreEqual = not . containsDifferentElements

Met deze vergelijking in het achterhoofd, welke invulling in onderstaande code is dan het meest logische?

Haskell:

allElementsAreEqual       []  =  ?
containsDifferentElements []  =  ?

[Noxious]

Ik heb een collega die niet helemaal snapt dat je in een UPDATE query meerdere velden kan meegeven geloof ik

PHP:

<?php
$resolution_id = addslashes(trim($_POST["id"]));
$resolution_description = addslashes(trim($_POST["description"]));
$resolution_width = addslashes(trim($_POST["width"]));
$resolution_height = addslashes(trim($_POST["height"]));
$resolution_name = $resolution_width . "x" . $resolution_height;
$stmt = sqlsrv_query($conn, "UPDATE Resolutions SET ResolutionW = " . $resolution_width . " WHERE ID = " . $resolution_id);
sqlsrv_free_stmt($stmt);
$stmt = sqlsrv_query($conn, "UPDATE Resolutions SET ResolutionH = " . $resolution_height . " WHERE ID = " . $resolution_id);
sqlsrv_free_stmt($stmt);
$stmt = sqlsrv_query($conn, "UPDATE Resolutions SET ResolutionName = '" . $resolution_name . "' WHERE ID = " . $resolution_id);
sqlsrv_free_stmt($stmt);
$stmt = sqlsrv_query($conn, "UPDATE Resolutions SET ResolutionDescription = '" . $resolution_description . "' WHERE ID = " . $resolution_id);
sqlsrv_free_stmt($stmt);
echo("<b>Resolution " . stripslashes(trim($resolution_name)) . " was updated.</b><br />\n");
?>

Oh en wtf @ trim

Die kan ik wel verklaren tho, alle velden in de database waren char(n) ipv varchar(n) in MSSQL

[ Voor 5% gewijzigd door Noxious op 20-10-2010 09:56 ]

[CodeCaster]

Lekker atomair ook.

[PiepPiep]

Boeboe schreef op dinsdag 19 oktober 2010 @ 16:18:
Waarom de cast?

Ehm.. omdat ik een beetje ziekjes ben en te lang niet echt meer iets met classes gedaan heb denk ik. Te lang in VB6 lopen klooien

[Gamebuster]

Noxious schreef op woensdag 20 oktober 2010 @ 09:54:
Ik heb een collega die niet helemaal snapt dat je in een UPDATE query meerdere velden kan meegeven geloof ik

PHP:

<?php
$resolution_id = addslashes(trim($_POST["id"]));
$resolution_description = addslashes(trim($_POST["description"]));
$resolution_width = addslashes(trim($_POST["width"]));
$resolution_height = addslashes(trim($_POST["height"]));
$resolution_name = $resolution_width . "x" . $resolution_height;
$stmt = sqlsrv_query($conn, "UPDATE Resolutions SET ResolutionW = " . $resolution_width . " WHERE ID = " . $resolution_id);
sqlsrv_free_stmt($stmt);
$stmt = sqlsrv_query($conn, "UPDATE Resolutions SET ResolutionH = " . $resolution_height . " WHERE ID = " . $resolution_id);
sqlsrv_free_stmt($stmt);
$stmt = sqlsrv_query($conn, "UPDATE Resolutions SET ResolutionName = '" . $resolution_name . "' WHERE ID = " . $resolution_id);
sqlsrv_free_stmt($stmt);
$stmt = sqlsrv_query($conn, "UPDATE Resolutions SET ResolutionDescription = '" . $resolution_description . "' WHERE ID = " . $resolution_id);
sqlsrv_free_stmt($stmt);
echo("<b>Resolution " . stripslashes(trim($resolution_name)) . " was updated.</b><br />\n");
?>

Oh en wtf @ trim

Die kan ik wel verklaren tho, alle velden in de database waren char(n) ipv varchar(n) in MSSQL

Geven UPDATE queries een resultaat terug; Heeft "free" enig nut na een UPDATE? Volgens mij geven die queries totaal geen resultaat terug.

[CodeCaster]

Ik zou trouwens wel eens width "0--" willen posten. Heb je een url?

[Noxious]

Gamebuster schreef op woensdag 20 oktober 2010 @ 11:54:
[...]

Geven UPDATE queries een resultaat terug; Heeft "free" enig nut na een UPDATE? Volgens mij geven die queries totaal geen resultaat terug.

Neuh en sowieso:
Only needs to be called if you are worried about using too much memory while your script is running.
All statement memory will automatically be freed when the script ends.

Dikke onzin al die free's dus.

CodeCaster schreef op woensdag 20 oktober 2010 @ 11:56:
Ik zou trouwens wel eens width "0--" willen posten. Heb je een url?

Helaas, is een intern beheersysteem

[ Voor 18% gewijzigd door Noxious op 20-10-2010 11:57 ]

[jip_86]

Wat is er mis met trim dan? Onnodige whitespace wil je toch niet in je data?

[Noxious]

Mja, behalve het feit dat ie er een keer dubbel in staat is het mogelijk nog logisch ja.
Echter wordt ook overal trim() gebruikt bij de exports uit de database, omdat het dus char velden waren

[Woy]

Noxious schreef op woensdag 20 oktober 2010 @ 11:56:
[...]

Neuh en sowieso:
Only needs to be called if you are worried about using too much memory while your script is running.
All statement memory will automatically be freed when the script ends.

Dikke onzin al die free's dus.

Ja want resources vrij geven op het moment dat je ze niet meer nodig hebt, is echt onzin

[djluc]

Woy schreef op woensdag 20 oktober 2010 @ 13:29:
[...]

Ja want resources vrij geven op het moment dat je ze niet meer nodig hebt, is echt onzin

In PHP is het getest dat het soms zelfs meer tijd kost dan de automatische vrijgave van resources als het script op het einde beland. Gezien het stateless is kan dit best voor te stellen zijn.

[Noxious]

Woy schreef op woensdag 20 oktober 2010 @ 13:29:
[...]

Ja want resources vrij geven op het moment dat je ze niet meer nodig hebt, is echt onzin

Waar zeg ik dat?

Ik vind het in een script waar deze 4 regels de enige query's zijn zonder enige return (het zijn updates, geen select oid met veel data) waar ze aan het einde van de pagina van slechts 20 regels worden vrijgegeven onzin ja.

[LinuX-TUX]

Beste Verwijderd in "[alg] Slechtste programmeervoorbeelden d..." & CyCloneNL in "[alg] Slechtste programmeervoorbeelden d...",

ik ben niet zo erg thuis in C#, daarom het volgende, wat gebeurd er als er maar 1 int in de array/list zit

Krijg je dan een index out of bounds voor je kiezen

edit:

Volgens mij zit ik zelf jullie 2 oplossingen te spaghettien in m'n hoofd tot mogelijke out of bounds

code:

for(int i = 1; i < numbers.count; i++)

!=

code:

for(int i = 1; i <= numbers.count; i++)

niets gezegt

---

Maar @ .oisyn : Net als java(script) krijg je dus een keiharde index out of bounds voor je kiezen (als er i <= numbers.count had gestaan?)

[ Voor 37% gewijzigd door LinuX-TUX op 20-10-2010 15:03 ]

[.oisyn]

LinuX-TUX schreef op woensdag 20 oktober 2010 @ 14:31:
Beste Verwijderd in "[alg] Slechtste programmeervoorbeelden d..." & CyCloneNL in "[alg] Slechtste programmeervoorbeelden d...",

ik ben niet zo erg thuis in C#, daarom het volgende, wat gebeurd er als er maar 1 int in de array/list zit

Dan returnt ie true, duh. De for-loop wordt dan nooit uitgevoerd.

.edit: oh wacht. Ik begreep je edit niet.

[ Voor 4% gewijzigd door .oisyn op 20-10-2010 14:43 ]

[Woy]

Noxious schreef op woensdag 20 oktober 2010 @ 14:25:
[...]

Waar zeg ik dat?

Ik vind het in een script waar deze 4 regels de enige query's zijn zonder enige return (het zijn updates, geen select oid met veel data) waar ze aan het einde van de pagina van slechts 20 regels worden vrijgegeven onzin ja.

Je geeft ook nergens aan dat het de enige 4 regels in het script zijn. Als dat zo is, dan zijn ze in dit geval misschien overbodig, maar ik zou het nog steeds geen onzin noemen om de resources expliciet vrij te geven. Het is hooguit overbodig in die situatie, maar niet slecht IMHO.

[ Voor 6% gewijzigd door Woy op 20-10-2010 15:16 ]

[Noxious]

Maar jij kon ook niet ruiken dat het een groot/klein script is, om het dan meteen af te doen met smilies vind ik wat overdreven

Maargoed, da's offtopic

Edit: overigens; uit hetzelfde pareltje:

PHP:

    //Resolutions
    case "resolutions":
        include("/pages/resolutions.page.php");
        break;
    case "deleteresolution":
        include("/pages/deleteresolution.page.php");
        break;
    case "newresolution":
        include("/pages/newresolution.page.php");
        break;
    case "saveresolution":
        include("/pages/saveresolution.page.php");
        break;
    case "editresolution":
        include("/pages/editresolution.page.php");
        break;
    case "updateresolution":
        include("/pages/updateresolution.page.php");
        break;

Dat moet toch eenvoudiger kunnen zou je zeggen

[ Voor 75% gewijzigd door Noxious op 20-10-2010 15:24 ]

[AtleX]

PHP:

<?php

$filename = "pages/".$page.".page.php";
if (file_exists($filename))
{
    include($filename);
}
?>

Al introduceer ik daarmee wel een beveiligingslek wat de code in jouw post niet heeft.

[ Voor 9% gewijzigd door AtleX op 20-10-2010 15:42 ]

[TJHeuvel]

Mwah, met zo'n kleine lijst aan mogelijkheden lijkt het me beter om te whitelisten dan blacklisten.
Zoals je zegt is het zomaar includen van bestanden behoorlijk gevaarlijk.

[Styxxy]

AtleX schreef op woensdag 20 oktober 2010 @ 15:42:
Al introduceer ik daarmee wel een beveiligingslek wat de code in jouw post niet heeft.

White listing toepassen en controlleren met bijvoorbeeld een in_array? Dat lijkt me toch beter te zijn dan die gehele switch.

[Gamebuster]

Noxious schreef op woensdag 20 oktober 2010 @ 11:56:
[...]

Neuh en sowieso:
Only needs to be called if you are worried about using too much memory while your script is running.
All statement memory will automatically be freed when the script ends.

Dikke onzin al die free's dus.


[...]

Helaas, is een intern beheersysteem

Onzin is het niet. Je wilt dat geheugen zo snel mogelijk weer vrij hebben. Normaal gesproken haal je wat data op en wordt het vrijgegeven aan het einde van het script, wanneer de gehele heap van het script verwijderd wordt (neem ik aan). Dit is niet erg als er weinig geheugengebruik is door bijv. enkele kleine queries, of wanneer er niet veel meer gerekend wordt wanneer de data er is. (ophalen, weergeven, einde script)

Wanneer je echter enorme lijsten met data ophaalt en daarna, wanneer je het niet meer gebruikt, nog eens andere zware berekeningen gaat draaien in PHP... dan zou je kunnen overwegen "free" te gebruiken om de extra paar microseconden aan extra rekentijd in te ruilen (hoeveel load kost een "free" op een groot query-resultaat nou eigenlijk? lijkt mij erg weinig) voor een aanzienlijk korter gebruik van veel geheugen, zodat je meer scripts naast elkaar kan draaien dan wanneer je geen "free" zou gebruiken; het geheugen wordt eerder vrijgegeven en dus kan dat vrijgegeven geheugen sneller gebruikt worden door andere scripts.

[Gamebuster]

AtleX schreef op woensdag 20 oktober 2010 @ 15:42:

PHP:

<?php

$filename = "pages/".$page.".page.php";
if (file_exists($filename))
{
    include($filename);
}
?>

Al introduceer ik daarmee wel een beveiligingslek wat de code in jouw post niet heeft.

Ik zou het doen met:

code:

<?php
$arrayMetLegaleFilenames = new Array("pagina1.php", "pagina2.php", "pagina3.php");
if($arrayMetLegaleFilenames->indexOf($filename) == -1)
  include($filename);
?>

Alleen maak je zo geen Array's in PHP, maar je snapt wat ik bedoel

[ Voor 9% gewijzigd door Gamebuster op 20-10-2010 15:55 ]

[Verwijderd]

Waarom zou je nog PHP gebruiken als je bezorgd bent over snelheid en geheugengebruik? Zeg ik nu iets heel stoms als ik dat vergelijkbaar vind met een botte bijl gebruiken voor een openhartoperatie, terwijl je bang bent voor complicaties?

[TJHeuvel]

Ja. Dat is heel stom.

PHP is niet inherent onveilig, de gemiddelde PHP programmeur is gewoon wat minder ervaren en daarom komt de taal als onveilig over.

[Matis]

Gamebuster schreef op woensdag 20 oktober 2010 @ 15:54:
Ik zou het doen met:

code:

<?php
$arrayMetLegaleFilenames = new Array("pagina1.php", "pagina2.php", "pagina3.php");
if($arrayMetLegaleFilenames->indexOf($filename) == -1)
  include($filename);
?>

Alleen maak je zo geen Array's in PHP, maar je snapt wat ik bedoel

Psst in_array()

[AtleX]

Verwijderd schreef op woensdag 20 oktober 2010 @ 15:56:
Waarom zou je nog PHP gebruiken als je bezorgd bent over snelheid en geheugengebruik?

Waarom niet? Ik draai een vrij druk gebruikte applicatie (~150 hits/second) op een machientje met 256MB geheugen. Er hangt een DB achter van zo'n 7GB en daaruit wordt random data gehaald. Dat werkt prima met een vrij stabiele CPU-belasting van zo'n 25-30%.

[ Voor 7% gewijzigd door AtleX op 20-10-2010 15:59 ]

[TJHeuvel]

Waarom bouwen we uberhaupt nog applicaties op een compiler, en typen we niet gewoon nulletjes en eentjes. Daarme haal je het meeste uit je CPU!

Nou, omdat dat langzaam ontwikkelen is. Zelfs Facebook maakt hun websites in PHP, en zet het daarna automatisch om naar C++.

[ Voor 3% gewijzigd door TJHeuvel op 20-10-2010 16:11 ]

[Noxious]

Matis schreef op woensdag 20 oktober 2010 @ 15:58:
[...]

Psst in_array()

Daar zat ik ook aan te denken ja

Overigens, ik bedoel niet dat free's altijd onzin zijn, maar in dit specifieke geval wel.

[Sebazzz]

CyCloneNL schreef op woensdag 20 oktober 2010 @ 16:06:
Nou, omdat dat langzaam ontwikkelen is. Zelfs Facebook maakt hun websites in PHP, en zet het daarna automatisch om naar C++.

Afaik gebruiken ze een andere runtime, die de boel JIT maar omzetten naar C++, volgens mij niet

Overigens over high-level vs low-level: Met bijvoorbeeld .NET's ngen (native assembly generator) kan je .NET assemblies naar native assemblies omzetten. Dit hoef niet altijd sneller te zijn, omdat bijvoorbeeld in een .NET assembly de JIT security checks zou kunnen overslaan in bepaalde condities, wat bij een native assembly niet zou gebeuren.

[TJHeuvel]

PHP HipHop
HipHop transforms your PHP source code into highly optimized C++ and then compiles it with g++ to build binary files. You keep coding in simpler PHP, then HipHop executes your source code in a semantically equivalent manner and sacrifices some rarely used features – such as eval() – in exchange for improved performance.

Al denk ik zelf dat er meer baat is bij het minder CPU gebruik dan het minderen van laad tijd. Stel dat je op je gigantische serverpark (wat Facebook ongetwijfeld beschikt) 1% minder CPU kunt gebruiken scheelt dat natuurlijk onwijs in kosten.

[CodeCaster]

Sebazzz schreef op woensdag 20 oktober 2010 @ 16:18:
[...]

Afaik gebruiken ze een andere runtime, die de boel JIT maar omzetten naar C++, volgens mij niet

Overigens over high-level vs low-level: Met bijvoorbeeld .NET's ngen (native assembly generator) kan je .NET assemblies naar native assemblies omzetten. Dit hoef niet altijd sneller te zijn, omdat bijvoorbeeld in een .NET assembly de JIT security checks zou kunnen overslaan in bepaalde condities, wat bij een native assembly niet zou gebeuren.

quote: http://developers.facebook.com/blog/post/358

HipHop for PHP isn't technically a compiler itself. Rather it is a source code transformer. HipHop programmatically transforms your PHP source code into highly optimized C++ and then uses g++ to compile it. HipHop executes the source code in a semantically equivalent manner and sacrifices some rarely used features — such as eval() — in exchange for improved performance.

[kaesve]

toch wel, volgens mij:
http://github.com/facebook/hiphop-php/wiki

HipHop transforms your PHP source code into highly optimized C++ and then compiles it with g++ to build binary files. You keep coding in simpler PHP, then HipHop executes your source code in a semantically equivalent manner and sacrifices some rarely used features – such as eval() – in exchange for improved performance.

[Sebazzz]

CyCloneNL schreef op woensdag 20 oktober 2010 @ 16:23:
[...]

CodeCaster schreef op woensdag 20 oktober 2010 @ 16:23:
[...]


[...]

kaesve schreef op woensdag 20 oktober 2010 @ 16:23:
toch wel, volgens mij:
http://github.com/facebook/hiphop-php/wiki


[...]

C-c-c-combobreaker
Van wat ik mij kon herinneren van de Tweakers.net FP was het een andere runtime, niets meer, maar blijkbaar zat ik fout.

[ Voor 13% gewijzigd door Sebazzz op 20-10-2010 16:26 ]

[Soultaker]

Over de prestatiewinst met HipHop was ik persoonlijk trouwens niet te spreken. Dat is ook niet zo verwonderlijk als je bedenkt dat HipHop dezelfde library implementatie als de Zend Engine gebruikt en dus ook precies dezelfde interne datastructuren.

Het performanceverschil tussen een PHP-programma dat werkt op een array (wat een ingewikkelde hashtable-achtige constructie is, intern) met bijvoorbeeld een C++-programma dat een std::vector gebruikt, is daardoor nog steeds gigantisch groot. Waarschijnlijk is dat ook niet praktisch op te lossen. Het enige voordeel dat je van HipHop hebt, is dat de PHP code zelf efficiënter uitgevoerd kan worden.

Maar de interpreter van de Zend Engine is niet zo traag. Meestal zit de bottleneck elders. Dus valt er met HipHop weinig te winnen, naar mijn idee, en is het nogal een zinloos project. Ik weet niet of ik de enige ben die HipHop daadwerkelijk uitgeprobeerd heeft? Zo niet, wat zijn jullie ervaringen daarmee?

[ Voor 15% gewijzigd door Soultaker op 20-10-2010 16:57 ]

[Gamebuster]

Verwijderd schreef op woensdag 20 oktober 2010 @ 15:56:
Waarom zou je nog PHP gebruiken als je bezorgd bent over snelheid en geheugengebruik? Zeg ik nu iets heel stoms als ik dat vergelijkbaar vind met een botte bijl gebruiken voor een openhartoperatie, terwijl je bang bent voor complicaties?

Tja, niet iedereen verwacht dat zijn site zwaar belast zal worden. Als je PHP site opeens veel bezoekers krijgt kan overwegen de sourcecode te optimaliseren of de site herschrijven naar een andere omgeving. (of PHP optimzers/caches/compilers/whatever)

[.oisyn]

Nog nooit uitgeprobeerd, maar ik had dus precies dezelfde bedenkingen als jij. Het is niet de interpreter/VM die PHP relatief traag maakt, het zijn de gebruikte datastructuren en de dynamic binding wat het inherent trager maakt dan menig strong typed taal.

[AtleX]

CyCloneNL schreef op woensdag 20 oktober 2010 @ 16:06:
Waarom bouwen we uberhaupt nog applicaties op een compiler, en typen we niet gewoon nulletjes en eentjes. Daarme haal je het meeste uit je CPU!

Vast wel, maar of het ook sneller is is een tweede. Er zijn niet veel programmeurs slimmer dan een compiler qua optimalisaties.

Soultaker schreef op woensdag 20 oktober 2010 @ 16:55:
Zo niet, wat zijn jullie ervaringen daarmee?

Ik heb het voor de lol wel even gedraaid, maar niet echt gemeten wat de prestatieverschillen waren. Het verschil was iig niet enorm.

[ Voor 27% gewijzigd door AtleX op 21-10-2010 11:26 ]

[Matis]

AtleX schreef op donderdag 21 oktober 2010 @ 11:25:
Vast wel, maar of het ook sneller is is een tweede. Er zijn niet veel programmeurs slimmer dan een compiler qua optimalisaties.

Een compiler is ook gemaakt door mensen

Ik heb het voor de lol wel even gedraaid, maar niet echt gemeten wat de prestatieverschillen waren. Het verschil was iig niet enorm.

Maar was het prestatieverschil in het voordeel van HipHop of niet?

[Verwijderd]

Matis schreef op donderdag 21 oktober 2010 @ 11:27:
[...]

Een compiler is ook gemaakt door mensen

Maar mensen kunnen in de praktijk toch wel alle instanties van het halting-probleem oplossen, en daar kan geen enkel algoritme tegen op. Op vergelijkbare manier kunnen mensen met ervaring inzichten hebben die je niet zomaar kunt abstraheren in een optimizer.

[AtleX]

Matis schreef op donderdag 21 oktober 2010 @ 11:27:
[...]

Een compiler is ook gemaakt door mensen

Ja door een groep mensen die jaren erover hebben gedaan om alle optimalisaties in te bouwen. Knappe jongen die dat nu allemaal zo uit zijn hoofd doet als hij zijn applicatie zit te bouwen.

[...]

Maar was het prestatieverschil in het voordeel van HipHop of niet?

Ja.

[.oisyn]

Daarentegen is een mens weer niet goed in repetitive mundane tasks en recursie, en is hij daarnaast vergeetachtig.

[ Voor 5% gewijzigd door .oisyn op 21-10-2010 11:47 ]

[Verwijderd]

Wat betreft dat eerste: zie WoW. Wat betreft dat tweede: zie mijn tweede punt.

[.oisyn]

Verwijderd schreef op donderdag 21 oktober 2010 @ 12:53:
Wat betreft dat eerste: zie WoW

Ah ja, vandaar dat iedereen chinezen inhuurt om dat te doen. Ga jij dat ook doen als je je code wilt compilen? Plus het feit dat die chinezen gebruik maken van macro's en scripts. Wat dat betreft is WoW gewoon een ontzettend slecht voorbeeld omdat je nou eenmaal gelimiteerd bent aan de real-time progressie van het spel, wat bij compilen niet het geval is (een compiler kan heel veel sneller combinaties uitproberen dan een miljoen chinezen dat kunnen)

[ Voor 40% gewijzigd door .oisyn op 21-10-2010 14:52 ]

[yade]

Outcompilen i.p.v. outsourcen. Ik vind het wel wat hebben.

[Vinnienerd]

Matis schreef op donderdag 21 oktober 2010 @ 11:27:
[...]
Een compiler is ook gemaakt door mensen

Computers zijn ook gemaakt door mensen

[Matis]

Vinnienerd schreef op vrijdag 22 oktober 2010 @ 02:09:
Computers zijn ook gemaakt door mensen

Precies, weg met die ondingen

Ohnee, doe maar niet. Anders mag ik vanaf maandag een nieuwe baan zoeken

[Verwijderd]

Jongens, doe eens weer een beetje ontopic?

Een schoonheid die ik onlangs aantrof:

code:

def p = processor.process(item)

if (p) {
   def l = []
   l << p
   l = l.flatten()
   l.each { pr ->
      result << pr
   }
}

[Verwijderd]

Matis schreef op donderdag 21 oktober 2010 @ 11:27:
[...]
Een compiler is ook gemaakt door mensen

Auto ook, toch verplaatst een auto zich sneller
Vliegtuig ook, toch ....
...

[Soultaker]

AtleX schreef op donderdag 21 oktober 2010 @ 11:25:
Er zijn niet veel programmeurs slimmer dan een compiler qua optimalisaties.

Err, ik gebruik geen compiler omdat die beter code kan genereren dan ik, maar omdat ik dan op een hoger niveau kan programmeren en daarmee m'n tijd aanzienlijk nuttiger kan besteden. Als ik het eeuwige leven had en performance van de gegenereerde code het enige criterium was (en leesbaarheid, onderhoudbaar, portabiliteit, correctheid enzovoorts geen rol speelden) zou ik aanzienlijk meer in assembly coden.

Verwijderd schreef op donderdag 21 oktober 2010 @ 11:35:
Maar mensen kunnen in de praktijk toch wel alle instanties van het halting-probleem oplossen, en daar kan geen enkel algoritme tegen op.

Vertel dat tegen deze lui: http://www.termination-po...mination_Competition_2010

[Verwijderd]

Ik vind dit wel een bijzonder slecht programmeervoorbeeld:

[Davio]

Verwijderd schreef op zaterdag 23 oktober 2010 @ 06:41:
Ik vind dit wel een bijzonder slecht programmeervoorbeeld:

[afbeelding]

Tenzij je hem moet modelleren met een polygon.

[pieturp]

Verwijderd schreef op zaterdag 23 oktober 2010 @ 06:41:
afbeelding]

ROFL

[Wijnbo]

Verwijderd schreef op zaterdag 23 oktober 2010 @ 06:41:
Ik vind dit wel een bijzonder slecht programmeervoorbeeld:

[afbeelding]

?

Of bedoel je die site die er achter zit

[Verwijderd]

Speciaal voor Wijnbo: [grapuitlegmodus]

spoiler:

Een banaan heeft niets met programmeren te maken en is dus een slecht voorbeeld.

[/grapuitlegmodus]

[Haan]

flauw

[jbdeiman]

Leuke vragen toch, ze houden helemaal geen rekening met wat er in een kas kan groeien Ik had er iig best wat fout, maar het slaat ook nergens op. De manier van vragen stellen is niet logisch. Daarnaast zou ik niet naar het WO (ik hoop toch echt dat dat op die site niet voor Wetenschappelijk Onderwijs staat) willen als ze daar zo'n niveau hebben.

[Davio]

Verwijderd schreef op zaterdag 23 oktober 2010 @ 02:40:
Jongens, doe eens weer een beetje ontopic?

Een schoonheid die ik onlangs aantrof:

code:

def p = processor.process(item)

if (p) {
   def l = []
   l << p
   l = l.flatten()
   l.each { pr ->
      result << pr
   }
}

Def P!

[Haan]

Davio schreef op maandag 25 oktober 2010 @ 10:47:
[...]

Def P!

[afbeelding]

Weten we meteen wat hij deed voordat hij de muziek in ging

[Matis]

Naar aanleiding ontdekking afgelopen vrijdag

Matis schreef op vrijdag 22 oktober 2010 @ 14:28:
fuuuuuuuuuuu IK kom er zojuist (ook) achter dat Mijn ING dus niet hoofdlettergevoelig is

Is capslockday toch nog ergens goed voor

Krijg ik zojuist een mailtje van de ING-servicebalie

Geachte Matis,

De beantwoording van uw e-mail is vertraagd. Onze excuses hiervoor.

Het klopt dat het wachtwoord voor Mijn ING niet hoofdlettergevoelig is en de gebruikersnaam wel.

Uit onderzoek is gebleken dat de hoofdlettergevoeligheid van de gebruikersnaam en de voorwaarden die gesteld zijn aan beide inlogcodes de veiligheid van onze klanten waarborgen. Uw melding hierover hebben wij wel geregistreerd en doorgestuurd naar de verantwoordelijke afdeling. Deze afdeling neemt dit mee in het verbeteringsproces.

Bedankt voor uw melding.

Met vriendelijke groet,
ING Klantenservice

Dhr. A.L. #####
Manager Verkoop en Service

Over slecht programmeervoorbeeld gesproken

[Aloys]

Verwijderd schreef op zaterdag 23 oktober 2010 @ 06:41:
Ik vind dit wel een bijzonder slecht programmeervoorbeeld:

[afbeelding]

Je gaat het niet geloven , maar wij hebben een dictaat hier op de RUG:



edit: Als je goed oplet zie je dat het zelfs dezelfde (echt waar) banaan is .

[ Voor 9% gewijzigd door Aloys op 25-10-2010 19:14 ]

[roy-t]

Aloys schreef op maandag 25 oktober 2010 @ 19:13:
[...]

Je gaat het niet geloven , maar wij hebben een dictaat hier op de RUG:
[afbeelding]


edit: Als je goed oplet zie je dat het zelfs dezelfde (echt waar) banaan is .

Zie hier het vak dat dit jaar zo vreselijk slecht gemaakt wordt dat zelfs onze legendarische Harm Bakker ingehuurd wordt als practicum assistent... .

* roy-t schaamt zich voor de mensen die moeite hebben met dat vak, maar vraagt zich wel heel erg af of er wat anders aan de hand is.

[Verwijderd]

Aloys schreef op maandag 25 oktober 2010 @ 19:13:
Je gaat het niet geloven , maar wij hebben een dictaat hier op de RUG:
[afbeelding]


edit: Als je goed oplet zie je dat het zelfs dezelfde (echt waar) banaan is .

Die mag Arnold Meijster in zijn zak steken! Ook een slecht Photoshopvoorbeeld trouwens

What are the odds...

[FragFrog]

roy-t schreef op maandag 25 oktober 2010 @ 19:47:
* roy-t schaamt zich voor de mensen die moeite hebben met dat vak, maar vraagt zich wel heel erg af of er wat anders aan de hand is.

't wordt continue overhoop gehaald en men loopt elk jaar weer te verschuiven wat het nou moet doen. Nogal logisch dat't een brak vak is wat je snel moet halen en vergeten.

De logica van eerst functioneel programmeren in JAVA en daarna OOP in C++ is me ook nooit helemaal duidelijk geworden, al schijnt dat voor OOP in C++ nu iets van datastructuren in de plaats is gekomen. Ze werken er wel aan.. 't lijkt alleen nooit heel erg te lukken