[alg] Slechtste programmeervoorbeelden deel 4

[.oisyn]

Waster schreef op zaterdag 12 januari 2013 @ 02:20:
En wat is er mis met altijd braces op dezelfde regel.

Wie zegt dan dat er wat mis mee is? Persoonlijke voorkeur, meer niet.

[Verwijderd]

Er is sowieso niks mis met

code:

if(...) 
  doeIets();

if(...)
{
   doeIets();
}

if(...) {
   doeIets();
}

Het is gewoon wat je als programmeur fijn vindt of binnen je bedrijf als regels geldt (indien zulke regels er binnen je bedrijf zijn). Zolang je maar consequent bent.

Ik gebruik braces pas wanneer deze strikt noodzakelijk zijn. Zelfde geldt trouwens ook voor if-statements

code:

a = b ? 1 : 0;

[ Voor 25% gewijzigd door Verwijderd op 12-01-2013 08:47 ]

[Carharttguy]

code:

a = b ? 1 : 0;

Persoonlijn vind ik die syntax echt niet zo mooi, gewoon omdat ze niet overeenstemd met al het andere, overal worden {} gebruikt, behalve bij zo'n rare if statement.

[RedHat]

Carharttguy schreef op zondag 13 januari 2013 @ 14:13:
[...]


Persoonlijn vind ik die syntax echt niet zo mooi, gewoon omdat ze niet overeenstemd met al het andere, overal worden {} gebruikt, behalve bij zo'n rare if statement.

En vaak als het wat complexer wordt vind ik het ook maar moeilijk leesbaar. Moet er altijd toch even iets bij nadenken als ik over code heenlees.

[.oisyn]

Dit is geen statement maar een expressie. Wat ook precies de reden is waarom je geen braces kan gebruiken. In C++ (waar hij vandaan komt) is die operator op sommige plekken gewoon noodzakelijk, een if kan dan niet omdat er juist een expression nodig is.

[Zoijar]

Met als grote voorbeeld nu C++11 constant expressions, e.g.:

C++:

constexpr int abs(int x) {
   return x < 0 ? -x : x;
}

Waar een if-statement niet mag.

[Carharttguy]

Zoijar schreef op zondag 13 januari 2013 @ 14:40:
Met als grote voorbeeld nu C++11 constant expressions, e.g.:

C++:

constexpr int abs(int x) {
   return x < 0 ? -x : x;
}

Waar een if-statement niet mag.

