Toon posts:

[Alg] Slechtste programmeervoorbeelden deel 3 Vorige deelOverzichtVolgende deelLaatste deel

Dit topic is onderdeel van een reeks. Ga naar het meest recente topic in deze reeks.

Pagina: 1 2 3 ... 11 Laatste
Acties:
  • 69.365 views sinds 30-01-2008

  • NMe
  • Registratie: Februari 2004
  • Laatst online: 23-05 21:12

NMe

Quia Ego Sic Dico.

Topicstarter
Het is alweer tijd voor deel 3 van deze succesvolle topicreeks. :P

Vorige delen:
[alg] slechtste prog voorbeelden.
[alg] Slechtste programmeervoorbeelden deel 2

Regels:
Uiteraard is het in dit topic niet de bedoeling dat andere users en/of topics aangehaald worden om ze voor gek te zetten. Lachen om je eigen code, of over dingen die je "wel eens tegengekomen bent" is prima, maar hou het onderling netjes. :)

Daarnaast is het niet de bedoeling dat je hier maar even snel een kort vraagje komt stellen. Als een vraag niet topicwaardig is, dan is hij wat dit forum betreft ook niet postwaardig. :)

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


  • Alex)
  • Registratie: Juni 2003
  • Laatst online: 06-05 09:08
Ik gisteren nog...
JavaScript:
1
...this.getElementsByTagName('img')[0]...


Het ging over een <a> met daarin een <img> die dynamisch was aangemaakt (via JS, userscripts)... iets zegt me dat gewoon "this.firstChild" ook had volstaan... (dit was btw in een onclick-eventhandler)

[Voor 8% gewijzigd door Alex) op 21-07-2007 16:13]

We are shaping the future


Anoniem: 26306

Afhankelijk van het feit of het mogelijk is dat er whitespace of andere elementen binnen dat a element kunnen staan. Als dat niet zo is, had firstChild inderdaad wel volstaan. En dat scheelt flink wat overhead ;)

  • Alex)
  • Registratie: Juni 2003
  • Laatst online: 06-05 09:08
JavaScript:
1
2
3
4
5
var link = document.createElement('a');

var image = document.createElement('img');

link.appendChild(image);

Daar zit geen whitespace tussen de <a> en de <img>, lijkt me...

We are shaping the future


Anoniem: 140111

@ oisyn, implode gaat hier helaas niet werken, tenzij ik met een 2de array ga werken natuurlijk.

  • xtra
  • Registratie: November 2001
  • Laatst online: 23:49

xtra

domestic archelogist

Alex) schreef op zaterdag 21 juli 2007 @ 16:12:
Ik gisteren nog...
JavaScript:
1
...this.getElementsByTagName('img')[0]...


Het ging over een <a> met daarin een <img> die dynamisch was aangemaakt (via JS, userscripts)... iets zegt me dat gewoon "this.firstChild" ook had volstaan... (dit was btw in een onclick-eventhandler)
Ergens heb je wel gelijk. Je moet dan wel blijven opletten of het een dynamische img is of een die er al was. Bij de laatste is een enter al genoeg om je script te verpesten. Om fouten voor te zijn had ik waarschijnlijk ook 'jouw' constructie genomen. (Of de reference die je toch al hebt bij het dynamisch aanmaken gebruiken)

Ik zeg het met e-mail
Men nederlands is wel is beter geweesd
Nederlands is makkelijker als je denkt.


  • Alex)
  • Registratie: Juni 2003
  • Laatst online: 06-05 09:08
xtra schreef op maandag 23 juli 2007 @ 14:38:
[...]

Ergens heb je wel gelijk. Je moet dan wel blijven opletten of het een dynamische img is of een die er al was. Bij de laatste is een enter al genoeg om je script te verpesten. Om fouten voor te zijn had ik waarschijnlijk ook 'jouw' constructie genomen. (Of de reference die je toch al hebt bij het dynamisch aanmaken gebruiken)
Het is dynamisch aangemaakt - geen extra tekens dus :)

Aan die references heb ik niets omdat het om code binnen een eventhandler gaat en je dan dus een scope-issue krijgt... tenzij je ergens een public array (o.i.d.) bijhoudt met daarin alle objecten... maar dat maakt niet uit, inmiddels heb ik alles werkend. IE deed moeilijk, dus ik heb uiteindelijk mijn hele mooie document.createElement-constructie overboord moeten gooien en het moeten vervangen door iets met innerHTML :X

Het leek wel alsof IE de DOM niet updatete, in Fx had ik geen problemen maar IE vertelde doodleuk dat hij het object niet kende :/

We are shaping the future


  • Deathraven
  • Registratie: November 2001
  • Laatst online: 28-05 13:44
Een abstracte klasse Document hebben waarop een hoop algemene afhandeling wordt gedaan.
Waarin een property staat met een harde verwijzing, zoiets als dit.

C#:
1
public virtual VenderXGrid Grid { get; }


En dan vervolgens een Document implementatie te hebben waarbij je VendorYGrid wilt gebruiken....

"Maar we wisselen toch nooit van Grid?" ... ;(

  • Orphix
  • Registratie: Februari 2000
  • Niet online
Deathraven schreef op maandag 23 juli 2007 @ 15:27:
Een abstracte klasse Document hebben waarop een hoop algemene afhandeling wordt gedaan.
Waarin een property staat met een harde verwijzing, zoiets als dit.

C#:
1
public virtual VenderXGrid Grid { get; }


En dan vervolgens een Document implementatie te hebben waarbij je VendorYGrid wilt gebruiken....

"Maar we wisselen toch nooit van Grid?" ... ;(
Mja ik vind het nog niet eens zo'n gekke gedachtengang. Ten eerste is het in heel veel gevallen zo dat er inderdaad nooit van vendor wordt gewisseld in de levensduur van een product. Daarnaast zou de enige oplossing zijn een generieke interface te maken die door zowel VendorX en VendorY worden geimplementeerd. Dit is veel werk en error-prone. Ik kan me goed voorstellen dat je zo'n ontwikkeling laat wachten tot het moment echt daar is. (wat misschien wel nu is ;))

  • Deathraven
  • Registratie: November 2001
  • Laatst online: 28-05 13:44
Tjah daar valt ook wel weer iets voor te zeggen. Tis alleen nogal een rotwerk om uiteindelijk alles te gaan refactoren. Helemaal als je niet in een keer alles kan/mag omzetten. Dan moet je namelijk dubbele code gaan opnemen zodat de 2 dingen toch nog naast elkaar gebruikt kunnen worden (for the time being) ... bleeeehh

Anoniem: 37526

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
    var ajaxRequest;
    try{
        
        ajaxRequest = new XMLHttpRequest();
    } catch (e){
        
        try{
            ajaxRequest = new ActiveXObject("Msxml2.XMLHTTP");
        } catch (e) {
            try{
                ajaxRequest = new ActiveXObject("Microsoft.XMLHTTP");
            } catch (e){
                
                alert("Sorry, Notepad will not work with your browser.");
                return false;
            }
        }
    }


O my...

  • Standeman
  • Registratie: November 2000
  • Laatst online: 10:30

Standeman

Moderator Wonen & Mobiliteit

Prutser 1e klasse

Ik kwam vandaag ook een mooie tegen:
Java:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
        if (wrappedData.length>32) {
            // It is a wrapped RSA Private key without key reference info
            return wrappedData;
        }
        else if (wrappedData.length<32) {
            // It is a wrapped DES or 2DES key without key reference info
            return wrappedData;
        }
        else {
            // It is a wrapped DES or 2DES key with key reference info
            int length = wrappedData[16];
            byte[] wrappedDesKey = new byte[length];
            System.arraycopy(wrappedData, 0, wrappedDesKey, 0, length);

            return wrappedDesKey;
        }

Volgens mij is 1 if zonder else's genoeg :)

The ships hung in the sky in much the same way that bricks don’t.


  • LuCarD
  • Registratie: Januari 2000
  • Niet online

LuCarD

Certified BUFH

Standeman schreef op vrijdag 03 augustus 2007 @ 15:29:
Ik kwam vandaag ook een mooie tegen:
Java:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
        if (wrappedData.length>32) {
            // It is a wrapped RSA Private key without key reference info
            return wrappedData;
        }
        else if (wrappedData.length<32) {
            // It is a wrapped DES or 2DES key without key reference info
            return wrappedData;
        }
        else {
            // It is a wrapped DES or 2DES key with key reference info
            int length = wrappedData[16];
            byte[] wrappedDesKey = new byte[length];
            System.arraycopy(wrappedData, 0, wrappedDesKey, 0, length);

            return wrappedDesKey;
        }

Volgens mij is 1 if zonder else's genoeg :)
ow? echt waar? en wat als de key exact 32 chars lang is?

Programmer - an organism that turns coffee into software.


Anoniem: 178962

LuCarD schreef op vrijdag 03 augustus 2007 @ 15:36:
[...]
ow? echt waar? en wat als de key exact 32 chars lang is?
Beter lezen ;)

