[alg] Slechtste programmeervoorbeelden deel 4

[kenneth]

boomstronkgegevens -> log data?

[Woy]

"Please turn on the datalogger and turn on the switch for reading log data" o.i.d. denk ik

[ Voor 9% gewijzigd door Woy op 14-07-2009 11:21 ]

[Matis]

Sebazzz schreef op dinsdag 14 juli 2009 @ 11:17:
Wat moet ik mij voorstellen bij een gegevenshouthakker? En met een bocht op een schakelaar (voor lezing van boomstronk gegevens) aansluiten?

"Please connect data jack and turn on the switch for reading log data"

_{Zet- en drukfouten voorbehouden}

[ Voor 6% gewijzigd door Matis op 14-07-2009 11:21 ]

[.oisyn]

kenneth schreef op dinsdag 14 juli 2009 @ 11:19:
boomstronkgegevens -> log data?

Ah ja die miste ik net idd. Data jack en turn on the switch kon ik dan nog wel uitvogelen. Maar fuck zeg, echt een typische Babelfish vertaling. Why even bother?

[Thooomas]

Haha Babelfish heeft inderdaad soms echt verschrikkelijke vertalingen Om zo'n vertaling ook echt te vertrouwen

[mcDavid]

Thooomas schreef op dinsdag 14 juli 2009 @ 19:59:
Haha Babelfish heeft inderdaad soms echt verschrikkelijke vertalingen Om zo'n vertaling ook echt te vertrouwen

gelukkig kan het altijd erger

[Ryur]

Woy schreef op dinsdag 14 juli 2009 @ 10:04:
[...]

Ik kwam laatst ook wel een "leuke" vertaling tegen in File-Zilla

"Bezig met host naam oplossen" , ja resolve betekent oplossen als je het letterlijk vertaald, maar in deze context klint het nogal stom.

Beetje offtopic, maar toch wel leuk.