Thanks voor het voorbeeld! Hoewel ik (ik ben geen C++ programmeur) nog niet helemaal snap welk voordeel een constexpr dan zou hebben buiten en normale functie. Het lijkt alsof deze functie een constante zou moeten returnen (zoals ik een voorbeeld op stackoverflow vond in de zin van 'MeaningOfLife = 42', maar in jouw voorbeeld returned hij niet altijd dezelfde waarde, maar een absolute waarde. Dus dat lijkt me de naam 'constexpr' een beetje tegen te spreken?

[Herko_ter_Horst]

Verwijderd schreef op zaterdag 12 januari 2013 @ 08:45:
Er is sowieso niks mis met

code:

if(...) 
  doeIets();

if(...)
{
   doeIets();
}

if(...) {
   doeIets();
}

Het is gewoon wat je als programmeur fijn vindt of binnen je bedrijf als regels geldt (indien zulke regels er binnen je bedrijf zijn). Zolang je maar consequent bent.

Maar dat is nu juist het probleem met variant 1: daarmee kun je niet consequent zijn, want bij meer dan 1 regel binnen de scope van de if, moet je braces gebruiken. Dan krijg je dus sowieso twee stijlen door elkaar.

[Phyxion]

Herko_ter_Horst schreef op zondag 13 januari 2013 @ 16:16:
[...]

Maar dat is nu juist het probleem met variant 1: daarmee kun je niet consequent zijn, want bij meer dan 1 regel binnen de scope van de if, moet je braces gebruiken. Dan krijg je dus sowieso twee stijlen door elkaar.

Consequentie heeft daar niks mee te maken, consequent is dat je altijd hetzelfde doet, dat kan prima dit zijn:

C#:

if (a)
    b();

if (a)
{
    b();
    c();
}

[Firesphere]

Consequent in je methode is het netste. Zorgt ook voor betere leesbaarheid voor collega's.

Tenminste, dat vind ik. De short-code methodes etc. kan ik heel slecht over. Hoe consistenter je code-methode is, hoe beter. Consistent != consequent trouwens

[.oisyn]

Carharttguy schreef op zondag 13 januari 2013 @ 15:36:
[...]


Thanks voor het voorbeeld! Hoewel ik (ik ben geen C++ programmeur) nog niet helemaal snap welk voordeel een constexpr dan zou hebben buiten en normale functie. Het lijkt alsof deze functie een constante zou moeten returnen (zoals ik een voorbeeld op stackoverflow vond in de zin van 'MeaningOfLife = 42', maar in jouw voorbeeld returned hij niet altijd dezelfde waarde, maar een absolute waarde. Dus dat lijkt me de naam 'constexpr' een beetje tegen te spreken?

Een constexpr functie kun je in een constant expression gebruiken. Het gaat er niet om dat ze een constante retourneren, het gaat erom dat de compiler at compile-time kan bepalen wat de output is gegeven een bepaalde (constant expression) input.

Constant expressions zijn in C++ nodig voor static array sizes en template non-type parameters. Met bovenstaande code is abs(5) ook gewoon bruikbaar in een constant expression

[Zoijar]

Carharttguy schreef op zondag 13 januari 2013 @ 15:36:
Thanks voor het voorbeeld! Hoewel ik (ik ben geen C++ programmeur) nog niet helemaal snap welk voordeel een constexpr dan zou hebben buiten en normale functie. Het lijkt alsof deze functie een constante zou moeten returnen (zoals ik een voorbeeld op stackoverflow vond in de zin van 'MeaningOfLife = 42', maar in jouw voorbeeld returned hij niet altijd dezelfde waarde, maar een absolute waarde. Dus dat lijkt me de naam 'constexpr' een beetje tegen te spreken?

Een constexpr is iets dat compile-time bepaald kan worden. Als ik hierna type abs(-42) staat het vast dat die expressie gelijk is aan 42. Dat kan niet runtime ineens veranderen. Je compiler kan dus overal waar abs(-42) staat het evalueren en vervangen door de constante 42. Zo kan je ook bijvoorbeeld een constexpr voor een faculteit functie maken, net als met template meta programming altijd al kon maar dan makkelijker en duidelijker.

[bwerg]

C:

for (i = 0; i++; i < N)
for (j = 0; j++; j < M)
{
    // doe iets in een 2D-array of zo
}

Oei, ik heb de tweede for-loop niet ingesprongen. Ben ik nu een ketter?

Maar het is sowieso mooier dan elke andere variant. Mits er in de buitenste for-loop niets anders gebeurt, natuurlijk.

[.oisyn]

Mijn regel:

C:

for (i = 0; i++; i < N) 
    for (j = 0; j++; j < M) 
        // zo

for (i = 0; i++; i < N) 
{
    for (j = 0; j++; j < M) 
    {
        // of zo
    }
}

for (i = 0; i++; i < N) 
    for (j = 0; j++; j < M) 
    {
        // maar niet zo
    }


for (i = 0; i++; i < N) 
for (j = 0; j++; j < M) 
{
    // laat staan zo
}

[F.West98]

code:

if (bla) {
    ..
} else {
    ...
}

en

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

[Olaf van der Spek]

ValHallASW schreef op vrijdag 11 januari 2013 @ 16:41:
[...]

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

Astyle vond BOOST_FOREACH macros niet zo fijn. Wie gebruikt astyle echt?

Carharttguy schreef op zondag 13 januari 2013 @ 14:13:
[...]


Persoonlijn vind ik die syntax echt niet zo mooi, gewoon omdat ze niet overeenstemd met al het andere, overal worden {} gebruikt, behalve bij zo'n rare if statement.

Dan gok ik dat je nog niet zoveel ervaring hebt.
De conditional operator kan erg handig zijn, mits juist gebruikt.

[ Voor 42% gewijzigd door Olaf van der Spek op 14-01-2013 00:11 ]

[bwerg]

.oisyn schreef op zondag 13 januari 2013 @ 22:53:

C:

for (i = 0; i++; i < N) 
{
    for (j = 0; j++; j < M) 
    {
        // of zo
    }
}

...

for (i = 0; i++; i < N) 
for (j = 0; j++; j < M) 
{
    // laat staan zo
}

Normaal hou ik me ook wel aan de inspringen-bij-accolades-conventies. Maar bij een dubbel for-loopje waarbij twee variabelen volledig dezelfde rol hebben vindt ik accolades (en extra inspringen) voor de buitenste loop vrij zinloos, lelijk en ruimteverspillend. De regels zijn er om het overzichtelijker te maken, als ze dat niet doen dan hoef je ze niet te hanteren.

Of ben ik echt de enige op de hele wereld en vindt iedereen dit lelijk en onoverzichtelijk?

[.oisyn]

Het is natuurlijk maar net wat je gewend bent, maar als ik die code zo vluchtig bekijk dan verwacht ik een enkele loop, geen geneste loop. En als ik die 2 FORs dan zie dan denk ik in eerste instantie aan een source control merge fout.

[Not Pingu]

deadinspace schreef op vrijdag 11 januari 2013 @ 19:14:
@ de eeuwige brace-discussie: ik doe het graag zo:

C:

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

    var1 = bar3();
}

In mijn ervaring zijn shortcuts als de single-line notatie, en zeker de implicit-else notatie vragen om problemen. Niet alleen komt het te vaak voor dat je toch een extra regel toevoegt waardoor je weer wel braces nodig hebt, bij de ijverige copy-pasters leidt het tot fouten.

Neem bijv deze die ik laatst tegen kwam:

C#:

public string MyValue
{
    get
    {
        if (!string.IsNullOrWhiteSpace(this.myValue))
        {
            return this.myValue;
        }

        return null;
    }

    set
    {
        if (!string.IsNullOrWhiteSpace(value))
        {
            this.myValue = value;
        }

        this.myValue = null;
    }
}

[.oisyn]

Not Pingu schreef op maandag 14 januari 2013 @ 16:17:
Neem bijv deze die ik laatst tegen kwam:

Euh, wat moeten we daar aan zien

In mijn ervaring zijn shortcuts als de single-line notatie, en zeker de implicit-else notatie vragen om problemen

En in mijn ervaring, die gebaseerd is op 'openings brace op nieuwe regel', ben ik het zoals gezegd nog nooit tegengekomen.

[ Voor 40% gewijzigd door .oisyn op 14-01-2013 16:22 ]

[Haan]

.oisyn schreef op maandag 14 januari 2013 @ 16:21:
[...]

Euh, wat moeten we daar aan zien

Kijk eens goed naar de set

[ Voor 27% gewijzigd door Haan op 14-01-2013 16:23 ]

[Dido]

.oisyn schreef op maandag 14 januari 2013 @ 16:21:
Euh, wat moeten we daar aan zien

Die setter heeft een paar regels overbodige code

Een goed voorbeeld van "het ziet er hetzelfde uit dus zal het ook wel werken"

[ Voor 17% gewijzigd door Dido op 14-01-2013 16:24 ]

[Olaf van der Spek]

Dido schreef op maandag 14 januari 2013 @ 16:24:
Die setter heeft een paar regels overbodige code

Nee, er mist een else. Get moet waarschijnlijk gewoon { return this.myValue } zijn.

.oisyn schreef op maandag 14 januari 2013 @ 16:21:
En in mijn ervaring, die gebaseerd is op 'openings brace op nieuwe regel', ben ik het zoals gezegd nog nooit tegengekomen.

Het nadeel daarvan is dat de code meer regels nodig heeft. Daardoor is het globale overzicht waarschijnlijk iets minder. Zelf zet ik braces ook op een nieuwe regel, maar ik gebruik geen braces voor single-line/statement 'blocks'.

[ Voor 62% gewijzigd door Olaf van der Spek op 14-01-2013 16:44 ]

[Dido]

Olaf van der Spek schreef op maandag 14 januari 2013 @ 16:39:
Nee, er mist een else. Get moet waarschijnlijk gewoon { return this.myValue } zijn.

Als je er ooit een waarde in wilt zetten wel ja

Maar je kunt vier regels code verwijderen zonder de huidige "functionaliteit" aan te passen. Die regels zijn dus overbodig.

Ik heb nooit gezegd dat die setter dan wat nuttigs deed

[YopY]

mbt codestyle, consistentie is idd koning; niet zozeer vanwege potentiele bugs bij het ontbreken van braces, maar - tenminste bij mij persoonlijk - vanwege 'flow'. Als de code er hetzelfde uitziet is alles ok, maar zodra ik ergens

code:

if(cond){

zie, springt mijn linkerwenkbrauw omhoog (de 'standaard' is om een spatie tussen if en (, en ) en { te doen). Kleine inconsistenties, en ik klink waarschijnlijk als een miereneuker nu, springen uit de code. Net zoals verkeerde indentatie in html, .

[Haan]

YopY schreef op maandag 14 januari 2013 @ 16:51:
mbt codestyle, consistentie is idd koning; niet zozeer vanwege potentiele bugs bij het ontbreken van braces, maar - tenminste bij mij persoonlijk - vanwege 'flow'. Als de code er hetzelfde uitziet is alles ok, maar zodra ik ergens

code:

if(cond){

zie, springt mijn linkerwenkbrauw omhoog (de 'standaard' is om een spatie tussen if en (, en ) en { te doen). Kleine inconsistenties, en ik klink waarschijnlijk als een miereneuker nu, springen uit de code. Net zoals verkeerde indentatie in html, .

In Visual Studio heb je daar de heerlijke combinate CTRL+K, CTRL+D voor, dat doet een auto-format, waar dingen als spaties en indentations mee gefixt worden

[Soultaker]

Not Pingu schreef op maandag 14 januari 2013 @ 16:17:
Neem bijv deze die ik laatst tegen kwam: [..]

Om twee discussies aan elkaar te knopen: dit lijkt me dus ook een goede situatie om gewoon een ternaire operator te gebruiken, aangezien je precies één waarde wil returnen (in de getter) of assignen (in de setter). De control flow is in de huidige situatie alleen maar verwarrend.

(Verder vind ik het stom dat in de getter IsNullOrWhiteSpace() gebruikt wordt als de setter al garandeert dat die waarden naar null geconverteerd zijn. De getter kan dus prima return this.myValue doen. Of andersom natuurlijk.)

[Zoijar]

YopY schreef op maandag 14 januari 2013 @ 16:51:
mbt codestyle, consistentie is idd koning; niet zozeer vanwege potentiele bugs bij het ontbreken van braces, maar - tenminste bij mij persoonlijk - vanwege 'flow'. Als de code er hetzelfde uitziet is alles ok, maar zodra ik ergens

code:

if(cond){

zie, springt mijn linkerwenkbrauw omhoog (de 'standaard' is om een spatie tussen if en (, en ) en { te doen). Kleine inconsistenties, en ik klink waarschijnlijk als een miereneuker nu, springen uit de code. Net zoals verkeerde indentatie in html, .

Zo vind ik het altijd heel irritant als er een spatie na de ( en voor de ) staat, of na de functie naam, als in

C++:

void foo ( int x ) { }

[Haan]

Soultaker schreef op maandag 14 januari 2013 @ 17:00:
[...]

Om twee discussies aan elkaar te knopen: dit lijkt me dus ook een goede situatie om gewoon een ternaire operator te gebruiken, aangezien je precies één waarde wil returnen (in de getter) of assignen (in de setter). De control flow is in de huidige situatie alleen maar verwarrend.

(Verder vind ik het stom dat in de getter IsNullOrWhiteSpace() gebruikt wordt als de setter al garandeert dat die waarden naar null geconverteerd zijn. De getter kan dus prima return this.myValue doen. Of andersom natuurlijk.)

Tja het desbetreffende voorbeeld kan je eigenlijk gewoon herschrijven naar

C#:

public string MyValue {get; set; }

dat is misschien niet helemaal waar, als je in de setter wilt voorkomen dat null wordt geassigned.

[ Voor 7% gewijzigd door Haan op 14-01-2013 17:04 ]

[Soultaker]

Maar dan worden whitespace strings niet naar null gemapt, wat schijnbaar de bedoeling was. Da's niet helemaal hetzelfde.

Also, ik kan niet echt C#, maar kun je jouw code niet nog verder versimpelen naar:

C#:

public string MyValue;

... of gedraagt een member variable met getter/setters zich fundamenteel anders dan een gewone?

[.oisyn]

.edit: kan ik deze post mooi hergebruiken

Soultaker schreef op maandag 14 januari 2013 @ 17:06:
Also, ik kan niet echt C#, maar kun je jouw code niet nog verder versimpelen naar:

C#:

public string MyValue;

... of gedraagt een member variable met getter/setters zich fundamenteel anders dan een gewone?

Public member variables worden "frowned upon" in .Net. Ook kun je in bijv. WPF alleen databinding doen met properties, niet met variables.

[ Voor 204% gewijzigd door .oisyn op 14-01-2013 17:20 ]

[Dido]

mmmm... druk ik op quote, is het bericht leeg

[.oisyn]

Ja ik las verkeerd

Maar ik vind het nogal een arbitrair voorbeeld. Als je blind code gaat copy/pasten dan gaat het 9 van de 10 keer gewoon fout, of je jezelf nou indekt met allerlei 'else' cases of niet. Je bent returns aan het weghalen, dus de hele code flow wordt anders. Als je dat doet dan moet je enorm goed opletten waar je mee bezig bent, of de returns alsnog laten staan. Niet echt de point-in-case van het nooit gebruiken van "implicit else" imho.

[ Voor 9% gewijzigd door .oisyn op 14-01-2013 17:18 ]

[Dido]

Dat ben ik met je eens

Sowieso word ik niet goed van het copy/pasten zonder te begrijpen wat je doet.

Mijn code werd erg vaak ge-c/p'd, en ik zag precies of dat met of zonder begrip was gedaan.

[Verwijderd]

Ik copy/paste in principe niet. Als het kort genoeg is dan herschrijf ik het een 2e keer. Is het een uitgebreid stuk code wat ik vaker wil gebruiken maak ik er een functie/method van.

Een stuk beter te onderhouden ook.

[SPee]

Inderdaad.

Gebruik/kopieer je het vaak, dan is het gerechtvaardigd om zelfstandig te zijn.
Maar er dan een eigen methode/class/library van.
Zo hoef je eventuele bugs maar op 1 plek aan te passen.

Gebruik je het niet vaak, dan hoef je het ook niet te kopieren.

Waar ik zit heeft degene die ik vervang ook veelvuldig gekopieerd.
Maar ga je echt goed kijken, blijkt dat maar 1 klein deel wordt gebruikt. De rest is gewoon ruis, waardoor het voor mij moeilijker wordt om achter de werking van het programma te komen.

Ook leuk is als in een andere class de functienamen gelijk zijn, maar de werking niet.

[Magiciano]

Situatie A:
Test test = new Test();
test.Voorbeeld = "100";

Situatie B:
string x = "Voorbeeld";
Test test = new Test();
test.x = "100";

Welke tussenstap mis ik nog voor situatie B?

[Waster]

Magiciano schreef op maandag 14 januari 2013 @ 19:05:
Situatie A:
Test test = new Test();
test.Voorbeeld = "100";

Situatie B:
string x = "Voorbeeld";
Test test = new Test();
test.x = "100";

Welke tussenstap mis ik nog voor situatie B?

Is dat een serieuze vraag

[Soultaker]

Ik vermoed dat 'ie een indirectie-stap in gedachten had (test[x] = ... in plaats van test.x = .. in JavaScript, of bijvoorbeeld setattr() in Python).

[.oisyn]

Magiciano schreef op maandag 14 januari 2013 @ 19:05:
Welke tussenstap mis ik nog voor situatie B?

Een gedegen opleiding

[naaitsab]

Waster schreef op maandag 14 januari 2013 @ 19:30:
[...]

Is dat een serieuze vraag

.oisyn schreef op maandag 14 januari 2013 @ 20:29:
[...]


Een gedegen opleiding

In plaats van iemand de grond in trappen kan je ook proberen te helpen of post gewoon geen reactie...
We zijn immers allemaal ooit bij 0 begonnen

OT:
http://stackoverflow.com/...ds-using-names-in-c-sharp
Dit is denk ik wat je zoekt

[Magiciano]

naaitsab schreef op maandag 14 januari 2013 @ 21:30:
[...]


[...]

In plaats van iemand de grond in trappen kan je ook proberen te helpen of post gewoon geen reactie...
We zijn immers allemaal ooit bij 0 begonnen

OT:
http://stackoverflow.com/...ds-using-names-in-c-sharp
Dit is denk ik wat je zoekt

Daar kan ik wat mee, bedankt!

[RayNbow]

naaitsab schreef op maandag 14 januari 2013 @ 21:30:
[...]


[...]

In plaats van iemand de grond in trappen kan je ook proberen te helpen of post gewoon geen reactie...
We zijn immers allemaal ooit bij 0 begonnen

offtopic:
Maar aan de andere kant is dit geen helpdesktopic.

[Gomez12]

naaitsab schreef op maandag 14 januari 2013 @ 21:30:
[...]
In plaats van iemand de grond in trappen kan je ook proberen te helpen of post gewoon geen reactie...
We zijn immers allemaal ooit bij 0 begonnen

Tja, vragen stellen in het slechtste programmeervoorbeelden topic is wmb toch onder 0 hoor. Voor vragen is er een heel subforum ipv 1 topic...

[.oisyn]

naaitsab schreef op maandag 14 januari 2013 @ 21:30:
[...]


[...]

In plaats van iemand de grond in trappen kan je ook proberen te helpen of post gewoon geen reactie...

onschuldig grapje in een luchtig topic. Volgens mij ben jij degene die verkeerd zit .

[naaitsab]

RayNbow schreef op maandag 14 januari 2013 @ 22:07:
[...]

offtopic:
Maar aan de andere kant is dit geen helpdesktopic.

offtopic:
True, maar dan nog "je vraag staat hier verkeerd" klinkt altijd nog beter dan het spotten met "is dat een vraag?"

Gomez12 schreef op maandag 14 januari 2013 @ 22:08:
[...]

Tja, vragen stellen in het slechtste programmeervoorbeelden topic is wmb toch onder 0 hoor. Voor vragen is er een heel subforum ipv 1 topic...

offtopic:
Als je een 'kleine' vraag stelt krijg je weer die hele galore op je dak dat je vraag te klein is en weet ik het allemaal, kleine vragen horen niet in een los topic dat is waar maar ook niet in een bestaand verzamel topic, dus waar dan wel? We hebben allemaal wel eens kleine vraagjes waar je niet uitkomt dus simpelweg antwoorden met 'niet' is nogal kort door de bocht.

.oisyn schreef op maandag 14 januari 2013 @ 22:38:
[...]
onschuldig grapje in een luchtig topic. Volgens mij ben jij degene die verkeerd zit .

offtopic:
Als je mensen persoonlijk gaat beledigen met het niveau van hun opleiding maakt het niet uit in wat voor topic je zit, wellicht leuk bedoelt maar dat is makkelijk verkeerd te interpreteren

Enfin, de beste man heeft zijn antwoord daar ging het om.

[Zoijar]

Tsja, ik snap sowieso niet waarom er op got altijd meteen zo moeilijk gedaan moet worden en niemand ergens tegen kan... maar goed

[Jaap-Jan]

naaitsab schreef op maandag 14 januari 2013 @ 23:18:
(..)

Je gaat zelf ook wel heel kort door de bocht, vind je niet.

1) Dit is het "Slechtste programmeervoorbeelden"- topic.
2) Het voorbeeld bevat een grote beginnersfout.
3) Hij dumpt er een vraag die net zo goed sarcastisch kan worden opgevat.
4) De code hoeft niet van hem te zijn, kan net zo goed een collega zijn.

Met dat in het achterhoofd vind ik het nogal kort door de bocht dat je .oisyn beschuldigd dat hij de vraagsteller de grond in trapt wegens zijn vermeende gebrek aan opleiding...

[ Voor 66% gewijzigd door Jaap-Jan op 14-01-2013 23:54 ]

[Patriot]

Als je een 'kleine' vraag stelt krijg je weer die hele galore op je dak dat je vraag te klein is en weet ik het allemaal, kleine vragen horen niet in een los topic dat is waar maar ook niet in een bestaand verzamel topic, dus waar dan wel? We hebben allemaal wel eens kleine vraagjes waar je niet uitkomt dus simpelweg antwoorden met 'niet' is nogal kort door de bocht.

Een topic voor een kleine vraag is niet zo'n probleem, zolang die kleine vraag maar ondersteund wordt door een blijk van eigen inzet vóór het aanmaken van dat topic. PRG is wat dat betreft misschien streng, maar het is ook een forum dat het meeste risico loopt op schade door een vloedgolf van dat soort topics.

[.oisyn]

naaitsab schreef op maandag 14 januari 2013 @ 23:18:

offtopic:
Als je mensen persoonlijk gaat beledigen met het niveau van hun opleiding maakt het niet uit in wat voor topic je zit, wellicht leuk bedoelt maar dat is makkelijk verkeerd te interpreteren

Dus eerst zeg je dat ik mensen persoonlijk beledig (dat impliceert intentie), en daarna zeg je dat het open is voor interpretatie. Welke van de twee is het nou?

Enfin, de beste man heeft zijn antwoord daar ging het om.

Maar is ie er ook mee geholpen? Zijn vraag riekt naar variabele variabelen (vandaar ook mijn originele opmerking). Reflectie kent zeker zijn toepassing als het gaat om typen die je tijdens het schrijven van je code nog niet kent (ergo, vooral van toepassing op libraries), maar in vrijwel alle andere gevallen zijn er betere oplossingen zoals een goede class hierarchy met interfaces of dingen als delegates. Door hem te wijzen op reflectie zonder enige educatie van de do's en don'ts bestaat de mogelijkheid dat ie verkeerde dingen aanleert.

En vertel me eens, waar denk je dat hij later meer last van heeft: die ene onbedoelde belediging die een keer plaatsvond op een forum, of het feit dat hij in zijn begindagen verkeerde dingen aangeleerd heeft gekregen die weer afgeleerd moeten worden?

Eigenlijk is jouw "antwoord" dus nog onbeschofter dan die opmerking van mij

En @ Magiciano: mocht je je door mijn opleiding enigszins beledigd voelen, excuses, zo was het iig niet bedoeld

[ Voor 58% gewijzigd door .oisyn op 15-01-2013 01:00 ]

[Zoijar]

.oisyn schreef op dinsdag 15 januari 2013 @ 00:16:
En @ Magiciano: mocht je je door mijn opleiding enigszins beledigd voelen, excuses, zo was het iig niet bedoeld

lol

[lauwsa]

Nu we het toch over slecht hebben, China style:

code:

        if(a == b)
        {
    if(c == d)
    {
foo();
    }
        }

[naaitsab]

Laat ik er nog 1 ding over zeggen, ik vond het overduidelijk een vraag richting ons van ik kom hier niet uit jullie wel? getuige de laatste zin van zijn post. Daarom vond ik de daaropvolgende reacties nogal ongepast ook al waren ze grappig bedoelt.

[lauwsa]

Een serieuze vraag in een topic met als naam Slechtste programmeervoorbeelden, dat verwacht je toch niet? Zeker als je de OP leest: “Daarnaast is het niet de bedoeling dat je hier maar even snel een kort vraagje komt stellen. Als een vraag niet topicwaardig is, dan is hij wat dit forum betreft ook niet postwaardig.”.

Als je dan kijkt wat je hier in hoort te plaatsen: “Lachen om je eigen code, of over dingen die je "wel eens tegengekomen bent" is prima ”. Dan kan je toch echt wel denken dat die laatste zin sarcasme is.

Uiteindelijk lijkt het een echt vraag te zijn, dit kan er door komen doordat hier een vraag gesteld wordt wat eigenlijk niet hoort of dat iemand een vraag fout heeft opgevat. Kan toch gebeuren? Fouten zijn menselijk.

Maar het is nu toch opgelost, wat maakt het dan nog uit? Dit was echt geen opzet.

[Creepy]

lauwsa schreef op dinsdag 15 januari 2013 @ 12:36:
Maar het is nu toch opgelost, wat maakt het dan nog uit?

Dat dus, dus weer gewoon ontopic aub

[kenneth]

Zeg, mag Magiciano lekker zelf beslissen of het ongepast is en of hij gekwetst is?

Tevens vind ik antwoorden in de richting van Reflection ook ongepast maar dat mag Reflection ook lekker zelf beslissen.

Creepy

[ Voor 5% gewijzigd door kenneth op 15-01-2013 12:38 ]

[YellowOnline]

lauwsa schreef op dinsdag 15 januari 2013 @ 12:11:
Nu we het toch over slecht hebben, China style:

code:

        if(a == b)
        {
    if(c == d)
    {
foo();
    }
        }

Is dat nu een grap of zouden programmeurs die in een rechts-naar-links taal (Arabisch, Hebreeuws) werken soms echt zo programmeren?

[ Voor 3% gewijzigd door YellowOnline op 15-01-2013 12:39 ]

[R3veNG]

YellowOnline schreef op dinsdag 15 januari 2013 @ 12:38:
[...]


Is dat nu een grap of zouden programmeurs die in een rechts-naar-links taal (Arabisch, Hebreeuws) werken soms echt zo programmeren?

Dit moet wel een grap zijn, want hoe kan je op voorhand al weten hoe ver je eerste lijn naar rechts verplaatst moeten worden? Of je moet telkens je een if'je er bij knalt de hele code naar rechts verplaatsen. Bah.

[YellowOnline]

R3veNG schreef op dinsdag 15 januari 2013 @ 12:41:
[...]


Dit moet wel een grap zijn, want hoe kan je op voorhand al weten hoe ver je eerste lijn naar rechts verplaatst moeten worden? Of je moet telkens je een if'je er bij knalt de hele code naar rechts verplaatsen. Bah.

Een TAB is snel gedaan!

[joram.agten]

Ik kwam een stuk javascript tegen dat vol staat met dergelijke constructies, daar hebben we toch even mee zitten lachen :

JavaScript:

if (accepted == 'true' || accepted == 'false') {
    if (accepted == 'true') {
        arrItems.push(this.getAComponent());
    } else {
        arrItems.push(this.getBComponent());
    }
}

[lauwsa]

YellowOnline schreef op dinsdag 15 januari 2013 @ 12:38:
[...]


Is dat nu een grap of zouden programmeurs die in een rechts-naar-links taal (Arabisch, Hebreeuws) werken soms echt zo programmeren?

Was niet serieus hoor . Maar die zullen alles gewoon rechts alligned.

joram.agten schreef op dinsdag 15 januari 2013 @ 13:16:
Ik kwam een stuk javascript tegen dat vol staat met dergelijke constructies, daar hebben we toch even mee zitten lachen :

JavaScript:

if (accepted == 'true' || accepted == 'false') {
    if (accepted == 'true') {
        arrItems.push(this.getAComponent());
    } else {
        arrItems.push(this.getBComponent());
    }
}

Hij krijgt zeker betaalt per regel code.

[ Voor 42% gewijzigd door lauwsa op 15-01-2013 13:23 ]

[YellowOnline]

joram.agten schreef op dinsdag 15 januari 2013 @ 13:16:
Ik kwam een stuk javascript tegen dat vol staat met dergelijke constructies, daar hebben we toch even mee zitten lachen :

JavaScript:

if (accepted == 'true' || accepted == 'false') {
    if (accepted == 'true') {
        arrItems.push(this.getAComponent());
    } else {
        arrItems.push(this.getBComponent());
    }
}

Ik ken noch JS, noch de context, maar misschien kan accepted ook een andere waarde dan true of false hebben. Zoniet kan er wel een If-je weg natuurlijk.

lauwsa schreef op dinsdag 15 januari 2013 @ 13:20:
[...]

[...]

Hij krijgt zeker betaalt per regel code.

Een vraag die ook al op TDWTF gesteld is: worden er eigenlijk mensen per lijn betaald? Zo'n systeem zou om misbruik vragen.

[ Voor 19% gewijzigd door YellowOnline op 15-01-2013 13:31 ]

[KiLLaHeRTz]

YellowOnline schreef op dinsdag 15 januari 2013 @ 13:26:
[...]


Ik ken noch JS, noch de context, maar misschien kan accepted ook een andere waarde dan true of false hebben. Zoniet kan er wel een If-je weg natuurlijk.

Dan nog is een else if() misschien netter.

[Firesphere]

YellowOnline schreef op dinsdag 15 januari 2013 @ 13:26:
[...]


Ik ken noch JS, noch de context, maar misschien kan accepted ook een andere waarde dan true of false hebben. Zoniet kan er wel een If-je weg natuurlijk.

Aangezien true en false worden vergeleken als strings is dit inderdaad mogelijk, maar alsnog niet netjes, else if en een afsluitende else, of, in het geval van nog meer mogelijkheden, een switch zou netter zijn.

[YellowOnline]

Ik speel nu advocaat van de duivel hé, maar een afsluitende Else is niet per se nodig. Er kan een actie volgen die doorgevoerd moet worden ongeacht de uitkomst van de eerste evaluatie.

Een voorbeeldje uit mijn eigen logmodule. Ik heb een commando (cmdlet, zoals dat heet in PoSh) Write-Log dat oa. een parameter heeft voor indenting (in spaties).

C#:

Function Write-Log($LogMessage, $LogFile, $Indent, $ForegroundColor, $BackgroundColor)
    {
    #(...)
    If ($Indent -EQ $Null)
        {
        $Indent = 4
        }
    #(...)
    }

Als er geen waarde meegegeven wordt default ik naar 4. Er is geen enkele reden om een Else toe te voegen.

Intussen (code is twee jaar oud) zou ik het weliswaar eleganter doen met

C#:

Function Write-Log($LogMessage, $LogFile, $Indent = 4, $ForegroundColor, $BackgroundColor)

Maar ik wil maar illustreren dat een If niet per se een Else moet hebben wmb.

Die default 4 is overigens omdat 4 ongeveer een tab is en er een time stamp voorgezet wordt.

[ Voor 5% gewijzigd door YellowOnline op 15-01-2013 13:58 ]

[Firesphere]

YellowOnline schreef op dinsdag 15 januari 2013 @ 13:55:
Ik speel nu advocaat van de duivel hé, maar een afsluitende Else is niet per se nodig. Er kan een actie volgen die doorgevoerd moet worden ongeacht de uitkomst van de eerste evaluatie.

Een voorbeeldje uit mijn eigen logmodule. Ik heb een commando (cmdlet, zoals dat heet in PoSh) Write-Log dat oa. een parameter heeft voor indenting (in spaties).

C#:

Function Write-Log($LogMessage, $LogFile, $Indent, $ForegroundColor, $BackgroundColor)
    {
    #(...)
    If ($Indent -EQ $Null)
        {
        $Indent = 4
        }
    #(...)
    }

Als er geen waarde meegegeven wordt default ik naar 4. Er is geen enkele reden om een Else toe te voegen.

Intussen (code is twee jaar oud) zou ik het weliswaar eleganter doen met

C#:

Function Write-Log($LogMessage, $LogFile, $Indent = 4, $ForegroundColor, $BackgroundColor)

Maar ik wil maar illustreren dat een If niet per se een Else moet hebben wmb.

Die default 4 is overigens omdat 4 ongeveer een tab is en er een time stamp voorgezet wordt.

Ik weet dat een afsluitende else niet nodig is
Maar als je 'true', 'false' en 'other' hebt, is het misschien wel handig

[joram.agten]

YellowOnline schreef op dinsdag 15 januari 2013 @ 13:26:

Ik ken noch JS, noch de context, maar misschien kan accepted ook een andere waarde dan true of false hebben. Zoniet kan er wel een If-je weg natuurlijk.

Beetje meer context, en die YesNoComponent geeft natuurlijk enkel true of false terug

JavaScript:

// Q2: Has the User accepted? (Yes - No)
arrItems.push(this.getAcceptedYesNoComponent());
var accepted = this.getRecord().data.accepted;
if (accepted == 'true' || accepted == 'false') {
    if (accepted == 'true') {
        arrItems.push(this.getAComponent());
    } else {
        arrItems.push(this.getBComponent());
    }
}

Een vraag die ook al op TDWTF gesteld is: worden er eigenlijk mensen per lijn betaald? Zo'n systeem zou om misbruik vragen.

Nee, we worden hier niet per lijn betaald.

[YellowOnline]

*knip*

[ Voor 100% gewijzigd door YellowOnline op 15-01-2013 15:08 ]

[Merethil]

YellowOnline schreef op dinsdag 15 januari 2013 @ 14:44:
Iemand vroeg hulp met vier-op-een-rij in Powershell en ik vroeg de code die hij al had. Dan kreeg ik dit:

[...]



OK, hij was wel nieuw in de taal, maar toch een mooi voorbeeld van hoe het niet moet.

(Ik heb de code moeten inkorten omdat het forum het wat te lang vond)

Je doet het verkeerd: Je had de code in quote-tags moeten zetten, dan mag het wel van het forum

[ Voor 71% gewijzigd door Merethil op 15-01-2013 14:48 ]

[CodeCaster]

Zo zag mijn eerste Snake er vijftien^* jaar geleden ook uit, en noodgedwongen kon je per level maximaal tien^* blokjes opeten, omdat ik geen zin had om nog meer movement- en collision detection-code te copypasten. Wat een verademing was de ontdekking van arrays.

^*: om en nabij.

[ Voor 16% gewijzigd door CodeCaster op 15-01-2013 14:53 ]

[Avalaxy]

YellowOnline schreef op dinsdag 15 januari 2013 @ 14:44:

C#:

knip

OK, hij was wel nieuw in de taal, maar toch een mooi voorbeeld van hoe het niet moet.

Eh, ik weet niet wat dat voor taal is, maar zeker geen C# hoor.

[YellowOnline]

Avalaxy schreef op dinsdag 15 januari 2013 @ 14:53:
[...]


Eh, ik weet niet wat dat voor taal is, maar zeker geen C# hoor.

Powershell. Er is geen lexer voor op T.net. De syntax van C# komt nog het dichtst in de buurt.

[Haan]

YellowOnline schreef op dinsdag 15 januari 2013 @ 14:44:
Iemand vroeg hulp met vier-op-een-rij in Powershell en ik vroeg de code die hij al had. Dan kreeg ik dit:



OK, hij was wel nieuw in de taal, maar toch een mooi voorbeeld van hoe het niet moet.

(Ik heb de code moeten inkorten omdat het forum het wat te lang vond)

Je weet dat het not done is om code uit een forum topic hier te plaatsen?

[.oisyn]

CodeCaster schreef op dinsdag 15 januari 2013 @ 14:48:
Zo zag mijn eerste Snake er vijftien^* jaar geleden ook uit, en noodgedwongen kon je per level maximaal tien^* blokjes opeten, omdat ik geen zin had om nog meer movement- en collision detection-code te copypasten. Wat een verademing was de ontdekking van arrays.

^*: om en nabij.

Zo beschreef iemand op een gamedevelopment forum hoe hij collision detection zou implementeren: "gewoon heel veel ifs".

[YellowOnline]

Haan schreef op dinsdag 15 januari 2013 @ 15:00:
[...]

Je weet dat het not done is om code uit een forum topic hier te plaatsen?

Er is een reden dat ik niet naar een user of thread verwijs. Had jij het nu niet gezegd dan had niemand het geweten, behalve wie het sowieso gezien had... . Het was een stevig voorbeeld voor deze thread die ik moeilijk kon laten liggen.

[ Voor 10% gewijzigd door YellowOnline op 15-01-2013 15:06 ]

[.oisyn]

Had jij het nu niet gezegd dan had niemand het geweten, behalve wie het sowieso gezien had...

En wat dacht je van de TS zelf die hier gewoon langs kwam?

[YellowOnline]

't Is al weg. Ik vond het iig. educatief materiaal.

.oisyn schreef op dinsdag 15 januari 2013 @ 15:07:
[...]

En wat dacht je van de TS zelf die hier gewoon langs kwam?

Ik wou 'm helpen, dus 't is niet dat ik van slechte wil ben

[ Voor 70% gewijzigd door YellowOnline op 15-01-2013 15:10 ]

[Broken]

YellowOnline schreef op dinsdag 15 januari 2013 @ 15:08:
't Is al weg. Ik vond het iig. educatief materiaal.


[...]


Ik wou 'm helpen, dus 't is niet dat van slechte wil ben

Ik heb de desbetreffende nog even via DM gesproken en wat hints gegeven. Het was een duidelijk gevalletje my first program, gelukkig ziet hij nu in dat een andere aanpak nodig is

[YellowOnline]

Kan iemand mij uitleggen wat ik hier aan het doen was bij het maken van een Excel-macro?

Visual Basic .NET:

    If ActiveSheet.Name = "Foo" Then
        Application = ActiveSheet.DropDowns(1).List(Row)
    Else
        If ActiveSheet.Name = "Bar" Then
            Application = ActiveSheet.DropDowns(1).List(Row)
        Else
            Application = ActiveSheet.DropDowns(1).List(Row)
        End If
    End If

Dat is van een half jaar geleden ofzo en ik herschrijf de code die oa. deze macro injecteert.

[ Voor 10% gewijzigd door YellowOnline op 16-01-2013 16:02 ]

[RocketKoen]

YellowOnline schreef op woensdag 16 januari 2013 @ 16:00:
Kan iemand mij uitleggen wat ik hier aan het doen was bij het maken van een Excel-macro?

Visual Basic .NET:

    If ActiveSheet.Name = "Foo" Then
        Application = ActiveSheet.DropDowns(1).List(Row)
    Else
        If ActiveSheet.Name = "Bar" Then
            Application = ActiveSheet.DropDowns(1).List(Row)
        Else
            Application = ActiveSheet.DropDowns(1).List(Row)
        End If
    End If

Dat is van een half jaar geleden ofzo en ik herschrijf de code die oa. deze macro injecteert.

Application = ActiveSheet.DropDowns(1).List(Row)
Maar dan in 9 regels code in plaats van 1

[Xesxen]

*knip* overheen gelezen

[ Voor 84% gewijzigd door Xesxen op 16-01-2013 16:12 ]

[Zoijar]

heh, mooie duidelijke output kreeg ik uit een program abort:

"Warning: no errors!"

[lauwsa]

Dan hoor je zeker fouten te krijgen . Jij doet iets goed fout .

[Zoijar]

lauwsa schreef op woensdag 16 januari 2013 @ 19:02:
Dan hoor je zeker fouten te krijgen . Jij doet iets goed fout .

Tsja, ik zie al wat het is. Shader code die wel gewoon compilet, maar er zit een oude kaart in deze machine dus de runtime kan het niet draaien. Ik gaf compiler fouten weer als de shader faalt

[Solopher]

Oké,

Ik kwam vandaag een pareltje tegen in oude code van niemand minder dan mijzelf:

PHP:

function updateProduct($imageResult = array())
{
    $postdata = array(
            'title' => $this->input->post('title'),
            'title_en' => $this->input->post('title_en'),
            'title_de' => $this->input->post('title_de'),
            'title_fr' => $this->input->post('title_fr'),
            'cat' => $this->input->post('cat'),
            'alias' => url_title($this->input->post('alias')),
            'alias_en' => url_title($this->input->post('alias_en')),
            'alias_de' => url_title($this->input->post('alias_de')),
            'alias_fr' => url_title($this->input->post('alias_fr')),
            'keywords' => $this->input->post('keywords'),
            'keywords_en' => $this->input->post('keywords_en'),
            'keywords_de' => $this->input->post('keywords_de'),
            'keywords_fr' => $this->input->post('keywords_fr'),
            'description' => $this->input->post('description'),
            'description_en' => $this->input->post('description_en'),
            'description_de' => $this->input->post('description_de'),
            'description_fr' => $this->input->post('description_fr'),
            'content' => addslashes($this->input->post('content')),
            'content_en' => addslashes($this->input->post('content_en')),
            'content_de' => addslashes($this->input->post('content_de')),
            'content_fr' => addslashes($this->input->post('content_fr')),
            'cusfield1' => $this->input->post('cusfield1'),
            'cusfieldxx' => $this->input->post('cusfieldxx'),
            'cusfield10' => $this->input->post('cusfield10'),
            'cusfield1_en' => $this->input->post('cusfield1_en'),
            'cusfieldxx_en' => $this->input->post('cusfieldxx_en'),
            'cusfield10_en' => $this->input->post('cusfield10_en'),
            'cusfieldxx_de' => $this->input->post('cusfieldxx_de'),
            'cusfield10_de' => $this->input->post('cusfield10_de'),
            'cusfield1_fr' => $this->input->post('cusfield1_fr'),
            'cusfieldxx_fr' => $this->input->post('cusfieldxx_fr'),
            'cusfield10_fr' => $this->input->post('cusfield10_fr'),
            'tupdated' => now()
        );

        if (count($imageResult) > 0) {
            $updateData = array_merge($postdata, $imageResult);
        } else {
            $updateData = $postdata;
        }


        if ($this->db->update($this->dbtables->product_table, $updateData, array('id' => $_POST['aid']))) {
            // Nu custom fields nog updaten.
            $customFields = array(
                'field1' => $this->input->post('field1'),
                'fieldxx' => $this->input->post('fieldxx'),
                'field10' => $this->input->post('field10'),
                'field1_en' => $this->input->post('field1_en'),
                'fieldxx_en' => $this->input->post('fieldxx_en'),
                'field10_en' => $this->input->post('field10_en'),
                'field1_de' => $this->input->post('field1_de'),
                'fieldxx_de' => $this->input->post('fieldxx_de'),
                'field10_de' => $this->input->post('field10_de'),
                'field1_fr' => $this->input->post('field1_fr'),
                'fieldxx_fr' => $this->input->post('fieldxx_fr'),
                'field10_fr' => $this->input->post('field10_fr')
            );

            $this->db->update($this->dbtables->product_cus_table, $customFields, array('pro_id' => $_POST['aid']));

            return true;
        } else {
            return false;
        }
}

Ik vond hem zelf zo erg dat ik hem hier wel moest delen.

[ Voor 34% gewijzigd door Solopher op 23-01-2013 21:44 . Reden: heb even heel wat dingen weggehaald, het nam en neemt nog steeds nogal veel plaats in beslag :D ]

[F.West98]

Even een stukje van mij ook, als je het over onleesbare code hebt:

PHP:

$chatroom = $chatroom[0];
$chatroom['usergroupst'] = unserialize($chatroom['usergroups']);
$chatroom['usergroupst'] = ((empty($chatroom['usergroupst'])) ? array() : $chatroom['usergroupst']);
$chatroom['usergroups'] = array();
foreach($chatroom['usergroupst'] as $usergroup) {
    $chatroom['usergroups'][$usergroup] = $usergroup;
}
foreach(/*iets*/) {
    $checked = false;
    if(isset($chatroom['usergroups'][$usergroup['usergroupid']])) {
        $checked = true;
    }
}

Ze hebben op die server de warnings aan staan dus ja dan moet het goed

[ Voor 5% gewijzigd door F.West98 op 23-01-2013 22:39 ]

[Gomez12]

Solopher schreef op woensdag 23 januari 2013 @ 21:39:
Oké,

Ik kwam vandaag een pareltje tegen in oude code van niemand minder dan mijzelf:
...

Ik vond hem zelf zo erg dat ik hem hier wel moest delen.

Ach, je wilt niet weten hoeveel "serieuze" systemen er op dezelfde manier werken omdat men ooit eens begonnen is met : Niet alles hoeft multi-taal, alleen dit en dat veldje. 2 maanden later : dat veldje ook nog even.
2 jaar later : Nu nog even een nieuwe taal erbij...

En nooit de tijd krijgen om het totaal anders op te zetten, enkel maar veldje voor veldje mogen aanpassen qua tijd

[tha_crazy]

Oud collega van mij vond if/else erg leuk.
Deed het als volgt, maar dan nog 20x erbij ongeveer.

C#:

            if(){
            }
            else{
                if(){
                }
                else{
                    if(){

                    }
                    else{
                        if(){
                        }
                        else{
                        }
                    }
                }
            }

[Soultaker]

Ik vind daar in principe niet veel mis mee, als je gewoon een hoop verschillende gevallen hebt waar je rekening mee moet houden. Soms kun je die dingen nog wel branchless maken maar daar wordt het ook niet altijd duidelijker van.

Wel zet ik alle if/else if/else clauses op het zelfde niveau qua indentatie in dat soort situaties. Dat leest een stuk prettiger.

[diabolofan]

Mits er commentaar bij geschreven is..

Alsnog wordt dit slecht leesbaar, ook als je alle links uit lijnt, imo. Beter zo snel mogelijk een return geven in de functie of anders goed delegeren. Ik denk dat voor geen één geval het echt nodig is om 20 if/else in elkaar te doen, mits goed opgezet.

[Ereaser]

En ik maar uitzoeken waarom foute results gewoon tussen de goede results zaten

Java:

    for (Object o : results) {
      String check = check(o);
      if (check == null) {
        //doe wat meer
      } else {
        objectList.remove(o);
        failList.add(o);
      }
    }
    objectArraylist= results;

[Makkelijk]

Hé, de website crashed als ik resize in chrome. Wat raar!

JavaScript:

/* This script doesn't work perfectly yet in all browsers so disable it for now */
// return; << uitgecomment ja

var resizeMapDiv = function() {
    $('#content').height($(window).height() - $('#footer').height());

    $(window).trigger('resize');
}

$(window).resize(function() {
    resizeMapDiv();
});

^ Wtf.
Gek genoeg doet hij het in andere browsers gewoon goed...

[ Voor 27% gewijzigd door Makkelijk op 30-01-2013 11:34 ]

[BasieP]

Soultaker schreef op vrijdag 25 januari 2013 @ 15:11:
Wel zet ik alle if/else if/else clauses op het zelfde niveau qua indentatie in dat soort situaties. Dat leest een stuk prettiger.

Dat staan ze in zijn voorbeeld
het is geen else if constructie he, 't zijn losse if's in een else statement, wat ervoor zorgt dat je naast de if nog iets anders kan doen.

dus

code:

  if () {
    ..
  } else {
    if () {
      ..
    } else {
      ..
    }
    ... hier dus iets anders ..
  }

[Zoijar]

diabolofan schreef op vrijdag 25 januari 2013 @ 15:15:
Beter zo snel mogelijk een return geven in de functie of anders goed delegeren.

Tsja, en dan krijg je het single-point-of-exit kamp weer over je heen...

[deadinspace]

Zoijar schreef op dinsdag 29 januari 2013 @ 20:13:
[...]

Tsja, en dan krijg je het single-point-of-exit kamp weer over je heen...

Die twee srategieën zijn prima te combineren met goto's.

Then again, dan krijg je weer goto-haters over je heen...

[Waster]

Zoijar schreef op dinsdag 29 januari 2013 @ 20:13:
[...]

Tsja, en dan krijg je het single-point-of-exit kamp weer over je heen...

De antwoorden in deze discussie maken wel duidelijk dat je met de moderne talen de argumenten volledig achterhaald zijn: http://programmers.stacke...one-return-only-come-from

[Verwijderd]

tha_crazy schreef op vrijdag 25 januari 2013 @ 11:59:
Oud collega van mij vond if/else erg leuk.
Deed het als volgt, maar dan nog 20x erbij ongeveer.

switch case ftw?
En ik denk dat becommentariëren in deze gevallen altijd noodzakelijk is.

[Zoijar]

Waster schreef op dinsdag 29 januari 2013 @ 20:23:
De antwoorden in deze discussie maken wel duidelijk dat je met de moderne talen de argumenten volledig achterhaald zijn: http://programmers.stacke...one-return-only-come-from

Oh, ja, ik vind het ook onzin hoor. Andere reden die ik daar niet zo snel zag was trouwens voor formele code verificatie; dat wordt wat makkelijker op die manier. Maarja...

[.oisyn]

Niet alleen formele. Early-outs zijn vrij makkelijk te interpreteren in je hoofd. Het aantal mogelijkheden slinkt alleen maar naarmate je verder gaat. Bij een SPoE moet je alleen maar meer en meer bij gaan houden in welke mogelijke states de functie nou kan verkeren.

[Olaf van der Spek]

.oisyn schreef op dinsdag 29 januari 2013 @ 23:45:
Bij een SPoE moet je alleen maar meer en meer bij gaan houden in welke mogelijke states de functie nou kan verkeren.

SPoR?