Het kan inderdaad met 1 if zonder else.

  • LuCarD
  • Registratie: Januari 2000
  • Niet online

LuCarD

Certified BUFH

Anoniem: 178962 schreef op vrijdag 03 augustus 2007 @ 15:39:
[...]

Beter lezen ;)

Het kan inderdaad met 1 if zonder else.
hmm ik ging er vanuit dat hij een gedeelte code had weggelaten... :D

Programmer - an organism that turns coffee into software.


Anoniem: 178962

Hoewel het niet eens zo'n grote WTF is. Het kan goed zijn dat er eerst 3 verschillende acties stonden, maar bij achteraf nadenken en aanpassen dat dit eruit is gekomen.

Het maakt verder ook weinig uit denk ik, een beetje compiler zal dat stukje wel voor de je optimaliseren denk ik en anders nog.

  • Standeman
  • Registratie: November 2000
  • Laatst online: 10:30

Standeman

Moderator Wonen & Mobiliteit

Prutser 1e klasse

Het was ook meer de leesbaarheid waar ik me aan stoorde.. En een echt grote WTF was het idd niet.

The ships hung in the sky in much the same way that bricks don’t.


Anoniem: 178962

Standeman schreef op vrijdag 03 augustus 2007 @ 15:57:
Het was ook meer de leesbaarheid waar ik me aan stoorde.. En een echt grote WTF was het idd niet.
Ja maar, ja maar, er staat toch commentaar in? :+

Anoniem: 49627

Echt een 'slecht programmeervoorbeeld' is het niet maar toch een 'leuk' foutje/bugje dat ik vanmorgen had gemaakt.
Java:
1
new StringBuffer('[').append(someString).append(']');

  • Marcj
  • Registratie: November 2000
  • Laatst online: 07:57
Anoniem: 49627 schreef op dinsdag 14 augustus 2007 @ 14:40:
Echt een 'slecht programmeervoorbeeld' is het niet maar toch een 'leuk' foutje/bugje dat ik vanmorgen had gemaakt.
Java:
1
Ik moest zelf ook even in de Java API kijken voordat ik het zag :D

Anoniem: 37526

Standeman schreef op vrijdag 03 augustus 2007 @ 15:29:
Ik kwam vandaag ook een mooie tegen:
Java:
1
...

Volgens mij is 1 if zonder else's genoeg :)
Daar ben ik het niet mee eens. Wat nou als er bij "wrapped DES or 2DES key without key reference info" opeens een extra functie moet worden toegevoegd?

De drie mogelijkheden zijn er gemaakt om de drie verschillende type keys duidelijk in de programmacode te scheiden, en ook om aan te tonen hoe je kunt zien of het een x, y of z key is. Het kan inderdaad korter, maar leesbaarder word het er niet op.

Anoniem: 178962

Anoniem: 49627 schreef op dinsdag 14 augustus 2007 @ 14:40:
Echt een 'slecht programmeervoorbeeld' is het niet maar toch een 'leuk' foutje/bugje dat ik vanmorgen had gemaakt.
Java:
1
Oei oei, die is sneaky zeg ;)

offtopic:
Java ook altijd :'(

[Voor 4% gewijzigd door Anoniem: 178962 op 14-08-2007 16:58]


  • .oisyn
  • Registratie: September 2000
  • Laatst online: 10:46

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

Nou zie ik geen toString() en/of assignment, maar volgens komt dat meer omdat dat gewoon weggelaten is in de quote. De issue is volgens mij wel dat er geen constructor bestaat voor char. Wel voor int, maar een char is toch niet impliciet te converteren naar int in Java, of wel?

[Voor 11% gewijzigd door .oisyn op 14-08-2007 17:05]

You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shut down. Kif, show them the medal I won.


  • JKVA
  • Registratie: Januari 2004
  • Niet online

JKVA

Design-by-buzzword fanatic

Anoniem: 178962 schreef op dinsdag 14 augustus 2007 @ 16:57:
[...]

Oei oei, die is sneaky zeg ;)

offtopic:
Java ook altijd :'(
Lol, ik had hem door. :+

Maar serieus, ik had hem al weleens gezien bij Java Puzzlers. Lekkere instinker.

Mark, ik neem aan dat dat statement gewoon ergens in real life code stond, tussen een stel ifs en zo? Dan kijk je er zo overheen.

Fat Pizza's pizza, they are big and they are cheezy


  • JKVA
  • Registratie: Januari 2004
  • Niet online

JKVA

Design-by-buzzword fanatic

.oisyn schreef op dinsdag 14 augustus 2007 @ 17:04:
Nou zie ik geen toString() en/of assignment, maar volgens komt dat meer omdat dat gewoon weggelaten is in de quote. De issue is volgens mij wel dat er geen constructor bestaat voor char. Wel voor int, maar een char is toch niet impliciet te converteren naar int in Java, of wel?
Wel dus. Jammergenoeg in zulke gevallen. :P

Wat het overigens lulliger maakt, is dat append(char) wel bestaat. |:(

[Voor 7% gewijzigd door JKVA op 14-08-2007 17:07]

Fat Pizza's pizza, they are big and they are cheezy


Anoniem: 178962

.oisyn schreef op dinsdag 14 augustus 2007 @ 17:04:
Nou zie ik geen toString() en/of assignment, maar volgens komt dat meer omdat dat gewoon weggelaten is in de quote. De issue is volgens mij wel dat er geen constructor bestaat voor char. Wel voor int, maar een char is toch niet impliciet te converteren naar int in Java, of wel?
Volgens mij wordt in dit geval inderdaad de char impliciet naar een int omgezet, al zal de compiler wellicht wel een waarschuwing geven.

Anoniem: 49627

Anoniem: 178962 schreef op dinsdag 14 augustus 2007 @ 17:06:
Volgens mij wordt in dit geval inderdaad de char impliciet naar een int omgezet, al zal de compiler wellicht wel een waarschuwing geven.
De compiler is zo lief om helemaal niets te zeggen, die vertrouwt, om compleet ongegronde redenen, op mijn onuitputtelijke wijsheid.

@JVKA
Ik had dit fragment echt vlak daarvoor geschreven en viel gelukkig vrijwel direct op.
edit: ik snap nu wat je met 'reallife code' bedoeld. Ja het stond wat meer verspreid door de code :) Dit is uiteraard even het versimpelde voorbeeld.

[Voor 13% gewijzigd door Anoniem: 49627 op 14-08-2007 20:34]


  • dingstje
  • Registratie: Augustus 2002
  • Laatst online: 17-05 22:52
Alex) schreef op zaterdag 21 juli 2007 @ 16:12:
Ik gisteren nog...
JavaScript:
1
...this.getElementsByTagName('img')[0]...


Het ging over een <a> met daarin een <img> die dynamisch was aangemaakt (via JS, userscripts)... iets zegt me dat gewoon "this.firstChild" ook had volstaan... (dit was btw in een onclick-eventhandler)
Ik zou toch ook een dergelijke constructie gebruikt hebben ipv firstChild, om de simpele reden dat als ik over 2 jaar die code aanpas ik niet meer weet dat er ergens een methode is die verwacht dat de eerste child een img is. Je zou wel kunnen argumenteren 'documenteer het dan', maar uiteindelijk stop je een nieuwe requirement in je systeem dat de eerste child binnen je anker een image moet zijn, wat imho niet netjes is.

If you can't beat them, try harder


  • JKVA
  • Registratie: Januari 2004
  • Niet online

JKVA

Design-by-buzzword fanatic

Anoniem: 49627 schreef op dinsdag 14 augustus 2007 @ 20:31:
[...]
De compiler is zo lief om helemaal niets te zeggen, die vertrouwt, om compleet ongegronde redenen, op mijn onuitputtelijke wijsheid.

@JVKA
Ik had dit fragment echt vlak daarvoor geschreven en viel gelukkig vrijwel direct op.
edit: ik snap nu wat je met 'reallife code' bedoeld. Ja het stond wat meer verspreid door de code :) Dit is uiteraard even het versimpelde voorbeeld.
offtopic:
Ik weet niet of het een bestaande term is. Ik ben bang van niet. :P Maar goed, de boodschap kwam over.

Fat Pizza's pizza, they are big and they are cheezy


  • .oisyn
  • Registratie: September 2000
  • Laatst online: 10:46

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

dingstje schreef op dinsdag 14 augustus 2007 @ 20:59:
[...]

