[alg] Slechtste programmeervoorbeelden deel 4

[.oisyn]

Michali schreef op dinsdag 05 juli 2011 @ 18:49:
[...]

code:

someBoolean = someBoolean == true;

Fixed.

code:

Fixed

MBV schreef op dinsdag 05 juli 2011 @ 20:18:
In C++ is een boolean volgens mij ook gewoon een char

Zie de reactie van Soultaker.

[Makkelijk]

Matis schreef op dinsdag 05 juli 2011 @ 21:38:
[...]

In C bestaat er niet eens een boolean
In C99 kun je eventueel stdbool.h includen, maar dat geeft je een macro terug met _Bool, waarin true als 1 wordt behandeld en false als 0.

Soultaker schreef op dinsdag 05 juli 2011 @ 21:55:
[...]

Onzin.

Jullie weten allebei best dat jullie allebei gelijk hebben

[urk_forever]

Laatst twee redelijk foute stukjes code tegen gekomen in een project van ons:

Het totaal aantal minuten in een constante stoppen:

C#:

const int TotalMinutes = new TimeSpan(365, 0, 0, 0).TotalMinutes;

En deze: true of false terug geven op basis van een veld waarde:

C#:

public bool GetBooleanValue() 
{
    if (_privateVar == SomeEnum.Waarde1) 
    {
        return true;
    }
    else if (_privateVar == SomeEnum.Waarde2)
    {
        return true;
    }
    else if (_privateVar == SomeEnum.Waarde3)
    {
        return true;
    }
    else if (_privateVar == SomeEnum.Waarde4)
    {
        return false;
    }
    else
    {
        return false;
    }
}

De echte code was nog wel iets uitgebreider, maar ik heb het maar aangepast zodat er maar 1 if met 1 else is.

[Avalaxy]

urk_forever schreef op dinsdag 05 juli 2011 @ 22:36:
-knip-

Probeerseltje:

C#:

public bool GetBooleanValue()
{
    bool returnValue = false;

    switch (_privateVar)
    {
        case SomeEnum.Waarde1:
        case SomeEnum.Waarde2:
        case SomeEnum.Waarde3:
            returnValue = true;
    }

    return returnValue;
}

[MBV]

.oisyn schreef op dinsdag 05 juli 2011 @ 22:13:
[...]

code:

Fixed

[...]

Zie de reactie van Soultaker.

C++:

#include <stdio.h>
int main()
{
  bool x = true;
  x = 5;
  return x;
}

geen compile errors met g++, dus waarschijnlijk doet !!x wel degelijk iets (normaliseren naar true of false). Hernoemd naar .c, met gcc behandeld, en wat krijgen we nu: 'bool' undeclared. Dus in C zit standaard geen bool, daar moet je wat voor includen.

[Gleighton]

Booleans? Daar heb je toch gewoon SETB voor?

[Makkelijk]

JavaScript doublebanged ook prima met functies.

JavaScript:

function a() {
  return true;
}
!!a => true
!!a === true => true

gotta love it.

[ Voor 11% gewijzigd door Makkelijk op 05-07-2011 23:00 ]

[.oisyn]

@MBV: your logic is flawed.

MBV schreef op dinsdag 05 juli 2011 @ 22:46:
[...]

C++:

#include 
int main()
{
  bool x = true;
  x = 5;
  return x;
}

geen compile errors met g++

Dus omdat je geen compile errors krijgt trek je de conclusie dat je een willekeurige int in een bool stoppen?
En ik mag hopen dat je wél compile errors krijgt (regel 1)

C++:

bool x = 4.5;

Geen compile errors, bool is vast van het type double dan he

C++:

bool x = new int(4);

Krijg nou tieten, er passen zelfs pointers in!

hint: implicit casts

Hernoemd naar .c, met gcc behandeld, en wat krijgen we nu: 'bool' undeclared. Dus in C zit standaard geen bool

Wederom vage conclusie. Java kent vast ook geen boolean, want dit compileert ook niet

Java:

class S
{
    public static void main(String[] args)
    {
        bool b = true;
    }
}

In C99 compileert het volgende gewoon. Ja, zonder includes.

C:

_Bool b;

Makkelijk schreef op dinsdag 05 juli 2011 @ 22:18:
Jullie weten allebei best dat jullie allebei gelijk hebben

Ik weet iig dat alleen Soultager gelijk heeft. <stdbool.h> bestaat idd, maar die geeft geen #define voor _Bool maar voor bool (en true en false). En waar verwijst bool dan naar? Juist, het built-in type _Bool. Wat ook meteen de stelling ontkracht dat C geen boolean type kent.

[ Voor 81% gewijzigd door .oisyn op 05-07-2011 23:25 ]

[urk_forever]

Avalaxy schreef op dinsdag 05 juli 2011 @ 22:45:
[...]


Probeerseltje:

C#:

public bool GetBooleanValue()
{
    bool returnValue = false;

    switch (_privateVar)
    {
        case SomeEnum.Waarde1:
        case SomeEnum.Waarde2:
        case SomeEnum.Waarde3:
            returnValue = true;
    }

    return returnValue;
}

Dat kan ook, ik heb er:

C#:

    if (_privateVar == SomeEnum.Waarde1 ||
        _privateVar == SomeEnum.Waarde2 ||
        _privateVar == SomeEnum.Waarde3)
    {
        return true;
    }
    else
    {
        return false;
    }

van gemaakt. De eigenlijke functie was nog wat uitgebreider.

[Verwijderd]

YopY schreef op woensdag 29 juni 2011 @ 15:08:
[...]


als je collega er nog werkt zou je idd dat moeten doen. Soms kun je beter laten voelen dan zelf proberen te gaan corrigeren. Als je het sociale type bent (of wilt worden) kun je er beter nog naast gaan zitten en wat vriendelijke suggesties aanbieden, zo van 'En nu gaan we deze duplicatie vervangen door een eenvoudiger algoritme.' oid.

Lekker sociaal, neerbuigend toontje inderdaad!

[Verwijderd]

Ik werk bij een bedrijf wat probleem specifieke hardware maakt, waar ook software op draait. Nu draaien er bij een zusterbedrijf soortgelijke projecten, maar dan van een ietwat lomper kaliber (qua software niet veel speciaals, qua hardware wel). Nu heeft afdeling software daar besloten om zelf een test taal in elkaar te draaien, om test scripts te kunnen maken. Nu bestaat er ook zoiets als Python, in combinatie met C / C++ kan daar alles wat je nodig hebt, maar krijg dat er maar eens in.

Het komt er dus op neer, op onze locatie, waar de software meestal ingewikkelder is dan de hardware, dat we Python met C / C++ gebruiken, en bij het zusterbedrijf de DHZ methode.

[ Voor 2% gewijzigd door Verwijderd op 06-07-2011 09:46 . Reden: warboel rechttrekken ]

[418O2]

urk_forever schreef op woensdag 06 juli 2011 @ 08:56:
[...]


Dat kan ook, ik heb er:

C#:

    if (_privateVar == SomeEnum.Waarde1 ||
        _privateVar == SomeEnum.Waarde2 ||
        _privateVar == SomeEnum.Waarde3)
    {
        return true;
    }
    else
    {
        return false;
    }

van gemaakt. De eigenlijke functie was nog wat uitgebreider.

C#:

    return (_privateVar == SomeEnum.Waarde1 ||
        _privateVar == SomeEnum.Waarde2 ||
        _privateVar == SomeEnum.Waarde3);  

Kan toch ook?

[CodeCaster]

Is Adobe Reader X een slecht programmeervoorbeeld?



Even een PDF'je van 250 KB openen en er doorheen scrollen, laptop was de eerste minuut onbruikbaar.

[ Voor 4% gewijzigd door CodeCaster op 06-07-2011 10:13 ]

[whoami]