Ik was laatst de EeePC (de oude nog, van Asus 7" met flashgeheugen i.p.v. SSD), en daar moest ik mijn netwerkprinter voor instellen. Vroeg 'Linux' wat voorn printer het was, een Linux/Unix-printer of een 'Ramen' printer. Zat even gek te kijken.

[.oisyn]

Doe mij ook zo'n ding, ik kan best wel wat nieuw geprintte ramen gebruiken. Print ie ook dubbelglas?

[Matis]

.oisyn schreef op dinsdag 14 juli 2009 @ 22:03:
Doe mij ook zo'n ding, ik kan best wel wat nieuw geprintte ramen gebruiken. Print ie ook dubbelglas?

Nee alleen Vista

[RetroTycoon]

Matis schreef op dinsdag 14 juli 2009 @ 22:06:
[...]

Nee alleen Vista

Scherpzinnig

[Standeman]

Ik kwam net een stukje code tegen van mezelf dat me een best naar gevoel gaf:

Java:

    private Task findTask(Collection<Task> tasks, int id)
    {
        for (Task task : tasks)
        {
            if (task.getId() == id)
            {
                return task;
            }
            else if (task.getSubTasks() != null)
            {
                Task subTask = findTask(task.getSubTasks(), id); // Call naar zelfde methode
                if (subTask != null)
                {
                    return subTask;
                }
            }
            break;
        }
        return null;
    }

Alhoewel het in principe wel goed zal gaan, de boom structuur is nou eenmaal niet oneindig,

[CoolGamer]

Standeman schreef op woensdag 15 juli 2009 @ 14:16:

Java:

    private Task findTask(Collection<Task> tasks, int id)
    {
        for (Task task : tasks)
        {
            [..]
            break;
        }
        return null;
    }

Een foreach gebruiken en altijd bij het eerste element breaken of returnen. Echt goed doorlopen van de boom doet hij niet. Dus met twee of meer subtasks wordt alleen de eerste vergeleken met het ID.

[ Voor 7% gewijzigd door CoolGamer op 15-07-2009 14:22 ]

[Herko_ter_Horst]

Standeman schreef op woensdag 15 juli 2009 @ 14:16:
Ik kwam net een stukje code tegen van mezelf dat me een best naar gevoel gaf:

Java:

    private Task findTask(Collection<Task> tasks, int id)
    {
        for (Task task : tasks)
        {
            if (task.getId() == id)
            {
                return task;
            }
            else if (task.getSubTasks() != null)
            {
                Task subTask = findTask(task.getSubTasks(), id); // Call naar zelfde methode
                if (subTask != null)
                {
                    return subTask;
                }
            }
            break;
        }
        return null;
    }

Alhoewel het in principe wel goed zal gaan, de boom structuur is nou eenmaal niet oneindig,

Lijkt mij toch een redelijk normale breadth-first recursive search implementatie...

Edit: whoops, de break over het hoofd gezien, zie hierboven.

[ Voor 3% gewijzigd door Herko_ter_Horst op 15-07-2009 14:24 ]

[Janoz]

Standeman schreef op woensdag 15 juli 2009 @ 14:16:
Ik kwam net een stukje code tegen van mezelf dat me een best naar gevoel gaf:

Java:

    private Task findTask(Collection<Task> tasks, int id)
    {
        for (Task task : tasks)
        {
            if (task.getId() == id)
            {
                return task;
            }
            else if (task.getSubTasks() != null)
            {
                Task subTask = findTask(task.getSubTasks(), id); // Call naar zelfde methode
                if (subTask != null)
                {
                    return subTask;
                }
            }
            break;
        }
        return null;
    }

Alhoewel het in principe wel goed zal gaan, de boom structuur is nou eenmaal niet oneindig,

Op de utteloze break na zie ik niet zo heel veel vreemds aan deze implementatie. Het is gewoon een standaard implementaties gebruikmakend van recursie. Zolang je als pre conditie hebt dat een taak nooit een subtaak (of sub sub taak enz enz) van zichzelf kan zijn is er niks aan de hand.

[CoolGamer]

Herko_ter_Horst schreef op woensdag 15 juli 2009 @ 14:23:
[...]

Lijkt mij toch een redelijk normale breadth-first recursive search implementatie...

Als die break er niet had gestaan was het volgens mij een depth-first, niet een breadth-first. Hij loopt een tak eerst helemaal door voordat hij naar de volgende tak gaat.

[Standeman]

TheCoolGamer schreef op woensdag 15 juli 2009 @ 14:21:
[...]

Een foreach gebruiken en altijd bij het eerste element breaken of returnen. Echt goed doorlopen van de boom doet hij niet. Dus met twee of meer subtasks wordt alleen de eerste vergeleken met het ID.

Die break.

grmbl, dat krijg je als iemand steeds tegen aan zit te ouwehoeren.

Janoz schreef op woensdag 15 juli 2009 @ 14:31:
[...]

Op de utteloze break na zie ik niet zo heel veel vreemds aan deze implementatie. Het is gewoon een standaard implementaties gebruikmakend van recursie. Zolang je als pre conditie hebt dat een taak nooit een subtaak (of sub sub taak enz enz) van zichzelf kan zijn is er niks aan de hand.

Die conditie is er inderdaad. hmmm, zijn mijn implementaties toch beter dan gedacht

[ Voor 37% gewijzigd door Standeman op 15-07-2009 14:34 ]

[Janoz]

De presentatie discussie is afgesplitst naar Over logica en presentatie. Mocht ik nog berichten vergeten zijn, stuur dan even een DM naar mij of 1 van mijn collega mods.

[ Voor 77% gewijzigd door Janoz op 15-07-2009 15:08 ]

[Sebazzz]

Standeman schreef op woensdag 15 juli 2009 @ 14:33:
[...]

Die break.

grmbl, dat krijg je als iemand steeds tegen aan zit te ouwehoeren.

Dat merk ik ook wel eens ja, programmeren en iemand die tegen je aan loopt te praten gaat niet altijd samen.

Janoz schreef op woensdag 15 juli 2009 @ 14:55:
De presentatie discussie is afgesplitst naar Over logica en presentatie. Mocht ik nog berichten vergeten zijn, stuur dan even een DM naar mij of 1 van mijn collega mods.

Het valt wel op dat discussies in dit of andere PRG topics heel vaak weer over PHP gaan, en dan vaak ook weer worden afgesplitst. Wat een taaltje toch hè, dat PHP

[.oisyn]

Sebazzz schreef op donderdag 16 juli 2009 @ 13:07:
Het valt wel op dat discussies in dit of andere PRG topics heel vaak weer over PHP gaan

En dat mijn post op een of andere manier altijd de eerste is die in de nieuwe topic belandt

[StephanVierkant]

Sebazzz schreef op donderdag 16 juli 2009 @ 13:07:
Het valt wel op dat discussies in dit of andere PRG topics heel vaak weer over PHP gaan, en dan vaak ook weer worden afgesplitst. Wat een taaltje toch hè, dat PHP

Dan komt bij mij de vraag op waarom dat komt? Is PHP de taal waar veel beginnende programmeurs mee prutsen, of is het gewoon een rottaal?

[frickY]

PHP wordt veel gebruikt door mensen die niet kunnen programmeren, omdat het lekker laagdrempelig en vol valnetten is.

[MBV]

A little bit of both...

[Patriot]

Stephan4kant schreef op donderdag 16 juli 2009 @ 23:46:
[...]

Dan komt bij mij de vraag op waarom dat komt? Is PHP de taal waar veel beginnende programmeurs mee prutsen, of is het gewoon een rottaal?

Je bent niet de eerste die die vraag stelt.

Verder ben ik het eens met MBV. Het is niet de meest geweldig in elkaar gebouwde scripttaal die er is, en tegelijkertijd zijn er zéér veel mensen met zeer weinig of de verkeerde kennis (op internet, maar ook in oude boeken, is ontzettend veel verkeerde informatie omtrent scripten met PHP te vinden).

[FragFrog]

Stephan4kant schreef op donderdag 16 juli 2009 @ 23:46:
Dan komt bij mij de vraag op waarom dat komt? Is PHP de taal waar veel beginnende programmeurs mee prutsen, of is het gewoon een rottaal?

Mijn opinie: veel beginnende programmeurs prutsen ermee. Voor de dingen doen waar het voor bedoeld was, dynamische webcontent, vind ik het absoluut geen rottaal. Tuurlijk, de syntax bevat wat rare dingen (zoals argument volgorde bij stringfuncties) en ik ben ooit eens een middag kwijt geweest omdat ofwel PHP's SoapClient, ofwel IIS' SoapServer zich niet aan de specificaties houden, en natuurlijk kan je er ongelovelijk ranzig mee coden, maar daar staat tegenover dat als je je best doet je ook ongelovelijk mooi kan coden.

Vergelijk bijvoorbeeld eens function pointers in C++ met een variabele functienaam en eventueel bijbehorende magic __call in PHP - dan is die laatste (in elk geval voor mij) vele malen logischer. Sindskort heeft het late static binding, je kan zelf een classloader definieren voor dynamische includes (ik gebruik al jaren geen require / include's meer), dingen als een error en session handler zitten erin maar zijn relatief simpel te vervangen door je eigen exemplaren mocht je dat willen, etc etc etc. Combineer dat met een sublieme manual, een gigantische hoeveelheid libraries, enorme userbase en je hebt een ongelovelijk toegankelijke maar vooral ook fijne taal. En ja, je hebt mensen die er op neer kijken, so what - als je denkt dat je een betere programmeur bent omdat je in C++ of .NET werkt, good for you.

Om m'n post niet helemaal nutteloos te maken; een oud project, code geschreven door een collega die niet lang met ons was

PHP:

$wizzardPage = intval($postData['wizzard']);

En m'n favoriete comment in die grote bende troep

PHP:

class Spider { 
  const USER_ID = 358; # >:) muhaha 

[Patriot]

Combineer dat met een sublieme manual

Subliem!? Dat vind ik een beetje ovedreven eigenlijk

PHP:

<?php
$wizzardPage = intval($postData['wizzard']);
?>

Wat is hier precies fout aan? Behalve dat het waarschijnlijk wizard moet zijn, maar dat ligt niet aan het programmeren.

[NMe]

FragFrog schreef op vrijdag 17 juli 2009 @ 01:38:
[...]

Tuurlijk, de syntax bevat wat rare dingen (zoals argument volgorde bij stringfuncties)

De volgorde van functieargumenten is iets dat deel uitmaakt van de meegeleverde library en dat heeft 0,0 te maken met syntax.

Patriot schreef op vrijdag 17 juli 2009 @ 03:11:
[...]

Subliem!? Dat vind ik een beetje ovedreven eigenlijk

Een beetje maar?

Wat is hier precies fout aan? Behalve dat het waarschijnlijk wizard moet zijn, maar dat ligt niet aan het programmeren.

En zelfs wizzard mag! Wikipedia: Rincewind

Zijdelings gerelateerd:

PHP:

echo intval(420000000000000000000);   // 0
echo intval('420000000000000000000'); // 2147483647

/me cry *

[Phyxion]

NMe schreef op vrijdag 17 juli 2009 @ 03:21:
[...]

De volgorde van functieargumenten is iets dat deel uitmaakt van de meegeleverde library en dat heeft 0,0 te maken met syntax.

[...]

Een beetje maar?

[...]

En zelfs wizzard mag! Wikipedia: Rincewind

Zijdelings gerelateerd:

PHP:

echo intval(420000000000000000000);   // 0
echo intval('420000000000000000000'); // 2147483647

/me cry *

Java heeft ook zulke bugs

[Janoz]

Phyxion schreef op vrijdag 17 juli 2009 @ 08:11:
[...]

Java heeft ook zulke bugs

Care to explain? Ik kan me namelijk niet herinneren dat java ook maar ergens bij een groot getal automatisch maar maxint neemt.

[Phyxion]

Janoz schreef op vrijdag 17 juli 2009 @ 09:03:
[...]


Care to explain? Ik kan me namelijk niet herinneren dat java ook maar ergens bij een groot getal automatisch maar maxint neemt.

Even schaamteloze copy paste van een Tweakblog

Java:

final long YEAR_IN_MS = 1000 * 60 * 60 * 24 * 365;
System.out.println(YEAR_IN_MS);

Java zet alles eerst om naar int

[Remus]

Phyxion schreef op vrijdag 17 juli 2009 @ 09:22:
[...]

Even schaamteloze copy paste van een Tweakblog

Java:

final long YEAR_IN_MS = 1000 * 60 * 60 * 24 * 365;
System.out.println(YEAR_IN_MS);

Java zet alles eerst om naar int

Dat is gedefinieerd gedrag van Java en er wordt in alle boeken, tutorials ed ook altijd behandeld. Literals zijn per definitie int, tenzij je er een L achter zet. Sterker nog als je een literal groter dan Integer.MAX_VALUE gebruikt dan zal de compiler gaan klagen.
In jouw voorbeeld wordt in eerste instanties het resultaat met ints berekend, waarbij overflow optreedt, en pas daarna wordt er converteerd naar long. Bij berekening waar één long in voorkomt wordt de rest ook geupcast naar een long en klopt het resultaat dus wel.

Dus het volgende geeft wat je wil:

Java:

final long YEAR_IN_MS = 1000L * 60 * 60 * 24 * 365;
System.out.println(YEAR_IN_MS);

[ Voor 17% gewijzigd door Remus op 17-07-2009 09:51 ]

[Janoz]

Ik zie het probleem, maar de beschrijving is niet correct.Java zet niet alles om naar int, alles is juist opgegeven als int en int * int = int. Een constante in je code zal altijd als int gezien worden. De hele berekening wordt met ints gedaan en daar gaat het verloren. Het daarna in een long stoppen is al te laat. Dit werkt beter:

Java:

final long YEAR_IN_MS = 1000l * 60 * 60 * 24 * 365; 
System.out.println(YEAR_IN_MS);

Door iig 1 long op te nemen krijg je long * int = long waardoor het resultaat al voor het in de variabele zetten als long behandeld wordt.

Goed, het blijft vervelend en lastig terug te vinden, maar ten eerste doet java het enkel bij een berekening die een overflow oplevert en dus niet 1 of andere exotische cast omdat je toevallig de println gebruikt.

Verder wordt er niet zomaar MAX_INT gebruikt, maar worden de bits die buiten het bereik geschreven worden genegeerd. Dit is
1 - vaak wat er ook wordt verwacht
2 - duidelijk in de standaard gedocumenteerd http://java.sun.com/docs/...ypesValues.doc.html#51035
3 - altijd hetzelfde (dus niet in het ene geval 0 en in het andere geval MAX_INT)

Het blijft echter wel vervelend dat de overflow niet (zomaar) gedetecteerd kan worden.


--edit--- Hmm, volgende keer maar even niet op zoek gaan naar de specificaties om een SpuitElfException te voorkomen

[ Voor 4% gewijzigd door Janoz op 17-07-2009 09:58 ]

[Woy]

Phyxion schreef op vrijdag 17 juli 2009 @ 09:22:
[...]

Even schaamteloze copy paste van een Tweakblog

Java:

final long YEAR_IN_MS = 1000 * 60 * 60 * 24 * 365;
System.out.println(YEAR_IN_MS);

Java zet alles eerst om naar int

Zoals al uitgelegd hierboven is dat logisch gedrag, omdat je int's met int's vermenigvuldigd. Het is logisch dat het resultaat een int is.

Java:

long someval = 1000;
final long YEAR_IN_MS = someval * 60 * 60 * 24 * 365;
System.out.println(YEAR_IN_MS);

Zal dan ook gewoon goed gaan, want het resultaat van een long * int = long

edit:
Hier nog een SpuitElfRuntimeException

[ Voor 3% gewijzigd door Woy op 17-07-2009 09:59 ]

[Phyxion]

Remus schreef op vrijdag 17 juli 2009 @ 09:48:
[...]


Dat is gedefinieerd gedrag van Java en er wordt in alle boeken, tutorials ed ook altijd behandeld. Literals zijn per definitie int, tenzij je er een L achter zet. Sterker nog als je een literal groter dan Integer.MAX_VALUE gebruikt dan zal de compiler gaan klagen.
In jouw voorbeeld wordt in eerste instanties het resultaat met ints berekend, waarbij overflow optreedt, en pas daarna wordt er converteerd naar long. Bij berekening waar één long in voorkomt wordt de rest ook geupcast naar een long en klopt het resultaat dus wel.

Dus het volgende geeft wat je wil:

Java:

final long YEAR_IN_MS = 1000L * 60 * 60 * 24 * 365;
System.out.println(YEAR_IN_MS);

Ik weet dat het gedocumenteerd is maar je assigned wel naar long, niet naar int. int * int is uiteraard int, maar je kan ook voor een eenvoudige oplossing kiezen door YEAR_IN_MS eerst op 1 doen bijvoorbeeld en dan YEAR_IN_MS *= 1000 * 60 * 60 * 24 * 365;

[Woy]

Phyxion schreef op vrijdag 17 juli 2009 @ 10:06:
[...]

Ik weet dat het gedocumenteerd is maar je assigned wel naar long, niet naar int. int * int is uiteraard int, maar je kan ook voor een eenvoudige oplossing kiezen door YEAR_IN_MS eerst op 1 doen bijvoorbeeld en dan YEAR_IN_MS *= 1000 * 60 * 60 * 24 * 365;

Ja dat kun je doen, maar logisch is het niet!

Je moet de assignment gewoon los zien van de berekening, en het is compleet logisch. In sommige gevallen wil je gewoon een overflow in plaats van een opschaling naar long. Het is gewoon belangrijk om begrip van de onderliggende datatypes te hebben.

[Phyxion]

Woy schreef op vrijdag 17 juli 2009 @ 10:09:
[...]

Ja dat kun je doen, maar logisch is het niet!

Je moet de assignment gewoon los zien van de berekening, en het is compleet logisch. In sommige gevallen wil je gewoon een overflow in plaats van een opschaling naar long. Het is gewoon belangrijk om begrip van de onderliggende datatypes te hebben.

Ik vind het dan logischer als je dat wilt om het dan zelf te casten naar int dan het in zo'n geval stuk te laten lopen. Persoonlijk misschien, maar zulke keuzes vind ik echt slecht.

[Remus]

Phyxion schreef op vrijdag 17 juli 2009 @ 10:06:
[...]

Ik weet dat het gedocumenteerd is maar je assigned wel naar long, niet naar int. int * int is uiteraard int, maar je kan ook voor een eenvoudige oplossing kiezen door YEAR_IN_MS eerst op 1 doen bijvoorbeeld en dan YEAR_IN_MS *= 1000 * 60 * 60 * 24 * 365;

In java is een expressie (en het resultaat van die expressie) onafhankelijk van de variabele waaraan het uiteindelijk wordt toegekend. Als je met longs wil rekenen, zul je dus ook gewoon met minimaal met een long moeten rekenen. En dat doe je hier simpelweg niet. Pas als de expressie is geevalueerd wordt de waarde gecast naar long en toegekend aan de variabele

Het is dus geen bug zoals jij het noem, maar gewoon gedefinieerd gedrag en - in tegenstelling tot veel dingen in PHP - een bewuste keuze van de ontwerpers.

[Remus]

Janoz schreef op vrijdag 17 juli 2009 @ 09:57:

Java:

final long YEAR_IN_MS = 1000l * 60 * 60 * 24 * 365; 
System.out.println(YEAR_IN_MS);

Dit noem ik wel een 'slecht programmeervoorbeeld': gebruik dan een hoofdletter L om het onderscheid tussen 1 en L te verduidelijken.

[Woy]

Remus schreef op vrijdag 17 juli 2009 @ 10:19:
[...]

Dit noem ik wel een 'slecht programmeervoorbeeld': gebruik dan een hoofdletter L om het onderscheid tussen 1 en L te verduidelijken.

Dat is geen slecht programmeervoorbeeld, maar eerder een "slecht stijlvoorbeeld". De kleine letter is inderdaad een stuk foutgevoeliger. Maar met een beetje goede code highlighting zou het geen probleem op moeten leveren.

[whoami]

NMe schreef op vrijdag 17 juli 2009 @ 03:21:
[...]

De volgorde van functieargumenten is iets dat deel uitmaakt van de meegeleverde library en dat heeft 0,0 te maken met syntax.

code:

class Foo
{
      public void Bar( int x, int y )
      {
           Console.WriteLine (String.Format("x: {0} y: {1}", x, y));
}

public class Program
{
     public static void Main()
     {
           Foo f = new Foo();
           f.Bar (y: 10, x: 5);
     }   
}

uit:
http://msmvps.com/blogs/j...evil-code-of-the-day.aspx

[Sebazzz]

Woy schreef op vrijdag 17 juli 2009 @ 10:21:
[...]

Dat is geen slecht programmeervoorbeeld, maar eerder een "slecht stijlvoorbeeld". De kleine letter is inderdaad een stuk foutgevoeliger. Maar met een beetje goede code highlighting zou het geen probleem op moeten leveren.

Dat doet VS niet by default, dus in plaats daarvan hebben we bij C# een mooie gedocumenteerd compiler warning

[netvor]

@integer overflows in Java:
Interessant; ik was tot nu toe onder de veronderstelling dat Java wel een exception gooit als een integer ergens overflowt. Niets blijkt minder waar:

Java:

int myint = 1;
for (int i=0;i<16;i++) {
  myint = myint * 256;
  System.out.println(myint);
}
/*  256
    65536
    16777216
    0
    0
    0
    0
    0
    0
    0
    0
    0
    0
    0
    0
    0 */

Het is duidelijk dat ik al meer dan een jaar niets in Java heb gedaan, en alleen nog hier en daar wat in Python programmeer:

Python:

myint = 1
for i in range(16):
  myint = myint * 256
  print myint
#   256
#   65536
#   16777216
#   4294967296
#   1099511627776
#   281474976710656
#   72057594037927936
#   18446744073709551616
#   4722366482869645213696
#   1208925819614629174706176
#   309485009821345068724781056
#   79228162514264337593543950336
#   20282409603651670423947251286016
#   5192296858534827628530496329220096
#   1329227995784915872903807060280344576
#   340282366920938463463374607431768211456

[whoami]

Phyxion schreef op vrijdag 17 juli 2009 @ 10:06:
[...]

Ik weet dat het gedocumenteerd is maar je assigned wel naar long, niet naar int. int * int is uiteraard int, maar je kan ook voor een eenvoudige oplossing kiezen door YEAR_IN_MS eerst op 1 doen bijvoorbeeld en dan YEAR_IN_MS *= 1000 * 60 * 60 * 24 * 365;

Dat vind ik veel viezer dan gewoon:

code:

long melp = 1000L * 60 * 60 * 24 * 365

hoor ....

[Phyxion]

whoami schreef op vrijdag 17 juli 2009 @ 10:28:
[...]

code:

class Foo
{
      public void Bar( int x, int y )
      {
           Console.WriteLine (String.Format("x: {0} y: {1}", x, y));
}

public class Program
{
     public static void Main()
     {
           Foo f = new Foo();
           f.Bar (y: 10, x: 5);
     }   
}

uit:
http://msmvps.com/blogs/j...evil-code-of-the-day.aspx

Interessante code, zeker als je het complete voorbeeld bekijkt, vrij logisch dat C# dat ervan maakt, maar zoals gezegd best wel evil code Niet een constructie die ik op zou zetten in ieder geval

@ Hierboven,
Dit was bedoeld voor Java, niet om zelf zo te coden.

[ Voor 4% gewijzigd door Phyxion op 17-07-2009 10:36 ]

[jbdeiman]

Lol, dat was me nog niet eens opgevallen, ik dacht dat daar 10001 stond Vond het al zo vreemd die uitleg erbij. Maar nu zie ik 'm.

De meeste talen zijn "zo goed als degene die ermee werkt" De mogelijkheden om mooi en goed te scripten (waarbij ik geen onderscheid wens te maken tussen OOP of structureel, beiden kan prima werken) zijn er wel (in JS, JAVA, C#, PHP enz) maar sommige van die talen zijn wat losser of gaan in elk geval wat gemakkelijker om met de "regeltjes" die er zijn.
PHP bijvoorbeeld vind ik ook een leuke, maar tegelijkertijd prima taal. Mits je weet wat je doet, altijd alle errors weergeeft in je ontwikkelomgeving (online natuurlijk op de achtergrond afvangen en bezoekers met een logische melding "afschepen") kan je er leuke dingen mee maken.
Wat ik in bijna alle (al moet ik eerlijk bekennen dat ik er helemaal geen ken) boeken slecht vind is dat ze bijna nooit isset() gebruiken en al helemaal error_reporting niet aan hebben staan. Ze noemen het vaak wel (ergens heel klein/ weggestopt op een plek waar niemand het opmerkt) even, maar geven niet aan dat je dat het best aan kan zetten tijdens de ontwikkeling en uit schakelen bij je online versie.

Daar gaat de beginnende PHP-er al meteen de fout in, omdat hij niet leert om volgens de standaard te werken. Iets wat je slecht aanleert is heel moeilijk om daarna weer af te leren.Sterker nog: Het is moeilijker om iets af te leren dan om iets aan te leren.
Behalve hier op 't forum zit ik ook op 2 andere Nederlandstalige (php) fora, zo vaak als je daar bijna kan volstaan met

PHP:

<?php 
ini_set('error_reporting',1);
error_reporting(E_ALL);
?>

(dit is even snel getypt, kan best een typefoutje inzitten)

Dan zien ze een melding gaan verder kijken en "Hé, dit is de melding..."

Laat boeken bij de basis beginnen, dus ook tijdens het leren aangeven wat fouten zijn, veroorzaakt, de melding is en hoe je ze op kan lossen/ snel terug kan vinden. (en nog veeel beter: Hoe kan je ze voorkomen)

[ Voor 10% gewijzigd door jbdeiman op 17-07-2009 10:39 ]

[whoami]

Sebazzz schreef op vrijdag 17 juli 2009 @ 10:30:
[...]

Dat doet VS niet by default, dus in plaats daarvan hebben we bij C# een mooie gedocumenteerd compiler warning

Idd.
Nooit op gelet eigenlijk, maar net even getest.

[Janoz]

Phyxion schreef op vrijdag 17 juli 2009 @ 10:12:
Ik vind het dan logischer als je dat wilt om het dan zelf te casten naar int dan het in zo'n geval stuk te laten lopen. Persoonlijk misschien, maar zulke keuzes vind ik echt slecht.

Casting regels zijn in java heel duidelijk, intuïtief en bruikbaar. Wat jij 'logisch' vind heeft als gevolg dat of elke primitieve berekening van byte en int middels 64 bit long arithmetics uitgevoerd moet worden, of dat bij elke simpele operatie gekeken moet worden of er een overflow is en vervolgens de hele berekening opnieuw gedaan worden met een breder type. Wat is dan überhaupt nog het nut van de kleinere types?


@Remus:
Je hebt helemaal gelijk.

[Phyxion]

Janoz schreef op vrijdag 17 juli 2009 @ 10:38:
[...]

Casting regels zijn in java heel duidelijk, intuïtief en bruikbaar. Wat jij 'logisch' vind heeft als gevolg dat of elke primitieve berekening van byte en int middels 64 bit long arithmetics uitgevoerd moet worden, of dat bij elke simpele operatie gekeken moet worden of er een overflow is en vervolgens de hele berekening opnieuw gedaan worden met een breder type. Wat is dan überhaupt nog het nut van de kleinere types?


@Remus:
Je hebt helemaal gelijk.

Het hoeft niet bij alles, maar met een final/const is het natuurlijk heel anders.

[Janoz]

Nou, dan verschillen we daarin van mening. Ik zou het dus minder logisch vinden dat exact dezelfde expressie ineens anders afgehandeld wordt omdat het toevallig aan een final variabele wordt toegekend.

[Woy]

Phyxion schreef op vrijdag 17 juli 2009 @ 10:46:
[...]

Het hoeft niet bij alles, maar met een final/const is het natuurlijk heel anders.

Ja want laten we voor elke manier van definitie maar andere regels gaan bedenken, daar word het een stuk duidelijker van?

Dan zou de waarde van een variabele dus niet alleen afhangen van welk data-type het is, maar ook met welke modifiers hij gedeclareerd word.

whoami schreef op vrijdag 17 juli 2009 @ 10:28:
[...]

code:

class Foo
{
      public void Bar( int x, int y )
      {
           Console.WriteLine (String.Format("x: {0} y: {1}", x, y));
}

public class Program
{
     public static void Main()
     {
           Foo f = new Foo();
           f.Bar (y: 10, x: 5);
     }   
}

uit:
http://msmvps.com/blogs/j...evil-code-of-the-day.aspx

Die is inderdaad wel evil, maar het omwisselen van parameter namen in een override van een functie past dan wel weer mooi in dit topic

[ Voor 40% gewijzigd door Woy op 17-07-2009 11:06 ]

[Zoijar]

Ik vind het wel een beetje vreemd eigenlijk dat een literal niet gewoon het grootste type heeft. Dat de assignment naar een int fout gaat is geheel logisch, maar dat de vermenigvuliding van twee literals al overflowed is bewerkelijk. Als je een cijfer teveel achter de komma typed by een float literal, gaat het dan ook fout? (Ik snap wel waarom het zo is, maar je moet toch toegeven dat het vreemd aanvoelt)

[ Voor 11% gewijzigd door Zoijar op 17-07-2009 11:09 ]

[Woy]

Zoijar schreef op vrijdag 17 juli 2009 @ 11:05:
Ik vind het wel een beetje vreemd eigenlijk dat een literal niet gewoon het grootste type heeft. Dat de assignment naar een int fout gaat is geheel logisch, maar dat de vermenigvuliding van twee literals al overflowed is bewerkelijk.

Ik vind het wel duidelijk dat het gewoon niet automatisch gedaan word. Bij C# krijg je overigens gewoon een compiler error als een vermenigvuldiging van literals een overflow oplevert.

The operation overflows at compile time in checked mode

Als je een cijfer teveel achter de komma typed by een float literal, gaat het dan ook fout?

Op zich zou dat netjes zijn, maar het verschil met floats is natuurlijk al dat de waarde in de float niet exact overeen hoeft te komen met de literal.

[ Voor 4% gewijzigd door Woy op 17-07-2009 11:10 ]

[Janoz]

Een floating point literal is standaard een double. Daar heb je automatisch al het grootste type. Daar zul je een F toe moeten voegen om juist de kleinere variant te krijgen.

Dat ze bij literals voor gehele getallen voor de 32bit int gekozen hebben ipv de 64bit long is waarschijnlijk uit efficiëntie overwegingen (in uitvoer en bij het programmeren). In 99% van de gevallen zou je daar toch een int bedoelen (bedenk dat het begin jaren 90 is dat de standaard is opgesteld), en om een long in een int te krijgen heb je een expliciete cast nodig.

[Olaf van der Spek]

Woy schreef op vrijdag 17 juli 2009 @ 10:09:
Ja dat kun je doen, maar logisch is het niet!

Volgens mij werkt dat helemaal niet. De expressie rechts van *= overflowed nog steeds voordat *= wordt uitgevoerd.

[Woy]

Olaf van der Spek schreef op vrijdag 17 juli 2009 @ 11:14:
[...]

Volgens mij werkt dat helemaal niet. De expressie rechts van *= overflowed nog steeds voordat *= wordt uitgevoerd.

Daar heb je idd ook nog eens gelijk in.

[Zoijar]

Janoz schreef op vrijdag 17 juli 2009 @ 11:11:
Dat ze bij literals voor gehele getallen voor de 32bit int gekozen hebben ipv de 64bit long is waarschijnlijk uit efficiëntie overwegingen (in uitvoer en bij het programmeren). In 99% van de gevallen zou je daar toch een int bedoelen (bedenk dat het begin jaren 90 is dat de standaard is opgesteld), en om een long in een int te krijgen heb je een expliciete cast nodig.

Efficientie boeit niet echt bij literals: ik mag aannemen dat de java compiler dat fold (Ook in het geval van (int)x * 2, zou je compiler moeten zien dat 2 als int kan). Ik denk eerder dat de rede is dat ze bijvoorbeeld compiler makers voor 32bit platformen niet willen dwingen om 64bit integer arithmetic te implementeren. Het is dus om implementatie van de compiler te versimpelen, niet omdat het zo logisch programmeert.

[ Voor 11% gewijzigd door Zoijar op 17-07-2009 11:18 ]

[Woy]

Zoijar schreef op vrijdag 17 juli 2009 @ 11:16:
[...]

Efficientie boeit niet echt bij literals: ik mag aannemen dat de java compiler dat fold. Ik denk eerder dat de rede is dat ze bijvoorbeeld compiler makers voor 32bit platformen niet willen dwingen om 64bit integer arithmetic te implementeren.

Janoz bedoelt denk efficientie van het data-type. Aangezien de meeste mensen gewoon een literal zonder toevoegingen gebruiken, kun je het standaard type beter het type maken wat onder de meeste omstandigheden het efficientst is.

[Zoijar]

Woy schreef op vrijdag 17 juli 2009 @ 11:19:
Janoz bedoelt denk efficientie van het data-type. Aangezien de meeste mensen gewoon een literal zonder toevoegingen gebruiken, kun je het standaard type beter het type maken wat onder de meeste omstandigheden het efficientst is.

Efficient in welk opzicht? Op een 64bit platform is een 32bit int niet efficient.

Normaals, ik snap dus de design beslissing wel, maar er werd hier net gedaan of die beslissing is gemaakt omdat het zo makkelijk programmeert, terwijl ik juist denk dat de beslissing alleen is gemaakt omdat het het schrijven van portable compilers een stuk simpeler maakt. Het programmeert natuurlijk makkelijker als je helemaal niet op dat soort dingen hoeft te letten.

[ Voor 30% gewijzigd door Zoijar op 17-07-2009 11:26 ]

[Janoz]

Maar die waren er nog niet zo wijdverspreid in de jaren 90. Daarnaast is een 32 bit bewerking niet minder efficiënt dan dezelfde 64bit bewerking op een 64bit systeem, zeker wanneer je het vergelijkt met het verschil tussen een 64 bit bewerking vs 32 bit bewerking op een 32 bit systeem.

Maar verder denk ik wel dat je gelijk hebt. Ik heb er ook "in uitvoer en programmeren" bij gezet en vervolgens enkel een voorbeeld over het programmeren bij gezet waarmee ik eigenlijk enkel aan wilde geven dat je toch vaak uit kunt met de int ipv de long. En ja, dat is eigenlijk meer het verdedigen van het uiteindelijke gevolg van de ontwerpbeslissing ipv de echte achterliggende reden van de beslissing.

[ Voor 35% gewijzigd door Janoz op 17-07-2009 11:29 ]

[Woy]

Zoijar schreef op vrijdag 17 juli 2009 @ 11:20:
[...]
Efficient in welk opzicht? Op een 64bit platform is een 32bit int niet efficient.

Daarom zei ik ook "onder de meeste omstandigheden". De meeste talen zijn ontworpen met 32 bits processoren in het achterhoofd.

Normaals, ik snap dus de design beslissing wel, maar er werd hier net gedaan of die beslissing is gemaakt omdat het zo makkelijk programmeert, terwijl ik juist denk dat de beslissing alleen is gemaakt omdat het het schrijven van portable compilers een stuk simpeler maakt. Het programmeert natuurlijk makkelijker als je helemaal niet op dat soort dingen hoeft te letten.

Ik zal niet ontekennen dat de keuze waarschijnlijk grotendeels gebaseerd is op de complexiteit van de compiler. Maar het geeft wel controle over wat er gebeurt, en dat is in sommige gevallen ook wel fijn.

[FragFrog]

NMe schreef op vrijdag 17 juli 2009 @ 03:21:
De volgorde van functieargumenten is iets dat deel uitmaakt van de meegeleverde library en dat heeft 0,0 te maken met syntax.

Jaja, strict genomen heb je gelijk, maar je snapt wat ik bedoel - de default libraries zijn wat maf soms

Een beetje maar?

De vier manuals / API's die ik meestal gebruik zijn die van PHP, JAVA, AS3 en C++. Daarvan bied die van PHP veel meer voorbeelden dan de anderen, hebben alleen die van PHP en C++ een overzichtelijke groepering (die verder gaat dan een lijst classes), geven de PHP & C++ search me de meest zinnige resultaten en vind ik alleen bij de PHP manual ook extra info als installatie instructies voor externe libraries. Overall ben ik nog geen betere tegengekomen.

Ik ben trouwens niet de enige die er zo over denkt

[Woy]

FragFrog schreef op vrijdag 17 juli 2009 @ 14:36:
[...]
De vier manuals / API's die ik meestal gebruik zijn die van PHP, JAVA, AS3 en C++. Daarvan bied die van PHP veel meer voorbeelden dan de anderen, hebben alleen die van PHP en C++ een overzichtelijke groepering (die verder gaat dan een lijst classes), geven de PHP & C++ search me de meest zinnige resultaten en vind ik alleen bij de PHP manual ook extra info als installatie instructies voor externe libraries. Overall ben ik nog geen betere tegengekomen.

Ik vind de Java doc's anders zeer uitgebreid, maar ben het met je eens dat ze misschien iets meer examples in de doc's op hadden kunnen nemen. Maar dat het niet gegroepeerd is ben ik niet met je eens, de namespaces zijn immers IMHO best duidelijk gekozen, en dat is dus een duidelijk groepering.

Bij de PHP doc's staan misschien wel een hoop examples, maar een groot nadeel daarvan is dat er ook vaak, zeker in de comments, enorme fouten in de examples zitten.

Wat dat betreft verdiend MS echt een groot compliment, de documentatie van hun is meestal erg goed!

Ik ben trouwens niet de enige die er zo over denkt

offtopic:
resemples ?

[Olaf van der Spek]

Zoijar schreef op vrijdag 17 juli 2009 @ 11:20:
Efficient in welk opzicht? Op een 64bit platform is een 32bit int niet efficient.

Dat lijkt me niet per definitie waar. Sterker nog, 32 bit variabelen zouden best eens efficienter kunnen zijn dan 64 bit variabelen op een 64 bit platform.

[.oisyn]

Phyxion schreef op vrijdag 17 juli 2009 @ 10:06:
[...]

Ik weet dat het gedocumenteerd is maar je assigned wel naar long, niet naar int. int * int is uiteraard int, maar je kan ook voor een eenvoudige oplossing kiezen door YEAR_IN_MS eerst op 1 doen bijvoorbeeld en dan YEAR_IN_MS *= 1000 * 60 * 60 * 24 * 365;

En dat helpt wil je zeggen? Het ding waar je mee vermenigvuldigt is nog altijd een int waar 1000 * 60 * 60 * 24 * 365 niet in past

.edit: ah dat was al gezegd
Wel suf dat de compiler er niet op warnt overigens.

[ Voor 7% gewijzigd door .oisyn op 21-07-2009 13:48 ]

[Sebazzz]

Woy schreef op vrijdag 17 juli 2009 @ 14:47:
[...]

Wat dat betreft verdiend MS echt een groot compliment, de documentatie van hun is meestal erg goed!

Van de .NET documentatie zeker weten wel ja, maar in de Win32 api documentatie zitten af en toe wel wat gaten.

[Verwijderd]

PHP:

$handle = fopen($url, "r");
while (!feof($handle)) {
   $buffer .= fgets($handle, 4096);
}

Resultaat:

23 miljoen regels in de error_log van Apache in een tijd van 4 minuten en 32 seconden.
Dat is ruim 86.000 errors per seconde, goed voor een totaal van 5 GB aan error_log.
En als mooie bijvangst gingen er 267 websites down.

Voor degenen die het niet zien: wat gebeurt er als de URL niet opgevraagd kan worden door bijvoorbeeld een network timeout of een name resolving error?

[bobo1on1]

Janoz schreef op vrijdag 17 juli 2009 @ 11:11:
Een floating point literal is standaard een double. Daar heb je automatisch al het grootste type.

Niet, long double is vaak nog groter dan double.

Output van:

C++:

cout << sizeof(1.0) << " " << sizeof(long double) << "\n";

op g++ 4.3.3:

code:

8 12

[XWB]

FragFrog schreef op vrijdag 17 juli 2009 @ 14:36:
[...]

Jaja, strict genomen heb je gelijk, maar je snapt wat ik bedoel - de default libraries zijn wat maf soms


[...]

De vier manuals / API's die ik meestal gebruik zijn die van PHP, JAVA, AS3 en C++. Daarvan bied die van PHP veel meer voorbeelden dan de anderen, hebben alleen die van PHP en C++ een overzichtelijke groepering (die verder gaat dan een lijst classes), geven de PHP & C++ search me de meest zinnige resultaten en vind ik alleen bij de PHP manual ook extra info als installatie instructies voor externe libraries. Overall ben ik nog geen betere tegengekomen.

Ik ben trouwens niet de enige die er zo over denkt

Pff, de php manual schiet ook vaak te kort hoor. Zo is de PDO doccumentatie niet volledig. Vandaag wou ik nog aan de slag met filter_input (), wat blijkt:

code:

Parameters
- filter
    Filter to apply. Defaults to FILTER_DEFAULT.

Ja, en waar is de rest? Ze staan hier, maar een linkje plaatsen was wel zo handig geweest.

[ Voor 26% gewijzigd door XWB op 24-07-2009 23:26 ]

[Janoz]

bobo1on1 schreef op vrijdag 24 juli 2009 @ 22:20:
[...]
Niet, long double is vaak nog groter dan double.

Java, waar ik het over had, heeft geen long double.

[Webgnome]

Het is niet echt een slecht voorbeeld maar het maakte me wel even aan het lachen

Visual Basic:

public function doStuff() as boolean
  On Error Goto Hell

  Exit function
Hell:
Print "Now BURN BURN BURN!"
end function

[Sebazzz]

Niet echt slecht? Goto is een no-go hoor

[Paul]

Fout gebruikt wel. Echter, in VB6 / VBA (en mogelijk nog wat VB-varianten) is het zo ongeveer de enige manier om iets aan foutafhandeling te doen

[.oisyn]

Het is iig al beter dan een ON ERROR RESUME NEXT

[ValHallASW]

Zowel voor ON ERROR GOTO als ON ERROR RESUME NEXT geldt dat je zelf de foutafhandeling moet doen, en dat het dus niet per definitie fout. De opmerking van Sebazzz dat 'goto een no-go is' is hier dan ook gewoon onzin. Het enige foute is dat er geen correcte foutafhandeling plaatsvindt; wat dat betreft is het functioneel equivalent aan

C#:

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

[Grijze Vos]

ValHallASW schreef op zaterdag 25 juli 2009 @ 21:32:
De opmerking van Sebazzz dat 'goto een no-go is' is hier dan ook gewoon onzin.

En dan maak je een typo en dan verwijst je goto ineens naar een label in een andere prodecure...
Goto is gewoon fundamenteel slecht. Een oud-professor van mijn universiteit heeft daar wel een keertje over gerant.

[bobo1on1]

Anderen hebben daar weer een andere mening over: http://kerneltrap.org/node/553/2131

Persoonlijk vind ik dat het altijd mogelijk is spaghetti code te schrijven, of je nou goto gebruikt of niet

[Paul]

En dan maak je een typo en zitten er ineens 25 uren in een dag. Integers zijn gewoon fundamenteel slecht

Ik ben het zeker met je eens dat je ze, als he het kunt vermijden, niet moet gebruiken, maar soms kom je er niet onderuit (enige wat ik me kan bedenken waar je er niet onderuit komt is bij error-afhandeling in een aantal Basic-varianten, dus dat is een heel beperkte set). En als ze fundamenteel slecht zouden zijn, dan zouden ze niet all over the place in je assembler zitten

Jouw opmerking is eerder kritiek op naamgeving dan op goto's an sich. Als je al je variabelen i1, i2, i3 ... i5144, i5145 noemt dan krijg je ook de meest wazige dingen als je met de verkeerde gaat rekenen door een typo. Als je echter je error-deel (functienaam)_error of zo noemt, en verder naar goed gebruik geen goto's gebruikt, is het al heel lastig om met een simpele typo ergens compleet anders uit te komen.

[Haan]

Grijze Vos schreef op zondag 26 juli 2009 @ 00:24:
[...]

En dan maak je een typo en dan verwijst je goto ineens naar een label in een andere prodecure...
Goto is gewoon fundamenteel slecht. Een oud-professor van mijn universiteit heeft daar wel een keertje over gerant.

Als je code schrijft waarbij door een typo opeens een andere functie of variabele wordt aangeroepen ben je eerder een fundamenteel slechte programmeur
Het maken van een typo heeft imo niets te maken met een programmeertaal, maar ligt volledig bij de programmeur, al wordt het met code-completion wel makkelijker om een 'typo' te maken doordat je per ongeluk de verkeerde suggestie uit een lijstje kan selecteren.

[ValHallASW]

Grijze Vos schreef op zondag 26 juli 2009 @ 00:24:
[...]
Een oud-professor van mijn universiteit heeft daar wel een keertje over gerant.

Heb je ook zelf al eens de moeite gelezen om het artikel te lezen? Hij betoogt namelijk dat gebruik van goto er gemakkelijk voor kan zorgen dat het niet meer mogelijk is om in te zien in welke 'state' het programma zich bevindt: je kunt immers raar tussen lussen springen. Hij betoogt dan ook om lussen en functies te gebruiken in plaats van goto's - daar raak je immers het overzicht kwijt (lees maar eens GWBASIC-code...). Daar is bij deze constructie alleen helemaal geen sprake van! Het enige probleem is dat er de mogelijkheid bestaat om vanuit een ander punt óók naar dit label te springen - maar dan zou dát het slechte programmeervoorbeeld zijn.

[Sebazzz]

Haan schreef op zondag 26 juli 2009 @ 09:15:
[...]

Als je code schrijft waarbij door een typo opeens een andere functie of variabele wordt aangeroepen ben je eerder een fundamenteel slechte programmeur

Daar is geen ' ' nodig, je hoort gewoon de psychologische afstand tussen variabele en methodenamen zo groot mogelijk te houden.

[Onbekend]

Haan schreef op zondag 26 juli 2009 @ 09:15:
Als je code schrijft waarbij door een typo opeens een andere functie of variabele wordt aangeroepen ben je eerder een fundamenteel slechte programmeur

Wat zijn eigenlijk precies de werkzaamheden van een programmeur?
Je hebt programmeurs die vanaf de vraag (vraag om bepaalde functionaliteit) t/m het schrijven van de documentatie alles zelf doen. Maar je hebt ook programmeurs die maar een deel van de rit doen, zoals alleen maar inkloppen van code waarvan iemand anders in een blokdiagram het gedrag van variabelen al heeft gedefinieerd.

[Sebazzz]

Ik vind dat een programmeur het applicatie/classdesign en het code kloppen doet. Uiteraard in samenwerking met anderen als dat toepasbaar is.

Als hobby-programmeur ben je ook nog documentarist, designer (als in: UI-design), en marketingmanager

[icyx]

Kijk, in het artikel op kerneltrap word, vind ik, duidelijk door Linus & Scott Robert Ladd aangegeven wanneer het niet fout is om een goto te gebruiken. Zie dit stukje:

In one case, a single "goto" doubled the speed of a
time-critical application; in the other case, "goto" shortens a segment of
code by half and makes the algorithm much clearer.

Wanneer het inderdaad op een manier gebruikt word wanneer een algoritme een stuk duidelijker word, vind ik het persoonlijk ook totaal niet verkeerd. Uiteindelijk wil je werkende code die goed te onderhouden is. Dit krijg je niet door hemel en aarde bewegen om de zelfde functionaliteit op een compleet onduidelijke manier zonder goto aan de man te brengen. Wanneer je het zo aanpakt vind ik het ook gewoon fundamenteel fout. Wat mij betreft kan je het een beetje vergelijken met het hebben van een hamer en een schroevendraaier. Omdat opa gezegd heeft dat de hamer een groot, eng monster is, gebruik je de schroevendraaier maar om een spijkertje in een stuk hout te slaan.

[Verwijderd]

icyx schreef op zondag 26 juli 2009 @ 16:50:
Kijk, in het artikel op kerneltrap word, vind ik, duidelijk door Linus & Scott Robert Ladd aangegeven wanneer het niet fout is om een goto te gebruiken. Zie dit stukje:

[...]

Wanneer het inderdaad op een manier gebruikt word wanneer een algoritme een stuk duidelijker word, vind ik het persoonlijk ook totaal niet verkeerd. Uiteindelijk wil je werkende code die goed te onderhouden is. Dit krijg je niet door hemel en aarde bewegen om de zelfde functionaliteit op een compleet onduidelijke manier zonder goto aan de man te brengen.

Tja, iedereen kan natuurlijk een quote ergens vandaan halen die mooi in zijn straatje past. Het liefst zag ik toch een bepaalde context waaruit het één en ander blijkt.

[icyx]

Verwijderd schreef op zondag 26 juli 2009 @ 17:43:
[...]


Tja, iedereen kan natuurlijk een quote ergens vandaan halen die mooi in zijn straatje past. Het liefst zag ik toch een bepaalde context waaruit het één en ander blijkt.

Natuurlijk kan dat altijd, maar dat is ook het hele idee. Ik ben het (denk ik) met je eens dat het vaak bad behaviour is om goto te gebruiken, maar juist die enkele uitzonderingen, die voorbeeldjes uit mijn straatje, maken het wat mij betrefd op dat soort momenten legitiem. Zoals het stukje code waar de discussie op kerneltrap mee begint:

C:

if (spin_trylock(&tty_lock.lock))
    goto got_lock;
if (tsk == tty_lock.lock_owner) {
    WARN_ON(!tty_lock.lock_count);
    tty_lock.lock_count++;
    return flags;
}
spin_lock(&tty_lock.lock);
got_lock:
    WARN_ON(tty_lock.lock_owner);

GOTO vrij:

C:

if (!(spin_trylock(&tty_lock.lock))){
    if (tsk ==tty_lock.lock_owner){
        WARN_ON(!tty_lock.lcok_count);
        tty_lock.lock_count++;
        return flags;
    }
}
WARN_ON(tty_lock.lock_owner);

Persoonlijk vind ik het eerste excerpt een stuk eleganter. Het (eenvoudige) error handling principe is wat mij betreft een stuk eleganter dan het op meerdere niveaus nesten de code, om vervolgens hetzelfde resultaat te krijgen.

[.oisyn]

ValHallASW schreef op zaterdag 25 juli 2009 @ 21:32:
Zowel voor ON ERROR GOTO als ON ERROR RESUME NEXT geldt dat je zelf de foutafhandeling moet doen

Het punt van de on error resume next is dat je helemaal geen foutafhandelijk doet, maar dat je errors gewoon keihard negeert.

Grijze Vos schreef op zondag 26 juli 2009 @ 00:24:
En dan maak je een typo en dan verwijst je goto ineens naar een label in een andere prodecure...

Kan dat in VB? My god...

Goto is gewoon fundamenteel slecht.

on error goto != goto. Voor foutafhandeling in VB had je niet zo heel veel andere keuze.

Een oud-professor van mijn universiteit heeft daar wel een keertje over gerant.

Zoals altijd geldt: use with care. De goto is daar niet veel anders in. De term "goto is evil" is goed om beginnende programmeurs mee om hun oren te slaan, maar hij is niet per definitie waar.

[ Voor 20% gewijzigd door .oisyn op 26-07-2009 18:27 ]

[prototype]

Dudes, get over it ;-), een goto is gewoon een jump, je gebruikt het al zonder dat je het door hebt: if statements, while loops etc... gebruiken onderwater allemaal dit. Een competente programmeur moet hier prima mee uit de voeten kunnen. Zoals .oisyn al zegt, het is goed om beginnende programmeurs even mee om de oren te slaan, maar voor gevorderde programmeurs is goto de betere keus in sommige gevallen.

[bobo1on1]

.oisyn schreef op zondag 26 juli 2009 @ 18:21:
[...]

Kan dat in VB? My god...

Kan in C ook met longjmp, dat maakt het nog niet minder slecht natuurlijk.

[Onbekend]

Bij errors roep ik vaak een centrale functie aan die iets in een log-file wegschrijft, en een (begrijpelijke) melding aan de gebruiker weergeeft.
Afhankelijk van de type foutmelding laat ik het programma stoppen of doorgaan. Een fout is weliswaar een fout, maar soms is een fout minder erg waardoor het programma evengoed door kan gaan met de bewerking.
Geen goto dus, maar gewoon een nette aanroep van een functie.

[ Voor 8% gewijzigd door Onbekend op 26-07-2009 19:11 ]

[.oisyn]

bobo1on1 schreef op zondag 26 juli 2009 @ 19:05:
[...]


Kan in C ook met longjmp, dat maakt het nog niet minder slecht natuurlijk.

We hadden het over een goto waar je per ongeluk een label uit een andere functie refereert. Dat is een taaltechnisch iets. Dat C een functie heeft die de stack state opslaat zodat je die later weer kunt gebruiken is een heel ander verhaal. Dergelijke functies zou je in elke taal kunnen implementeren.

[Grijze Vos]

ValHallASW schreef op zondag 26 juli 2009 @ 14:10:
[...]

Heb je ook zelf al eens de moeite gelezen om het artikel te lezen?

Wat denk je zelf? Dat ik iets link zonder het gelezen te hebben? Ik heb genoeg assembly geschreven om te weten hoe onoverzichtelijk een paar goto's worden.

Ik begrijp dat je in VB niet veel keuze hebt omdat er geen zinnige try/catch constructie is, maar dat maakt de constructie niet automagisch beter.

.oisyn schreef op zondag 26 juli 2009 @ 18:21:
[...]
Zoals altijd geldt: use with care. De goto is daar niet veel anders in. De term "goto is evil" is goed om beginnende programmeurs mee om hun oren te slaan, maar hij is niet per definitie waar.

Dat iets evil is betekent gewoon dat je het moet vermijden tenzij noodzakelijk. Soms is die noodzaak er inderdaad. Als je een kernel bouwt en het is 2x zo snel om iets met een jump te doen, dan moet je dat vooral doen. Je moet wel -weten- wat je doet. Het niveau van de programmeurs in het werkveld is echter bedroevend laag, dus ik ben liever iets kritischer bij dit soort dingen.

Je weet hoe het gaat met dit soort dingen. Iemand gebruikt die on error labels eerst gewoon. Dan denkt ie "heey, ik kan ook naar hetzelfde label wijzen, en alle fouten door dezelfde code laten afhandelen." En voor je het weet bouwt iemand spaghetti die jij mag onderhouden.

[ Voor 10% gewijzigd door Grijze Vos op 27-07-2009 00:42 ]

[jbdeiman]

Ik snap op zich het punt van een GOTO nou niet zo zeer:
Je doet bij een goto eigenlijk zoiets:

als(voorwaarde_is_voldaan){
ga naar regelnaam/ functienaam
}

dat is eigenlijk precies hetzelfde als wanneer je een functie schrijft die de actie doet die na je goto wordt uitgevoerd.
Een goto is eigenlijk niets meer dan een kortere notatie van een if/else controle. Het komt neer op:

PHP:

<?php
if($voorwaarde = true){
  //ga naar goto
  }
else{
  //voer dit uit
  }
function functienaam(){
  echo 'blaat';
  }
?>

Als aan de voorwaarde is voldaan, dan voert die uit wat in de If staat, als niet aan de voorwaarde is voldaan, voert die de else uit.. Nooit beiden..
Daarnaast kan je na de if/ else prima verder gaan met je code, net als wat je bij een goto zou doen. Overigens snap ik de ophef over de goto wel, zeker voor de beginnende programmeur is het heel simpel om maar snel een stukje code over te slaan, de echte logica is op dat moment alleen maar lastiger. Zeker wanneer je op een stuk code meerdere goto's gebruikt, kan het wel eens zijn dat er heen en weer gesprongen wordt. De leesbaarheid van je code komt dat dan niet echt ten goede vind ik.

[RobIII]

jbdeiman schreef op maandag 27 juli 2009 @ 12:01:
Ik snap op zich het punt van een GOTO nou niet zo zeer:
<snip>
Overigens snap ik de ophef over de goto wel, zeker voor de beginnende programmeur is het heel simpel om maar snel een stukje code over te slaan, de echte logica is op dat moment alleen maar lastiger. Zeker wanneer je op een stuk code meerdere goto's gebruikt, kan het wel eens zijn dat er heen en weer gesprongen wordt. De leesbaarheid van je code komt dat dan niet echt ten goede vind ik.

[!null]

Dat is ook al een slecht programmeervoorbeeld, flinke inconsistentie

[Zoijar]

icyx schreef op zondag 26 juli 2009 @ 18:08:
Zoals het stukje code waar de discussie op kerneltrap mee begint:

C:

if (spin_trylock(&tty_lock.lock))
    goto got_lock;
if (tsk == tty_lock.lock_owner) {
    WARN_ON(!tty_lock.lock_count);
    tty_lock.lock_count++;
    return flags;
}
spin_lock(&tty_lock.lock);
got_lock:
    WARN_ON(tty_lock.lock_owner);

GOTO vrij:

C:

if (!(spin_trylock(&tty_lock.lock))){
    if (tsk ==tty_lock.lock_owner){
        WARN_ON(!tty_lock.lcok_count);
        tty_lock.lock_count++;
        return flags;
    }
}
WARN_ON(tty_lock.lock_owner);

Persoonlijk vind ik het eerste excerpt een stuk eleganter.

Echt? Ik zou altijd die tweede kiezen. Het is nog korter ook! Het enige geldige punt dat ze maken is voor die rare conditionele loops, waar je anders een "bool isdone = false; while (!done) { if (xx) done = true;}" contructie nodig hebt. Dan kan een goto handig zijn, hoewel een break meestal duidelijker is. Als je dat dan nest, dan werkt een break niet, en dan heb je een goto nodig. Ik heb dat nog nooit nodig gehad...

hoewel ik het zo zou schrijven:

C:

if (!spin_trylock(&tty_lock.lock) && tsk == tty_lock.lock_count) {
        WARN_ON(!tty_lock.lcok_count);
        tty_lock.lock_count++;
        return flags;
    } // eventueel een else { en return flags buiten de if, maar alleen indien beide code path een return flags doen
WARN_ON(tty_lock.lock_owner);

[/code]

[ Voor 13% gewijzigd door Zoijar op 27-07-2009 12:30 ]

[.oisyn]

jbdeiman schreef op maandag 27 juli 2009 @ 12:01:
Een goto is eigenlijk niets meer dan een kortere notatie van een if/else controle.

Waar het om gaat is dat een if gestructureerd is. Je kunt er niet alle kanten mee opspringen, de volgorde van executie is ten alle tijden van boven naar beneden, waarbij eventueel een heel blok code al dan niet wordt uitgevoerd. Het is bij een if statement dus inherent duidelijk om te zien hoe de executie gaat zijn. Bij een goto is dat niet het geval.

Zoijar schreef op maandag 27 juli 2009 @ 12:28:
Als je dat dan nest, dan werkt een break niet, en dan heb je een goto nodig.

Niet nodig, je kunt die bool ook naar buiten trekken en in de buitenste loop nog een keer checken en dan opnieuw breaken. Bij nog diepere nesting wordt dat idd onleesbaar, maar voor performance hoef je het doorgaans niet te laten (meestal is de gegenereerde code exact identiek aan de code die goto gebruikt, omdat de compiler ook wel snapt dat je een bool zet en dan de lus verlaat, waarna meteen die bool weer wordt getest zodat je net zo goed meteen door kunt springen)

[ Voor 38% gewijzigd door .oisyn op 27-07-2009 12:31 ]

[RobIII]

Overigens:

jbdeiman schreef op maandag 27 juli 2009 @ 12:01:
Je doet bij een goto eigenlijk zoiets:

als(voorwaarde_is_voldaan){
ga naar regelnaam/ functienaam
}

Als je er een if-statement om heen zet wel; een goto op zichzelf is echter onconditioneel en verstoort gewoon de flow van de code (en dus krijg je spaghetti code).

Er zijn trouwens best gevallen waarin GOTO bruikbaar/handig/noodzakelijk is, maar die gevallen zijn zéér zeldzaam en dan moet je een verdomd goede reden hebben om een GOTO te gebruiken (tenzij je in ASM werkt; en zelfs die zijn vaak nog conditioneel )

.oisyn schreef op maandag 27 juli 2009 @ 12:28:
[...]

Waar het om gaat is dat een if gestructureerd is. Je kunt er niet alle kanten mee opspringen, de volgorde van executie is ten alle tijden van boven naar beneden, waarbij eventueel een heel blok code al dan niet wordt uitgevoerd. Het is bij een if statement dus inherent duidelijk om te zien hoe de executie gaat zijn. Bij een goto is dat niet het geval.

Ey Doe's niet voorkruipen

[ Voor 35% gewijzigd door RobIII op 27-07-2009 12:32 ]

[Zoijar]

.oisyn schreef op maandag 27 juli 2009 @ 12:28:
Niet nodig, je kunt die bool ook naar buiten trekken en in de buitenste loop nog een keer checken en dan opnieuw breaken. Bij nog diepere nesting wordt dat idd onleesbaar, maar voor performance hoef je het doorgaans niet te laten (meestal is de gegenereerde code exact identiek aan de code die goto gebruikt, omdat de compiler ook wel snapt dat je een bool zet en dan de lus verlaat, waarna meteen die bool weer wordt getest zodat je net zo goed meteen door kunt springen)

True. Dat performance argument snapte ik ook niet; meestal genereert het idd exact dezelfde code, mits je het goed opschrijft.

Eerlijk gezegd komt die hele discussie op mij erg over als "wij zijn expert kernel hackers en kunnen een goto wel goed gebruiken en weten ook een heel zeldzaam legitiem geval waar het correct is, dus goto is niet evil en iedereen die dat denkt is eigenlijk maar dom omdat ze niet zo slim zijn dat ze het goed kunnen gebruiken". Maarja...

[RayNbow]

.oisyn schreef op zondag 26 juli 2009 @ 18:21:
[...]

Het punt van de on error resume next is dat je helemaal geen foutafhandelijk doet, maar dat je errors gewoon keihard negeert.

Wil je zeggen dat het volgende stukje code errors keihard negeert dan?
 

VBScript:

On Error Resume Next
Dim x
x = 1/0
If Err Then
   MsgBox "Error " & Err & ": " & Err.Description
End If

[.oisyn]

RayNbow schreef op maandag 27 juli 2009 @ 13:01:
[...]

Wil je zeggen dat het volgende stukje code errors keihard negeert dan?

Nee, maar ik hoef hoop ik niet uit te leggen dat dit wel een heel erg simpel voorbeeld is, en dat je in de werkelijkheid te maken hebt met veel grotere lappen code, waarbij in een functie bijv. wordt gerekend op error afhandeling van buitenaf, maar dat iemand anders dan toch maar een Resume Next er van heeft gemaakt in de context van een specifieke aanroep.

Of ga jij overal je code peperen met If Err statements?

[RayNbow]

.oisyn schreef op maandag 27 juli 2009 @ 13:08:
[...]

Nee, maar ik hoef hoop ik niet uit te leggen dat dit wel een heel erg simpel voorbeeld is, en dat je in de werkelijkheid te maken hebt met veel grotere lappen code, waarbij in een functie bijv. wordt gerekend op error afhandeling van buitenaf, maar dat iemand anders dan toch maar een Resume Next er van heeft gemaakt in de context van een specifieke aanroep.

Right tool for the right job.

On Error Resume Next gebruik je dus als je lokaal de fout wilt en kan afhandelen. Met On Error GoTo bevindt de error handler meestal onderaan in de functie of sub.

Of ga jij overal je code peperen met If Err statements?

Nee, want in grotere blokken code waar het niet precies uitmaakt waar de fout optreedt zul je dus gebruik maken van On Error GoTo.

Of in een bepaalde functionele taal gebruik je de Maybe of een Error (zoals Either) monad