[alg] Slechtste programmeervoorbeelden deel 5

[Creepy]

Blubber/DeadInspace: voer dat eens uit met "A. Th." (zie commentaar van Janoz ).

_{edit: anders is Janoz nog net ff sneller.....}

[ Voor 26% gewijzigd door Creepy op 05-12-2013 15:07 ]

[LapjeDZ]

Kwam van de week dit juweeltje tegen bij een klasgenoot die met JPanels probeerde te werken

Java:

public void Repaint() {
    repaint();
}

Hebben we iig goed om kunnen lachen.

[Caelorum]

Nu weet ik dat repaint() al public is, maar dit is natuurlijk wel een manier om private methods alsnog te exposen

[Janoz]

Nou, het enige wat daar gebeurt is een dikke stackoverflow

[ Voor 15% gewijzigd door Janoz op 05-12-2013 21:40 ]

[Caelorum]

Janoz schreef op donderdag 05 december 2013 @ 18:48:
Nou, het enige wat daar gebeurt is een dikke stackoverflow

Want? Het zijn toch twee verschillende functies?

[Safaci]

Tja, als meneer wil dat elke functie met een hoofdletter begint, dan is dit een oplossing.

[thomasmoors]

#define TRUE FALSE

vind ik een mooi voorbeeld

[kenneth]

C#:

protected void MyEventHandler(object sender, EventArgs e)
{
    if (foo % 2 == 0)
    {
        switch(columnName)
        {
            case "NameColumn":
                bar = MyMethod("NameColumn", true);
                break;
            case "FieldColumn":
                bar = MyMethod("FieldColumn", true);
                break;
            case "OtherFieldColumn":
                bar = MyMethod("OtherFieldColumn", true);
                break;
        }
    }
    else
    {
        switch(columnName)
        {
            case "NameColumn":
                bar = MyMethod("NameColumn", false);
                break;
            case "FieldColumn":
                bar = MyMethod("FieldColumn", false);
                break;
            case "OtherFieldColumn":
                bar = MyMethod("OtherFieldColumn", false);
                break;
        }
    }
}

[Caelorum]

oh god.. ^^

[-Sander1981-]

kenneth schreef op dinsdag 10 december 2013 @ 15:51:
...

C#:

protected void MyEventHandler(object sender, EventArgs e)
{
    bool descriptiveName = foo % 2 == 0;
    switch(columnName)
    {
        case "NameColumn":
        case "FieldColumn":
        case "OtherFieldColumn":
            bar = MyMethod(columnName, descriptiveName);
            break;
    }
}

Zo te zien is het belangrijk dat dit een van deze drie kolommen is. Nu is een switch voor dat soort dingen ook niet echt bedoeld, dus hoe zouden jullie dat aanpakken?

[ Voor 6% gewijzigd door -Sander1981- op 10-12-2013 17:32 ]

[Alex)]

Belangrijkste vraag: wat moet het doen? Gezien de foo % 2 vermoed ik dat het gebruikt wordt in de front-end voor zebra striping (ListView?), dat zou je ook op kunnen lossen met een AlternateItemTemplate.

[bwerg]

Caelorum schreef op donderdag 05 december 2013 @ 16:44:
Nu weet ik dat repaint() al public is, maar dit is natuurlijk wel een manier om private methods alsnog te exposen

Je kunt gewoon de methode zelf overriden met een andere, zwakkere, access modifier. Dat verbieden heeft niet veel zin omdat men anders alsnog deze omweg kan nemen om hetzelfde te bereiken, wat de boel alleen maar lelijker maakt.

[defixje]

Verwijderd schreef op woensdag 04 december 2013 @ 19:54:
Collega vanmiddag:

PHP:

<?php

   if ($not_found) {
      ob_clean();
      header('HTTP/1.1 301 Moved Permanently');
      header("Location: http://www.nieuwe-url-yolo.com/");
      exit;
      clean_up_routine_that_does_something_important();
   }

"MIJN CLEANUP ROUTINE WERKT NIET MEER"

Nou dat ik gekk!! Ik schat dat die exit; gewoon op regel 2 moet komen te staan....

[ Voor 7% gewijzigd door defixje op 11-12-2013 01:28 ]

[Sjaaky]

kenneth schreef op donderdag 05 december 2013 @ 11:48:
binnen iedere iteratie van een foreach excepties afvangen die gecheckt hadden kunnen worden of op z'n minst buiten de loop eenmalig opgevangen kunnen worden, yay!

Checken en voorkomen, ben helemaal met je eens .
Eenmalig buiten de loop opvangen niet. Die foreach ziet eruit als de mainloop die alle items verwerkt. Als er 1 item een exception geeft wil je de rest nog steeds verwerken. Niets zo vervelend als 1 falend item/dossier/order/you-name-it, dat de hele nachtelijke batchverwerking stopt. Zelfs als ik zeker weet dat er geen exceptions uit mijn code komen, voeg ik toch een algemene try-catch-log toe binnen de loop. Een klant kan vaak wel leven met enkele items die een paar dagen later verwerkt worden, maar als alles stopt kan ik pas gaan slapen als ik het opgelost heb.

[kenneth]

Hij vangt een IOORException af op args[] (zie comment), dat kan eenmalig aan het begin van Main.

[Stroopwafels]

Niet echt een programmeerfout maar error reporting aan op een live omgeving...
Full path disclosure is ook leuk trouwens.

[ Voor 15% gewijzigd door Stroopwafels op 13-12-2013 14:23 ]

[BlueMotion]

hoezo lussen gebruiken:

code:

mainloop(){
  //keep running the following code
  readInput();
  doSomething();
  callOtherFunction();

  mainloop();
}

Deze jongen was erg handig met programmaatjes schrijven, maar had geen flauw benul van de kracht van recursie

[Styxxy]

BlueMotion schreef op zondag 15 december 2013 @ 21:43:
hoezo lussen gebruiken:
[...]
Deze jongen was erg handig met programmaatjes schrijven, maar had geen flauw benul van de kracht van recursie

En dan na X-veel-keer tegen een stack overflow lopen (nu ja, zal wel héél lang duren in dit geval, maar dan nog).

Edit: duurde niet echt lang bij mij (functies zonder body gemaakt).

[ Voor 8% gewijzigd door Styxxy op 15-12-2013 22:33 ]

[kenneth]

Als de compiler tail recursion elimination ondersteunt zal het wel meevallen met de stack overflow

[Bosmonster]

JavaScript:

jQuery.fn.encHTML = function () {
    return this.each(function () {
        var me = jQuery(this);
        var html = me.html();
        me.html(html.replace(/&/g, '&amp;').replace(/</g, '&lt;').replace(/>/g, '&gt;'));
    });
};

jQuery.fn.decHTML = function () {
    return this.each(function () {
        var me = jQuery(this);
        var html = me.html();
        me.html(html.replace(/&amp;/g, '&').replace(/&lt;/g, '<').replace(/&gt;/g, '>'));
    });
};

