[Alg] Slechtste programmeervoorbeelden deel 3

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

Wat betreft het gebruik van exceptions in plaats van checks op de waarde 0, misschien zit er wel wat in. Ik denk dat het niet zoveel uitmaakt welke manier ik gebruik voor mijn applicatie. Het is puur een desktop applicatie (geen server toepassing).

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

for (int i = 0; i < balanceWeek.Count - 1; i++)             {                 icurrent = Convert.ToDouble(balanceWeek[i]);                 iplusplus = Convert.ToDouble(balanceWeek[i + 1]);                 if (icurrent != 0)                 {                     percentWeek.Add(((iplusplus - icurrent) / icurrent) * 100);                 }                 else                 {                     //Prevent infinity being added to the arraylist.                     percentWeek.Add(0);                 }             }

Het staat nu dicht bij elkaar, dus je zoekt het toevallig makkelijk op, maar iets als current_week_balance en next_week_balance is imo toch echt veel beter.

quote:

Niemand_Anders schreef op dinsdag 28 augustus 2007 @ 08:48:
Is een stuk sneller dan het afvangen van een exception. Je moet als programmeur altijd zoveel mogelijk exceptions voorkomen. Kijk ook eens na het geheugen gebruik van je applicatie wanneer je een exception optreed. Afhankelijk van je stacktrace pakt je programma eenvoudig 'ineens' 5mb extra.

Zeker bij een desktop applicatie maakt het geheugengebruik mij absoluut niet uit, dan gebruik ik gewoon wat voor mij het meest makkelijke of duidelijke is. (Dat exceptions in dit geval misschien niet nodig zijn even buiten beschouwing gelaten). Door te kijken naar de implementatie van bepaalde features overtreed je trouwens ook nog een basis principe in het object georiënteerd denken namelijk de scheiding van interface (de taal) en implementatie (de compiler).

quote:

JMfx schreef op dinsdag 28 augustus 2007 @ 11:30:De ?: operators vind ik persoonlijk erg onduidelijk, veel onoverzichtelijker dan if / else.

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

1 2 3 4 5

percentWeek.Add(     icurrent != 0         ? (iplusplus - icurrent) / icurrent * 100         : 0 );

quote:

PrisonerOfPain schreef op dinsdag 28 augustus 2007 @ 11:59:

[...]


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

1 2 3 4 5

percentWeek.Add(     icurrent != 0         ? (iplusplus - icurrent) / icurrent * 100         : 0 );

Maar waarom zou je deze manier van schrijven gebruiken? Je hebt nu meer coderegels dan het if / else equivalent (afgezien van wat haakjes). En de if / else is veel overzichtelijker.

quote:

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


Maar waarom zou je deze manier van schrijven gebruiken? Je hebt nu meer coderegels dan het if / else equivalent (afgezien van wat haakjes). En de if / else is veel overzichtelijker.

Dit kan veel overzichtelijker zijn dan if else als je bijvoorbeeld variabelen wilt initialiseren o.b.v. bepaalde criteria. Je moet bij een if else je variabele vooraf (op null) initialiseren, met de ternary operator niet. Dan kan alles inline.
Java:

1 2 3

String test = (bladiebla != null) bladiebla.getStringOfzo()     ? bladiebla.getStringOfzo()     : "leeg";

quote:

PrisonerOfPain schreef op dinsdag 28 augustus 2007 @ 07:56:
[...]
Als ik haakjes zie verwacht ik een afwijkende situatie, als dat niet het geval is vind ik ze maar on overzichtelijk en maken ze het juist onduidelijker.

Tjah, dat kun je wel verwachten, maar dan nog moet je het met haakjes heel gemakkelijk kunnen lezen en weet je direct zonder ook maar na te denken wat er staat.

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

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

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

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

quote:

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

Tjah, dat kun je wel verwachten, maar dan nog moet je het met haakjes heel gemakkelijk kunnen lezen en weet je direct zonder ook maar na te denken wat er staat.

Behalve het feit dat teveel haakjes dingen juist helemaal niet duidelijker maken, omdat je door de haakjes de grammatica niet meer kunt zien. Dat haakjes altijd verduidelijken is helemaal niet zonder meer waar.

quote:

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

Behalve het feit dat teveel haakjes dingen juist helemaal niet duidelijker maken, omdat je door de haakjes de grammatica niet meer kunt zien. Dat haakjes altijd verduidelijken is helemaal niet zonder meer waar.

quote:

TRRoads schreef op dinsdag 28 augustus 2007 @ 13:44:
[...]
Het is aan de programmeur natuurlijk om te bepalen wanneer dat het als overbodig overkomt en wanneer het nuttig is, als je daar niet goed in bent dan is het beste om gewoon altijd de haakjes te plaatsen dan ben je in ieder geval nog consistent.

Dat zeg ik Gamma..

quote:

Niemand_Anders schreef op dinsdag 28 augustus 2007 @ 08:48:
Een variabele met de waarde 0 is zeker geen exception.

Afhankelijk van de situatie kan dat wel degelijk een exception zijn. Bijvoorbeeld als er in principe nooit de mogelijkheid is dat die variabele op 0 kan staan.

quote:

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

Behalve het feit dat teveel haakjes dingen juist helemaal niet duidelijker maken, omdat je door de haakjes de grammatica niet meer kunt zien. Dat haakjes altijd verduidelijken is helemaal niet zonder meer waar.

true, hoewel ik de voorkeur geef om vooral bij de ternary operator er een paar haakjes extra bij te doen. Juist om enige onduidelijkheid te voorkomen ook als dat niet echt nodig.

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

Maar is dat niet een andere discussie?

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

quote:

JMfx schreef op dinsdag 28 augustus 2007 @ 13:29:
[...]
Maar waarom zou je deze manier van schrijven gebruiken? Je hebt nu meer coderegels dan het if / else equivalent (afgezien van wat haakjes). En de if / else is veel overzichtelijker.

Het aantal regels is niet relevant, noch het aantal tekens. Wat voor mij belangrijker is is dat je op deze manier minder dubbele code hebt (twee keer de percentWeek.Add aanroep).

quote:

TRRoads schreef op dinsdag 28 augustus 2007 @ 13:44:
[...]
Tjah, dat kun je wel verwachten, maar dan nog moet je het met haakjes heel gemakkelijk kunnen lezen en weet je direct zonder ook maar na te denken wat er staat.

Zodra je een tijd ervaring hebt met een bepaalde programmeertaal mag je er toch vanuit gaan dat je de voorrangsregels van de betreffende taal kent? Zeker aangezien die regels meestal duidelijk in de manual gespecificeerd zijn. Een van de weinige keren dat ik haakjes prefereer is in PHP als && en and door elkaar gebruikt worden (die hebben namelijk andere voorrangsregels maar betekenen hetzelfde), maar goed dat word sowieso amper gebruikt. Als ik veel haakjes wou zien had ik wel voor een op s-expressions gebaseerde programmeertaal gekozen.

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

quote:

Janoz schreef op dinsdag 28 augustus 2007 @ 14:06:
Ik gebruik de ternary operator eigenlijk alleen bij het toekennen of bij het afdrukken. Vaak is het om een default waarde te kunnen gebruiken. Zeker wanneer je veel gegevens afdrukt (of append aan een later te gebruiken string) vind ik een if juist veel lelijker.

En soms moet het:
C++:

1 2 3 4 5 6 7 8

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

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

.oisyn wijzigde dit bericht 28-08-2007 14:15 (7%)

k

blastboy wijzigde dit bericht 28-08-2007 14:17 (100%)

quote:

mark platvoet schreef op dinsdag 14 augustus 2007 @ 14:40:
Echt een 'slecht programmeervoorbeeld' is het niet maar toch een 'leuk' foutje/bugje dat ik vanmorgen had gemaakt.
Java:

1	new StringBuffer('[').append(someString).append(']');

Dit werkt toch wel gewoon bij mij als ik hiervan een println doe. Ik ben wel geen ervaren java programmeur dusja misschien mag ik de .toString() wel niet doen om dat bugje te krijgen.

quote:

Stierenoog schreef op donderdag 16 augustus 2007 @ 14:21:
Ik weet niet of iets soortgelijks al langs gekomen is, maar dit kwam ik zojuist tegen:
PHP:

1 2 3 4 5 6 7 8 9 10 11 12 13

<?php switch(true) { case ($x == 1 || $x == 2 || $x == 3):     ...     break; case ($x == 4 || $x == 5):     ...     break; case ($x == 6 || $x == 7 || $x == 8):     ...     break; default:     ... } ?>

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

De taal RPGIV waar ik in programmer kent enkel deze switch
code:

Select;
   When x = 1; 
   .... 
   Other;
EndSl;

[

quote:

Stierenoog schreef op donderdag 16 augustus 2007 @ 14:21:
Ik weet niet of iets soortgelijks al langs gekomen is, maar dit kwam ik zojuist tegen:
PHP:

1 2 3 4 5 6 7 8 9 10 11 12 13

<?php switch(true) { case ($x == 1 || $x == 2 || $x == 3):     ...     break; case ($x == 4 || $x == 5):     ...     break; case ($x == 6 || $x == 7 || $x == 8):     ...     break; default:     ... } ?>

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

De taal RPGIV waar ik in programmer kent enkel deze switch
Java:

1 2 3 4 5

Select;    When x = 1;     ....     Other; EndSl;

quote:

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


De taal RPGIV waar ik in programmer kent enkel deze switch
Java:

1 2 3 4 5

Select;    When x = 1;     ....     Other; EndSl;

Ja maargoed, je programmeert niet in een andere taal om je aan de regels van de vorige taal te houden
PHP heeft nog wel niet voor niets case-fallthrough.

quote:

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


Dit werkt toch wel gewoon bij mij als ik hiervan een println doe. Ik ben wel geen ervaren java programmeur dusja misschien mag ik de .toString() wel niet doen om dat bugje te krijgen.

Dan zou ik toch nog eens even goed gaan kijken. Als ik het uitvoer is namelijk het haakje open verdwenen. Check eventueel ff javadoc

quote:

TRRoads schreef op dinsdag 28 augustus 2007 @ 14:12:
Je schrijft code dan ook niet zodat je het zelf goed kunt lezen, je schrijft code zodat een ander het goed kan lezen (En daarbij hopelijk ook zo dat je het zelf kunt lezen )

In teamverband volg ik gewoon de opgestelde regels, in alle andere gevallen kies ik wat mij het beste ligt (of de huidige coding guideline).

Zag net nog een leuk voorbeeldje op wikipedia:
C:

1 2 3 4 5 6

vehicle = arg == 'B' ? bus :             arg == 'C' ? car :             arg == 'A' ? airplane :             arg == 'T' ? train :             arg == 'H' ? horse :             feet;

quote:

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

Heeft niemand jouw ooit verteld dat je altijd je variabelen moet controleren voordat je ze gebruikt? Verder behoort een exception een onverwachte situatie te zijn. Een variabele met de waarde 0 is zeker geen exception.

Ligt aan de situatie. Delen door 0 kan niet en als een getal dat als deler gebruikt wordt, na berekening uitkomt op 0, lijkt me dat een redelijk exception. Het is ook een stuk makkelijker met debuggen: ipv. alleen als resultaat te zien dat je app een stuk langzamer wordt door het afhandelen van NaN/Infinity, meteen een aanwijzing hebben waar de ongeldige waarde erinsluipt.

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

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

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

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

http://worsethanfailure.com/

edit: en dan voornamelijk het code deel

apNia wijzigde dit bericht 28-08-2007 15:45 (29%)