Ik zou toch ook een dergelijke constructie gebruikt hebben ipv firstChild, om de simpele reden dat als ik over 2 jaar die code aanpas ik niet meer weet dat er ergens een methode is die verwacht dat de eerste child een img is. Je zou wel kunnen argumenteren 'documenteer het dan', maar uiteindelijk stop je een nieuwe requirement in je systeem dat de eerste child binnen je anker een image moet zijn, wat imho niet netjes is.
Dat is met de code die daar staat niet veel anders. Het enige verschil is dat het de eerste IMG tag moet zijn ipv gewoon de eerste tag. Geef dat ding dan gewoon een naam :)

You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shut down. Kif, show them the medal I won.


  • dingstje
  • Registratie: Augustus 2002
  • Laatst online: 17-05 22:52
.oisyn schreef op dinsdag 14 augustus 2007 @ 21:48:
[...]

Dat is met de code die daar staat niet veel anders. Het enige verschil is dat het de eerste IMG tag moet zijn ipv gewoon de eerste tag. Geef dat ding dan gewoon een naam :)
_/-\o_ Ik had me eventjes laten meeslepen waardoor ik het globale plaatje niet meer zag

If you can't beat them, try harder


Anoniem: 114584

Ik weet niet of iets soortgelijks al langs gekomen is, maar dit kwam ik zojuist tegen:

PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
switch(true) {
case ($x == 1 || $x == 2 || $x == 3):
    ...
    break;
case ($x == 4 || $x == 5):
    ...
    break;
case ($x == 6 || $x == 7 || $x == 8):
    ...
    break;
default:
    ...
}


Hier heeft iemand toch echt iets niet helemaal begrepen ...

Anoniem: 178962

_/-\o_

Al kan zo'n dergelijke constructie wel handig zijn als de cases iets complexer zijn, vooral de default optie is dan erg handig (itt veel if's en elses).

[Voor 92% gewijzigd door Anoniem: 178962 op 16-08-2007 14:24]


Anoniem: 37526

Anoniem: 178962 schreef op donderdag 16 augustus 2007 @ 14:24:
_/-\o_

Al kan zo'n dergelijke constructie wel handig zijn als de cases iets complexer zijn, vooral de default optie is dan erg handig (itt veel if's en elses).
Dat zeker. Al is dit wel een grappige, waarbij de X prima in de switch-parameter kan. :P

Anoniem: 42901

Kom ik net dit tegen...

C++:
1
2
3
4
5
6
if (x)
    if (y)
        if (z)
        {
            // Uiteindelijke code
        }


:X

Anoniem: 178962

Zonder een rijtje met else statements is die niet heel nuttig inderdaad.

Anoniem: 42901

Anoniem: 178962 schreef op donderdag 16 augustus 2007 @ 16:38:
Zonder een rijtje met else statements is die niet heel nuttig inderdaad.
Dat was er inderdaad niet(en dat stond er eerder ook niet: tis niet weggehaald om vervolgens niet te worden gerefactored).

  • JMfx
  • Registratie: April 2007
  • Laatst online: 28-05 22:10
C#:
1
2
3
4
5
6
7
8
9
            try
            {
                percentWeek.Add(((iplusplus - icurrent) / icurrent) * 100);
            }
            catch (Exception)
            {
                //Division by zero.
                percentWeek.Add(0);
            }


Ik ging er vanuit dat de arrayList wel een DivisionByZero exception geeft als icurrent 0 is. Maar de arraylist voegt in dat geval 'infinity' toe.

  • BasieP
  • Registratie: Oktober 2000
  • Laatst online: 02-08-2021
JMfx schreef op maandag 27 augustus 2007 @ 21:34:
C#:
1
2
3
4
5
6
7
8
9
            try
            {
                percentWeek.Add(((iplusplus - icurrent) / icurrent) * 100);
            }
            catch (Exception)
            {
                //Division by zero.
                percentWeek.Add(0);
            }


Ik ging er vanuit dat de arrayList wel een DivisionByZero exception geeft als icurrent 0 is. Maar de arraylist voegt in dat geval 'infinity' toe.
sowieso vind ik een try catch een rare keus voor het opvangen van dit soort 'fouten'
zoiets is meer mijn style:

C#:
1
percentWeek.add(icurrent>0?(iplusplus - icurrent) / icurrent * 100:0);

(ow en je hebt nutteloze haakjes in je code ;) )

[Voor 3% gewijzigd door BasieP op 27-08-2007 21:39]

This message was sent on 100% recyclable electrons.


  • Not Pingu
  • Registratie: November 2001
  • Laatst online: 19-05 13:59

Not Pingu

Dumbass ex machina

JMfx schreef op maandag 27 augustus 2007 @ 21:34:
C#:
1
2
3
4
5
6
7
8
9
            try
            {
                percentWeek.Add(((iplusplus - icurrent) / icurrent) * 100);
            }
            catch (Exception)
            {
                //Division by zero.
                percentWeek.Add(0);
            }


Ik ging er vanuit dat de arrayList wel een DivisionByZero exception geeft als icurrent 0 is. Maar de arraylist voegt in dat geval 'infinity' toe.
Nee, vreemd genoeg geven rekenoperaties op wederzijdse floats in C# geen exception als die resulteren in een NaN of Infinity waarde. Ben het in mijn 3D renderer vaak tegengekomen bij matrixtransformaties.

Certified smart block developer op de agile darkchain stack. PM voor info.


  • riezebosch
  • Registratie: Oktober 2001
  • Laatst online: 22-03 19:52
Not Pingu schreef op maandag 27 augustus 2007 @ 21:50:
[...]


Nee, vreemd genoeg geven rekenoperaties op wederzijdse floats in C# geen exception als die resulteren in een NaN of Infinity waarde. Ben het in mijn 3D renderer vaak tegengekomen bij matrixtransformaties.
Wel geinig detail is dat de Math functies er ook prima mee overweg kunnen. Als je een oneindig getal in Math.Atan stopt (positief of negatief) komt er gewoon 90 of -90 graden uit (in radialen dan). Leuke is dat je met rondjes draaien dan ook gewoon door kan rekenen met overstaande gedeeld door aanliggende, ook op het moment dat je aanliggende 0 wordt.

Canon EOS 400D + 18-55mm F3.5-5.6 + 50mm F1.8 II + 24-105 F4L + 430EX Speedlite + Crumpler Pretty Boy Back Pack


Anoniem: 14829

BasieP schreef op maandag 27 augustus 2007 @ 21:38:
sowieso vind ik een try catch een rare keus voor het opvangen van dit soort 'fouten'
zoiets is meer mijn style:

C#:
1
percentWeek.add(icurrent>0?(iplusplus - icurrent) / icurrent * 100:0);

(ow en je hebt nutteloze haakjes in je code ;) )
"conditie ? true : false" probeer ik zoveel mogelijk te mijden. Een normale if/else wordt door de compiler net zo efficient gecompileerd, en is na een half jaar een stuk beter leesbaar voor m'n collega's en ook voor mijzelf.
Idem voor die 'nutteloze haakjes'. Niet iedereen heeft MVDWOA altijd direct paraat, en dan zijn wat extra haakjes een stuk verduidelijkender en voor de compiler maakt 't geen barst uit.

Anoniem: 178962

Inderdaad, die haakjes zijn helemaal niet zo nutteloos, ze maken de code duidelijker leesbaar en helpen om fouten te voorkomen (hij zal immers altijd zich aan de haakjes houden, ook als je zelf een foutje maakt in de juiste volgorde, dan is het gedrag nog zoals je verwacht).

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 10:46

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

JMfx schreef op maandag 27 augustus 2007 @ 21:34:
C#:
1
2
3
4
5
6
7
8
9
            try
            {
                percentWeek.Add(((iplusplus - icurrent) / icurrent) * 100);
            }
            catch (Exception)
            {
                //Division by zero.
                percentWeek.Add(0);
            }


Ik ging er vanuit dat de arrayList wel een DivisionByZero exception geeft als icurrent 0 is. Maar de arraylist voegt in dat geval 'infinity' toe.
Even for the record, je berekening heeft niets met een ArrayList te maken. Dat je de berekende waarde in de lijst wilt stoppen doet er niet toe - je berekent éérst de waarde, en daarna stop je 'm pas in de lijst. De lijst heeft geen controle over de berekening, en zal dus zelf ook geen DivisionByZero exception gooien (een ArrayList hoeft immers niets te delen).

You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shut down. Kif, show them the medal I won.


  • PrisonerOfPain
  • Registratie: Januari 2003
  • Laatst online: 25-05 16:52