jQuery.fn.isEncHTML = function (str) {
    if (str.search(/&amp;/g) != -1 || str.search(/&lt;/g) != -1 || str.search(/&gt;/g) != -1)
        return true;
    else
        return false;
};

jQuery.fn.decHTMLifEnc = function () {
    return this.each(function () {
        var me = jQuery(this);
        var html = me.html();
        if (jQuery.fn.isEncHTML(html))
            me.html(html.replace(/&amp;/g, '&').replace(/&lt;/g, '<').replace(/&gt;/g, '>'));
    });
}

[R4gnax]

Bosmonster schreef op maandag 16 december 2013 @ 14:16:

JavaScript:

jQuery.fn.encHTML = function () {
    return this.each(function () {
        var me = jQuery(this);
        var html = me.html();
        me.html(html.replace(/&/g, '&amp;').replace(/</g, '&lt;').replace(/>/g, '&gt;'));
    });
};

jQuery.fn.decHTML = function () {
    return this.each(function () {
        var me = jQuery(this);
        var html = me.html();
        me.html(html.replace(/&amp;/g, '&').replace(/&lt;/g, '<').replace(/&gt;/g, '>'));
    });
};

jQuery.fn.isEncHTML = function (str) {
    if (str.search(/&amp;/g) != -1 || str.search(/&lt;/g) != -1 || str.search(/&gt;/g) != -1)
        return true;
    else
        return false;
};

jQuery.fn.decHTMLifEnc = function () {
    return this.each(function () {
        var me = jQuery(this);
        var html = me.html();
        if (jQuery.fn.isEncHTML(html))
            me.html(html.replace(/&amp;/g, '&').replace(/&lt;/g, '<').replace(/&gt;/g, '>'));
    });
}

Ok. Eens even kijken ...

1. Iterative ipv atomatic replacement levert bij bepaalde reeksen bugs op.
2. Niet alle noodzakelijke characters worden ge-escaped. De slash is in IE niet veilig. Quotes zijn in de regel niet altijd veilig. Bepaalde typen line breaks moeten voor IE ge-escaped worden alvorens ze als HTML ingevoegd worden anders leveren ze problemen op. etc.
3. Waarom het wiel opnieuw uitvinden? jQuery.fn.text() is bedoeld om tekst als tekst in te voegen.
4. Gaan controleren of een string HTML-encoded is? "Wat is deze string? Kies: html <-> tekst"

Heb ik ze dan zo ongeever?

[ Voor 6% gewijzigd door R4gnax op 16-12-2013 20:02 ]

[kenneth]

Guard clauses op deze manier geïmplementeerd:

C#:

private void MyComboBox_SelectedValueChanged(object sender, EventArgs e)
{
    if (!isInitializing)
    {
        if (this.MyComboBox.SelectedValue != null)
        {
            DataRowView dataRowView = this.MyComboBox.SelectedItem as DataRowView;
            if (dataRowView != null)
            {
                // code hier
            }
        }
    }
}

De feitelijke code van de methode begint op vier indentniveaus diep

[Alex)]

Als ik een OnItemDataBound-eventhandler implementeer maak ik vaak zulke constructies:

C#:

private void ListView_OnItemDataBound(object sender, ListViewItemEventArgs e) 
{
    var dataItem = e.Item as ListViewDataItem;
    
    if (e.Item.ItemType == ListViewItemType.DataItem && dataItem != null) 
    {
        var myClass = dataItem as MyClass;
        
        if (myClass != null) 
        { 
            // doe iets
        } 
    } 
}

Ik vind het niet echt nette code, maar ik weet ook niet echt hoe het beter zou kunnen. Ik zou de nesting kunnen omdraaien (return early) maar dat vind ik ook niet echt netjes ogen...

[kenneth]

Ik heb er nu dit van gemaakt zodat de (lijvige) body niet ergens rechts van mijn monitor begint:

C#:

if (!isInitializing)
{
    return;
}

if (this.MyComboBox.SelectedValue == null)
{
    return;
}

DataRowView dataRowView = this.MyComboBox.SelectedItem as DataRowView;
if (dataRowView == null)
{
    return;
}

// code hier

Maargoed, UI-code is toch vaak verre van elegant met alle casts, validaties en dergelijke.

[Alex)]

Die tweede check is eigenlijk overbodig hè

[kenneth]

Ik heb eigenlijk geen flauw idee waarom hij erin zit, ik blijf er lekker af

[Caelorum]

kenneth schreef op dinsdag 17 december 2013 @ 10:53:
Ik heb er nu dit van gemaakt zodat de (lijvige) body niet ergens rechts van mijn monitor begint: [...]

C#:

DataRowView dataRowView = this.MyComboBox.SelectedItem as DataRowView;
if ( !isInitializing
     || this.MyComboBox.SelectedValue == null
     || dataRowView == null)
{
    return;
}

// code hier

Of heb ik hier nu een early morning code stukje te pakken van mijzelf?

[ Voor 7% gewijzigd door Caelorum op 17-12-2013 11:25 ]

[kenneth]

Ja, beter zo eigenlijk denk ik

[BryanD]

Caelorum schreef op dinsdag 17 december 2013 @ 11:24:
[...]

C#:

DataRowView dataRowView = this.MyComboBox.SelectedItem as DataRowView;
if ( !isInitializing
     || this.MyComboBox.SelectedValue == null
     || dataRowView == null)
{
    return;
}

// code hier

Of heb ik hier nu een early morning code stukje te pakken van mijzelf?

Is het op deze manier niet zo dat als die this.MyComboBox.SelecteItem (neem aan dat die uit de SelectedValue komt) leeg is dat je dan een oopsie krijgt met het toekenen aan je dataRowView? Of wordt dataRowView dan gewoon false of null o.i.d.?

[kenneth]

C#:

var dataRowView = new ComboBox().SelectedItem as DataRowView;

Assert.Equal(null, dataRowView); // klopt, geen NRE 

[Caelorum]

BryanD schreef op dinsdag 17 december 2013 @ 11:57:
[...] Is het op deze manier niet zo dat als die this.MyComboBox.SelecteItem (neem aan dat die uit de SelectedValue komt) leeg is dat je dan een oopsie krijgt met het toekenen aan je dataRowView? Of wordt dataRowView dan gewoon false of null o.i.d.?

Jup,

[...] The as operator is like a cast operation. However, if the conversion isn't possible, as returns null instead of raising an exception [...]
The code is equivalent to the following expression except that the expression variable is evaluated only one time.

C#:

expression is type ? (type)expression : (type)null

