[alg] Slechtste programmeervoorbeelden deel 4

[Hydra]

GrimaceODespair schreef op dinsdag 06 november 2012 @ 17:05:
Eigenlijk zou er voor Threading zoiets als een rijbewijs moeten zijn: Je mag niet aan threading doen als je geen Threading-bewijs hebt. Anders ben je strafbaar.

En dan gewoon oldskool vingers afhakken enzo!

[Jegorex]

Hydra schreef op dinsdag 06 november 2012 @ 17:07:
[...]


En dan gewoon oldskool vingers afhakken enzo!

9 vingers afhakken zodat je niet meer kunt multitasken met je vingers?

[MBV]

zzattack schreef op dinsdag 06 november 2012 @ 17:07:
[...]

Met soortgelijke boetes voor overtredingen dan wel! En verplicht op cursus bij te schrijnende overtredingen

Dan vind ik deze toch wel 3 dagen threading-ontzegging waard

[Bosmonster]

Dit topic is al te lang dood.

JavaScript:

function firstElementChecker(elem) {
    $(elem + ":first-child").addClass("firstElem");
}
function firstElementConverter(elem) {
    $(elem).addClass("firstElem");
}

function lastElementConverter(elem) {
    $(elem).addClass("lastElem");
}

// IE Only functions
function initIEonly() {
    firstElementConverter(".accordion > li, .foldOut > li");
    firstElementConverter(".accordion li > a, .foldOut li > a");
}

Naast de rare opzet gaat dit volgens mij niet helemaal doen wat het moet doen

[YopY]

Nouja, het lijkt erop dat dit een IE-compatibility poging is, aangezien IE 7 en co geen CSS pseudo-selectors (:first-child) ondersteunen en je het dus niet voor styling kunt gebruiken. :first-child werkt echter wel in jquery, dus dit lijkt me een redelijke oplossing.

Hij doet het natuurlijk niet omdat hij het op alle li's onder iets met een class .accordion / .foldOut doet, maar dat terzijde.

[chem]

Nee, hij doet het niet omdat een multiple selector eenmalig wordt voorzien van een suffix.

En eerlijk gezegd is het netter als je dit server-side doet. IE is al zo'n ramp, om die ook nog extra JS voor te schotelen...

[R4gnax]

YopY schreef op donderdag 29 november 2012 @ 16:45:
Nouja, het lijkt erop dat dit een IE-compatibility poging is, aangezien IE 7 en co geen CSS pseudo-selectors (:first-child) ondersteunen en je het dus niet voor styling kunt gebruiken. :first-child werkt echter wel in jquery, dus dit lijkt me een redelijke oplossing.

IE ondersteunt sinds versie 7 toch echt wel :first-child hoor...

[Chris7]

R4gnax schreef op donderdag 29 november 2012 @ 23:13:
[...]

IE ondersteunt sinds versie 7 toch echt wel :first-child hoor...

Volgens mij niet, dat soort selectors werkt pas sinds IE9. Ik heb het pasgeleden nog geprobeerd maar in IE <9 krijg je dan hele rare dingen...

[.oisyn]

Niet "dat soort selectors", maar specifiek :first-child. Die werkte voor 8 weldegelijk. Wel een <!doctype> gebruik uiteraard.
MSDN: :first-child pseudo-class (Internet Explorer)

[ Voor 34% gewijzigd door .oisyn op 30-11-2012 16:05 ]

[Chris7]

Aha, inderdaad. Ik had blijkbaar alleen :last-child gebruikt en die werkt niet in oudere IE-versie's. Ik dacht dat ook first-child CSS3 is maar die zat al in 2.1.

[ZpAz]

last-child of first-child, één van de twee werkt zelfs in IE6 als ik me niet vergis. Maar niet beide.

edit:

Chris7 schreef op vrijdag 30 november 2012 @ 19:15:
Aha, inderdaad. Ik had blijkbaar alleen :last-child gebruikt en die werkt niet in oudere IE-versie's. Ik dacht dat ook first-child CSS3 is maar die zat al in 2.1.

Aa, first-child werkt dus al in IE6.

[ Voor 61% gewijzigd door ZpAz op 30-11-2012 19:38 ]

[Sitethief]

PHP:

$i=0;
$max = count($lsProducts);
while($i < $max) {
        //doeiets
        //doenogiets
}

En ik me maar afvragen waarom de code er zo lang over deed...

[Tsunami]

En daarom bestaat for, dan maak je dat soort fouten niet

[Haan]

Tsunami schreef op woensdag 05 december 2012 @ 11:58:
En daarom bestaat for, dan maak je dat soort fouten niet

Dat is inderdaad les 1 of 2 als je begint met programmeren: "als je bij voorbaat al weet hoeveel iteraties je gaat doen, gebruik je een for-loop."

[Davio]

Tsunami schreef op woensdag 05 december 2012 @ 11:58:
En daarom bestaat for, dan maak je dat soort fouten niet

Hoe bedoel je?

PHP:

for($i=0; $i < $max; $j++)
{
// DoStuff....
}

[Rutix]

Davio schreef op woensdag 05 december 2012 @ 12:41:
[...]

Hoe bedoel je?

PHP:

for($i=0; $i < $max; $j++)
{
// DoStuff....
}

En daarom gebruik je geen php

[R4gnax]

ZpAz schreef op vrijdag 30 november 2012 @ 19:36:
last-child of first-child, één van de twee werkt zelfs in IE6 als ik me niet vergis. Maar niet beide.

edit:

[...]


Aa, first-child werkt dus al in IE6.

Nee, vanaf IE7. IE6 ondersteunt alleen de :first-letter en :first-line pseudos, misschien dat je daar mee in de war zit.