Anoniem: 14829 schreef op maandag 27 augustus 2007 @ 23:41:
Niet iedereen heeft MVDWOA altijd direct paraat, en dan zijn wat extra haakjes een stuk verduidelijkender en voor de compiler maakt 't geen barst uit.
Dus ik mag van een andere programmeur niet verwachtten dat 'ie de grammatica regels van z'n eigen programmeertaal onder de knie heeft? Net als dat ik niet mag verwachtten dat een programmeur basale syntax constructies onder de knie heeft zoals de ?: operator?
Anoniem: 178962 schreef op maandag 27 augustus 2007 @ 23:46:
Inderdaad, die haakjes zijn helemaal niet zo nutteloos, ze maken de code duidelijker leesbaar en helpen om fouten te voorkomen
Als ik haakjes zie verwacht ik een afwijkende situatie, als dat niet het geval is vind ik ze maar on overzichtelijk en maken ze het juist onduidelijker.

  • Niemand_Anders
  • Registratie: Juli 2006
  • Laatst online: 12-06-2021

Niemand_Anders

Dat was ik niet..

Not Pingu schreef op maandag 27 augustus 2007 @ 21:50:
[...]


Nee, vreemd genoeg geven rekenoperaties op wederzijdse floats in C# geen exception als die resulteren in een NaN of Infinity waarde. Ben het in mijn 3D renderer vaak tegengekomen bij matrixtransformaties.
JMfx schreef op maandag 27 augustus 2007 @ 21:34:
C#:
1
2
3
4
5
6
7
8
9
            try
            {
                percentWeek.Add(((iplusplus - icurrent) / icurrent) * 100);
            }
            catch (Exception)
            {
                //Division by zero.
                percentWeek.Add(0);
            }


Ik ging er vanuit dat de arrayList wel een DivisionByZero exception geeft als icurrent 0 is. Maar de arraylist voegt in dat geval 'infinity' toe.
Heeft niemand jouw ooit verteld dat je altijd je variabelen moet controleren voordat je ze gebruikt? Verder behoort een exception een onverwachte situatie te zijn. Een variabele met de waarde 0 is zeker geen exception.

En dan hebben we het nog nieteens over de performance.
C#:
1
2
3
4
if (icurrent == 0)
    //add 0
else
    //add calculated value

Is een stuk sneller dan het afvangen van een exception. Je moet als programmeur altijd zoveel mogelijk exceptions voorkomen. Kijk ook eens na het geheugen gebruik van je applicatie wanneer je een exception optreed. Afhankelijk van je stacktrace pakt je programma eenvoudig 'ineens' 5mb extra. Op een desktop computer zal dat niet snel een probleem zijn (tenzij de gebruiker al flink aan het swappen is), maar op een server is dit dodelijk. Want daar heb je niet 1 bezoeker, maar vak tientallen en bij drukken sites soms wel duizenden requests per minuut op 1 machine.

Als laatste puntje wil je ik nog even op de naming guidelines van Microsoft wijzen.

If it isn't broken, fix it until it is..


  • gorgi_19
  • Registratie: Mei 2002
  • Laatst online: 10:30

gorgi_19

Kruimeltjes zijn weer op :9

JMfx schreef op maandag 27 augustus 2007 @ 21:34:
C#:
1
2
3
4
5
6
7
8
9
            try
            {
                percentWeek.Add(((iplusplus - icurrent) / icurrent) * 100);
            }
            catch (Exception)
            {
                //Division by zero.
                percentWeek.Add(0);
            }


Ik ging er vanuit dat de arrayList wel een DivisionByZero exception geeft als icurrent 0 is. Maar de arraylist voegt in dat geval 'infinity' toe.
Als je een DivisionByZero wilt krijgen, moet je niet met doubles / floats gaan werken, maar met decimals.

Digitaal onderwijsmateriaal, leermateriaal voor hbo


  • Woy
  • Registratie: April 2000
  • Niet online

Woy

Moderator Devschuur®
gorgi_19 schreef op dinsdag 28 augustus 2007 @ 09:03:
[...]

Als je een DivisionByZero wilt krijgen, moet je niet met doubles / floats gaan werken, maar met decimals.
Je moet zowiezo geen DivisionByZero willen krijgen ;)

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


Anoniem: 43565

rwb schreef op dinsdag 28 augustus 2007 @ 09:13:
[...]

Je moet zowiezo geen DivisionByZero willen krijgen ;)
In dat geval is het toch een Exception i.p.v. een if-else :)
De vraag is dan of je het gewoon op nul wilt zetten ipv paniek wilt schoppen, schermpjes wilt oppoppen en logs wilt vol schrijven.

[Voor 21% gewijzigd door Anoniem: 43565 op 28-08-2007 09:29]


  • PolarBear
  • Registratie: Februari 2001
  • Niet online
JMfx schreef op maandag 27 augustus 2007 @ 21:34:
C#:
1
2
3
4
5
6
7
8
9
            try
            {
                percentWeek.Add(((iplusplus - icurrent) / icurrent) * 100);
            }
            catch (Exception)
            {
                //Division by zero.
                percentWeek.Add(0);
            }


Ik ging er vanuit dat de arrayList wel een DivisionByZero exception geeft als icurrent 0 is. Maar de arraylist voegt in dat geval 'infinity' toe.
\

Als je specifiek de DivisionByZero exception wil handelen kan je overigens ook dit doen (even afgezien van het feit of dit met exceptions afhandelen het netst is:
Visual Basic .NET:
1
2
3
4
5
6
7
            Try
                'Code
            Catch zeroEx As DivideByZeroException
                'Divide by zero afhandelen
            Catch ex As Exception
                'overige fouten afhandelen
            End Try
Niemand_Anders schreef op dinsdag 28 augustus 2007 @ 08:48:
Als laatste puntje wil je ik nog even op de naming guidelines van Microsoft wijzen.
Als je ergens op wijst mag je dat wel iets uitgebreider doen. Linkje, waar gaat het mis etc. Dan kunnen we er nog wat van leren cq er over discusseren.

  • Voutloos
  • Registratie: Januari 2002
  • Niet online
'iplusplus' is een slechte variabelenaam, daar heb je niet eens een coding style doc voor nodig. :>
Je zou denken op basis van die naam dat het altijd 1 meer is dan icurrent (of i), maar waarom dan niet gewoon 1 (of 100, heb je meteen een percentage :Y) ) neer zetten als noemer in dat sommetje? Als het iets anders is (waarschijnlijk), geef het dan een betere naam, bijvoorbeeld i_next, next_value of next_element of wat het ook mag voorstellen.

{signature}


  • JMfx
  • Registratie: April 2007
  • Laatst online: 28-05 22:10
Wat betreft het gebruik van exceptions in plaats van checks op de waarde 0, misschien zit er wel wat in. Ik denk dat het niet zoveel uitmaakt welke manier ik gebruik voor mijn applicatie. Het is puur een desktop applicatie (geen server toepassing).

De haakjes zijn natuurlijk ter verduidelijking, daar lijkt mij niet zoveel mis mee. De ?: operators vind ik persoonlijk erg onduidelijk, veel onoverzichtelijker dan if / else. Ik zou die niet gebruiken. Wat betreft de naamgeving, de code loopt door een arraylist. Zie hieronder.

C#:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
            for (int i = 0; i < balanceWeek.Count - 1; i++)
            {
                icurrent = Convert.ToDouble(balanceWeek[i]);
                iplusplus = Convert.ToDouble(balanceWeek[i + 1]);

                if (icurrent != 0)
                {
                    percentWeek.Add(((iplusplus - icurrent) / icurrent) * 100);
                }
                else
                {
                    //Prevent infinity being added to the arraylist.
                    percentWeek.Add(0);
                }
            }

  • Voutloos
  • Registratie: Januari 2002
  • Niet online
Het staat nu dicht bij elkaar, dus je zoekt het toevallig makkelijk op, maar iets als current_week_balance en next_week_balance is imo toch echt veel beter.

{signature}


  • PrisonerOfPain
  • Registratie: Januari 2003
  • Laatst online: 25-05 16:52
Niemand_Anders schreef op dinsdag 28 augustus 2007 @ 08:48:
Is een stuk sneller dan het afvangen van een exception. Je moet als programmeur altijd zoveel mogelijk exceptions voorkomen. Kijk ook eens na het geheugen gebruik van je applicatie wanneer je een exception optreed. Afhankelijk van je stacktrace pakt je programma eenvoudig 'ineens' 5mb extra.
Zeker bij een desktop applicatie maakt het geheugengebruik mij absoluut niet uit, dan gebruik ik gewoon wat voor mij het meest makkelijke of duidelijke is. (Dat exceptions in dit geval misschien niet nodig zijn even buiten beschouwing gelaten). Door te kijken naar de implementatie van bepaalde features overtreed je trouwens ook nog een basis principe in het object georiënteerd denken namelijk de scheiding van interface (de taal) en implementatie (de compiler).
JMfx schreef op dinsdag 28 augustus 2007 @ 11:30:De ?: operators vind ik persoonlijk erg onduidelijk, veel onoverzichtelijker dan if / else.
Waarschijnlijk omdat je (en anderen) alles op een regel probeert te proppen, wat compleet overbodig is. Meestal schrijf ik het daarom ook zo op:

C#:
1
2
3
4
5
percentWeek.Add(
    icurrent != 0
        ? (iplusplus - icurrent) / icurrent * 100
        : 0
);

  • JMfx
  • Registratie: April 2007
  • Laatst online: 28-05 22:10
PrisonerOfPain schreef op dinsdag 28 augustus 2007 @ 11:59:

[...]


Waarschijnlijk omdat je (en anderen) alles op een regel probeert te proppen, wat compleet overbodig is. Meestal schrijf ik het daarom ook zo op:

C#:
1
2
3
4
5
percentWeek.Add(
    icurrent != 0
        ? (iplusplus - icurrent) / icurrent * 100
        : 0
);
Maar waarom zou je deze manier van schrijven gebruiken? Je hebt nu meer coderegels dan het if / else equivalent (afgezien van wat haakjes). En de if / else is veel overzichtelijker.

  • JKVA
  • Registratie: Januari 2004
  • Niet online

JKVA

Design-by-buzzword fanatic

JMfx schreef op dinsdag 28 augustus 2007 @ 13:29:
[...]


Maar waarom zou je deze manier van schrijven gebruiken? Je hebt nu meer coderegels dan het if / else equivalent (afgezien van wat haakjes). En de if / else is veel overzichtelijker.
Dit kan veel overzichtelijker zijn dan if else als je bijvoorbeeld variabelen wilt initialiseren o.b.v. bepaalde criteria. Je moet bij een if else je variabele vooraf (op null) initialiseren, met de ternary operator niet. Dan kan alles inline.
Java:
1
2
3
String test = (bladiebla != null) bladiebla.getStringOfzo()
    ? bladiebla.getStringOfzo()
    : "leeg";

Fat Pizza's pizza, they are big and they are cheezy


Anoniem: 178962

PrisonerOfPain schreef op dinsdag 28 augustus 2007 @ 07:56:
[...]
Als ik haakjes zie verwacht ik een afwijkende situatie, als dat niet het geval is vind ik ze maar on overzichtelijk en maken ze het juist onduidelijker.
Tjah, dat kun je wel verwachten, maar dan nog moet je het met haakjes heel gemakkelijk kunnen lezen en weet je direct zonder ook maar na te denken wat er staat.

Hoe meer je moet nadenken bij het lezen van code, des te groter dat er fouten worden gemaakt, mensen maken namelijk nogal eens fouten bij het nadenken ;)

Opmaak van formules als in nutteloze haakjes, spaties, enters, zelfs commentaar in de formule moet gewoon geen enkel probleem zijn en kun je alleen maar aanmoedigen als in ieder geval een poging de code beter leesbaar te maken.

Het is aan de programmeur natuurlijk om te bepalen wanneer dat het als overbodig overkomt en wanneer het nuttig is, als je daar niet goed in bent dan is het beste om gewoon altijd de haakjes te plaatsen dan ben je in ieder geval nog consistent.

Voor de compiler etc maakt het allemaal geen hol uit, dus wat dat betreft is er weinig reden het niet te doen (buiten jouw persoonlijke smaak, maar gezien je andere voorbeelden is die nogal anders als die van mij).

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 10:46

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

Anoniem: 178962 schreef op dinsdag 28 augustus 2007 @ 13:44:
[...]

Tjah, dat kun je wel verwachten, maar dan nog moet je het met haakjes heel gemakkelijk kunnen lezen en weet je direct zonder ook maar na te denken wat er staat.
Behalve het feit dat teveel haakjes dingen juist helemaal niet duidelijker maken, omdat je door de haakjes de grammatica niet meer kunt zien. Dat haakjes altijd verduidelijken is helemaal niet zonder meer waar.

You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shut down. Kif, show them the medal I won.


Anoniem: 178962

.oisyn schreef op dinsdag 28 augustus 2007 @ 13:46:
[...]

Behalve het feit dat teveel haakjes dingen juist helemaal niet duidelijker maken, omdat je door de haakjes de grammatica niet meer kunt zien. Dat haakjes altijd verduidelijken is helemaal niet zonder meer waar.
Anoniem: 178962 schreef op dinsdag 28 augustus 2007 @ 13:44:
[...]
Het is aan de programmeur natuurlijk om te bepalen wanneer dat het als overbodig overkomt en wanneer het nuttig is, als je daar niet goed in bent dan is het beste om gewoon altijd de haakjes te plaatsen dan ben je in ieder geval nog consistent.
Dat zeg ik Gamma..

  • Erkens
  • Registratie: December 2001
  • Niet online

Erkens

Fotograaf / Backend developer

Niemand_Anders schreef op dinsdag 28 augustus 2007 @ 08:48:
Een variabele met de waarde 0 is zeker geen exception.
Afhankelijk van de situatie kan dat wel degelijk een exception zijn. Bijvoorbeeld als er in principe nooit de mogelijkheid is dat die variabele op 0 kan staan.
.oisyn schreef op dinsdag 28 augustus 2007 @ 13:46:
[...]

Behalve het feit dat teveel haakjes dingen juist helemaal niet duidelijker maken, omdat je door de haakjes de grammatica niet meer kunt zien. Dat haakjes altijd verduidelijken is helemaal niet zonder meer waar.
true, hoewel ik de voorkeur geef om vooral bij de ternary operator er een paar haakjes extra bij te doen. Juist om enige onduidelijkheid te voorkomen ook als dat niet echt nodig.

  • Rowdy.nl
  • Registratie: Juni 2003
  • Laatst online: 24-05 10:47

Rowdy.nl

Koekje d'r bij?

Sommige van mijn collega's (waaronder ik) vinden de ?: constructie heel handig en gebruiken 'm veelvuldig. Sommige andere collega's rennen d'r onderhand gillend van weg. Tis imho een kwestie van persoonlijke voorkeur, 't een is niet (altijd) beter dan 't ander...

Maar is dat niet een andere discussie? ;)

Rowdy.nl - X++ by day. C# by night. I drink coffee in the morning and beer in the evening.


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 10:45

Janoz

Moderator Devschuur®

!litemod

Ik gebruik de ternary operator eigenlijk alleen bij het toekennen of bij het afdrukken. Vaak is het om een default waarde te kunnen gebruiken. Zeker wanneer je veel gegevens afdrukt (of append aan een later te gebruiken string) vind ik een if juist veel lelijker.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • PrisonerOfPain
  • Registratie: Januari 2003
  • Laatst online: 25-05 16:52
JMfx schreef op dinsdag 28 augustus 2007 @ 13:29:
[...]
Maar waarom zou je deze manier van schrijven gebruiken? Je hebt nu meer coderegels dan het if / else equivalent (afgezien van wat haakjes). En de if / else is veel overzichtelijker.
Het aantal regels is niet relevant, noch het aantal tekens. Wat voor mij belangrijker is is dat je op deze manier minder dubbele code hebt (twee keer de percentWeek.Add aanroep).
Anoniem: 178962 schreef op dinsdag 28 augustus 2007 @ 13:44:
[...]
Tjah, dat kun je wel verwachten, maar dan nog moet je het met haakjes heel gemakkelijk kunnen lezen en weet je direct zonder ook maar na te denken wat er staat.
Zodra je een tijd ervaring hebt met een bepaalde programmeertaal mag je er toch vanuit gaan dat je de voorrangsregels van de betreffende taal kent? Zeker aangezien die regels meestal duidelijk in de manual gespecificeerd zijn. Een van de weinige keren dat ik haakjes prefereer is in PHP als && en and door elkaar gebruikt worden (die hebben namelijk andere voorrangsregels maar betekenen hetzelfde), maar goed dat word sowieso amper gebruikt. Als ik veel haakjes wou zien had ik wel voor een op s-expressions gebaseerde programmeertaal gekozen.

Anoniem: 178962

Je schrijft code dan ook niet zodat je het zelf goed kunt lezen, je schrijft code zodat een ander het goed kan lezen ;) (En daarbij hopelijk ook zo dat je het zelf kunt lezen :+)

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 10:46

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

Janoz schreef op dinsdag 28 augustus 2007 @ 14:06:
Ik gebruik de ternary operator eigenlijk alleen bij het toekennen of bij het afdrukken. Vaak is het om een default waarde te kunnen gebruiken. Zeker wanneer je veel gegevens afdrukt (of append aan een later te gebruiken string) vind ik een if juist veel lelijker.
En soms moet het:
C++:
1
2
3
4
5
6
7
8
class MyClass
{
    MyOtherClass myVar;