urk_forever schreef op woensdag 06 juli 2011 @ 08:56:
[...]


Dat kan ook, ik heb er:

C#:

    if (_privateVar == SomeEnum.Waarde1 ||
        _privateVar == SomeEnum.Waarde2 ||
        _privateVar == SomeEnum.Waarde3)
    {
        return true;
    }
    else
    {
        return false;
    }

van gemaakt. De eigenlijke functie was nog wat uitgebreider.

Ik heb een extension method voor enum - types (althans, je kan dat niet zo één op één afdwingen dat het enkel op enums werkt), waarmee je dit kan:

code:

if( _privateVar.In (SomeEnum.Value1, SomeEnum.Value2, SomeEnum.Value3 )
{
    return true;
}

return false;

kan doen.

of nog korter:

code:

return _privateVar.In (Someenum.Value1, SomeEnum.Value2, SomeEnum.Value3);

[ Voor 6% gewijzigd door whoami op 06-07-2011 10:18 ]

[.oisyn]

CodeCaster schreef op woensdag 06 juli 2011 @ 10:12:
Is Adobe Reader X een slecht programmeervoorbeeld?

FoxIT reader!

[Coca-Cola]

.oisyn schreef op woensdag 06 juli 2011 @ 10:59:
[...]

FoxIT reader!

/offtopic
Adobe is idd om te huilen, Ik gebruik meestal ook FoxIT maar lees net:
http://news.cnet.com/8301-30685_3-20076699-264/firefox-pdf-reader-passes-pixel-perfect-test/

[PrisonerOfPain]

.oisyn schreef op woensdag 06 juli 2011 @ 10:59:
[...]

FoxIT reader!

Ja en fuck die PDF reader in Chrome voor ik 'm gedisabled had raakt ik alle presentaties en papers kwijt omdat ze niet meer op m'n hardeschijf stonden

[Megamind]

.oisyn schreef op woensdag 06 juli 2011 @ 10:59:
[...]

FoxIT reader!

offtopic:
Niet upgraden naar Adobe reader 10, gewoon 9.X gebruiken die werkt prima)

[.oisyn]

PrisonerOfPain schreef op woensdag 06 juli 2011 @ 12:20:
[...]


Ja en fuck die PDF reader in Chrome voor ik 'm gedisabled had raakt ik alle presentaties en papers kwijt omdat ze niet meer op m'n hardeschijf stonden

Klopt, ik heb ook de PDF reader voor Chrome gedisabled en gebruik gewoon de foxIT plugin. Sowieso kon Chrome meer dan de helft van de PDFs gewoon niet lezen, maar ik geloof dat dat tegenwoordig verbeterd is.

Voor de rest, FoxIT reader support officieel geen Chrome, maar als je ook FireFox geïnstalleerd hebt en je kiest bij de installer van FoxIT voor FF integration, dan werkt hij ook in Chrome. Als je geen FF hebt of wil installeren, dan kun je de plugin ook handmatig aan chrome toevoegen. Ik zal even opzoeken hoe dat ook alweer werkt.

.edit:
1. Copy "C:\Program Files\Foxit Software\Foxit Reader\plugins\npFoxitReaderPlugin.dll" to "C:\Program Files\Google\Chrome\Application\Plugins"
Note that the Plugins folder is in the same place as Chrome.exe, so you can go there by right-clicking the shortcut and clicking Open File Location (useful if its stored somewhere else)

2. Copy "FoxitReaderOCX.ocx" from "C:\Users\USER\AppData\Local\Temp" to "C:\Windows\System32".
I have absolutely no idea why it is in the temporary folder. I think it may be created when you attempt to install the FireFox plugin, in which case you will need to attempt install it first. Don't worry if it fails because FireFox isn't installed, it will create this file in the process.

3. Run "regsvr32 FoxitReaderOCX.ocx" with admin rights.
To do this, right-click Command Prompt in start and click Run As Administrator. Then enter the above command and press enter.

4. Restart Chrome if you have it running, and browse to a PDF to test it. It seems to lag for a sec while it loads the plugin, but should work.

Megamind schreef op woensdag 06 juli 2011 @ 12:20:
[...]

offtopic:
Niet upgraden naar Adobe reader 10, gewoon 9.X gebruiken die werkt prima)

Die reader was al kut toen het nog Acrobat 5 heette. Logge resourcevretende teringzooi, dat altijd maar wil updaten.

[ Voor 46% gewijzigd door .oisyn op 06-07-2011 12:45 ]

[PrisonerOfPain]

.oisyn schreef op woensdag 06 juli 2011 @ 12:41:
Voor de rest, FoxIT reader support officieel geen Chrome, maar als je ook FireFox geïnstalleerd hebt en je kiest bij de installer van FoxIT voor FF integration, dan werkt hij ook in Chrome. Als je geen FF hebt of wil installeren, dan kun je de plugin ook handmatig aan chrome toevoegen. Ik zal even opzoeken hoe dat ook alweer werkt.

PDFs in de browser lezen is absoluut niet mijn ding. Geef mij maar lekker een aparte executable die opent na het downloaden, daar ben ik een stuk beter mee af.

[.oisyn]

Ik zei ook "voor de rest"

[PrisonerOfPain]

Hehehehe

[Alex)]

Als we het toch over brakke software hebben, wil ik Firefox 5 nomineren. Na 2 uur gebruik 750 MB RAM vreten

Ik ga nu maar Chrome gebruiken...

[Caelorum]

Hmm geen problemen met Adobe reader X hier. Werkt zelfs sneller dan FoxIT bij mij
Ik zet wel altijd meteen die achterlijke Reader preloader of wat dat ding ook doet uit. Wil geen troep die automatisch zonder dat ik het weet opstart bij het starten van de PC.

[ Voor 51% gewijzigd door Caelorum op 06-07-2011 13:25 ]

[Alex)]

Ik heb een tijdje FoxIt gebruikt, tot ze er adware bij gingen proppen. Toen ben ik teruggegaan naar Adobe Reader (9 destijds, nu X) die het voor mijn gevoel toch beter doet dan FoxIt.

[MueR]

Kunnen we weer on-topic?

[Avalaxy]

urk_forever schreef op woensdag 06 juli 2011 @ 08:56:
[...]


Dat kan ook, ik heb er:

C#:

    if (_privateVar == SomeEnum.Waarde1 ||
        _privateVar == SomeEnum.Waarde2 ||
        _privateVar == SomeEnum.Waarde3)
    {
        return true;
    }
    else
    {
        return false;
    }

van gemaakt. De eigenlijke functie was nog wat uitgebreider.

Dat vind ik minder netjes om 2 redenen:

• Ik hou niet van grote checks in een if-statement, die zou ik dan liever in een aparte functie stoppen.
• Meerdere returns binnen een method vind ik ook niet echt netjes, je kunt daar makkelijk een enkele return statement van maken

[Paul]

Hoe maak je daar een aparte functie van? Dan staat er in die functie vrijwel letterlijk dat code-blok

Je kunt het herschrijven naar 'return (bla == a || bla == b) (nu is dit voorbeeld ook wel erg rechtlijnig natuurlijk ), maar dat is gewoon wat je gewend bent / de rest van het bedrijf doet. Zelf vind ik meerdere returns alleen maar duidelijk: 'ah, we zijn klaar...' in plaats van een extra niveau indentation, naar beneden scrollen en zien of er nog meer wordt gedaan etc.

[Avalaxy]

Paul schreef op woensdag 06 juli 2011 @ 16:15:
Hoe maak je daar een aparte functie van? Dan staat er in die functie vrijwel letterlijk dat code-blok

In deze casus heeft dat inderdaad niet veel zin, maar bij een wat langere method is het wel handig om niet alle voorwaarden te hoeven bekijken maar hier gewoon een enkele functie-call ziet die true danwel false returnt zonder iets te weten over de achterliggende logica.