Tot en met IE8 bevat :first-child trouwens nog een leuke bug; als je een element dynamisch met JavaScript invoegt als eerste child element, dan zal het oude child element nog steeds gematched worden met de :first-child CSS rule. In IE7 tellen non-element SGML constructs zoals comments ook nog mee voor het bepalen van wat het eerste child element van een element is.

[ Voor 3% gewijzigd door R4gnax op 05-12-2012 13:15 ]

[Tsunami]

Of je telt gewoon niet met willekeurige letters. i staat voor index, voor de rest kan je wel wat beters bedenken.

[RobIII]

Tsunami schreef op woensdag 05 december 2012 @ 13:16:
Of je telt gewoon niet met willekeurige letters. i staat voor index, voor de rest kan je wel wat beters bedenken.

Wat je hoeft altijd maar over één index te itereren...

[WormLord]

RobIII schreef op woensdag 05 december 2012 @ 13:19:
[...]

Wat je hoeft altijd maar over één index te itereren...

Een tweede index waar je over wil itereren noem je natuurlijk ii.

[Vaan Banaan]

Ik gebruik daar altijd de combi's I1 / l1 of l1 / ll voor.
Hangt er vanaf welke het slechtst in de IDE te onderscheiden is.

code:

Ik gebruik daar altijd de combi's I1 / l1 of l1 / ll voor.
Hangt er vanaf welke het slechtst in de IDE te onderscheiden is.

[mcDavid]

Vaan Banaan schreef op woensdag 05 december 2012 @ 22:04:
Ik gebruik daar altijd de combi's I1 / l1 of l1 / ll voor.
Hangt er vanaf welke het slechtst in de IDE te onderscheiden is.

code:

Ik gebruik daar altijd de combi's I1 / l1 of l1 / ll voor.
Hangt er vanaf welke het slechtst in de IDE te onderscheiden is.

Monospace

[ Voor 9% gewijzigd door mcDavid op 05-12-2012 22:28 ]

[Verwijderd]

Ach, zolang je binnen de lus niet met complexe getallen hoeft te rekenen voldoen i en opvolgend j prima dacht ik zo...

[BasieP]

Verwijderd schreef op woensdag 05 december 2012 @ 22:52:
Ach, zolang je binnen de lus niet met complexe getallen hoeft te rekenen voldoen i en opvolgend j prima dacht ik zo...

eens. Dat zie je ook in ongeveer 80% van de code van anderen (in alle talen)

[MBV]

nou ja, meer dan 2 lusjes in elkaar is sowieso dubieus. x, y en z voor 3 dimensies uitgezonderd, maar die noem je niet i en j...

[Patriot]

MBV schreef op donderdag 06 december 2012 @ 09:25:
nou ja, meer dan 2 lusjes in elkaar is sowieso dubieus. x, y en z voor 3 dimensies uitgezonderd, maar die noem je niet i en j...

Het is PHP hè, dus er zijn vast mensen die bijvoorbeeld een treemodelletje niet recursief hebben aangepakt maar gewoon met 40 lussen "want wie gaat er nou verder dan 40"

Brr.. ik zeg het als grap maar ik weet dat er iemand is geweest die het heeft gedaan..

[Firesphere]

Patriot schreef op donderdag 06 december 2012 @ 09:55:
[...]


Het is PHP hè, dus er zijn vast mensen die bijvoorbeeld een treemodelletje niet recursief hebben aangepakt maar gewoon met 40 lussen "want wie gaat er nou verder dan 40"

Brr.. ik zeg het als grap maar ik weet dat er iemand is geweest die het heeft gedaan..

Raad eens wat ik van de week heb mogen fixen

[MBV]

Sterkte! Ik heb wel eens een boom van 5 lagen diep gehad, maar de eerste 2 lagen waren dan een foreach die elke keer een functie processThirdThing($tree[i][j]) aanriep.

Ik bedoel dus een boom van eigenschappen: order bevat regels bevat producten bevat eigenschappen.

[ Voor 22% gewijzigd door MBV op 06-12-2012 16:00 ]

[Zoijar]

Patriot schreef op donderdag 06 december 2012 @ 09:55:
Het is PHP hè, dus er zijn vast mensen die bijvoorbeeld een treemodelletje niet recursief hebben aangepakt

Terzijde, ik vind recursieve functies ook meestal niet zo netjes. Moeilijk uit te breiden, te debuggen, eet stack space... toch leer je dat vaak op school. Zelf push ik altijd 'work items' op een stack/vector binnen een functie. Dan kan je ook nog switchen tussen breadth of depth first door van het begin of einde van je vector te lezen. (en dat geheel kan je natuurlijk weer generaliseren/templatizen oid)

[Bosmonster]

YopY schreef op donderdag 29 november 2012 @ 16:45:
Nouja, het lijkt erop dat dit een IE-compatibility poging is, aangezien IE 7 en co geen CSS pseudo-selectors (:first-child) ondersteunen en je het dus niet voor styling kunt gebruiken. :first-child werkt echter wel in jquery, dus dit lijkt me een redelijke oplossing.

Hij doet het natuurlijk niet omdat hij het op alle li's onder iets met een class .accordion / .foldOut doet, maar dat terzijde.

Ik snap wat ie denkt dat het moet doen, maar dat doet het dus niet. Nu voegt ie gewoon aan alle li's die class toe

Daarnaast is het inderdaad sinds IE7 niet meer nodig en zelfs die ondersteunen we praktisch niet meer.

Daarnaast, heb je echt 3 functies nodig waarvan de naam langer is dan de totale aanroep voor iets simpels als het toevoegen van een class? En als je dat al doet, wil je dan niet liever gewoon de element-set gebruiken ipv een selector-string? Nu krijg je bij die bovenste dus iets raars dat ie string concat moet doen voor iets waar het niet echt een fijne oplossing is (en breekt op meerdere element-selectors, dan pakt ie alleen de laatste)

[ Voor 22% gewijzigd door Bosmonster op 06-12-2012 17:10 ]

[MBV]

Zoijar schreef op donderdag 06 december 2012 @ 16:37:
[...]

Terzijde, ik vind recursieve functies ook meestal niet zo netjes. Moeilijk uit te breiden, te debuggen, eet stack space... toch leer je dat vaak op school. Zelf push ik altijd 'work items' op een stack/vector binnen een functie. Dan kan je ook nog switchen tussen breadth of depth first door van het begin of einde van je vector te lezen. (en dat geheel kan je natuurlijk weer generaliseren/templatizen oid)

En daarom heeft PHP ook recursieve foreach, en ik dacht zelfs map/reduce achtige zaken.

[L-VIS]

Oh de ironie: http://cookievrij.nos.nl/

[Verwijderd]

Zoijar schreef op donderdag 06 december 2012 @ 16:37:
[...]

Terzijde, ik vind recursieve functies ook meestal niet zo netjes. Moeilijk uit te breiden, te debuggen, eet stack space... toch leer je dat vaak op school. Zelf push ik altijd 'work items' op een stack/vector binnen een functie. Dan kan je ook nog switchen tussen breadth of depth first door van het begin of einde van je vector te lezen. (en dat geheel kan je natuurlijk weer generaliseren/templatizen oid)

Dat lijkt me wel HEEL omslachtig als je simpelweg een treeview wil weergeven.

[MBV]

L-VIS schreef op dinsdag 11 december 2012 @ 09:49:
Oh de ironie: http://cookievrij.nos.nl/

Alleen 2 functionele cookies voor de load balancer, lijkt mij niet zo'n probleem Er stonden nog wat cookies van nos.nl, als je die weggooit worden ze niet opnieuw aangemaakt.

[L-VIS]

Er stonden eerder nog google analytics cookies! Maar die twee cookies zijn in mijn ogen wel een probleem als je site cookievrij heet.

[Puc van S.]

L-VIS schreef op dinsdag 11 december 2012 @ 10:41:
Er stonden eerder nog google analytics cookies! Maar die twee cookies zijn in mijn ogen wel een probleem als je site cookievrij heet.

En al helemaal als je beweert dat je zelfs voor functionele cookies toestemming hoort te vragen:
https://twitter.com/laram/status/278418507807461377

[.oisyn]

Verwijderd schreef op dinsdag 11 december 2012 @ 10:14:
[...]


Dat lijkt me wel HEEL omslachtig als je simpelweg een treeview wil weergeven.

Even los van of je het ermee eens bent of niet, het is absoluut niet omslachtig, laat staan "HEEL" omslachtig.

[ Voor 5% gewijzigd door .oisyn op 11-12-2012 11:28 ]

[Tarilo]

PHP:

$rTransactie = "SELECT * FROM $tabel WHERE TRUE ORDER BY DATUM";

Dit soort pareltjes vind ik dagelijks in productiecode. Ik zal maar niet beginnen over de kwaliteit van de rest can de code...

[JohnStaakke]

[Gomez12]

Tarilo schreef op dinsdag 11 december 2012 @ 15:13:

PHP:

$rTransactie = "SELECT * FROM $tabel WHERE TRUE ORDER BY DATUM";

Dit soort pareltjes vind ik dagelijks in productiecode. Ik zal maar niet beginnen over de kwaliteit van de rest can de code...

Daadwerkelijk in productie-code of in sql-logs?

Het 2e kan ik me nog enigszins voorstellen als iemand met string concatenation query's zit op te bouwen en hierbij toevallig geen where heeft.
Maar het 1e...

[lauwsa]

Volgens mij kwam ik vroeger een keer uit op een vergelijkbaar probleem als dit:

code:

#include "iostream"

using namespace std;

int main()
{
    double valueA = 1.0;
    double valueB = 0.0;

    for( int i = 0; i < 10; i++)
        valueB += 0.1;

    cout << (valueA == valueB ? "Equal\n" : "Not equal\n");

    return 0;
}

Resultaat: Not equal. De compiler heeft gelijk, maar als je de vaules uitprint dan denk je echt: Waarom komt dat toch niet uit. Eigenlijk staat er gewoon 1 == 0.9999999999. Dus idd not equal.

[Zoijar]

lauwsa schreef op maandag 24 december 2012 @ 11:06:
Volgens mij kwam ik vroeger een keer uit op een vergelijkbaar probleem als dit:

code:

#include "iostream"

using namespace std;

int main()
{
    double valueA = 1.0;
    double valueB = 0.0;

    for( int i = 0; i < 10; i++)
        valueB += 0.1;

    cout << (valueA == valueB ? "Equal\n" : "Not equal\n");

    return 0;
}

Resultaat: Not equal. De compiler heeft gelijk, maar als je de vaules uitprint dan denk je echt: Waarom komt dat toch niet uit. Eigenlijk staat er gewoon 1 == 0.9999999999. Dus idd not equal.

Het is wel heel logisch en dit soort dingen zou eigenlijk elke programmeur ook moeten weten. Een float kan namelijk geen 0.1 representen.

Ik weet dat het eigenlijk niet helemaal correct is maar meestal doe ik gewoon abs(a-b) < 1.0E-5 aangezien mijn getallen meestal in de buurt van 1.0 liggen.

http://www.cygnus-softwar...loats/comparingfloats.htm

[Olaf van der Spek]