    MyClass(bool myParam) : myVar(myParam ? 1 : 2)
    {
    }
};

Wat tevens ook een van de belangrijkste redenen is waarom het ding überhaupt bestaat.

[Voor 7% gewijzigd door .oisyn op 28-08-2007 14:15]

You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shut down. Kif, show them the medal I won.


  • blastboy
  • Registratie: December 2001
  • Laatst online: 16-01-2015
k

[Voor 100% gewijzigd door blastboy op 28-08-2007 14:17]


  • blastboy
  • Registratie: December 2001
  • Laatst online: 16-01-2015
Anoniem: 49627 schreef op dinsdag 14 augustus 2007 @ 14:40:
Echt een 'slecht programmeervoorbeeld' is het niet maar toch een 'leuk' foutje/bugje dat ik vanmorgen had gemaakt.
Java:
1
Dit werkt toch wel gewoon bij mij als ik hiervan een println doe. Ik ben wel geen ervaren java programmeur dusja misschien mag ik de .toString() wel niet doen om dat bugje te krijgen.

  • blastboy
  • Registratie: December 2001
  • Laatst online: 16-01-2015
Anoniem: 114584 schreef op donderdag 16 augustus 2007 @ 14:21:
Ik weet niet of iets soortgelijks al langs gekomen is, maar dit kwam ik zojuist tegen:

PHP:
1


Hier heeft iemand toch echt iets niet helemaal begrepen ...
De taal RPGIV waar ik in programmer kent enkel deze switch

code:
1

  • blastboy
  • Registratie: December 2001
  • Laatst online: 16-01-2015
[
Anoniem: 114584 schreef op donderdag 16 augustus 2007 @ 14:21:
Ik weet niet of iets soortgelijks al langs gekomen is, maar dit kwam ik zojuist tegen:

PHP:
1


Hier heeft iemand toch echt iets niet helemaal begrepen ...
De taal RPGIV waar ik in programmer kent enkel deze switch

Java:
1

  • --MeAngry--
  • Registratie: September 2002
  • Laatst online: 28-05 12:38

--MeAngry--

aka Qonstrukt

blastboy schreef op dinsdag 28 augustus 2007 @ 14:38:
[
[...]


De taal RPGIV waar ik in programmer kent enkel deze switch

Java:
1
2
3
4
5
Select;
   When x = 1; 
   .... 
   Other;
EndSl;
Ja maargoed, je programmeert niet in een andere taal om je aan de regels van de vorige taal te houden :P
PHP heeft nog wel niet voor niets case-fallthrough. :)

Kia e-Soul MY2020 64kWh ExecutiveLine


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 10:45

Janoz

Moderator Devschuur®

!litemod

blastboy schreef op dinsdag 28 augustus 2007 @ 14:23:
[...]


Dit werkt toch wel gewoon bij mij als ik hiervan een println doe. Ik ben wel geen ervaren java programmeur dusja misschien mag ik de .toString() wel niet doen om dat bugje te krijgen.
Dan zou ik toch nog eens even goed gaan kijken. Als ik het uitvoer is namelijk het haakje open verdwenen. Check eventueel ff javadoc

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • PrisonerOfPain
  • Registratie: Januari 2003
  • Laatst online: 25-05 16:52
Anoniem: 178962 schreef op dinsdag 28 augustus 2007 @ 14:12:
Je schrijft code dan ook niet zodat je het zelf goed kunt lezen, je schrijft code zodat een ander het goed kan lezen ;) (En daarbij hopelijk ook zo dat je het zelf kunt lezen :+)
In teamverband volg ik gewoon de opgestelde regels, in alle andere gevallen kies ik wat mij het beste ligt (of de huidige coding guideline).

Zag net nog een leuk voorbeeldje op wikipedia:
C:
1

  • Not Pingu
  • Registratie: November 2001
  • Laatst online: 19-05 13:59

Not Pingu

Dumbass ex machina

Niemand_Anders schreef op dinsdag 28 augustus 2007 @ 08:48:

Heeft niemand jouw ooit verteld dat je altijd je variabelen moet controleren voordat je ze gebruikt? Verder behoort een exception een onverwachte situatie te zijn. Een variabele met de waarde 0 is zeker geen exception.
Ligt aan de situatie. Delen door 0 kan niet en als een getal dat als deler gebruikt wordt, na berekening uitkomt op 0, lijkt me dat een redelijk exception. Het is ook een stuk makkelijker met debuggen: ipv. alleen als resultaat te zien dat je app een stuk langzamer wordt door het afhandelen van NaN/Infinity, meteen een aanwijzing hebben waar de ongeldige waarde erinsluipt.

Als je een gigantische hoop rekenwerk doet (bijv. een stel matrixtransformaties) is het niet altijd even makkelijk om te achterhalen waar het nou fout ging. Zeker at debugtime wil je dan die informatie hebben.

Certified smart block developer op de agile darkchain stack. PM voor info.


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 10:45

Janoz

Moderator Devschuur®

!litemod

Delen door 0 kan wel. Daar komt oneindig uit tenzij je 0 deelt door 0. "Delen door nul is flauwekul" is een rijmpje dat op de basisschool onderwezen wordt omdat het concept van oneindig nogal lastig uit te leggen is. Hetzelfde geldt voor de wortel uit een negatief getal ;). Zoals riezebosch eerder al aangaf kun je vaak nog wel gewoon verder rekenen met deze het resultaat van een delen door nul actie.

Zelf een waarde toe gaan kennen in een dergelijke context lijkt me eerder fout. Wanneer je een percentage uitrekend over een bepaalde periode en de periode blijkt 0 te zijn dan is bij een groei de groei inderdaad oneindig en bij een gelijk gebleven hoeveelheid (0/0) inderdaad de groei ongedefinieerd. Inf en NaN zijn de enige juiste uitkomsten uit een dergelijke berekening.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • apNia
  • Registratie: Juli 2002
  • Laatst online: 28-05 22:54

apNia

Schreeuwen en Nibbits eten!

Wellicht leuk om in de startpost te zetten: The Daily WTF (tegenwoordig 'Worse Than Failure')

http://worsethanfailure.com/

edit: en dan voornamelijk het code deel ;)

[Voor 29% gewijzigd door apNia op 28-08-2007 15:45]


  • blastboy
  • Registratie: December 2001
  • Laatst online: 16-01-2015
ik krijg deze output in de commandline: [Test]

en dit is mijn code:

Java:
1
2
3
4
5
6
7
8
9
10
11
public class ExportData
{
public static void main(String[] args)
 { 
      StringBuffer buff = new StringBuffer().append('[').append("Test").append(']');
            
      
      System.out.println(buff.toString());
 }

}

  • NetForce1
  • Registratie: November 2001
  • Laatst online: 25-05 11:17

NetForce1

(inspiratie == 0) -> true

blastboy schreef op dinsdag 28 augustus 2007 @ 15:45:
ik krijg deze output in de commandline: [Test]

en dit is mijn code:

Java:
1
...
Het probleem zat em in de constructor-aanroep, probeer dit maar eens:
Java:
1
2
3
4
5
6
public class ExportData {
public static void main(String[] args) { 
      StringBuffer buff = new StringBuffer('[').append("Test").append(']');
      System.out.println(buff.toString());
 }
}

De wereld ligt aan je voeten. Je moet alleen diep genoeg willen bukken...
"Wie geen fouten maakt maakt meestal niets!"


Anoniem: 43565

Janoz schreef op dinsdag 28 augustus 2007 @ 15:31:
Delen door 0 kan wel. Daar komt oneindig uit tenzij je 0 deelt door 0. "Delen door nul is flauwekul" is een rijmpje dat op de basisschool onderwezen wordt omdat het concept van oneindig nogal lastig uit te leggen is. Hetzelfde geldt voor de wortel uit een negatief getal ;). Zoals riezebosch eerder al aangaf kun je vaak nog wel gewoon verder rekenen met deze het resultaat van een delen door nul actie.

Zelf een waarde toe gaan kennen in een dergelijke context lijkt me eerder fout. Wanneer je een percentage uitrekend over een bepaalde periode en de periode blijkt 0 te zijn dan is bij een groei de groei inderdaad oneindig en bij een gelijk gebleven hoeveelheid (0/0) inderdaad de groei ongedefinieerd. Inf en NaN zijn de enige juiste uitkomsten uit een dergelijke berekening.
Er kan ook een exception uit komen. Hangt er van af of je ints of floats/doubles gebruikt.