MSDN: as (C# Reference)

[Woy]

Maar als MyComboBox null is tijdens het initializen krijg je wel een ander resultaat dan het originele stuk code , de naamgeving van "MyComboBox_SelectedValueChanged" doet vermoeden dat dat niet voor kan komen natuurlijk

Overigens hoef je de

C#:

this.MyComboBox.SelectedValue == null

check ook niet te doen, want die vang je al af door de

C#:

dataRowView == null

Check.

[ Voor 60% gewijzigd door Woy op 17-12-2013 15:01 ]

[Caelorum]

Woy schreef op dinsdag 17 december 2013 @ 14:58:
Maar als MyComboBox null is tijdens het initializen krijg je wel een ander resultaat dan het originele stuk code , [...]

Daar werd alleen in het eerste stukje code ook al niet op gecheckt dus

[Woy]

Caelorum schreef op dinsdag 17 december 2013 @ 15:00:
[...]

Daar werd alleen in het eerste stukje code ook al niet op gecheckt dus

Maar door de !isInitializing check word die code niet uitgevoerd. Dus hoewel het in deze situatie geen problemen op zal leveren is het wel degelijk ander gedrag. Hetzelfde geld bijvoorbeeld als SelectedItem een exception zou kunnen gooien als nog niet alles geïnitialiseerd is.

[afraca]

Ik kan er ook niks aan doen dat ik het tegenkwam, als het over elke andere taal ging had ik het net zo goed gepost, maar we gaan het even hebben over PHP..... Want waarom toch soms van die inconsistente functienamen?

On 12/16/2013 07:30 PM, Rowan Collins wrote:

> The core functions which follow neither rule include C-style
> abbreviations like "strptime" which couldn't be automatically swapped to
> either format, and complete anomalies like "nl2br". If you named those
> functions as part of a consistent style, you would probably also follow
> stronger naming conventions than Rasmus did when he named
> "htmlspecialchars".

Well, there were other factors in play there. htmlspecialchars was a
very early function. Back when PHP had less than 100 functions and the
function hashing mechanism was strlen(). In order to get a nice hash
distribution of function names across the various function name lengths
names were picked specifically to make them fit into a specific length
bucket. This was circa late 1994 when PHP was a tool just for my own
personal use and I wasn't too worried about not being able to remember
the few function names.

-Rasmus

http://news.php.net/php.internals/70691

[Caelorum]

Woy schreef op dinsdag 17 december 2013 @ 15:02:
[...] Maar door de !isInitializing check word die code niet uitgevoerd. Dus hoewel het in deze situatie geen problemen op zal leveren is het wel degelijk ander gedrag. [...]

Klopt helemaal, veranderen naar && not true checks dan maar?

[pieturp]

Kwam deze niksnut vandaag in één van m'n projecten tegen:

PHP:

if ($errors && count($errors)) {
                
}

[ValHallASW]

afraca schreef op dinsdag 17 december 2013 @ 17:31:
Ik kan er ook niks aan doen dat ik het tegenkwam, als het over elke andere taal ging had ik het net zo goed gepost, maar we gaan het even hebben over PHP..... Want waarom toch soms van die inconsistente functienamen?


[...]


http://news.php.net/php.internals/70691

Waarom überhaupt hash buckets als je toch maar 100 entries hebt? Het is niet alsof die 5-in-plaats-van-50-vergelijkingen de wereld gaat schelen. En áls je dan met hash buckets gaat werken... strlen()? Hoe bedenk je het?! Zelfs het eerste karakter van de string nemen is nog logischer...

[afraca]

ValHallASW schreef op dinsdag 17 december 2013 @ 20:42:
[...]

Waarom überhaupt hash buckets als je toch maar 100 entries hebt? Het is niet alsof die 5-in-plaats-van-50-vergelijkingen de wereld gaat schelen. En áls je dan met hash buckets gaat werken... strlen()? Hoe bedenk je het?! Zelfs het eerste karakter van de string nemen is nog logischer...

Rasmus was natuurlijk al groot aan het dromen Daarom een dergelijke briljante "hash"-functie.... En ik vind je suggestie briljant voor een alternatieve aanpak

[Mawlana]

SQL:

select * from tasks 
where trunc(tasks.Modified_Date)>=To_char(trunc(sysdate-7,'IW')) and 
trunc(tasks.Modified_Date)<to_char(TRUNC(sysdate,'IW'))

SQL:

select * from tasks 
where to_char(tasks.In_Progress,'IYYYIW')=to_char(sysdate-7,'IYYYIW')

En maar afvragen waarom die queries er zo lang overdoen...

Ik vind het nog opmerkelijk dat de eerste query wel resultaten teruggeeft (datum vs string).

[Hipska]

OMG, ik wist niet dat dat nog bestond, en dan nog op onze eigen tweakblogs!
chaozz: Using readable dates in SQL and PHP

[Xantios]

Hipska schreef op dinsdag 07 januari 2014 @ 11:25:
OMG, ik wist niet dat dat nog bestond, en dan nog op onze eigen tweakblogs!
chaozz: Using readable dates in SQL and PHP

Ik zie hier niet direct het probleem mee?
Sorteert lekker makkelijk joh !

[naam]

JavaScript:

$.ajax({
    type: 'POST',
    url:  post_url,
    data: selected_filters,
    success: function(data, textStatus, jqXHR) {
        $('#ajax_result').html(data);
        eval ("$('a[rel^=facebox_]').fancybox(options);");
        eval ("$('a[class=roomGet]').click(submit_cart);");
    },
    dataType: 'html'
});

Dit had niet in eval gehoeven.. Zit al in een javascript context Lekker zitten slapen dus..

[GekkePrutser]

Maar even eentje van mezelf, waar ik net pas achter kom....

• Pak een temperatuur in milligraden
• Bereken de graden als floor(meetwaarde / 1000.0)
• Bereken de decimalen als meetwaarde % 1000
• Sla op in de DB als decimal waarde, "<graden>.<decimalen>"

Achteraf gezien is het heel duidelijk waarom dit mis ging. 10.009 wordt 10.9 En ik weet niet eens meer waarom ik zo moeilijk deed. Ik wou het geloof ik 'exact houden' en niet de floating point engine gebruiken, maar dat was dus niet zo slim om dat zo te doen

Maar het mysterie van 'waarom maakt die grafiek toch steeds van die gekke sprongen' is nu opgelost

[ Voor 8% gewijzigd door GekkePrutser op 20-01-2014 14:11 ]

[Hydra]

Hipska schreef op dinsdag 07 januari 2014 @ 11:25:
OMG, ik wist niet dat dat nog bestond, en dan nog op onze eigen tweakblogs!
chaozz: Using readable dates in SQL and PHP

Geeft goed weer waarom de tweakers blog functionaliteit niks oplevert voor tweakers. Dat soort meuk wil je niet als content. Als iemand perse dom advies wil geven kan 'ie wel wel een wordpress install aanmaken.

[kenneth]

You can query periods really simple

Mooi dunglish

[JeroenT]

Nog een parel van een voormalig collega;

PHP:

if( $invoice['Invoice']['type'] == 'debit' ) {
     $text = $company['Company']['footer_first'];
     $text2 = $company['Company']['footer_debit'];
} elseif ( $invoice['Invoice']['type'] == 'credit' ) {
     $text = $company['Company']['footer_first'];
     $text2 = $company['Company']['footer_debit'];
}

[Soultaker]

GekkePrutser schreef op maandag 20 januari 2014 @ 13:57:
Maar even eentje van mezelf, waar ik net pas achter kom....

• Pak een temperatuur in milligraden
• Bereken de graden als floor(meetwaarde / 1000.0)
• Bereken de decimalen als meetwaarde % 1000
• Sla op in de DB als decimal waarde, "<graden>.<decimalen>"

Gelukkig is dit een fout waarbij je achteraf de meetwaarden kunt fixen door extra nullen in te voegen na de punt. Maar je had je vast nog niet gerealiseerd dat dit ook fout gaat met temperaturen onder 0 (tenzij je met Python werkt). Je zou de decimalen moeten berekenen als: meetwaarde - (meetwaarde/1000)*1000 of iets dergelijks.

[.oisyn]

Gelukkig komen temperaturen onder nul deze winter niet voor

[Rannasha]

.oisyn schreef op woensdag 22 januari 2014 @ 16:23:
Gelukkig komen temperaturen onder nul deze winter niet voor

Of je rekent in Kelvin, ben je ook van negatieve temperaturen af (in ieder geval bij alledaags gebruik).

Maar als je graag met integers wil rekenen, waarom sla je dan niet de mili-graden waarde op in de DB en converteer je pas naar een floating point op het moment dat je de variabele wil tonen aan de user?

[MTWZZ]

C#:

double whatevs = 12.456;
decimal foo = Decimal.Parse(whatevs.ToString());

Afhankelijk van je culture is het 12,456 of 12456

[ Voor 21% gewijzigd door MTWZZ op 22-01-2014 17:32 ]

[Dido]

MTWZZ schreef op woensdag 22 januari 2014 @ 17:32:
Afhankelijk van je culture is het 12,456 of 12456

En als het 12456 is in jouw culture, dan is dat hetzelfde als 12,456

[Haan]

De hele constructie is al een WTF, wat is er mis met

C#:

double whatevs = 12.456; 
decimal foo = (decimal)whatevs;

?

[MTWZZ]

Haan schreef op donderdag 23 januari 2014 @ 09:12:
De hele constructie is al een WTF, wat is er mis met

C#:

double whatevs = 12.456; 
decimal foo = (decimal)whatevs;

?

Het is sowieso al raar idd maar die impliciete culture is wel een added bonus

[Acid_Burn]

Waarom niet direct naar decimal? Waarom zit die double er überhaupt in?

[MBV]

Ik hoop dat er wat code is weggelaten die dat min-of-meer logisch maakt...

[HuHu]

MTWZZ schreef op donderdag 23 januari 2014 @ 18:11:
[...]

Het is sowieso al raar idd maar die impliciete culture is wel een added bonus

Die culture staat gewoon duidelijk in de documentatie. Het is toch algemeen bekend dat getallen anders worden opgeschreven in verschillende landen? Als je dan getal.ToString() aanroept... wat verwacht je dan? 12345 / 12,345 / 12.346 kunnen hetzelfde getal zijn, afhankelijk van welke schrijfwijze je hanteert.

Decimal.Parse gebruikt als het goed is dezelfde culture in de conversie. Wat is hier dan de "wtf" of het "slechte programmeervoorbeeld"?

[Swinnio]

Geen idee of het al eerder is voorbijgekomen maar op http://thedailywtf.com/Ar...g-the-OMGTWTF-Winner.aspx zijn ook prachtige voorbeelden te vinden.

[begintmeta]

HuHu schreef op vrijdag 24 januari 2014 @ 11:18:
... 12345 / 12,345 / 12.346 kunnen hetzelfde getal zijn, afhankelijk van welke schrijfwijze je hanteert.
...

Van dat laatste had ik dat niet verwacht.

[Verwijderd]

HuHu schreef op vrijdag 24 januari 2014 @ 11:18:
[...]

Die culture staat gewoon duidelijk in de documentatie. Het is toch algemeen bekend dat getallen anders worden opgeschreven in verschillende landen? Als je dan getal.ToString() aanroept... wat verwacht je dan? 12345 / 12,345 / 12.346 kunnen hetzelfde getal zijn, afhankelijk van welke schrijfwijze je hanteert.

Decimal.Parse gebruikt als het goed is dezelfde culture in de conversie. Wat is hier dan de "wtf" of het "slechte programmeervoorbeeld"?

Nee, dat is te makkelijk he (niet sarcastisch bedoeld). Hoevaak ik dat mensen al niet heb moeten uitleggen als ze op een andere omgeving daar ineens ander gedrag zien . Nu maakt elke programmeur wel eens zulke fouten, want je OTAP omgeving op dezelfde culture en instellingen installeren is natuurlijk geen optie

Los daarvan, moet je natuurlijk eigenlijk gewoon altijd zoiets voorkomen door een standard culture te gebruiken..

[Grijze Vos]

Haan schreef op donderdag 23 januari 2014 @ 09:12:
De hele constructie is al een WTF, wat is er mis met

C#:

double whatevs = 12.456; 
decimal foo = (decimal)whatevs;

?

Wat is er mis met de geeikte methode? Convert.ToDecimal

[HuHu]

begintmeta schreef op vrijdag 24 januari 2014 @ 12:05:
[...]

Van dat laatste had ik dat niet verwacht.

Dat laatste (ik neem aan dat je 12.345 bedoelt) is nog wel de Nederlandse schrijfwijze. Voorbeeld: een huis kost 249.500,00 euro. De punt is het scheidingsteken voor de duizendtallen in het Nederlands en de komma voor de decimalen.

[MatHack]

HuHu schreef op vrijdag 24 januari 2014 @ 13:18:
[...]

Dat laatste (ik neem aan dat je 12.345 bedoelt) is nog wel de Nederlandse schrijfwijze. Voorbeeld: een huis kost 249.500,00 euro. De punt is het scheidingsteken voor de duizendtallen in het Nederlands en de komma voor de decimalen.

Hij doelde op je typfout

[Haan]

HuHu schreef op vrijdag 24 januari 2014 @ 11:18:
Decimal.Parse gebruikt als het goed is dezelfde culture in de conversie. Wat is hier dan de "wtf" of het "slechte programmeervoorbeeld"?

Een double naar een string converteren en de string weer naar decimal vind je normaal?

Grijze Vos schreef op vrijdag 24 januari 2014 @ 13:15:
[...]

Wat is er mis met de geeikte methode? Convert.ToDecimal

Kwestie van smaak denk ik, als ik de comments in deze thread mag geloven, is het zelfs zo dat de cast notatie onder water ook gewoon de Convert method aanroept.
Dan ga ik persoonlijk liever voor de kortste notatie.

[ Voor 22% gewijzigd door Haan op 25-01-2014 11:42 ]

[Verwijderd]

Java:

int roadSize = ...;
{...}
int[] roadCells = new int[roadSize];
{...}
    try{
        for(int i = 0; i<roadCells.length; i++){
            if (roadCells[i+1] == 1){
                {...}
            }
        }
    } catch (ArrayIndexOutOfBoundsException e) {
        if (roadCells[0] == 1){
            {...}
        }
    }

Ja...Ehm...Het werkt...soort van...
Het idee was hier een Cellular Automaton na te maken van een "autoweg" met bepaalde update regels die afhangen van de auto's voor ieder punt op de weg. De weg moest een cyclisch gedrag hebben, dus dit was "de handigste oplossing". Ik weet nog steeds niet hoe iemand hierop kan komen

[-Sander1981-]

Van een collega laatst:

C#:

for (int index = 0; index <= list.Count - 1; index++)
{
    // Doe iets met list[index]
}

Zelf vind ik het dan duidelijker om als de exacte waarde van index verder niet van belang is, een foreach te gebruiken, maar dat is meer een kwestie van voorkeur.

[R4gnax]

-Sander1981- schreef op maandag 17 februari 2014 @ 22:46:
Van een collega laatst:

C#:

for (int index = 0; index <= list.Count - 1; index++)
{
    // Doe iets met list[index]
}

Zelf vind ik het dan duidelijker om als de exacte waarde van index verder niet van belang is, een foreach te gebruiken, maar dat is meer een kwestie van voorkeur.

Nog even afgezien van het feit dat list.Count - 1 elke keer opnieuw uitgerekend wordt.

[kenneth]

Gelukkig is List<>.Count O(1)

[Verwijderd]

-Sander1981- schreef op maandag 17 februari 2014 @ 22:46:
Van een collega laatst:

C#:

for (int index = 0; index <= list.Count - 1; index++)
{
    // Doe iets met list[index]
}

Zelf vind ik het dan duidelijker om als de exacte waarde van index verder niet van belang is, een foreach te gebruiken, maar dat is meer een kwestie van voorkeur.

Performance, de for loop is sneller dan een foreach loop

[Megamind]

Het lijkt mij dat de compiler dat allemaal optmaliseert.

[Feanathiel]

Waarom? GetEnumerator hoeft niet hetzelfde te doen als de indexer.

[Janoz]

Verwijderd schreef op dinsdag 18 februari 2014 @ 04:51:
[...]


Performance, de for loop is sneller dan een foreach loop

Ja? Waarom?

[Verwijderd]

Janoz schreef op dinsdag 18 februari 2014 @ 08:35:
[...]

Ja? Waarom?

Oud maar een leuk stukje http://blogs.msdn.com/b/k...6072.aspx?Redirected=true Mocht je met .NET 4.X programeren dan kan je beter Parallel.For gebruiken.

[Janoz]

Wat ik daar lees is dat foreach helemaal niet langzamer is dan for bij arrays.

There are circumstances where foreach() introduces a performance penalty; but when the compiler can statically determine that the collection is infact an array, then foreach performs exactly the same as the equivalent hand coded loop.

Daarnaast kan ik me heel goed voorstellen dat er bepaalde situaties zijn waarbij foreach veel efficienter is dan een for. Denk bijvoorbeeld aan het itereren over een LinkedList

[Verwijderd]

Janoz schreef op dinsdag 18 februari 2014 @ 09:52:
Wat ik daar lees is dat foreach helemaal niet langzamer is dan for bij arrays.

[...]


Daarnaast kan ik me heel goed voorstellen dat er bepaalde situaties zijn waarbij foreach veel efficienter is dan een for. Denk bijvoorbeeld aan het itereren over een LinkedList

Klopt, IMHO, maar in andere gevallen is het wel sneller, zo het is beter om jezelf aan te leren altijd for loops te gebruiken i.p.v. foreach, je kan even zoeken op google wat de verschillen zijn en ik denk dat het nog beter is om jezelf Parallel.For aan te leren.

[Woy]

Janoz schreef op dinsdag 18 februari 2014 @ 09:52:
Daarnaast kan ik me heel goed voorstellen dat er bepaalde situaties zijn waarbij foreach veel efficienter is dan een for. Denk bijvoorbeeld aan het itereren over een LinkedList

Dat ligt er natuurlijk aan hoe je de for gebruikt, als je inderdaad met de for loop elke keer de indexer gebruikt zal het erg slecht zijn voor de performance, maar als code als in onderstaand voorbeeld zal minstens net zo goed als een foreach performen ( Waarschijnlijk beter door het ontbreken van de overhead van een Enumerator )

C#:

for(var cur = list.Head; cur != null; cur = cur.Next )
{
}

Maar sowieso is het meestal gewoon een non-discussie wat er beter performt, want veel zal het vaak niet schelen. Je kunt je beter druk maken over de leesbaarheid van de code.

[Schnoop]

Verwijderd schreef op dinsdag 18 februari 2014 @ 09:58:
[...]


Klopt, IMHO, maar in andere gevallen is het wel sneller, zo het is beter om jezelf aan te leren altijd for loops te gebruiken i.p.v. foreach, je kan even zoeken op google wat de verschillen zijn en ik denk dat het nog beter is om jezelf Parallel.For aan te leren.

Sorry hoor maar dit is klinklare onzin. Het gebruiksgemak van foreach en parallel.foreach weegt echt niet op tegen de minimale performance winst van for loops. Met list sizes van onder de 1000 zul je sowieso weinig tot niks merken.

Tenzij je met slecht geoptilmalizeerde talen werkt (denk aan LUA enz.) of met zeer grote datasets werkt is het echt niet nodig om for loops i.p.v. foreach te gaan schrijven.

[Verwijderd]

Schnoop schreef op dinsdag 18 februari 2014 @ 10:04:
[...]


Sorry hoor maar dit is klinklare onzin. Het gebruiksgemak van foreach en parallel.foreach weegt echt niet op tegen de minimale performance winst van for loops. Met list sizes van onder de 1000 zul je sowieso weinig tot niks merken.

Tenzij je met slecht geoptilmalizeerde talen werkt (denk aan LUA enz.) of met zeer grote datasets werkt is het echt niet nodig om for loops i.p.v. foreach te gaan schrijven.

Ooit software geschreven waar performance een issue kan zijn?

[Feanathiel]

Verwijderd schreef op dinsdag 18 februari 2014 @ 10:06:
[...]


Ooit software geschreven waar performance een issue kan zijn?

Volgens mij is het branchen/joinen van de taken alsnog duurder dan simpelweg op één thread de loop te laten uitvoeren. Pas bij grote arrays heeft het zin imo.

[Verwijderd]

Feanathiel schreef op dinsdag 18 februari 2014 @ 10:07:
[...]


Volgens mij is het branchen/joinen van de taken alsnog duurder dan simpelweg op één thread de loop te laten uitvoeren. Pas bij grote arrays heeft het zin imo.

Dat kan ja, ligt eraan hoe groot de arrays zijn, maar het heeft zin als je meerdere cores tot je beschikking hebt, dan kan het aanzienlijk schelen in de performance.

[kenneth]

Verwijderd schreef op dinsdag 18 februari 2014 @ 10:06:
[...]


Ooit software geschreven waar performance een issue kan zijn?

Dus omdat er software bestaat waar performance een issue kan zijn, is het beter om altijd for loops te prefereren?

Premature optimization, root of all evil, enzovoort.

Natuurlijk interessant om te weten als performance daadwerkelijk een issue is maar om een eenvoudige en leesbare constructie permanent af te serveren is overdreven.

[Schnoop]

Verwijderd schreef op dinsdag 18 februari 2014 @ 10:06:
[...]


Ooit software geschreven waar performance een issue kan zijn?

Als jij een taal gebruikt welke bij het ittereren van 1000 items en verschil heeft van 100ms in speed dan gebruik je een, zoals ik al eerder aangaf, slecht geoptimaliseerde taal.

Nogmaals, dit wordt enkel relevant bij het gebruik van grote datasets. En zelfs dan bestaat de kans dat een foreach sneller is.

Het is een verzameling van factoren om te besluiten wat je gebruikt maar de gemiddelde programmeur zal zelden moeten resorten naar een for loop, laat staan zichzelf aanleren om ze altijd te gebruiken i.p.v. foreach loop.

[Verwijderd]

kenneth schreef op dinsdag 18 februari 2014 @ 10:16:
[...]

Dus omdat er software bestaat waar performance een issue kan zijn, is het beter om altijd for loops te prefereren?

Premature optimization, root of all evil, enzovoort.

Natuurlijk interessant om te weten als performance daadwerkelijk een issue is maar om een eenvoudige en leesbare constructie permanent af te serveren is overdreven.

Daarvoor schreef ik ook IMHO

[MBV]

Verwijderd schreef op dinsdag 18 februari 2014 @ 10:06:
[...]


Ooit software geschreven waar performance een issue kan zijn?

Ik heb bij het performance team gezeten van een grote leverancier van navigatiesystemen. De problemen die ik heb gezien hadden verschillende oorzaken, maar dat lag nooit aan de 0.1% verschillen tussen for-loops en foreach. Performance-problemen ontstaan meestal omdat thread A wacht op een signaal van thread B dat nooit komt, of doordat thread B 'perongeluk' aan het busy-waiten is, of doordat geheugen dom wordt gealloceerd. Zodra je naar micro-optimalisaties op zoek moet voor de laatste procent (buiten reken-intensieve kritische stukken die heel vaak worden aangeroepen, bij navigatie zou dat het renderen van de kaart of routeberekening kunnen zijn) zit je al diep in de problemen. Je kan dan beter op zoek gaan naar een betere compiler of compilervlaggen.

Als je leesbare code met duidelijke interfaces schrijft voorkom je de echte problemen, dat is veel belangrijker dan je druk maken om wat voor loopje.

[Verwijderd]

MBV schreef op dinsdag 18 februari 2014 @ 10:22:
[...]

Ik heb bij het performance team gezeten van een grote leverancier van navigatiesystemen. De problemen die ik heb gezien hadden verschillende oorzaken, maar dat lag nooit aan de 0.1% verschillen tussen for-loops en foreach. Performance-problemen ontstaan meestal omdat thread A wacht op een signaal van thread B dat nooit komt, of doordat thread B 'perongeluk' aan het busy-waiten is, of doordat geheugen dom wordt gealloceerd. Zodra je naar micro-optimalisaties op zoek moet voor de laatste procent (buiten reken-intensieve kritische stukken die heel vaak worden aangeroepen, bij navigatie zou dat het renderen van de kaart of routeberekening kunnen zijn) zit je al diep in de problemen. Je kan dan beter op zoek gaan naar een betere compiler of compilervlaggen.

Als je leesbare code met duidelijke interfaces schrijft voorkom je de echte problemen, dat is veel belangrijker dan je druk maken om wat voor loopje.

Dan hebben we het over C(++) en niet over C# toch?

Edit: http://www.c-sharpcorner....formance-of-C-Sharp-code/ lees en ik ben benieuwd naar jullie ervaringen/meningen!

[ Voor 6% gewijzigd door Verwijderd op 18-02-2014 10:37 ]

[Woy]

Wat een crap artikel is dat zeg.

Punt 1: zit misschien wat in, maar dat is meer een keuze tussen het hebben van een fixed size lijst of niet. Als je weet dat het altijd fixed size is kies je inderdaad een Array, maar zelfs daar is performance verschil vaak helemaal niet zo groot ( Behalve als je het in een loop 1000'en keren doet natuurlijk )

Punt 2: Qua performance is het ook weer compleet afhankelijk van wat je in de loop doet. Dat kleine beetje overhead van de loop gaat in 99,9% van de gevallen echt niet het verschil maken.

Punt 3: Ja die keuze moet je maken, maar hij doet het voorkomen alsof een struct sneller is dan een class, maar dat is compleet afhankelijk van de situatie. Het maakt ook nogal een verschil in het gebruik of je classes of structs gebruikt, dus de functionele keuze is nog veel belangrijker dan de performance.

Punt 4: Valide punt, al is "Altijd" ook wel overrated, want bij kleine concatenaties zal het verschil niet echt relevant zijn.

Punt 5: Compleet idioot om voor te stellen dat je maar geen properties moet gebruiken. Mocht een property assignment echt een probleem vormen dan kun je altijd nog kijken of je dat wil optimaliseren. Natuurlijk is het goed om te weten dat er wat overhead in het gebruik van properties kan zitten. Maar weer een compleet premature optimization.

Hij noemt hooguit wat punten waar je je best bewust van moet zijn, maar echt niet iets waar ik doorgaans veel rekening mee zou houden over nette leesbare code schrijven.

[Martijn.C.V]

Iemand met wie ik had gewerkt had een periode wat minder concentratie, wat resulteerde in stukjes code als deze:

PHP:

$foo = true; // Nooit! anders dan true of false.

    if( $foo==true){ /* ... */;}
elseif( $foo==false){ /* ... */;}
else{ /* ... */ }

Mag iemand mij vertellen wanneer de else iets doet Zoveel van dit soort dingetjes, grappig om ze tegen te komen

[Verwijderd]

Woy schreef op dinsdag 18 februari 2014 @ 10:49:
Wat een crap artikel is dat zeg.

Punt 1: zit misschien wat in, maar dat is meer een keuze tussen het hebben van een fixed size lijst of niet. Als je weet dat het altijd fixed size is kies je inderdaad een Array, maar zelfs daar is performance verschil vaak helemaal niet zo groot ( Behalve als je het in een loop 1000'en keren doet natuurlijk )

Punt 2: Qua performance is het ook weer compleet afhankelijk van wat je in de loop doet. Dat kleine beetje overhead van de loop gaat in 99,9% van de gevallen echt niet het verschil maken.

Punt 3: Ja die keuze moet je maken, maar hij doet het voorkomen alsof een struct sneller is dan een class, maar dat is compleet afhankelijk van de situatie. Het maakt ook nogal een verschil in het gebruik of je classes of structs gebruikt, dus de functionele keuze is nog veel belangrijker dan de performance.

Punt 4: Valide punt, al is "Altijd" ook wel overrated, want bij kleine concatenaties zal het verschil niet echt relevant zijn.

Punt 5: Compleet idioot om voor te stellen dat je maar geen properties moet gebruiken. Mocht een property assignment echt een probleem vormen dan kun je altijd nog kijken of je dat wil optimaliseren. Natuurlijk is het goed om te weten dat er wat overhead in het gebruik van properties kan zitten. Maar weer een compleet premature optimization.

Hij noemt hooguit wat punten waar je je best bewust van moet zijn, maar echt niet iets waar ik doorgaans veel rekening mee zou houden over nette leesbare code schrijven.

Het ging mij over de for versus foreach loop, niet over de andere optimalisaties, dat ben ik met je eens dat die persoon daar veels te veel in doorslaat (hij kijkt alleen naar de tijd en ziet het project niet meer)

[MBV]

Verwijderd schreef op dinsdag 18 februari 2014 @ 10:30:
[...]


Dan hebben we het over C(++) en niet over C# toch?

Edit: http://www.c-sharpcorner....formance-of-C-Sharp-code/ lees en ik ben benieuwd naar jullie ervaringen/meningen!

Nee, dat is taal-onafhankelijk! Als je denkt dat 'thread X doet per-ongeluk een busy wait' een taal-afhankelijk probleem is, dan heb je het punt helemaal gemist. Het enige punt waar taal een verschil maakt is memory-management (C++ v.s. managed talen als C# en Java) en bij interfacing tussen die twee. En ook in een managed taal kan je onhandige dingen doen met geheugen, waardoor je fragmentatie en veel garbage collections krijgt. Of natuurlijk forced garbage collections...

[Verwijderd]

MBV schreef op dinsdag 18 februari 2014 @ 10:58:
[...]

Nee, dat is taal-onafhankelijk! Als je denkt dat 'thread X doet per-ongeluk een busy wait' een taal-afhankelijk probleem is, dan heb je het punt helemaal gemist. Het enige punt waar taal een verschil maakt is memory-management (C++ v.s. managed talen als C# en Java) en bij interfacing tussen die twee. En ook in een managed taal kan je onhandige dingen doen met geheugen, waardoor je fragmentatie en veel garbage collections krijgt. Of natuurlijk forced garbage collections...

Dat begrijp ik ThreadX, maar heb je echte performance nodig dan zal je toch low level moeten programmeren en niet in C#. Maar ik dwaal af het ging om het verschil tussen de for en foreach loop

[Russel88]

Net een testje gemaakt in m'n eigen project. En in mijn testcase (List van 982 objecten) is het verwaarloosbaar.
28618 ticks vs. 29223 ticks.

Edit net artikel gelezen.
Enige stukje waar je wat aan hebt is dat een StringBuilder sneller is met concatenation dan een string. Jammer dat hij dat dan ook niet uitlegt waarom het sneller is in zijn artikel. Is trouwens een vraag die vaak terugkomt bij C# test vragen.

[ Voor 49% gewijzigd door Russel88 op 18-02-2014 11:19 ]

[Voutloos]

Martijn.C.V schreef op dinsdag 18 februari 2014 @ 10:50:
Iemand met wie ik had gewerkt had een periode wat minder concentratie, wat resulteerde in stukjes code als deze:

PHP:

$foo = true; // Nooit! anders dan true of false.

    if( $foo==true){ /* ... */;}
elseif( $foo==false){ /* ... */;}
else{ /* ... */ }

Mag iemand mij vertellen wanneer de else iets doet Zoveel van dit soort dingetjes, grappig om ze tegen te komen

Sowieso lui die if( $foo==true) schrijven...

En als boolean vars een naam geeft als 'isFoo' heb je die hele k*tuitleg niet nodig.

#obviousoverigfeedback

[Verwijderd]

Op zich is het natuurlijk niet slecht om in een if elseif serie een uiteindelijke else te hebben waarin een error/exception/whatever wordt gegooid om een onverwachte situatie af te vangen ipv blind door te gaan.

[Woy]

Verwijderd schreef op dinsdag 18 februari 2014 @ 10:58:
[...]


Het ging mij over de for versus foreach loop, niet over de andere optimalisaties, dat ben ik met je eens dat die persoon daar veels te veel in doorslaat (hij kijkt alleen naar de tijd en ziet het project niet meer)

Ook daar is het compleet afhankelijk van wat je exact doet. In het geval van een array doorlopen op index is het inderdaad iets sneller, maar bij bijvoorbeeld een List doorlopen op index is het al weer langzamer.

C#:

class Program
{
    static void Main(string[] args)
    {
        Stopwatch sw = new Stopwatch();

        var listSize = 10000000;
        var iterations = 100;
        var array = Enumerable.Range(0, listSize).ToArray();
        var list = Enumerable.Range(0, listSize).ToList();

        sw.Start();
        for (int i = 0; i < iterations; i++)
            ArrayForTest(array);
        sw.Stop();
        Console.WriteLine("ArrayForTest = {0} ms", sw.ElapsedMilliseconds);
            
        sw.Restart();
        for (int i = 0; i < iterations; i++)
            ArrayForeachTest(array);
        sw.Stop();            
        Console.WriteLine("ArrayForeachTest = {0} ms", sw.ElapsedMilliseconds);
            
        sw.Restart();
        for (int i = 0; i < iterations; i++)
            ListForTest(list);
        sw.Stop();
        Console.WriteLine("ListForTest = {0} ms", sw.ElapsedMilliseconds);
            
        sw.Restart();
        for (int i = 0; i < iterations; i++)
            ListForeachTest(list);
        sw.Stop();
        Console.WriteLine("ListForeachTest = {0} ms", sw.ElapsedMilliseconds);

        Console.ReadKey(true);
    }

    static long ArrayForTest(int[] array)
    {
        long result = 0;
        for(int i = 0; i < array.Length; i++)
        {
            result += array[i];
        }
        return result;
    }

    static long ArrayForeachTest(int[] array)
    {
        long result = 0;
        foreach (int item in array)
        {
            result += item;
        }
        return result;
    }

    static long ListForTest(List<int> list)
    {
        long result = 0;
        for (int i = 0; i < list.Count; i++)
        {
            result += list[i];
        }
        return result;
    }

    static long ListForeachTest(List<int> list)
    {
        long result = 0;
        foreach(int item in list)
        {
            result += item;
        }
        return result;
    }
}

Output:

ArrayForTest = 2644 ms
ArrayForeachTest = 3208 ms
ListForTest = 7550 ms
ListForeachTest = 6294 ms

En dit is met 100 * 10.000.000 iteraties, dus compleet verwaarloosbaar in normale situaties.

[Schnoop]

Verwijderd schreef op dinsdag 18 februari 2014 @ 10:30:
[...]


Dan hebben we het over C(++) en niet over C# toch?

Edit: http://www.c-sharpcorner....formance-of-C-Sharp-code/ lees en ik ben benieuwd naar jullie ervaringen/meningen!

Punt 1
Wat hij aanhaalt bevestigd alleen maar wat ik al 100 keer gezegd heb, het maakt echt alleen uit bij grotere datasets.
Hier een (.NET 4) resultaat van zijn stuk code wat 5 keer gedraaid wordt, waarbij ik 10.000.000 iteraties gebruik i.p.v. 10.000 en geen timerticks tel maar miliseconden.:

Je ziet inederaad verschil, bij 10 miljoen iteraties.

Bij de 100.000 iteraties geven beide 0 ms, bij de 1 miljoen krijg je pas verschil te zien:


Punt 2
Hij vergelijkt hier appels met peren. ALs hij het realistisch had willen doen had zijn for loop niet Count.Add(i); moeten zijn maar Count.Add(Count[i]);
Aanschouw het resultaat (wederom iteraties verhoogd naar 10.000.000):

kijk eens aan, de foreach is zelfs sneller in dit specifiek geval....

Punt 3
Structs zijn enkel beter indien je er data inzet welke ongewijzigd blijft. Het aanmaken van structs gaat welliswaar sneller maar het aanpassen niet. Hieronder het zelfde verhaal waar bij de structs en classes al zijn aangemaakt en in een loop (10 mil iteraties) aangepast worden. Je ziet dat bij aanpassingen classes sneller zijn.


Hangt dus af van de situatie. De meneer in de link gaat hier verder niet op in dus de vergelijknig slaat wederom kant nog wal.

Punt 4
Een punt waar hij wel gelijk heeft. Uiteraard bij "veelvuldig" gebruik. Bij 1 string manipulatie zal je er niks van merken.

Punt 5
ugh....
Het verschil (wederom miliseconden) van 10 miljoen keer:

Mocht je inderdaad een systeem schrijven wat meer dan 10 miljoen keer zoiets doet dan is het wellicht interessant om geen properties te gebruiken. Als de meneer dit vermeld had had hij zijn lezers wellicht nog iets geleerd.

[Verwijderd]

Schnoop schreef op dinsdag 18 februari 2014 @ 11:48:
[...]


Punt 1
Wat hij aanhaalt bevestigd alleen maar wat ik al 100 keer gezegd heb, het maakt echt alleen uit bij grotere datasets.
Hier een (.NET 4) resultaat van zijn stuk code wat 5 keer gedraaid wordt, waarbij ik 10.000.000 iteraties gebruik i.p.v. 10.000 en geen timerticks tel maar miliseconden.:
[afbeelding]
Je ziet inederaad verschil, bij 10 miljoen iteraties.

Bij de 100.000 iteraties geven beide 0 ms, bij de 1 miljoen krijg je pas verschil te zien:
[afbeelding]

Punt 2
Hij vergelijkt hier appels met peren. ALs hij het realistisch had willen doen had zijn for loop niet Count.Add(i); moeten zijn maar Count.Add(Count[i]);
Aanschouw het resultaat (wederom iteraties verhoogd naar 10.000.000):
[afbeelding]
kijk eens aan, de foreach is zelfs sneller in dit specifiek geval....

Punt 3
Structs zijn enkel beter indien je er data inzet welke ongewijzigd blijft. Het aanmaken van structs gaat welliswaar sneller maar het aanpassen niet. Hieronder het zelfde verhaal waar bij de structs en classes al zijn aangemaakt en in een loop (10 mil iteraties) aangepast worden. Je ziet dat bij aanpassingen classes sneller zijn.
[afbeelding]

Hangt dus af van de situatie. De meneer in de link gaat hier verder niet op in dus de vergelijknig slaat wederom kant nog wal.

Punt 4
Een punt waar hij wel gelijk heeft. Uiteraard bij "veelvuldig" gebruik. Bij 1 string manipulatie zal je er niks van merken.

Punt 5
ugh....
Het verschil (wederom miliseconden) van 10 miljoen keer:
[afbeelding]
Mocht je inderdaad een systeem schrijven wat meer dan 10 miljoen keer zoiets doet dan is het wellicht interessant om geen properties te gebruiken. Als de meneer dit vermeld had had hij zijn lezers wellicht nog iets geleerd.

Hoho, wil je even een paar postings naar boven en dan die van mij bekijken

[Schnoop]

Verwijderd schreef op dinsdag 18 februari 2014 @ 12:00:
[...]
Hoho, wil je even een paar postings naar boven en dan die van mij bekijken

Wij geven hier al een aantal keer aan dat het alleen uitmaakt bij zeer grote arrays, en dan kom jij met een link aanzetten die precies dat bevestigd (maar niet letterlijk omdat de schrijver geen idee heeft wat hij doet). Vervolgens vraag je onze mening over dit stuk, die heb ik zojuist gegeven.

Zijn compleet stuk hoort in ieder geval thuis in "slechte programmeervoorbeelden". Niet vanwege de code maar puur vanwege de belachelijk beargumentatie en het gebrek aan diepgang.

[Verwijderd]

Schnoop schreef op dinsdag 18 februari 2014 @ 12:07:
[...]
Zijn compleet stuk hoort in ieder geval thuis in "slechte programmeervoorbeelden". Niet vanwege de code maar puur vanwege de belachelijk beargumentatie en het gebrek aan diepgang.

Dan zit zijn stukje nu in juiste thread

[Russel88]

Verwijderd schreef op dinsdag 18 februari 2014 @ 12:11:
[...]


Dan zit zijn stukje nu in juiste thread

Ipv. slim proberen te doen kun je ook een voorbeeld geven waarbij het wel significant sneller is. Je begint je eigen stelling steeds verder af te zwakken.

Performance, de for loop is sneller dan een foreach loop

Klopt, IMHO, maar in andere gevallen is het wel sneller, zo het is beter om jezelf aan te leren altijd for loops te gebruiken i.p.v. foreach, je kan even zoeken op google wat de verschillen zijn en ik denk dat het nog beter is om jezelf Parallel.For aan te leren.

Dat kan ja, ligt eraan hoe groot de arrays zijn, maar het heeft zin als je meerdere cores tot je beschikking hebt, dan kan het aanzienlijk schelen in de performance.

[Verwijderd]

Russel88 schreef op dinsdag 18 februari 2014 @ 12:23:
[...]


Ipv. slim proberen te doen kun je ook een voorbeeld geven waarbij het wel significant sneller is. Je begint je eigen stelling steeds verder af te zwakken.


[...]


[...]


[...]

O nee, dat doe ik (nog) niet mijn stelling verder af te zwakken, maar ik ga nu wel meer twijfelen over het performance verschil tussen een for en foreach loop. Laat ik het zo zeggen, als ik niet met "tegenbewijs" kan komen hebben jullie gelijk, afgesproken?