Zoijar schreef op maandag 24 december 2012 @ 11:52:
Het is wel heel logisch en dit soort dingen zou eigenlijk elke programmeur ook moeten weten. Een float kan namelijk geen 0.1 representen.

Het gaat hier over doubles en of 0.1 wel of niet exact kan hangt volgens mij af van het platform.

[Koppensneller]

Een double is gewoon een float met meer precisie

[Zoijar]

Olaf van der Spek schreef op maandag 24 december 2012 @ 11:55:
Het gaat hier over doubles en of 0.1 wel of niet exact kan hangt volgens mij af van het platform.

Meh, doubles, floats, reals...

Ja, de decimalxx IEEE 754 formats zijn idd decimaal, maar ken jij platformen die dat gebruiken? Ergens bij banken wellicht? (ik heb geen idee, nog nooit ergens gezien)

[ Voor 5% gewijzigd door Zoijar op 24-12-2012 11:59 ]

[Herko_ter_Horst]

http://floating-point-gui.de

[lauwsa]

Ik ben nog maar een hobbyist hé . Of ja, ik begin over een maand met Informatica in Eindhoven. Dus dat klopt bijna niet meer.

Ik had toen zelf trouwens geen floats gebruikt, die krijg ik aangeleverd. Ik wilde er een vergelijking mee maken wat dus niet zo goed lukte dan verwacht. Maar och, daar leer je van.

[R4gnax]

Zoijar schreef op maandag 24 december 2012 @ 11:58:
[...]
Ja, de decimalxx IEEE 754 formats zijn idd decimaal, maar ken jij platformen die dat gebruiken? Ergens bij banken wellicht? (ik heb geen idee, nog nooit ergens gezien)

Waarschijnlijk niet, of tenminste met een eigen sausje er overheen. IEEE 854 is de originele IEEE standaard voor radix-independent floating points, maar deze standardiseerde de interne binaire representatie niet, waardoor data interchange tussen veel software eigenlijk niet te garanderen valt zonder afspraken over het gebruik van een aansluitende interne representatie. (Pas met IEEE 754-2008, een herziene versie uit 2008 die ook een herziene versie van IEEE 854 bevat, is deze gestandardiseerd.)

[HeSitated]

Geen code voorbeeld (die ziet er zelfs nog gestructureerd uit ), maar alleen de gedachte al: maandag een vb-script debuggen van 3400 regels...

[JohnStaakke]

Iemand op mijn FB die dit post:



En het dan nog gaat zitten verdedigen ook. So wrong in so many ways.

[Afvalzak]

L-VIS schreef op dinsdag 11 december 2012 @ 10:41:
Er stonden eerder nog google analytics cookies! Maar die twee cookies zijn in mijn ogen wel een probleem als je site cookievrij heet.

Staan er bij mij ook 2 van, oeps

Wel grappig dat met al het gepraat over tree's ik een stamboom reclame krijg op deze pagina

[Avalaxy]

JohnStaakke schreef op vrijdag 04 januari 2013 @ 00:08:
Iemand op mijn FB die dit post:

[afbeelding]

En het dan nog gaat zitten verdedigen ook. So wrong in so many ways.

Gelukkig maar dat je oneindig veel tijd hebt om te leren, date('d-m-Y') levert namelijk '07-01-2013' op (kun je functies uberhaupt wel met een hoofdletter beginnen in PHP trouwens?

Maargoed, het runt toch niet, 'd' zal niet herkend worden zonder dollarteken er voor.

[ Voor 7% gewijzigd door Avalaxy op 04-01-2013 00:40 ]

[RobIII]

Avalaxy schreef op vrijdag 04 januari 2013 @ 00:38:
(kun je functies uberhaupt wel met een hoofdletter beginnen in PHP trouwens?

Jep:

quote: http://php.net/manual/en/functions.user-defined.php

Note: Function names are case-insensitive, though it is usually good form to call functions as they appear in their declaration.
_{emphasis mine}

Echter:

quote: http://php.net/manual/en/language.variables.basics.php

Variables in PHP are represented by a dollar sign followed by the name of the variable. The variable name is case-sensitive
_{emphasis mine}

Mooi spul jonguh!

PHP:

$x = 'A';
$X = 'B';

echo sprintf("%s : %s\r\n", $x, $X);
EchO SprIntF("%s : %s\r\n", $x, $X);

A : B
A : B

Avalaxy schreef op vrijdag 04 januari 2013 @ 00:38:
Maargoed, het runt toch niet, 'd' zal niet herkend worden zonder dollarteken er voor.

Evenals het ontbreken van de quotes om 'd-m-Y' om nog maar eens een obvious fout aan te wijzen...

[ Voor 83% gewijzigd door RobIII op 04-01-2013 01:32 ]

[lauwsa]

JohnStaakke schreef op vrijdag 04 januari 2013 @ 00:08:
Iemand op mijn FB die dit post:

[afbeelding]

En het dan nog gaat zitten verdedigen ook. So wrong in so many ways.

Hopen dat hij geen PHP in zijn tentamen krijgt .

[Janoz]

Olaf van der Spek schreef op maandag 24 december 2012 @ 11:55:
[...]

Het gaat hier over doubles en of 0.1 wel of niet exact kan hangt volgens mij af van het platform.

In een binair talstelsel heeft 0.1 hetzelfde probleem als 1/3 heeft in het decimale talstelsel. Het enige verschil tussen float of double is dat je gewoon meer 'cijfers achter de komma' hebt en er dus iets minder naast zit.

Tenzij je met platform ook platformen bedoeld die onderliggend niet met bits werken....

/oudekoe

[steveman]

PHP:

<?php

$date = "07-01-13";
$d = Date("d-m-y");

if ($date == $d) {
    echo "We are screwed dude!";
}
else {
    echo "Nog tijd om te leren voor proeftentamen :)";
}?>

Omfg ik verveel me echt...

Tevens, jeej m'n eerste php-dingetje

[Hydra]

Dus op 8-1-13 heb je nog tijd om voor je tentamen te leren?

[Patriot]

PHP:

<?php

// TODO: Knappe taal gebruiken
$date = strtotime('07-01-2013');

if (time() >= $date) {
    echo "We are screwed dude!";
}
else {
    echo "Still screwed, using PHP";
}

?>

[Olaf van der Spek]

Janoz schreef op vrijdag 04 januari 2013 @ 10:14:
In een binair talstelsel heeft 0.1 hetzelfde probleem als 1/3 heeft in het decimale talstelsel. Het enige verschil tussen float of double is dat je gewoon meer 'cijfers achter de komma' hebt en er dus iets minder naast zit.

Dat is niet het enige verschil, het bereik van double is ook groter.

Tenzij je met platform ook platformen bedoeld die onderliggend niet met bits werken....

Daar doelde ik inderdaad op, maar dat is vooral een theoretisch issue.

[Zoijar]

Janoz schreef op vrijdag 04 januari 2013 @ 10:14:
Tenzij je met platform ook platformen bedoeld die onderliggend niet met bits werken....

Als je echt wilt mierenneuken (oid), dan maakt het niet uit wat het plaform onderliggend gebruikt maar wat de float representatie betekent. Standaard floats zijn uitgedrukt in machten van (-)2; de decimale floats schrijf je ook in bits maar de basis is in machten van 10 waardoor je wel 0.1 kan uitdrukken. Al moet je dan wel hardware support hebben om met die bit-reeksen te rekenen, althans als het efficient moet. Fixed point 8 bits kan je ook opvatten als een getal van 0 tot 2.55 in stapjes van 0.01. Dan heb je een platform dat onderliggend met bits werkt maar in een decimale basis.

[lauwsa]

C++:

char * test = new char[length] + 1;

Oops, misschien voortaan beter kijken wat je "toevoeg" . Wel leuk, op Windows met een x86 CPU kreeg ik er geen problemen mee. Op Debian met een ARM CPU krijg ik er wel problemen mee. Op Ubuntu met een x86 CPU kreeg ik er geen problemen mee.

Ook nog leuk:

C++:

int dataSize = data.size();

for ( int i = 0; i < dataSize; i++)
{
    if( data[i] == 'x')
        data = blabla();
    //Wat kan er nu toch fout gaan xD
}

[ Voor 24% gewijzigd door lauwsa op 07-01-2013 12:39 ]

[Zoijar]

lauwsa schreef op maandag 07 januari 2013 @ 12:37:

C++:

char * test = new char[length] + 1;

Oops, misschien voortaan beter kijken wat je "toevoeg" . Wel leuk, op Windows met een x86 CPU kreeg ik er geen problemen mee. Op Debian met een ARM CPU krijg ik er wel problemen mee. Op Ubuntu met een x86 CPU kreeg ik er geen problemen mee.

Wat voor problemen dan? Je mag wel 1 bij een pointer optellen. Je moet het niet casten naar int oid en dan unaligned lezen, maar verder zie ik het probleem niet?

[.oisyn]

Als je een char array van 'length' bytes alloceert dan wil je er waarschijnlijk ook 'length' bytes instoppen . Daarnaast heb je nog een probleem met delete[].

[BarôZZa]

Niet zo zeer slecht, maar wel enorm lelijk en vermakelijk. De meest betrouwbare manier om een file upload te stylen met behulp van CSS.

Cascading Stylesheet:

.fileupload {
    width: 100px;
    height: 50px;
    position: relative;
    overflow: hidden;
    background: ...; /* and other things to make it pretty */
}

.fileupload input {
    position: absolute;
    top: 0;
    right: 0; /* not left, because only the right part of the input seems to
                 be clickable in some browser I can't remember */
    cursor: pointer;
    opacity: 0.0;
    filter: alpha(opacity=0); /* and all the other old opacity stuff you
                                 want to support */
    font-size: 300px; /* wtf, but apparently the most reliable way to make
                         a large part of the input clickable in most browsers */
    height: 200px;
}

[Sebazzz]

lauwsa schreef op maandag 07 januari 2013 @ 12:37:
Oops, misschien voortaan beter kijken wat je "toevoeg" . Wel leuk, op Windows met een x86 CPU kreeg ik er geen problemen mee. Op Debian met een ARM CPU krijg ik er wel problemen mee. Op Ubuntu met een x86 CPU kreeg ik er geen problemen mee.

Op Windows met x86 in release mode neem ik aan? Ik kan me niet voorstellen dat je in debug mode er niet uit klapt.

[Olaf van der Spek]

Sebazzz schreef op maandag 07 januari 2013 @ 23:28:
[...]

Op Windows met x86 in release mode neem ik aan? Ik kan me niet voorstellen dat je in debug mode er niet uit klapt.

Ligt aan de rest van de code. Zonder delete[] gaat het misschien nog wel, mogelijk schrijf je ergens een 0 teveel weg.

[.oisyn]

Heap corruption van dat blok (dus als je buiten de bounds van de array schrijft) wordt pas gedetecteerd bij het vrijgeven van het blok (of bij het aanroepen van een heap check functie). Maar daar komt ie natuurlijk nooit, want diezelfde delete[] gaat nu sowieso fout.

Aangezien lauwsa zegt dat er "geen problemen mee waren" roept ie dus nooit delete[] aan. En ja, dan zal het gemiddeld gezien wel vaak goed gaan. Geheugenallocaties onder VC++ zijn standaard 8-bytes aligned, dus voor elke 'length' die geen veelvoud van 8 is kun je er rustig een byte extra achteraan plakken

[lauwsa]

Hmm, de code kwam niet echt in een fase waar hij de chars moest verwijderen. Dat was juist het vervelende, je hebt het nog steeds zo gevonden maar dan weet je tenminste meteen wat het probleem is. Bij een delete zal hij een Debug asserion failed geven in Debug mode en in release mode zal hij hoogst waarschijnlijk vast lopen in de HeapFree functie.

Ik neem aan dat de Compiler bijbouwt hoe groot de geheugen blokken zijn die hij vrij gegeven heeft? Als er uit getreden word zal hij dat denk ik detecteren dat er wat niet klopt. Of doet hij dat op een andere manier?

Maar waarom gaat het eigenlijk niet fout op Debian met een ARM CPU? Op Ubuntu en op Debian gebruik ik zo ver ik weet G++. Het kan ook nog zijn dat op Debian daar kritische data stond.

[ Voor 9% gewijzigd door lauwsa op 08-01-2013 08:58 ]

[lauwsa]

Sebazzz schreef op maandag 07 januari 2013 @ 23:28:
[...]

Op Windows met x86 in release mode neem ik aan? Ik kan me niet voorstellen dat je in debug mode er niet uit klapt.

Zolang je niks verwijderd niet:

C++:

    char * test = new char[2];
    test[0] = 'a';
    test[1] = '\0';

    char * test2 = new char[3] + 1;
    test2[0] = 'a';
    test2[1] = 'a';
    test2[2] = 'a';
    test2[3] = '\0';

Als je delete[] gebruikt natuurlijk wel, op debug sowieso en op release waarschijnlijk ook. Edit: getest, op beide modes gaat het niet goed met delete.

[ Voor 5% gewijzigd door lauwsa op 08-01-2013 08:59 ]

[.oisyn]

Bij test2 schrijf je overigens 2 bytes voorbij het einde

[lauwsa]

I know, dat gebeurde ook in het voorbeeld daar boven.
Ik schrijf iets met de lengthe: length er in, en zet een \0 aan het einden.

Die +1 was bedoeld voor de \0. Wat dus bij de pointer op geteld word waardoor er 2 plaatsen “verspilt” worden.

[.oisyn]

Oh zo

[Zoijar]

lauwsa schreef op dinsdag 08 januari 2013 @ 09:52:
I know, dat gebeurde ook in het voorbeeld daar boven.
Ik schrijf iets met de lengthe: length er in, en zet een \0 aan het einden.

Die +1 was bedoeld voor de \0. Wat dus bij de pointer op geteld word waardoor er 2 plaatsen “verspilt” worden.

Oh, ok, ja, als je out of bounds schrijft en een niet gealloceerde pointer delete dan snap ik wel dat dat fout gaat

[Houbie]

Ooit gelezen in mijn eerste jaar informatica (van een medestudent)

Java:

int getInt(int n) {
   return n;
}

[Michali]

Simonhoubracken schreef op dinsdag 08 januari 2013 @ 16:03:
Ooit gelezen in mijn eerste jaar informatica (van een medestudent)

Java:

int getInt(int n) {
   return n;
}

Zo slecht is het niet, voor educatie doeleinden. Verder is het natuurlijk wel doelloos, maar misschien was die persoon gewoon dingen aan het uitproberen. Van een eerstejaars student moet je ook niet verwachten dat die alleen maar productieniveau code schrijft. Heeft iig een leesbare naam die redelijk beschrijft wat de functie doet.

[Geerrrt]

Kwam deze laatst nog een keer tegen in oude code:

Java:

public boolean checkState(TestRoom testRoom) {
    return this.checkState(testRoom);
}

En het maar niet zien

[Verwijderd]

Dat is wel dom ja. Kreeg je geen warning van je IDE?

[lauwsa]

Je cpu zal dat leuk gevonden hebben .

[RobIII]

lauwsa schreef op woensdag 09 januari 2013 @ 19:41:
Je cpu zal dat leuk gevonden hebben .

Anderhalve nanoseconde ja, daarna krijg je gewoon een stack overflow

[Olaf van der Spek]

RobIII schreef op woensdag 09 januari 2013 @ 19:55:
[...]

Anderhalve nanoseconde ja, daarna krijg je gewoon een stack overflow

Ligt eraan, met tail recursie optimalistie niet per se.

[PdeBie]

slecht? Niet echt. Slordig? Dat zeker.
Kwam net tijdens het refactoren onderstaand if statement tegen in een stukje code. What was I thinking???

C#:

if (!UseDebtorsOnOrderForm)
            phFormDebtor.Visible = false;

[Zoijar]

pdebie schreef op vrijdag 11 januari 2013 @ 13:56:
slecht? Niet echt. Slordig? Dat zeker.
Kwam net tijdens het refactoren onderstaand if statement tegen in een stukje code. What was I thinking???

C#:

if (!UseDebtorsOnOrderForm)
            phFormDebtor.Visible = false;

Je bedoelt de ontbrekende braces? Een doodzonde idd. Gebruik nooit een if-statement zonder braces. Dat een nieuw-ontwikkelde taal het uberhaupt ondersteund vind ik al een fout van C# trouwens.

@onder: ja, dat snap ik

[ Voor 16% gewijzigd door Zoijar op 11-01-2013 14:09 ]

[CodeCaster]

Leesbaarder dus minder foutgevoelig:

C#:

phFormDebtor.Visible = UseDebtorsOnOrderForm;

[ Voor 3% gewijzigd door CodeCaster op 11-01-2013 14:09 ]

[PdeBie]

@CodeCaster: dat is het dus inderdaad geworden

@Zoijar: Als er maar 1 regel volgt gebruik ik nooit braces, tenzij er een else achter komt.
Bij elke if braces gebruiken vind ik het minder leesbaar door worden. Maar dat is persoonlijk denk ik.

Ik doe het zelf dus zo:

C#:

//-------------------------------------------
//exclusief else

if(foo)
  bar();

//-------------------------------------------
//inclusief else

if(foo)
{
  bar();
}
else
{
  otherFunction();
}

[ Voor 3% gewijzigd door PdeBie op 11-01-2013 14:15 ]

[Zoijar]

pdebie schreef op vrijdag 11 januari 2013 @ 14:14:
@Zoijar: Als er maar 1 regel volgt gebruik ik nooit braces, tenzij er een else achter komt.
Bij elke if braces gebruiken vind ik het minder leesbaar door worden. Maar dat is persoonlijk denk ik.

Brace-style valt over te twisten, maar je weet niet of er in de toekomst maar 1 regels volgt. Je ziet soms dit:

C++:

if (blah blah lbha lbha)
    // if bla we do blah blah
    // because blah blahblah
    // also see blah blah
    visibility = false;

// continue processing

foo();

En dan voegt iemand achter visibility = false ook later nog toe, scale = 0... Het is foutgevoelig en onhandig. Als je maar 1 regel wilt gebruiken:

C++:

if (blah)  {vis = false;}

Over brace style doe ik trouwens dit, maar dat is persoonlijk:

C++:

if (a) {
   //
} else {
   //
}

Ik vind teveel verticaal wit de code lastig leesbaar maken. Schermen zijn al veel breder dan hoger tegenwoordig.

[kenneth]

CodeCaster schreef op vrijdag 11 januari 2013 @ 14:08:
Leesbaarder dus minder foutgevoelig:

C#:

phFormDebtor.Visible = UseDebtorsOnOrderForm;

Is alleen maar equivalent als er ook else phFormDebtor.Visible = true; achter zou staan

[PdeBie]

Dat is inderdaad puur een kwestie van gewenning denk ik ja.

Ik laat de braces juist verticaal uitlijnen, zodat ik makkelijker de begin en eind brace kan vinden (ook al markeert Visual Studio dit voor je als je de cursor erop zet). Binnen een brace inspringen uiteraard.

C#:

if(foo) {
    if(foo2) {
        //do lot's of stuff here
    }
    else {
        //do a little bit here
    }

    var1 = bar3();
    
    //some comment
    //some comment
    //some comment
}

Mijn variant:

C#:

if(foo)
{
    if(foo2)
    {
        //do lot's of stuff here
    }
    else
    {
        //do a little bit here
    }

    var1 = bar3();
    
    //some comment
    //some comment
    //some comment
}

Iets verder scrollen inderdaad. Maar voor mij persoonlijk vind ik het verticaal uitlijnen leesbaarder.

[ Voor 25% gewijzigd door PdeBie op 11-01-2013 14:49 ]

[kenneth]

"Jouw" variant is ook de standaardinstelling in VS.

Bij ons zijn standaardinstellingen heilig. Wel zo makkelijk, zowel wat betreft luiheid als het voorkomen van brace wars

[YellowOnline]

Dit vind ik het leesbaarst qua curly brackets/indenting:

C#:

<#
Voorbeeld met inspiratieloze variabelen 
#>

Function Veel-Ietsen()
    {
    ForEach ($Iets in $Ietsen)
        {
        While ($Iets -NE $IetsAnders)
            {
            If ($Iets -LT $NogIetsAnders)
                {
                Switch ($Iets -EQ $NogIets)
                    { 
                    1 {"Iets 1"} 
                    2 {"Iets 2"} 
                    3 {"Iets 3"} 
                    Default {"Oops"}
                    }
                }
            Else
                {
                #Nothing
                }
            Iets++
            }
        }
    }

Veel-Ietsen

Da's eigenlijk hetzelfde als wat jullie hierboven standaard vinden, behalve dat ik een tab meer doe om de codeblokken beter te onderscheiden (imho).

[ Voor 24% gewijzigd door YellowOnline op 11-01-2013 15:13 ]

[.oisyn]

pdebie schreef op vrijdag 11 januari 2013 @ 14:47:
Mijn variant:

C#:

if(foo)
{
    if(foo2)
    {
        //do lot's of stuff here
    }
    else
    {
        //do a little bit here
    }

    var1 = bar3();
    
    //some comment
    //some comment
    //some comment
}

Met ^^^^

Wel of geen verplicht braces is imho ook erg afhankelijk van of je braces op dezelfde regel plaatst of niet.

C++:

// #1
if (x)
    doSomething();

// #2
if (x) {
    doSomething();

// #3
if (x)
{
    doSomething();

Het verschil tussen #1 en #2 is zo klein dat een fout zo gemaakt is. Dus als je #2 gebruikt zou ik #1 nooit gebruiken. Bij #3 is de openings-brace echter niet te missen en maak je zelden de fout dat je gewoon een regel toevoegt zonder de brace toe te voegen. Het is mij iig nog nooit overkomen (ja *letterlijk* nooit)

[ Voor 34% gewijzigd door .oisyn op 11-01-2013 15:24 ]

[Zoijar]

Eigenlijk zou je een file formaat moeten hebben dat een soort ast opslaat en dat je die kan afbeelden hoe jij wilt (vergelijk, code in xml, editor met xsl/css stylesheet) en dat hij dan ook jouw invoer weer om kan zetten in het canonical formaat. Of bestaat dat al? (buiten smalltalk )

Het is toch eigenlijk raar dat programmeurs onderling afspraken moeten maken over de layout van de code en niet puur en alleen de werking?

[ Voor 23% gewijzigd door Zoijar op 11-01-2013 15:27 ]

[.oisyn]

Wat een beetje haaks staat op mijn vorige opmerking, tenzij je verplicht dat je altijd braces moet gebruiken omdat er nou eenmaal mensen zijn die #2 als persoonlijke voorkeur hebben (en dus fouten kunnen maken met jouw #1 code)

[PdeBie]

Zoijar schreef op vrijdag 11 januari 2013 @ 15:24:
Het is toch eigenlijk raar dat programmeurs onderling afspraken moeten maken over de layout van de code en niet puur en alleen de werking?

Bij mijn vorige werkgever hadden we geen tot weinig afspraken hierover en dat zag je ook terug in de code.

Dat was voor mij destijds ontzettend onhandig, omdat ik in het ene project met de code van programmeur A zat te rommelen en bij een ander project met de code van programmeur B.
Beiden hielden hun eigen stijl er op na en ik moest dus regelmatig 2 of 3 keer lezen wat er nou stond.

[kenneth]

Natuurlijk, het is belangrijk om afspraken erover te maken maar Zoijar heeft gelijk dat het raar is dat die afspraken nodig zijn.

Want:

C#:

if (i == 1) {
    result = "hello";
}

C#:

if ( i == 1 )
{
    result = "hello";
}

Daar zit toch geen verschil in voor een compiler? Zoveel conventies komen neer op gezanik over whitespace ... daar zou allang een geautomatiseerde oplossing voor moeten zijn. Check ik de code uit, krijg ik de code geformat zoals ik het wil, checkt mijn collega code uit, krijgt hij het geformat volgens zijn voorkeuren. Daar ligt een compiler echt niet wakker van en je dvcs-oplossing zou daar ook niet wakker van moeten liggen.

Het is de IT verdorie, wij zijn van het automatiseren van repetitieve oplossingen voor repetitieve problemen

[Afvalzak]

Ja, maar als je geen braces doet, worden ze niet automagisch toegevoegd volgens mij?

[kenneth]

Valt ook wel een mouw aan te passen als je code als een AST is opgeslagen, zoals Zoijar zegt. En dan in je IDE een instelling "don't use braces when block contains a single statement" ...

[ValHallASW]

kenneth schreef op vrijdag 11 januari 2013 @ 16:09:
Zoveel conventies komen neer op gezanik over whitespace ... daar zou allang een geautomatiseerde oplossing voor moeten zijn. Check ik de code uit, krijg ik de code geformat zoals ik het wil, checkt mijn collega code uit, krijgt hij het geformat volgens zijn voorkeuren. Daar ligt een compiler echt niet wakker van en je dvcs-oplossing zou daar ook niet wakker van moeten liggen.

Het is de IT verdorie, wij zijn van het automatiseren van repetitieve oplossingen voor repetitieve problemen

Het is een beetje opzetwerk, maar met git en astyle kan dat gewoon. Zie http://git-scm.com/book/ch7-2.html bij 'keyword expansion'.

[Zoijar]

kenneth schreef op vrijdag 11 januari 2013 @ 16:19:
Valt ook wel een mouw aan te passen als je code als een AST is opgeslagen, zoals Zoijar zegt. En dan in je IDE een instelling "don't use braces when block contains a single statement" ...

Ik zou me zelfs nog voor kunnen stellen dat je behalve dat je een standaard lokale stylesheet kiest, je ook nog lokaal per file extra persoonlijke formatting aan zou kunnen geven die afwijkt van de default. Soort meta formatting hints.

[ Voor 15% gewijzigd door Zoijar op 11-01-2013 17:10 ]

[deadinspace]

@ de eeuwige brace-discussie: ik doe het graag zo:

C:

if( foo )
{
    if(foo2)
        baz1();
    else
        baz2();

    var1 = bar3();
}

Dus braces op nieuwe regels, vertikaal uitgelijnd onder het eerste karakter van het bijbehorende control-flow keyword, en geen braces voor 1-statement ifs/elses.

Ik vind dit persoonlijk een fijne balans; de braces op deze manier schrijven maakt het voor mij makkelijk blocks te zien, en ze weglaten bij 1-statement ifs (wat vrij veel voorkomt) beperkt de hoogte van de code weer een beetje. Ik kan me niet herinneren dat ik hiermee ooit ben vergeten braces toe te voegen voor een extra statement in de if-body.

Stiekem wilde ik dat meer talen aan semantische whitespace deden zoals Python...

Zoijar schreef op vrijdag 11 januari 2013 @ 15:24:
Eigenlijk zou je een file formaat moeten hebben dat een soort ast opslaat en dat je die kan afbeelden hoe jij wilt (vergelijk, code in xml, editor met xsl/css stylesheet) en dat hij dan ook jouw invoer weer om kan zetten in het canonical formaat. Of bestaat dat al? (buiten smalltalk )

In principe bestaat dat al, waar de kanonieke vorm "code met willekeurige formatting" is (feitelijk ook een AST-representatie ) en de display tools code formatters zijn

Niet zo technisch elegant als wat jij impliceerde, maar wel iets dat al bestaat en met huidige software kan werken

Het is toch eigenlijk raar dat programmeurs onderling afspraken moeten maken over de layout van de code en niet puur en alleen de werking?

Ja. Ach, misschien komen we daar nog wel eens van af, net zoals samenwerken zonder VCS tegenwoordig een beetje als onacceptabel wordt gezien...

[Waster]

En wat is er mis met altijd braces op dezelfde regel.

code:

if (bla) {
    ..
}

Dan kosten try catch tenminste niet zoveel ruimte:

code:

try
{
    ..
}
catch (Exception e)
{
    ..
}