Voor Java:
int/0 geeft een ArithmeticException.
float/0 geeft Infinity
0.0/0 geeft NaN
0.0/0.0 geeft NaN
float/0.0 geeft Infinity

Is certificeringsstof en er zit 'een' vorm van logica in :Y)

  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 10:45

Janoz

Moderator Devschuur®

!litemod

blastboy schreef op dinsdag 28 augustus 2007 @ 15:45:
ik krijg deze output in de commandline: [Test]

en dit is mijn code:

Java:
1
2
3
4
5
6
7
8
9
10
11
public class ExportData
{
public static void main(String[] args)
 { 
      StringBuffer buff = new StringBuffer().append('[').append("Test").append(']');
            
      
      System.out.println(buff.toString());
 }

}
Ja, maar die code is nu eenmaal niet hetzelfde als de geposte code he ;)

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 10:45

Janoz

Moderator Devschuur®

!litemod

Anoniem: 43565 schreef op dinsdag 28 augustus 2007 @ 15:56:
[...]

Er kan ook een exception uit komen. Hangt er van af of je ints of floats/doubles gebruikt.

Voor Java:
int/0 geeft een ArithmeticException.
float/0 geeft Infinity
0.0/0 geeft NaN
0.0/0.0 geeft NaN
float/0.0 geeft Infinity

Is certificeringsstof en er zit 'een' vorm van logica in :Y)
Ik weet het (/me is ook rijkelijk gecertificeerd), maar die beperking heeft vooral met het gebruikte datatype type te maken. In een int is namelijk lastig op te slaan dat het oneindig of NaN is.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • Not Pingu
  • Registratie: November 2001
  • Laatst online: 19-05 13:59

Not Pingu

Dumbass ex machina

Janoz schreef op dinsdag 28 augustus 2007 @ 15:31:
Zoals riezebosch eerder al aangaf kun je vaak nog wel gewoon verder rekenen met deze het resultaat van een delen door nul actie.
Maar in welk geval wil je dat? Ervan uitgaande dat de berekeningen die je wilt implementeren wiskundig gewoon kloppen en nuldeling ofwel per definitie wordt afgevangen of niet mogelijk hoort te zijn, is een nuldeling gewoon een onverwacht iets.

Bovendien heeft doorrekenen met die infinitywaarde geen enkele zin, want dat had waarschijnlijk een betekenisvolle real-waarde moeten zijn die nu niet meer betekenisvol is (behalve dan als aanwijzing dat er iets fout gaat in je code).

Dan kun je mensen wel uitmaken voor kleuters, maar het feit blijft dat infinity/nan in de meeste gevallen een showstopper is. Je kunt het goed functioneren van je code dan niet meer garanderen.

Certified smart block developer op de agile darkchain stack. PM voor info.


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 10:45

Janoz

Moderator Devschuur®

!litemod

Je kunt wel degelijk doorrekenen met een Inf of een NaN. Alle operatoren ondersteunen deze waarden gewoon. Een leuk voorbeeld is bijvoorbeeld degene die riezebosch aangaf. Uit atan(Inf) komt gewoon 90 (of 1/2 Pi).

Het punt is dat een berekening waar Inf uitkomt waarschijnlijk gewoon Inf uit hoort te komen. De uitkomst Inf is dus helemaal geen teken dat er iets fout gegaan is.

De enige fouten die in een computer voorkomen zijn eerder overflows en afrondfouten.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • .oisyn
  • Registratie: September 2000
  • Laatst online: 10:46

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

Janoz schreef op dinsdag 28 augustus 2007 @ 15:31:
Delen door 0 kan wel. Daar komt oneindig uit tenzij je 0 deelt door 0. "Delen door nul is flauwekul" is een rijmpje dat op de basisschool onderwezen wordt omdat het concept van oneindig nogal lastig uit te leggen is. Hetzelfde geldt voor de wortel uit een negatief getal ;)
Nou zou ik delen door 0 en de wortel van een negatief getal niet bepaald over 1 kam willen scheren. De wortel uit een negatief getal is goed-gedefinieerd en geeft een complex getal. De oneindigheid als gevolg van deling door 0 is echter niet helemaal correct. Als je het zou benaderen dan klopt het idd:
limx -> 0 (1/x) = 0.

Maar volgens wiskundige definities kun je een reëel getal niet delen door 0. Het is ongedefinieerd. Het zou alles kunnen zijn, want x*0 = 0 voor alle x. De basisschool was daadwerkelijk correct (itt de stelling over de wortel van negatieve getallen)

You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shut down. Kif, show them the medal I won.


Anoniem: 43565

Janoz schreef op dinsdag 28 augustus 2007 @ 16:17:
[...]

Ik weet het (/me is ook rijkelijk gecertificeerd), maar die beperking heeft vooral met het gebruikte datatype type te maken. In een int is namelijk lastig op te slaan dat het oneindig of NaN is.
ik ben geen wiskundige maar ik dacht dat je een Exception kreeg omdat delen door 0 gewoon niet kan en een Inf, omdat een float nooit exact nul hoeft te zijn (afrondingsfouten) en dus gelezen kan worden als oneindig klein.

Maar dan hou je inderdaad NaN over wat een betere uitkomst zou zijn en dat kun je inderdaad niet in een int opslaan.

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 10:46

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

Anoniem: 43565 schreef op dinsdag 28 augustus 2007 @ 17:04:
[...]

ik ben geen wiskundige maar ik dacht dat je een Exception kreeg omdat delen door 0 gewoon niet kan en een Inf, omdat een float nooit exact nul hoeft te zijn (afrondingsfouten) en dus gelezen kan worden als oneindig klein.
Inf staat voor infinity, niet voor infinitesimal. IEEE floats hebben geen aparte representatie voor infinitesimal. Een deling door 0 geeft gewoon infinity, tenzij de noemer ook 0 is, dan geeft het indefinite (ofwel NaN)

You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shut down. Kif, show them the medal I won.


Anoniem: 43565

.oisyn schreef op dinsdag 28 augustus 2007 @ 18:29:
[...]

Inf staat voor infinity, niet voor infinitesimal. IEEE floats hebben geen aparte representatie voor infinitesimal. Een deling door 0 geeft gewoon infinity, tenzij de noemer ook 0 is, dan geeft het indefinite (ofwel NaN)
ik bedoel dat een deling door infinitesmall infinity opleverd.

m.i. geeft 0 zelf namelijk in alle gevallen alles danwel niets als uitkomst en zijn computers gewoon gek

[Voor 12% gewijzigd door Anoniem: 43565 op 28-08-2007 18:39]


  • .oisyn
  • Registratie: September 2000
  • Laatst online: 10:46

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

Oh ok, maar dat kan dus niet, want er is geen aparte representatie voor infinitesimal (let op de spelling ;)). Maar uit berekeningen die voorbij FLOAT_MAX gaan komt meestal wel infinity ja.

You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shut down. Kif, show them the medal I won.


  • Free rider
  • Registratie: November 2006
  • Laatst online: 09-05 01:08
.oisyn schreef op dinsdag 28 augustus 2007 @ 18:29:
Een deling door 0 geeft gewoon infinity, tenzij de noemer ook 0 is, dan geeft het indefinite (ofwel NaN)
"tenzij de noemer ook 0 is" Ik neem aan dat je de teller bedoelt.
Maar dat is niet juist. Stel dat de teller positief is. Als de noemer (0) positief zou zijn, is het resultaat inderdaad Inf. Maar als de noemer negatief zou zijn, is het resultaat -Inf. Maar geen van beide stellingen zijn waar, immers 0 is niet kleiner en ook niet groter dan 0.

  • riezebosch
  • Registratie: Oktober 2001
  • Laatst online: 22-03 19:52
.oisyn schreef op dinsdag 28 augustus 2007 @ 16:35:
[...]

Nou zou ik delen door 0 en de wortel van een negatief getal niet bepaald over 1 kam willen scheren. De wortel uit een negatief getal is goed-gedefinieerd en geeft een complex getal. De oneindigheid als gevolg van deling door 0 is echter niet helemaal correct. Als je het zou benaderen dan klopt het idd:
limx -> 0 (1/x) = 0.

Maar volgens wiskundige definities kun je een reëel getal niet delen door 0. Het is ongedefinieerd. Het zou alles kunnen zijn, want x*0 = 0 voor alle x. De basisschool was daadwerkelijk correct (itt de stelling over de wortel van negatieve getallen)
Waarom is 0/0 eigenlijk geen 1, zoals geldt voor elke andere x?

Canon EOS 400D + 18-55mm F3.5-5.6 + 50mm F1.8 II + 24-105 F4L + 430EX Speedlite + Crumpler Pretty Boy Back Pack


  • .oisyn
  • Registratie: September 2000
  • Laatst online: 10:46

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