[YopY]

Nog een alternatief: in Java kun je enums in een switch / case proppen:

Java:

    // aannemend dat _privateVar een SomeEnum is
    switch(_privateVar) {
        case Waarde1:
        case Waarde2:
        case Waarde3:
            return true;
    }
    return false;

Maar de C# 'in' extension method is een stuk cleaner, vind ik zelf.

Als _privateVar een enum is zou je dat ook gewoon in Java kunnen doen, door een in() functie toe te voegen aan je enum:

Java:

enum SomeEnum {
    Waarde1,
    Waarde2,
    Waarde3;
    public boolean in(SomeEnum ... enums) {
        for (SomeEnum value : enums) {
            if (this == value) {
                return true;
            }
        }
        return false;
    }
};

// en gebruiken
SomeEnum _privateValue = SomeEnum.Waarde1;
if (_privateValue.in(SomeEnum.Waarde1, SomeEnum.Waarde2)) {
    // doe iets.
}

[.oisyn]

Alleen wel jammer dat je daarvoor de enum aan moet passen, en dat ook moet doen voor iedere enum.

[PrisonerOfPain]

YopY schreef op woensdag 06 juli 2011 @ 17:04:
Nog een alternatief: in Java kun je enums in een switch / case proppen:

Java:

    // aannemend dat _privateVar een SomeEnum is
    switch(_privateVar) {
        case Waarde1:
        case Waarde2:
        case Waarde3:
            return true;
    }
    return false;

Maar de C# 'in' extension method is een stuk cleaner, vind ik zelf.

Als _privateVar een enum is zou je dat ook gewoon in Java kunnen doen, door een in() functie toe te voegen aan je enum:

Java:

enum SomeEnum {
    Waarde1,
    Waarde2,
    Waarde3;
    public boolean in(SomeEnum ... enums) {
        for (SomeEnum value : enums) {
            if (this == value) {
                return true;
            }
        }
        return false;
    }
};

// en gebruiken
SomeEnum _privateValue = SomeEnum.Waarde1;
if (_privateValue.in(SomeEnum.Waarde1, SomeEnum.Waarde2)) {
    // doe iets.
}

Ik snap de gedachtengang hierachter dus compleet niet. Het is niet/amper leesbaarder en wel nodeloos ingewikkelder.


Aangenomen dat je enum values power-of-two zijn (wat ze niet altijd zijn, maar dat kun je afdwingen). Kun je ook gewoon dit doen:

C:

if(x & (Waarde1 | Waarde2))
{
  printf("Warempel");
}

[Manuel]

Op dit moment ben ik nog bezig met een Joomla template aan te passen voor een klant en ik kom mij daar een slecht voorbeeld tegen, perfect voor dit topic. Zie hier een stukje Javascript:

JavaScript:

var s5_height1 = 0;
var s5_width1 = 0;
var s5_height2 = 0;
var s5_width2 = 0;
var s5_height3 = 0;
var s5_width3 = 0;
var s5_height4 = 0;
var s5_width4 = 0;
var s5_height5 = 0;
var s5_width5 = 0;
var s5_height6 = 0;
var s5_width6 = 0;
var s5_height7 = 0;
var s5_width7 = 0;
var s5_height8 = 0;
var s5_width8 = 0;
var s5_height9 = 0;
var s5_width9 = 0;
var s5_height10 = 0;
var s5_width10 = 0;

//Kan je nagaan dat dit doorloopt t/m de 100 aan toe..
//Natuurlijk moeten al deze variabelen ook waardes hebben, zie hier:

if (s5_fm_ul2.length >= 1) {
    if (n==1) {
    s5_fm_ul2[n].style.height = (s5_height1 - 2) + "px";
    s5_fm_ul2[n].style.width = (s5_width1 - 2) + "px";
    }
    if (s5_fm_ul2.length >= 2) {
    if (n==2) {
        s5_fm_ul2[n].style.height = (s5_height2 - 2) + "px";
        s5_fm_ul2[n].style.width = (s5_width2 - 2) + "px";
    }
}
//Dit loopt tevens door t/m 100...
//Nog een stukje verder (ook door tot 100):
if (s5_n=="1") {
    document.getElementById(s5_ul).style.height = (s5_height1 - 2) + "px";
    document.getElementById(s5_ul).style.width = (s5_width1 - 2) + "px";
}
if (s5_n=="2") {
    document.getElementById(s5_ul).style.height = (s5_height2 - 2) + "px";
    document.getElementById(s5_ul).style.width = (s5_width2 - 2) + "px";
}

[bomberboy]

PrisonerOfPain schreef op woensdag 06 juli 2011 @ 17:38:
[...]
Ik snap de gedachtengang hierachter dus compleet niet. Het is niet/amper leesbaarder en wel nodeloos ingewikkelder.

Ben ik ook helemaal mee akkoord

Aangenomen dat je enum values power-of-two zijn (wat ze niet altijd zijn, maar dat kun je afdwingen). Kun je ook gewoon dit doen:

C:

if(x & (Waarde1 | Waarde2))
{
  printf("Warempel");
}

Dit is enerzijds elegant, maar vereist volgens mij gewoon te veel voorkennis, je moet al weten dat die enums machten van 2 zijn en developers zijn niet altijd even vertrouwd met bitwise operatoren en je leest er eigenlijk te makkelijk over heen indien je ze niet regelmatig gebruikt.

Bij sommige van de eerdere voorstellen kom ik persoonlijk dan nog liever de originele versie van de code tegen. Ok, het is niet zo netjes en elegant, maar je ziet in een (of twee) oogopslag(en) wat het doet. De versie die de OP er van gemaakt heeft biedt dat dan zeker.

Sommige van de andere vernuftige oplossingen zijn helemaal niet straightforward en moet je dus ofwel erg vertrouwd zijn met de codebase of er extra commentaar bij gooien. Wat voor mij persoonlijk een belangrijk metriek is om code mee te beoordelen is de tijd die iemand anders nodig heeft om te snappen wat ze doet.

[Caelorum]

Manuel schreef op woensdag 06 juli 2011 @ 20:39:
Op dit moment ben ik nog bezig met een Joomla template aan te passen voor een klant en ik kom mij daar een slecht voorbeeld tegen, perfect voor dit topic. Zie hier een stukje Javascript:

JavaScript:

[...]

Ziet eruit als een of ander codegen tooltje

[RayNbow]

PrisonerOfPain schreef op woensdag 06 juli 2011 @ 17:38:

C:

if(x & (Waarde1 | Waarde2))
{
  printf("Warempel");
}

Als we toch aan het taal-hoppen zijn, doe het dan goed:

Haskell:

  when (x `elem` [Waarde1, Waarde2]) $ do
  {
     putStrLn "zOMG!"
  }

[Manuel]

Caelorum schreef op woensdag 06 juli 2011 @ 20:53:
[...]

Ziet eruit als een of ander codegen tooltje

Ik hoop dat ze het wel hebben gebruikt i.p.v. alles handmatig te typen. Het neemt alleen niet weg dat dit een ranzige constructie is wat in minder regels kan worden bereikt.

[PrisonerOfPain]

RayNbow schreef op woensdag 06 juli 2011 @ 21:01:
[...]

Als we toch aan het taal-hoppen zijn, doe het dan goed:

Haskell:

  when (x `elem` [Waarde1, Waarde2]) $ do
  {
     putStrLn "zOMG!"
  }

Jij hoort "obligatory Haskell reference" te heetten.

bomberboy schreef op woensdag 06 juli 2011 @ 20:39:
Dit is enerzijds elegant, maar vereist volgens mij gewoon te veel voorkennis, je moet al weten dat die enums machten van 2 zijn en developers zijn niet altijd even vertrouwd met bitwise operatoren en je leest er eigenlijk te makkelijk over heen indien je ze niet regelmatig gebruikt.

Het hangt een beetje af van het veld waarin je werkt, maar ik vind dat bitwise operators en powers-of-two basiskennis zijn en snap ook niet waarom men dit niet zou kunnen gebruiken. Het leest praktisch hetzelfde als andere oplossingen en vrijwel de meest efficiente oplossing voor dit probleem (als je het compiled word het "and, cmp, jump" de bitmask word naar alle waarschijnlijk ge-constant-fold).

Een foreach over een stel var-args of andere lijst zoals in het Haskell voorbeeld zal je hotspot of andere 'ach-hij-doet-al-het-werk-wel-voor-mij'-compiler niet zo snel krijgen. Nu is efficientie natuurlijk niet alles maar iedere keer als ik een developer hoor klagen over hoe lang het wel niet duurt om simpele dingen te doen, of naar het geheugengebruik van bepaalde programmas kijk moet ik aan dit soort dingen denken.

Nog een mooie die ik laatst tegen kwam:

C++:

enum SomeEnum
{
     // Belangrijk; de enum bevat maar een paar waarden
     ValueX,
     ValueY
};


std::map<SomeEnum, unsigned int *> collection;

Nu moet je weten dat een std::map (in de belangrijke stl implemenaties) geimplementeerdis als een red-black tree. Kortom, je hebt een relatief gigantische overhead mbt cache-misses (data en instruction), branches, allocatie patronen en geheugengebruik. Immers een gemiddelde red-black tree node heeft een color en een left-, right-, parent- en data-pointer.

Schrijf dat lekker zo op:

C++:

enum SomeEnum
{
     ValueX,
     ValueY,
     SomeEnumCount
};

unsigned int *collection[SomeEnumCount] = {};

[HeSitated]

Avalaxy schreef op dinsdag 05 juli 2011 @ 22:45:

C#:

public bool GetBooleanValue()
{
    bool returnValue = false;

    switch (_privateVar)
    {
        case SomeEnum.Waarde1:
        case SomeEnum.Waarde2:
        case SomeEnum.Waarde3:
            returnValue = true;
    }

    return returnValue;
}

Dit werkt wel in javascript, maar niet in C#

Je krijgt de melding: Control cannot fall through from one case label ('case 2:') to another
In VB.Net kun je meerdere waardes achter 1 case zetten, in C# moet je met goto's werken....

Zo ongeveer de enige plek waar je goto's zou mogen gebruiken?

[Avalaxy]

HeSitated schreef op woensdag 06 juli 2011 @ 22:58:
[...]

Dit werkt wel in javascript, maar niet in C#

Je krijgt de melding: Control cannot fall through from one case label ('case 2:') to another
In VB.Net kun je meerdere waardes achter 1 case zetten in C# moet je met goto's werken....

Zo ongeveer de enige plek waar je goto's zou mogen gebruiken?

Verrek. Ik gebruik bijna nooit fall through, maar in Java kon het wel, dus ik dacht in C# ook.

[CodeCaster]

HeSitated schreef op woensdag 06 juli 2011 @ 22:58:
[...]


Dit werkt wel in javascript, maar niet in C#

Je krijgt de melding: Control cannot fall through from one case label ('case 2:') to another
In VB.Net kun je meerdere waardes achter 1 case zetten in C# moet je met goto's werken....

Zo ongeveer de enige plek waar je goto's zou mogen gebruiken?

Goto voorstellen in plaats van een simpele OR, ik begin die meneer Dijkstra steeds beter te begrijpen...

[HeSitated]

Avalaxy schreef op woensdag 06 juli 2011 @ 23:01:
Verrek. Ik gebruik bijna nooit fall through, maar in Java kon het wel, dus ik dacht in C# ook.

Hmm, ik moet me corrigeren: het mag wel maar dan mogen er geen statements staan...

Dus het gegeven voorbeeld is zo wel goed:

C#:

 
    switch (_privateVar)
    {
        case SomeEnum.Waarde1:
        case SomeEnum.Waarde2:
        case SomeEnum.Waarde3:
            returnValue = true;
            break;
    } 

Die break is dus essentieel...

[ Voor 3% gewijzigd door HeSitated op 06-07-2011 23:12 ]

[alex3305]

Avalaxy schreef op dinsdag 05 juli 2011 @ 22:45:
[...]

Probeerseltje:

[...]

Of nog wat gemakkelijker:

C#:

public bool GetBooleanValue()
{
    switch (_privateVar)
    {
        case SomeEnum.Waarde1:
        case SomeEnum.Waarde2:
        case SomeEnum.Waarde3:
            return true;
    }

    return false;
}

Dan heb je ook geen eventuele break meer nodig en geen tijdelijke variabele.

[Avalaxy]

alex3305 schreef op woensdag 06 juli 2011 @ 23:19:
[...]

Of nog wat gemakkelijker:

C#:

public bool GetBooleanValue()
{
    switch (_privateVar)
    {
        case SomeEnum.Waarde1:
        case SomeEnum.Waarde2:
        case SomeEnum.Waarde3:
            return true;
    }

    return false;
}

Dan heb je ook geen eventuele break meer nodig en geen tijdelijke variabele.

Maar dan zit je weer met meerdere return statements binnen 1 method, wat ik dan weer een bad practice vind.

[Sebazzz]

Je mag ook "goto case 5" gebruiken als fall-through (expliciet dus).

[alex3305]

Avalaxy schreef op woensdag 06 juli 2011 @ 23:25:
[...]


Maar dan zit je weer met meerdere return statements binnen 1 method, wat ik dan weer een bad practice vind.

Vind ik persoonlijk good practice, maar niet altijd. Zelf gebruik ik het nogal eens bij boolean en void functies, waar het nodig is kan ik dan controleren op een bepaalde conditie, en de methode aan de hand daarvan beëindigen. Dat vind ik dan een stuk mooier dan ontzettend grote if-blokken of verwijzingen naar compleet andere functies - wat ik ook weleens zie langskomen.

[.oisyn]

Avalaxy schreef op woensdag 06 juli 2011 @ 23:25:
[...]


Maar dan zit je weer met meerdere return statements binnen 1 method, wat ik dan weer een bad practice vind.

Whatever rocks your boat. Ik vind het maar irritant dat mensen enorme omwegen nemen om maar 1 returnstatement te gebruiken, terwijl een opsomming van early-out condities met elk een eigen return statement een stuk leesbaarder is.

[BM]

.oisyn schreef op donderdag 07 juli 2011 @ 00:05:
[...]

Whatever rocks your boat. Ik vind het maar irritant dat mensen enorme omwegen nemen om maar 1 returnstatement te gebruiken, terwijl een opsomming van early-out condities met elk een eigen return statement een stuk leesbaarder is.

Heb een tijdje 'samengewerkt' met een ontwikkelaar die ook fel voorstander was van 1 return statement per methode, terwijl ik juist vooraan de methode al wat controles uitvoerde, en daar wel meerdere return statements had staan.
Heeft wat verhitte discussies opgeleverd, maar uiteindelijk heb ik maar toegegeven, en de code herschreven. Niet dat het er (imho) leesbaarder op werd, maar goed. Hij moest mijn code controleren, dus heb me maar aan zijn regeltjes gehouden

[alwinuzz]

Oh man dat doet me denken aan arrow code, dat doet zo'n pijn aan m'n ogen.
Hoe minder tabs hoe beter wmb, leest een stuk makkelijker.

Waar komt dat 'meerdere return statements is bad practice' eigenlijk vandaan? Als ik hier zo lees, komt het uit de COBOL/FORTRAN/C* tijd. Of in ieder geval uit de tijd dat elke functie z'n eigen rommel (allocations) moest opruimen. Dus je voorkeur kan ook afhangen van welke taal je programmeert?

Ik werk met een GC en using(), dus ik return lekker waar ik wil

[Jeldert]

Ook altijd handig met debuggen. Kan je tenminste een breakpoint zetten op de return waar hij niet zou moeten komen

[chime]

BM schreef op donderdag 07 juli 2011 @ 06:49:
[...]



Heb een tijdje 'samengewerkt' met een ontwikkelaar die ook fel voorstander was van 1 return statement per methode, terwijl ik juist vooraan de methode al wat controles uitvoerde, en daar wel meerdere return statements had staan.
Heeft wat verhitte discussies opgeleverd, maar uiteindelijk heb ik maar toegegeven, en de code herschreven. Niet dat het er (imho) leesbaarder op werd, maar goed. Hij moest mijn code controleren, dus heb me maar aan zijn regeltjes gehouden

Kans is groot dat je dan teveel verantwoordelijkheid in een methode steekt.
Best is dan om elke actie in die methode door een aparte kleine methode uit te voeren (refactoring dus)
Al is het maar om het geheel leesbaar te houden.

Natuurlijk mogen van mij die extra methodes hun waarde direct uit de hoofdmethode retourneren ... dat allemaal in 1 extra referentie steken om 1 exit point te hebben is gewoon ... idioot.

[BM]

chime schreef op donderdag 07 juli 2011 @ 08:41:
Natuurlijk mogen van mij die extra methodes hun waarde direct uit de hoofdmethode retourneren ... dat allemaal in 1 extra referentie steken om 1 exit point te hebben is gewoon ... idioot.

Ik daag je uit om die discussie aan te gaan met die collega die ik bedoelde Mij lukte het niet

[Matis]

BM schreef op donderdag 07 juli 2011 @ 08:47:
Ik daag je uit om die discussie aan te gaan met die collega die ik bedoelde Mij lukte het niet

Ik heb er ook zo eentje. Ik streef er naar om maar één return statement per functie te hebben.
Echter om onnodige nesting (of arrow code) tegen te gaan, zijn soms meerdere return values per functie echt noodzakelijk. Is het alleen al voor de leesbaarheid.

R# stelt het soms zelfs voor

[Zsub]

Maar die collega klinkt nogal als een zealot, daar is sowieso haast niet mee te discussiëren.

[Verwijderd]

alwinuzz schreef op donderdag 07 juli 2011 @ 08:11:
Oh man dat doet me denken aan arrow code, dat doet zo'n pijn aan m'n ogen.
Hoe minder tabs hoe beter wmb, leest een stuk makkelijker.

Waar komt dat 'meerdere return statements is bad practice' eigenlijk vandaan? Als ik hier zo lees, komt het uit de COBOL/FORTRAN/C* tijd. Of in ieder geval uit de tijd dat elke functie z'n eigen rommel (allocations) moest opruimen. Dus je voorkeur kan ook afhangen van welke taal je programmeert?

Ik werk met een GC en using(), dus ik return lekker waar ik wil

Heerlijk, die evangelisten. Het enige waar ik op hamer is consequent zijn, dan weet je tenminste wat je kan verwachten. Zo moet ik hier met een pakket werken waar er bij functies x,y, hoogte en breedte moet worden meegegeven. De ene functie doet x,y,breedte,hoogt, en de andere doet, y,x,hoogte, breedte. Of menig ander denkbare combinatie.

[PiepPiep]

alwinuzz schreef op donderdag 07 juli 2011 @ 08:11:
Ik werk met een GC en using(), dus ik return lekker waar ik wil

Of een combinatie daarvan!
Wel een taal die een GC maar niet using gebruiken en dan om zelf het geheugen te kunnen legen omdat er anders onverklaarbare dingen fout gaan zelf de GC.Collect() oid aanroepen.
Vervolgens is er een lusje die 1000 keer uitgevoerd wordt waarin die GC.Collect() aangeroepen wordt en verbaast zijn dat de boel zo langzaam wordt.

[.oisyn]

alwinuzz schreef op donderdag 07 juli 2011 @ 08:11:
Waar komt dat 'meerdere return statements is bad practice' eigenlijk vandaan? Als ik hier zo lees, komt het uit de COBOL/FORTRAN/C* tijd.

Was er ook niet een link met bewijsbaarheid van code? Al lijkt me dat niet zo heel veel uit te maken, nu ik er zo over nadenk. De code is natuurlijk vrij makkelijk te transformeren van het ene paradigma naar het andere.

Anyway, code complete zegt (als ik een post op het internet moet geloven, ik heb het boek (nog) niet )

17.1 return

Minimize the number of returns in each routine. It's harder to understand a routine if, reading it at the bottom, you're unaware of the possibility that it *return*ed somewhere above.

Use a return when it enhances readability. In certain routines, once you know the answer, you want to return it to the calling routine immediately. If the routine is defined in such a way that it doesn't require any cleanup, not returning immediately means that you have to write more code.

Ik ben het er mee eens dat je moet oppassen met verstopte returns. De eerste alinea van code complete vind ik een beetje onzin though, waarom zou je code moeten kunnen begrijpen als je alleen naar de onderste paar regels van een functie kijkt

[ Voor 45% gewijzigd door .oisyn op 07-07-2011 11:24 ]

[Janoz]

Het 'probleem' bij meerdere return statements is dat je in 1 oogopslag niet precies kunt zien waar je uit de functie gaat, maar eigenlijk heb je dan al een heel ander probleem. Als dat blijkbaar een probleem wordt zijn je functies sowieso al te groot. Daarnaast, als ik in mijn ide met mijn cursor op de methodenaam sta dan worden alle mogelijke exitpunten gehighlight.

[Icekiller2k6]

dus voor fotran/cobol zouden we willen dat je

code:

$waarde = null
if..() waarde=1

if() waarde=2


return $waarde

doet?

[PrisonerOfPain]

.oisyn schreef op donderdag 07 juli 2011 @ 11:19:
Anyway, code complete zegt (als ik een post op het internet moet geloven, ik heb het boek (nog) niet )

Mocht je het een keer willen lenen moet je maar een gil geven zodra ik weer in Nederland ben (begin september). Ik heb d'r zelf niet zo'n hoge dunk van, maar soit.

[Armageddon_2k]

Mwa, ik ben het er mee eens dat je niet een overdaad aan Return statements moet hebben.
Maar wat is jullie mening over het preventief stoppen van een functie? (iets wat ik veel gebruik)


Bijvoorbeeld het volgende, je zou prima een if statement over je complete functie kunnen gooien, maar dan krijg je arrow programming.

Visual Basic .NET:

'Deze functie shuffelt bijvoorbeeld alle characters na character 20 in een string.
Private Function EndPartShuffle(ByVal Text as String) Boolean

   'Preventief stoppen als de functie nutteloos is
   If Text.Length() < 20 Then Return False

   'Functie volgt hier
   '... 

End Function

Edit:
Na CodeCaster zn blogje even gelzen te hebben, heeft het vanaf nu de naam: FailFast

[ Voor 7% gewijzigd door Armageddon_2k op 07-07-2011 11:55 ]

[CodeCaster]

.oisyn schreef op donderdag 07 juli 2011 @ 11:19:
[...]

Was er ook niet een link met bewijsbaarheid van code? Al lijkt me dat niet zo heel veel uit te maken, nu ik er zo over nadenk. De code is natuurlijk vrij makkelijk te transformeren van het ene paradigma naar het andere.

Anyway, code complete zegt (als ik een post op het internet moet geloven, ik heb het boek (nog) niet )

[...]

Ik ben het er mee eens dat je moet oppassen met verstopte returns. De eerste alinea van code complete vind ik een beetje onzin though, waarom zou je code moeten kunnen begrijpen als je alleen naar de onderste paar regels van een functie kijkt

Dat hele principe stamt toch uit de tijd van dinosauriërs? Dankzij exceptions is vrijwel ieder commando (maar voornamelijk toch externe functieaanroepen) binnen een functie een mogelijk exit point, omdat er een exception gegooid kan worden, en die wil je niet altijd afvangen op de plek waar 'ie gegooid kan worden.

Maar ja, ik had mijn mening hierover al eens geventileerd. CodeCaster: Codekwaliteit: Single Entry, Single Exit en methode-omvang

[PrisonerOfPain]

Overigens, de eerste die dit soort pietluttige dingen opbrengt bij een code-review kan van een stomp verwachtten. Er zijn ongeveer net zo veel argument voor als tegen en het komt dus vrijwel altijd aan op persoonlijke smaak.

[.oisyn]

Heel collegiaal . Is dat The DICE Method^TM?

[ Voor 49% gewijzigd door .oisyn op 07-07-2011 11:49 ]

[PrisonerOfPain]

.oisyn schreef op donderdag 07 juli 2011 @ 11:49:
Heel collegiaal . Is dat The DICE Method^TM?

Meh het is gewoon zonde van de tijd, geen van beidde gaat de discussie winnen, het verbetert de kwaliteit van de code niet, haalt er geen bugs uit (maar zou ze wel kunnen introduceren) en gaat compleet voorbij aan het nut van een code-review.

En hier komen geregeld stokslagen aan code-reviews te pas, ja

[MBV]

.oisyn schreef op donderdag 07 juli 2011 @ 11:19:
[...]

Was er ook niet een link met bewijsbaarheid van code? Al lijkt me dat niet zo heel veel uit te maken, nu ik er zo over nadenk. De code is natuurlijk vrij makkelijk te transformeren van het ene paradigma naar het andere.

Ja, unstructured cyclomatic complexity (Wikipedia: Essential complexity ) kan heel hoog worden van willekeurige return statements overal.

C++:

if (x)
{
  for (int i; i < max; i++)
  {
    if (y[ i ])
    {
      return true;
    }
  }
}
return false;

Dit kan je (omdat het een bekend patroon is) heel snel omschrijven naar een extra conditie in de for-loop, een bool found die op true wordt gezet in de 2e if, en return found. Maar eigenlijk is dit dus een functie met veel meer complexiteit die je op het eerste gezicht zou verwachten, teken maar eens een control-flow graph van deze code Dan is dit nog nette code, in feite is een return-statement hetzelfde als 'goto end'.

[Avalaxy]

PrisonerOfPain schreef op donderdag 07 juli 2011 @ 11:48:
Overigens, de eerste die dit soort pietluttige dingen opbrengt bij een code-review kan van een stomp verwachtten. Er zijn ongeveer net zo veel argument voor als tegen en het komt dus vrijwel altijd aan op persoonlijke smaak.

chime schreef op donderdag 07 juli 2011 @ 08:41:
[...]

Natuurlijk mogen van mij die extra methodes hun waarde direct uit de hoofdmethode retourneren ... dat allemaal in 1 extra referentie steken om 1 exit point te hebben is gewoon ... idioot.

Wat zijn jullie voor figuren zeg? Laat anderen in godsnaam hun eigen mening hebben alsjeblieft Een beetje meer respect mag wel hoor.

[418O2]

Elke programmeur weet het het beste, zijn manier is de juiste, elke andere programmeur is dom en doet het verkeerd.

Toch?

[ThaNOD]

Elke programmeur weet het het beste

Daar is dit topic toch ook voor, om te laten zien dat wij _wel_ weten hoe het moet

[ Voor 9% gewijzigd door ThaNOD op 07-07-2011 14:13 ]

[.oisyn]

MBV schreef op donderdag 07 juli 2011 @ 12:56:
[...]

Ja, unstructured cyclomatic complexity (Wikipedia: Essential complexity ) kan heel hoog worden van willekeurige return statements overal.

C++:

if (x)
{
  for (int i; i < max; i++)
  {
    if (y[ i ])
    {
      return true;
    }
  }
}
return false;

Die code is sowieso onbewijsbaar, je initialiseert i niet eens

Dit kan je (omdat het een bekend patroon is) heel snel omschrijven naar een extra conditie in de for-loop, een bool found die op true wordt gezet in de 2e if, en return found.

En dat maakt de functie dan ook niet minder complex imho. Je kunt elk stuk code met meerdere returns geautomatiseerd transformeren naar iets waar maar 1 return in staat.

[PrisonerOfPain]

Avalaxy schreef op donderdag 07 juli 2011 @ 14:10:
Wat zijn jullie voor figuren zeg? Laat anderen in godsnaam hun eigen mening hebben alsjeblieft Een beetje meer respect mag wel hoor.

Fijn dat mijn mening vervolgens afgedaan word als respectloos


_{Mocht het niet duidelijk zijn, ik ga mensen dus niet daadwerlijk met fysiek geweld te lijf}

[MBV]

@.oisyn: Met goto's ja
Het probleem met meerdere return-statements is IMHO ook niet dat het veel complexer is, maar dat die complexiteit 'verstopt' wordt. Zolang het goed is voor de leesbaarheid, en niet te veel raar goto-gedrag wordt veroorzaakt, is het IMHO prima om meerdere return-statements te gebruiken. Verkleint het risico op fouten alleen maar.

[.oisyn]

MBV schreef op donderdag 07 juli 2011 @ 14:48:
@.oisyn: Met goto's ja

Nee, met een conditie-variabele uiteraard

Het probleem met meerdere return-statements is IMHO ook niet dat het veel complexer is, maar dat die complexiteit 'verstopt' wordt.

En het probleem met dergelijke statements (die je na deze zin verder specificeert maar die ik nu expres niet quote ) is dat mensen denken "oeh, iemand heeft gezegd dat meerdere returns slecht zijn, laat ik alles op alles zetten om maar 1 return-statement in m'n functie te hebben" en daarbij de leesbaarheid totaal vernaggelen.

[ Voor 57% gewijzigd door .oisyn op 07-07-2011 14:57 ]

[Big Womly]

MBV schreef op donderdag 07 juli 2011 @ 14:48:
@.oisyn: Met goto's ja
Het probleem met meerdere return-statements is IMHO ook niet dat het veel complexer is, maar dat die complexiteit 'verstopt' wordt. Zolang het goed is voor de leesbaarheid, en niet te veel raar goto-gedrag wordt veroorzaakt, is het IMHO prima om meerdere return-statements te gebruiken. Verkleint het risico op fouten alleen maar.

C++:

bool b=false;
for (int i=0;!b&&i<max;++i) {
  b|=y[i];
}
return x&&b;

1 return, 0 GOTO's

[PrisonerOfPain]

Big Womly schreef op donderdag 07 juli 2011 @ 15:02:
[...]

C++:

bool b=false;
for (int i=0;!b&&i<max;++i) {
  b|=y[i];
}
return x&&b;

1 return, 0 GOTO's

En al rap een stuk minder leesbaar.

[Verwijderd]

PrisonerOfPain schreef op donderdag 07 juli 2011 @ 15:04:
[...]


En al rap een stuk minder leesbaar.

En een stuk minder rapper. Of is de compiler zo slim om dit als een break op te vatten? Anders controleert hij de rest van de loop op die boolean... Ik zie het probleem niet van meerdere returns in een method.

Waar ligt trouwens de grens; mag een break in een loop ook niet? Oke, while(true) met een break ergens is lelijk, maar als ik deze theorie volg zou je dus nergens mogen breaken?!

[.oisyn]

Verwijderd schreef op donderdag 07 juli 2011 @ 15:10:
[...]

En een stuk minder rapper. Of is de compiler zo slim om dit als een break op te vatten?

Over het algemeen wel.

Big Womly schreef op donderdag 07 juli 2011 @ 15:02:
[...]

C++:

bool b=false;
for (int i=0;!b&&i<max;++i) {
  b|=y[i];
}
return x&&b;

1 return, 0 GOTO's

Je code doet niet hetzelfde.

[PrisonerOfPain]

Verwijderd schreef op donderdag 07 juli 2011 @ 15:10:
Waar ligt trouwens de grens; mag een break in een loop ook niet? Oke, while(true) met een break ergens is lelijk, maar als ik deze theorie volg zou je dus nergens mogen breaken?!

Zolang het compiled en werkt mag wat mij betreft alles; zeker als je naar code op een dergelijke manier kijkt (eg. codeflow). Design wise heb ik wat meer regeltjes maar die varieren per taal, toepassing en platform.

[efan]

in plaats van de code achter de 'else' te zetten, maar nee.. eerst de variable (ContinueOpening) op true en dan vervolgens if (true) ... ook weer lekker vaag

code:

 PreviousOpenOrders=OpenOrders;
   
      if (OpenOrders>=MaxTrades) {ContinueOpening=False;}
      else {ContinueOpening=True;}
 
      if (LastPrice==0) {
         for(cnt=0;cnt<OrdersTotal();cnt++) { 
            OrderSelect(cnt, SELECT_BY_POS, MODE_TRADES);
            mode=OrderType();
            if (OrderSymbol()==XSymbol && OrderMagicNumber() == MagicNo[Magic0]) {
               LastPrice=OrderOpenPrice();
               if (mode==OP_BUY) { myOrderType=OP_BUY; }
               if (mode==OP_SELL) { myOrderType=OP_SELL; }
            }
         }
      }
 
     if (true) { //OpenOrders<1) {
         myOrderType=99;
         //if (iMACD(14,26,9,MODE_MAIN,0)>0 and iMACD(14,26,9,MODE_MAIN,0)>iMACD(14,26,9,MODE_MAIN,1)) then OrderType=2;
          //if (iMACD(14,26,9,MODE_MAIN,0)<0 and iMACD(14,26,9,MODE_MAIN,0)<iMACD(14,26,9,MODE_MAIN,1)) then OrderType=1;
          //if (iMACD(NULL,0,14,26,9,PRICE_CLOSE,MODE_MAIN,0)>iMACD(NULL,0,14,26,9,PRICE_CLOSE,MODE_MAIN,1)) { myOrderType=2; }      
          //if (iMACD(NULL,0,14,26,9,PRICE_CLOSE,MODE_MAIN,0)<iMACD(NULL,0,14,26,9,PRICE_CLOSE,MODE_MAIN,1)) { myOrderType=1; }
 
         imacd1=iMACD(XSymbol,0,14,26,9,PRICE_CLOSE,MODE_MAIN,0);
         imacd2=iMACD(XSymbol,0,14,26,9,PRICE_CLOSE,MODE_MAIN,1);
//         imacd1=iMACD("EURUSD",0,14,26,9,PRICE_CLOSE,MODE_MAIN,0);
//         imacd2=iMACD("EURUSD",0,14,26,9,PRICE_CLOSE,MODE_MAIN,1);
         if (imacd1>imacd2 && Bside) { myOrderType=OP_BUY; }
         if (imacd1<imacd2 && Sside) { myOrderType=OP_SELL; }
             
         if (ReverseCondition==1) {
            if (myOrderType==OP_SELL) { myOrderType=OP_BUY; }
            else { if (myOrderType==OP_BUY) { myOrderType=OP_SELL; } }
         }
      }

p.s. code is trouwens MQL4 voor metatrader

[PiepPiep]

Big Womly schreef op donderdag 07 juli 2011 @ 15:02:
[...]

C++:

bool b=false;
for (int i=0;!b&&i<max;++i) {
  b|=y[i];
}
return x&&b;

1 return, 0 GOTO's

En aangezien dit topic over slechte code gaat zou het zomaar eens kunnen dat y een object is waarbij je een functie aanroept als je via [] iets uitleest en die functie veel meer doet dan hij eigenlijk mag en dus nadat y[i] een true terug geeft hij gewoon doorgaat met 'iets' doen wat je niet door hebt

Oh wacht, C++, dan weet ik niet of dat ook echt kan.
Ik weet wel dat in C# een get of set veeeeel meer kan doen dan alleen de waarde getten of setten.

[ Voor 12% gewijzigd door PiepPiep op 07-07-2011 15:50 ]

[PrisonerOfPain]

PiepPiep schreef op donderdag 07 juli 2011 @ 15:49:
Oh wacht, C++, dan weet ik niet of dat ook echt kan.

Je kunt operator[] gewoon overloaden om te doen wat je wilt.

[.oisyn]

PiepPiep schreef op donderdag 07 juli 2011 @ 15:49:
Ik weet wel dat in C# een get of set veeeeel meer kan doen dan alleen de waarde getten of setten.

Klopt, maar waarom is dat relevant? Dezelfde issue zou je ook hebben met de code van MBV. Desalniettemin, er zit een fout in waardoor het niet hetzelfde werkt zoals de code van MBV.

[PrisonerOfPain]

.oisyn schreef op donderdag 07 juli 2011 @ 16:05:
[...]

Klopt, maar waarom is dat relevant? Dezelfde issue zou je ook hebben met de code van MBV. Desalniettemin, er zit een fout in waardoor het niet hetzelfde werkt zoals de code van MBV.

Omdat 'ie minder vaak word aangeroepen door een foute loop conditie?

[.oisyn]

Daar zie ik niets fouts aan. Wel aan dat hij 'x' niet checkt alvorens de array af te lopen. Misschien is 'y' wel ongeldig als 'x' false is.

[PrisonerOfPain]

Wat ik je brom, minder leesbaar.

[PietrKempy]

Nou dat goede code of slechte code heel subjectief is heb ik gisteren toch ook wel gemerkt en dan nog op een heel laag niveau (1e bachelor ind. ir. informatica). Had voor mijn informatica examen een 13 gehad waarvan de helft op programmeren stond en vond dat nogal heel weinig dus ik maar eens gaan controleren. Dingen waarvoor ik punten verloren ben:

C++:

const int CONSTANTE = 1; // overvloedig gebruik van hoofdletters

int variabele1 = 0;
int variabele2 = 0; // variabelen  op 0 zetten is niet goed voor de leesbaarheid

if (waar == true){
 // 1 lijntje met iets doen
} // { } niet nodig bij slechts 1 lijntje code na if

Nu is het vreselijke dat de lector die mij de labo's gaf voor het vak juist hamerde op dingen zoals dit en dat we dat zeker altijd zo moesten doen. (constante altijd met een hoofdleter, variabele altijd een waarde meegeven als je ze declareert, code na een if / for / else / ... altijd openen en eindigen ookal is het maar 1 lijntje). En dat dan een andere lector je examen verbeterd en er punten voor aftrekt. Gelukkig maakte het voor mij niet veel uit, maar ik kon er moeilijk over discussieren met de persoon die mijn code controleerde. Natuurlijk ben ik ook niet veel punten verloren hiervoor maar maakte wel het verschil tussen een 14 en een 13.

[Avalaxy]

Hmm, variabelen initialiseren... ReSharper geeft er juist altijd een opmerking over dat de waarde weg moet/kan (en andersom ook een waarschuwing als je een variabele wilt gebruiken die nog geen waarde heeft).

[alex3305]

@Avalaxy, nu moet je wel nagaan dat het bij ReSharper (voor C# ) over een heel ander soort taal gaat dan C++, waarbij zaken als garbage collectie niet standaard ingebakken zitten.

Verder vind ik de commentaar hebben op de code van PietrKempy maar mierenneuken. Of je nu wel of niet extra accolades gebruikt is over het algemeen helemaal niet relevant IMHO. Als je het maar consequent doet.

[BM]

Avalaxy schreef op vrijdag 08 juli 2011 @ 01:44:
Hmm, variabelen initialiseren... ReSharper geeft er juist altijd een opmerking over dat de waarde weg moet/kan (en andersom ook een waarschuwing als je een variabele wilt gebruiken die nog geen waarde heeft).

Ik vind het vaak maar geneuzel. Waarschuwen als een variabele nog geen waarde heeft, prima. Maar vaak vind ik het persoonlijk wel leesbaarder als een varaiabele vooraf een waarde toegewezen krijgt, ook al is dat toevallig de standaardwaarde voor dat type variabele.

Zal wel weer stukje persoonlijke voorkeur zijn

[Dragor]

PietrKempy schreef op vrijdag 08 juli 2011 @ 01:22:
*knip*

Nu is het vreselijke dat de lector die mij de labo's gaf voor het vak juist hamerde op dingen zoals dit en dat we dat zeker altijd zo moesten doen. (constante altijd met een hoofdleter, variabele altijd een waarde meegeven als je ze declareert, code na een if / for / else / ... altijd openen en eindigen ookal is het maar 1 lijntje). En dat dan een andere lector je examen verbeterd en er punten voor aftrekt. Gelukkig maakte het voor mij niet veel uit, maar ik kon er moeilijk over discussieren met de persoon die mijn code controleerde. Natuurlijk ben ik ook niet veel punten verloren hiervoor maar maakte wel het verschil tussen een 14 en een 13.

Ik hoop voor je dat je dat gaat aankaarten bij die docenten. Als de ene docent je iets leert, moet de andere docent je daar natuurlijk niet voor gaan straffen.

offtopic:
Hoezo wordt er punten gegeven in de vorm van 13 of 14? Bij mij was het altijd 1 t/m 10 (met uitzondering van excentrieke leraren die ook ooit eens een 11 konden geven )

[Matis]

BM schreef op vrijdag 08 juli 2011 @ 07:00:
Ik vind het vaak maar geneuzel. Waarschuwen als een variabele nog geen waarde heeft, prima. Maar vaak vind ik het persoonlijk wel leesbaarder als een varaiabele vooraf een waarde toegewezen krijgt, ook al is dat toevallig de standaardwaarde voor dat type variabele.

Zal wel weer stukje persoonlijke voorkeur zijn

Dat geniet ook mijn voorkeur. In mijn tijd als VHDL-ontwikkelaar MOEST je een variabele instantieren, omdat het design anders niet wist welke van de 9 (of 3) waardes hij moest zijn

Daarnaast vind ik het ontzettend irritant dat R# (of misschien wel VS2010) in if(variabele == true) de " == true" grijs maakt, omdat het een onnodige check is.
Dat snap ik ook wel, maar ik doe dat ook voor de leesbaarheid. Net als " == false" ook met een ! aan de voorkant moet, wat nog veel minder leesbaar is

[ Voor 18% gewijzigd door Matis op 08-07-2011 08:05 ]

[MTWZZ]

Matis schreef op vrijdag 08 juli 2011 @ 08:04:
[...]

Dat geniet ook mijn voorkeur. In mijn tijd als VHDL-ontwikkelaar MOEST je een variabele instantieren, omdat het design anders niet wist welke van de 9 (of 3) waardes hij moest zijn

'-' Don't care

raap me op

[YopY]

PietrKempy schreef op vrijdag 08 juli 2011 @ 01:22:
Nou dat goede code of slechte code heel subjectief is heb ik gisteren toch ook wel gemerkt en dan nog op een heel laag niveau (1e bachelor ind. ir. informatica). Had voor mijn informatica examen een 13 gehad waarvan de helft op programmeren stond en vond dat nogal heel weinig dus ik maar eens gaan controleren. Dingen waarvoor ik punten verloren ben:

Wat een geneuzel, . Voor een examen moeten de code conventies opgeschreven worden, en ook dan zou je geen puntenaftrek moeten krijgen voor zaken (zoals deze) die volledig persoonlijke voorkeur zijn (en die ook nog eens tegenstrijdig met de 'gangbare' voorkeuren zijn).

[.oisyn]

Matis schreef op vrijdag 08 juli 2011 @ 08:04:
Daarnaast vind ik het ontzettend irritant dat R# (of misschien wel VS2010) in if(variabele == true) de " == true" grijs maakt, omdat het een onnodige check is.
Dat snap ik ook wel, maar ik doe dat ook voor de leesbaarheid. Net als " == false" ook met een ! aan de voorkant moet, wat nog veel minder leesbaar is

Dit vind ik eigenlijk maar een rare redenatie. Als je vind dat het if(a == true) is, waarom vindt je dan niet dat het if((a == true) == true) zou moeten zijn? En het resultaat daarvan is ook weer een boolean, dus moet je die ook weer vergelijken met true. Ad infinitum.

Of is het meer omdat jij gewoon altijd een vergelijking verwacht, ipv gewoon een algemene boolean expressie?

[Caelorum]

.oisyn schreef op vrijdag 08 juli 2011 @ 10:59:
[...]
Of is het meer omdat jij gewoon altijd een vergelijking verwacht, ipv gewoon een algemene boolean expressie?

Mja je weet iig zeker dat het geen fout is en dat de dev dus neit gewoon vergeten is om een ! ervoor te zetten. True schrijven ipv false is iig meer werk dan een ! wel of niet
Ook ik probeer zoveel mogelijk == true of == false neer te zetten wanneer er geen vergelijking staat.

[.oisyn]

True schrijven ipv false is iig meer werk dan een ! wel of niet

Waarom? Omdat je hele andere tekens in moet typen? Ik denk dat je wat te kort door de bocht redeneert, het hangt nogal af van de psychologische achtergrond waarom je het fout doet. Het zal denk ik in de minste gevallen zo zijn dat je simpelweg een ! vergeten bent, maar meer dat je een logische denkfout maakt (en daardoor dus ook true zal typen ipv false)

[PiepPiep]

Als je kijkt naar hoeveel tik werk iets is als je aan het programmeren bent ben je imho fout bezig.

[Caelorum]

.oisyn schreef op vrijdag 08 juli 2011 @ 11:17:
[...]

Waarom? Omdat je hele andere tekens in moet typen? Ik denk dat je wat te kort door de bocht redeneert, het hangt nogal af van de psychologische achtergrond waarom je het fout doet. Het zal denk ik in de minste gevallen zo zijn dat je simpelweg een ! vergeten bent, maar meer dat je een logische denkfout maakt (en daardoor dus ook true zal typen ipv false)

Dat klopt, maar als ik mijn eigen code of die van anderen doorlees valt een == true die verkeerd is sneller op dan het wel of niet aanwezig zijn van een !, maar wellicht dat anderen daar minder problemen mee hebben ^^

[.oisyn]

Dat is weer een hele andere stelling, waar we het over hadden was hoe snel je een vergissing maakt en of dat met ! anders is dan voor == false

Kwa leesbaarheid, ik heb er zelf niet zo heel veel problemen mee moet ik zeggen. Waar je denk ik wel mee op moet passen is de eventuele conclusie "oh, hij heeft == true getikt, dus het zal wel kloppen" terwijl je anders denkt "hmm misschien is ie een ! vergeten?"

Maar goed, zoals altijd geldt, zorg dat je de namen van je conditievariabelen en functies de lading dekken en add eventueel commentaar waarom de check gedaan wordt en je het gedeelte in de if uitvoert. Dan is een foute conditie ook makkelijk te spotten.

[ Voor 4% gewijzigd door .oisyn op 08-07-2011 12:16 ]

[Caelorum]

.oisyn schreef op vrijdag 08 juli 2011 @ 12:15:
Dat is weer een hele andere stelling, waar we het over hadden was hoe snel je een vergissing maakt en of dat met ! anders is dan voor == false

Mja bij mij is dat min of meer hetzelfde. Soms zit ik een uur lang te coden en denk ik niet meer na. Als ik dan koffie heb gehaald en ik lees mijn eigen code dan spot ik de fouten sneller op deze manier