Ik bedoelde idd teller, maar voor de rest begrijp ik je verhaal niet helemaal. Toen ik het had over "infinity" deed ik geen uitspraak of dat positief dan wel negatief zou zijn. Als je deelt door 0 (zij het +0 of -0) en de teller is niet 0, is het +inf als teller en noemer hetzelfde teken hebben, en -inf anderzijds.

Even voor de goede orde, hier had ik het natuurlijk over de IEEE floating point regels, dat stuk heb je echter uit de quote gehaald. Niet dat het correcte wiskunde is (waarvan ik al eerder heb aangegeven dat het dat niet is)

You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shut down. Kif, show them the medal I won.


  • .oisyn
  • Registratie: September 2000
  • Laatst online: 10:46

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

riezebosch schreef op dinsdag 28 augustus 2007 @ 23:23:
[...]

Waarom is 0/0 eigenlijk geen 1, zoals geldt voor elke andere x?
Je bedoelt als in x/x? Waarom is het dan geen 0, zoals voor elke andere x in 0/x?

You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shut down. Kif, show them the medal I won.


  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 23-07-2021
Ach tja, nog even over de haakjes bij berekeningen. Worst case praktijkvoorbeeld wat ik ooit eens ben tegengekomen was gewoon 2 regels met gezamelijk 460 tekens, enkeltekenige ( $a, $i, $b etc ) variabelen en zonder haakjes 1 formule uitgeschreven. Heeft me toen ongeveer een uur gekost om de formule compleet te begrijpen.

Na herschrijven was het 10 regels code met behoorlijke variabelen en haakjes en goede enters en indentin ( plus 2 regels comments ). Meeste collega´s zagen nu in 1 oogopslag wat het deed.

En na navragen bij programmeur was het een optimalisatie slag die welgeteld ,08 sec afhaalde van een functie die gewoon 1 sec duurde. Toen collega maar even uitgelegd dat dit een compleet overbodige optimalisatie was die meer koste dan het opleverde ( collega´s negeerden deze regels gewoon omdat het te veel tijd koste om te gaan uitzoeken wat het deed ).

Betreffende collega had trouwens wel meer van dit soort kuntstukjes in zijn code gebouwd, regels kan ik maar 255 tekens lang maken,ach tja als je een beetje gaat concatenaten kan ik meerdere regels van 255 tekens maken die gewoon 1 statement zijn ( hoogtepunt 21 regels over 1 statement doen en dan raar opkijken als je collega´s jouw code weigeren te debuggen . Alleen maar omdat de debugger alleen maar per statement/regel keek dus als hier iets fout in ging dan kon iemand even 21 regels samengeperste troepcode op het oog gaan zitten debuggen of herschrijven.... )
Maar ja, gelukkig is het al enkele jaren een ex-collega...

  • kenneth
  • Registratie: September 2001
  • Niet online

kenneth

achter de duinen

Zie ik in onze code ergens ranzige datefuncties (met variabelenamen als i, j, k, l, m, n :')) ... ik vroeg me af waar het vandaan kwam ... blijkt het hier te zijn http://www.codeproject.com/csharp/GregToISO.asp
Zie ook de commentaren ...

/me gaat maar eens omschrijven ... zitten bugs in :{

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.


  • PrisonerOfPain
  • Registratie: Januari 2003
  • Laatst online: 25-05 16:52
kenneth schreef op donderdag 30 augustus 2007 @ 13:04:
Zie ik in onze code ergens ranzige datefuncties (met variabelenamen als i, j, k, l, m, n :')) ... ik vroeg me af waar het vandaan kwam ... blijkt het hier te zijn http://www.codeproject.com/csharp/GregToISO.asp
Zie ook de commentaren ...

/me gaat maar eens omschrijven ... zitten bugs in :{
C#:
1
2
3
4
5
using System;
using System.Globalization;

Calendar c = new Calendar();
int weekNumberISO = c.GetWeekOfYear(someTime, CalendarWeekRule.FirstFourDayWeek, DayOfWeek.Monday);

  • kenneth
  • Registratie: September 2001
  • Niet online

kenneth

achter de duinen

Juist :)

Toen ik zag wat de code zou moeten doen, wist ik al 99% zeker dat dit gewoon in het .NET framework zit. Dat soort dingen voel je gewoon aan ... zou je denken :P

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.


  • ikke007
  • Registratie: Juni 2001
  • Laatst online: 17-05 11:05

ikke007

SQL Addict

Vandaag een geniale van mijn collega. Ik heb hier een tabel met daarin diverse xsl templates. (template_id, template). Ik vraag mijn collega welke template de actieve template is.
"template_id 0 is de actieve, want zodra deze niet meer actief is wordt hij handmatig hernoemd naar max(template_id)+1".

Oftewel: De oudste niet-actieve template is id 1, en de nieuwste niet-actieve template is 20 en 0 is de actieve. logisch! }:O

[Voor 0% gewijzigd door ikke007 op 30-08-2007 15:49. Reden: typo]

Lets remove all security labels and let the problem of stupidity solve itself


  • Dido
  • Registratie: Maart 2002
  • Laatst online: 23-05 10:12

Dido

heforshe

kenneth schreef op donderdag 30 augustus 2007 @ 14:43:
Toen ik zag wat de code zou moeten doen, wist ik al 99% zeker dat dit gewoon in het .NET framework zit. Dat soort dingen voel je gewoon aan ... zou je denken :P
Mwah, blindelings vertrouwen op correcte implementatie van wat ingewikkelder date-functions wordt je in bepaalde omgevingen keihard afgeleerd, hoor. Het is al enige tijd terug, maar ik heb ooit de ingebouwde weeknummer-functie moeten herschrijven (en dat is ook vrij onleesbare code geworden - soit, het werkt, en er is geen denkbare reden om het voor 2300 aan te passen) omdat de Australische leverancier erin geslaagd was om alleen het Amerikaanse weeknummer te implementeren (dus niet ISO) en dat nog fout te doen ook.

Wat betekent mijn avatar?


  • gorgi_19
  • Registratie: Mei 2002
  • Laatst online: 10:30

gorgi_19

Kruimeltjes zijn weer op :9

Wat heb je dan als alternatief? Alles herbenoemen? Evt. kan je nog datums er achter frotten. :)

Digitaal onderwijsmateriaal, leermateriaal voor hbo


  • kenneth
  • Registratie: September 2001
  • Niet online

kenneth

achter de duinen

Dido schreef op donderdag 30 augustus 2007 @ 16:08:
[...]

Mwah, blindelings vertrouwen op correcte implementatie van wat ingewikkelder date-functions wordt je in bepaalde omgevingen keihard afgeleerd, hoor.
Oh, zeker met datumfuncties ben ik zeer terughoudend geworden ja, maar waarom zou je een buggy (!) implementatie maken van iets wat al in 't framework zit? Als het al beter is, zeg dan waarom. Maar blijkbaar wist deze meneer gewoon niet van het bestaan af van System.Globalization.

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.


  • Dido
  • Registratie: Maart 2002
  • Laatst online: 23-05 10:12

Dido

heforshe

kenneth schreef op donderdag 30 augustus 2007 @ 16:18:
Oh, zeker met datumfuncties ben ik zeer terughoudend geworden ja, maar waarom zou je een buggy (!) implementatie maken van iets wat al in 't framework zit? Als het al beter is, zeg dan waarom. Maar blijkbaar wist deze meneer gewoon niet van het bestaan af van System.Globalization.
Een buggy implementatie is natuurlijk sowieso nooit een alternatief (hell, als je het dan doet, dan test je het toch geautomatiseerd even door voor de eerstvolgende x00 jaar?).

En als er een werkende implementatie bestaat verdient het vaak aanbeveling die te gebruiken, natuurlijk.

Wat betekent mijn avatar?

Pagina: 1 2 3 ... 11 Laatste

Dit topic is gesloten.

Let op:
Uiteraard is het in dit topic niet de bedoeling dat andere users en/of topics aangehaald worden om ze voor gek te zetten. Lachen om je eigen code, of over dingen die je "wel eens tegengekomen bent" is prima, maar hou het onderling netjes. :)


Nintendo Switch (OLED model) Apple iPhone SE (2022) LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S22 Garmin fēnix 7 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2022 Hosting door True

Tweakers maakt gebruik van cookies

Bij het bezoeken van het forum plaatst Tweakers alleen functionele en analytische cookies voor optimalisatie en analyse om de website-ervaring te verbeteren. Op het forum worden geen trackingcookies geplaatst. Voor het bekijken van video's en grafieken van derden vragen we je toestemming, we gebruiken daarvoor externe tooling die mogelijk cookies kunnen plaatsen.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Forum cookie-instellingen

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee