[Alg] Slechtste programmeervoorbeelden deel 3

[.oisyn]

Zoijar schreef op vrijdag 11 juli 2008 @ 16:35:
[...]

Ik denk heus wel na over alle suggesties hoor; het is niet zo dat ik bij voorbaat al zeker van m'n gelijk ben. Ik heb je code zelfs compiled en getest, maar het werkt gewoon niet goed. Tot nu toe heb ik nog steeds geen goed argument gezien om throwing dtors te gebruiken, en wel op een veilige manier. Ik raad je daarom ook nog steeds aan die code die je postte niet te gebruiken: het is niet veilig.

Ik mag trouwens hopen dat in die code E iig wel een gedefinieerde copy ctor had die óók de counter ophoogt, itt wat hier in de topic staat.

[Zoijar]

.oisyn schreef op vrijdag 11 juli 2008 @ 17:00:
Ik mag trouwens hopen dat in die code E iig wel een gedefinieerde copy ctor had die óók de counter ophoogt, itt wat hier in de topic staat.

Ja, dat was idd een leuke verrassing nadat ik de code had ge-copy/paste...

[YopY]

Hydra schreef op vrijdag 11 juli 2008 @ 16:35:
[...]
Dat vond ik dus ook. Op 1920x1200 zie je die puntkomma's nauwelijks.

Is ook de reden waarom ik óf geen enorme resoluties gebruik, óf de standaard lettertypen van code aanpas naar een groter font en alles op bold. Is een stuk leesbaarder. Kan ook zijn dat ik een bril nodig heb of teveel naar beeldschermen staar. Overigens is het limiteren van de hoeveelheid code die je in de breedte zelf kunt zien ook handig om die breedte in te perken, om zo onleesbare structuren of te diepe nestings te voorkomen.

En ik vraag mijzelf ook af waardoor compilers dat soort structuren (ifs afgesloten met puntkomma's) nog goedkeuren. Oké, het is verder geen vreemde structuur (de basisregels van de grammatica van een programmeertaal zijn immers meestal eenvoudig), maar functioneel doet het niks. Op z'n minst zou ik een warning verwachten.

[Zoijar]

YopY schreef op vrijdag 11 juli 2008 @ 20:33:
En ik vraag mijzelf ook af waardoor compilers dat soort structuren (ifs afgesloten met puntkomma's) nog goedkeuren.

1>.\main.cpp(51) : warning C4390: ';' : empty controlled statement found; is this the intent?

[Razr]

Visual Studio 2008 geeft ook gewoon netjes een warning

Warning: Possible mistaken empty statement

[DaCoTa]

Hydra schreef op vrijdag 11 juli 2008 @ 16:35:
[...]
Dat vond ik dus ook. Op 1920x1200 zie je die puntkomma's nauwelijks. Pas toen ik dat stuk code teruggebracht had naar if(false); {} en hij nog steeds het stuk tussen accolades uitvoerde viel me opeens op dat er een puntkomma stond. Een collega zag 'em ook niet.

Tja. Vrijdagen

Besteed een keer een halve vrijdag aan het zoeken en kiezen van een goed coding font, bijvoorbeeld Bitstream Vera Sans Mono of ProFont ofzo. Dat zal een boel schelen.

En over die puntcomma, het gebeurd je waarschijnlijk maar 1x in je leven dat je er een vrijdag aan kwijtraakt. De volgende keer is het een dinsdag.

[ Voor 4% gewijzigd door DaCoTa op 12-07-2008 01:08 ]

[g4wx3]

ik had hetzelfde probleem met een stomme punt komma.
En de fout niet gevonden!

PHP:

function url_werkt_niet($key,$value)
{
    $params = array($key=>$value);          # Combine parameters
    $params = array_merge($_GET,$params);   # Merge all parameters, dupes are overwriten
    $params_arr = array();
    foreach($params as $key=>$value );
    {
        $params_arr[] = $key.'='.urlencode($value);
    }
    
    return '?' . implode('&',$params_arr);
}

Ik had er een topic voor geopend:
[php] foreach ..?

Zelf dacht ik echt dat er een probleem was met de interne pointer ofzo. Dit geeft , wat ook logisch is, namelijk geen enkele foutmelding.
Uiteraard als de fout eenmaal is gevonden dan kan je makkelijk zeggen dat dit forumbevuiling is. Toch wil ik de mensen danken die me hebben beantwoord.

BTW: Ook vrijdag morge.. is dit toeval of heeft dit te maken met EM-golven die uit het heelal de atmosfeer van de aarde binnendringen of iets als telepathie lolz

[ Voor 26% gewijzigd door g4wx3 op 12-07-2008 09:21 ]

[soulrider]

regel 6[code]foreach($params as $key=>$value ); [/code]

achter je foreach staat ie ...

als je gewoon je code regel per regel naleest zie je die toch staan ?
(of ne search en dan next ...

ps: daar is dit topic niet echt voor bedoeld, maar anderzijds ook een leuk voorbeeld

en in je vorig topic wordt het ook al 2x gezegd ... lezend begrijpen begrijpend lezen aub...

ik zet in PHP en andere talen waar nodig de '{' altijd vlak achter de if, foreach, while-voorwaarde ter voorkoming dat ik er ook puntcomma's tussen zet. code wordt mss iets minder duidelijk, maar daar gebruik ik dan indents voor.

//edit: zelf nog niet wakker: sorry boven- en onderbuur

[ Voor 66% gewijzigd door soulrider op 12-07-2008 11:50 ]

[Voutloos]

soulrider schreef op zaterdag 12 juli 2008 @ 11:37:
en in je vorig topic wordt het ook al 2x gezegd ... lezend begrijpen aub...

Begrijpend lezen leert je dat g4wx3 de fout inmiddels al door had.

[Niekk]

Misschien een kleine offtopic, maar wordt deze manier van programmeren dan als "onduidelijk" beschouwd ? Ik programmeer zoals weinig mensen doen, maar vind het wel lekker werken.

code:

<?php
if($blah == "nee") {
    echo "Blah is hetzelfde als nee!";
} else if($blah == "ja") {
    echo "Blah is hetzelfde als ja!";
} else {
    echo "Praat gewoon niet.";
}

function mooie_functie($begin, $eind) {
    return $begin." ".$eind;
}

echo mooie_functie("Hallo", "Doei");
?>

Je snapt wel dat dit een onzin voorbeeld is, maar gewoon om te laten zien hoe een beetje mijn stijl is. Ik zie tegenwoordig steeds meer dingen als
if()
{
//bla
}
else
{

Dat vind ik pas onoverzichtelijk. Of dingen als:
}
else {
Dat snap ik dan ook niet.

[Voutloos]

Code style mbt de plaatsing van accolades is gewoon offtopic. De meningen blijven toch verschillen over wat beter is, daar gaat de onvermijdbare discussie die nu toch altijd weer volgt niets aan veranderen. Het enige dat telt is dat je accolade stijl consistent is én overeenkomt met je collega's.

edit:
Uiteraard, maar daarom zeg ik ook specifieke accolade stijl. Alhoewel indenting daar natuurlijk sterk aan gerelateerd is. Maar ik wou het niet voer álle stijl regels hebben, want sommige stijlen zijn gewoon wel foutgevoelig en compleet k*t.

[ Voor 30% gewijzigd door Voutloos op 12-07-2008 12:47 ]

[Creepy]

Voutloos: en dat je in elk geval enige vorm van indenting gebruikt (en uiteraard dezelfde als je collega's)

[Niekk]

inderdaad. Daar heb ik ook een hekel aan, mensen die niet inspringen persoonlijk spring ik in met 4 spaties. (in mijn editor ingesteld als tab). WAAROM? TAB IS VEEL HANDIGER? hoor ik dan altijd meteen. Dit komt omdat ik veel via vi(m) moet doen. En een tab is daar echt huge. als ik dan in een groot stuk code zit, waar al 5 keer is ingesprongen, met tabs ipv 4 spaces, dan loopt dat al over 2 regels.

[g4wx3]

Voordat ik een paar stijl cursusen gelezen had deed ik het ook zo.

Nu zet ik accolades op de zelfde hoogte, het behoort samen, dus moet het op de zelfde intend staan. Daarnaast creeert het meer witruimte, waardoor compacte programmercode veel aangenamer te lezen is.

Verder maak ik me niet druk wat een stijl iemand gebruikt, wel kan ik van de stijl *soms* afleiden hoe profesioneel een programma is.

een goed begin vind je hier:
http://www.evolt.org/arti...lines/18/60247/index.html
en hier helemaal uitgebreid: (EDIT: bij nader inzien niet wat ik verwachte...)
http://ludit.kuleuven.be/pahupa/
(ik heb er toch veel van opgestoken)

helaas doe ik volgens het boekje nog veel fout, zoals tabs ipv spaties, variablen zijn onduidelijk (willekeurig zelfs) en nog meer "slechte" dingen. Maar aan de andere kant blijft het een eeuwige discusie spaties - tabs ed.

Toch is het voor iedereen intressant om een stijlcursus te lezen.

EDIT: Een halfuur gezocht naar deze stijlcursussen...

[ Voor 6% gewijzigd door g4wx3 op 12-07-2008 13:08 ]

[R_W]

Tabbreedte is gewoon in te stellen in Vim.

[Voutloos]

Niekk schreef op zaterdag 12 juli 2008 @ 12:48:
WAAROM? TAB IS VEEL HANDIGER? hoor ik dan altijd meteen. Dit komt omdat ik veel via vi(m) moet doen.

Als een collega dat tegen jou zegt is er geen consistente stijl, dus is er een probleem. Wie er bijdraait maakt op zicht niet heel veel uit, alhoewel het toch ook niet complete rocket science moet zijn om een tab breedte te wijzigen.

waar al 5 keer is ingesprongen, met tabs ipv 4 spaces, dan loopt dat al over 2 regels.

Generaliserende halve waarheid: Dan is die functie te groot.

[Marcj]

Niekk schreef op zaterdag 12 juli 2008 @ 12:48:
inderdaad. Daar heb ik ook een hekel aan, mensen die niet inspringen persoonlijk spring ik in met 4 spaties. (in mijn editor ingesteld als tab). WAAROM? TAB IS VEEL HANDIGER? hoor ik dan altijd meteen. Dit komt omdat ik veel via vi(m) moet doen. En een tab is daar echt huge. als ik dan in een groot stuk code zit, waar al 5 keer is ingesprongen, met tabs ipv 4 spaces, dan loopt dat al over 2 regels.

of je doet :set ts=4

[Tanuki]

g4wx3 schreef op zaterdag 12 juli 2008 @ 09:14:
ik had hetzelfde probleem met een stomme punt komma.
En de fout niet gevonden!

PHP:

function url_werkt_niet($key,$value)
{
    $params = array($key=>$value);          # Combine parameters
    $params = array_merge($_GET,$params);   # Merge all parameters, dupes are overwriten
    $params_arr = array();
    foreach($params as $key=>$value );
    {
        $params_arr[] = $key.'='.urlencode($value);
    }
    
    return '?' . implode('&',$params_arr);
}

Ik had er een topic voor geopend:
[php] foreach ..?

Zelf dacht ik echt dat er een probleem was met de interne pointer ofzo. Dit geeft , wat ook logisch is, namelijk geen enkele foutmelding.
Uiteraard als de fout eenmaal is gevonden dan kan je makkelijk zeggen dat dit forumbevuiling is. Toch wil ik de mensen danken die me hebben beantwoord.

BTW: Ook vrijdag morge.. is dit toeval of heeft dit te maken met EM-golven die uit het heelal de atmosfeer van de aarde binnendringen of iets als telepathie lolz

De echte WTF is hier denk ik toch wel het niet gebruiken van http_build_query()...

Zo kan je die code hierboven namelijk ombouwen naar:

PHP:

function url_werkt_niet($key,$value)
{
        return http_build_query(array_merge($_GET, array($key=>$value)), null, '&');
}

En die ? zet je er natuurlijk buiten de url_werkt_niet() functie voor.

[ Voor 9% gewijzigd door Tanuki op 12-07-2008 13:14 ]

[Niekk]

R_W schreef op zaterdag 12 juli 2008 @ 12:56:
Tabbreedte is gewoon in te stellen in Vim.

klopt, maar wel onhandig als je op tig verschillende systemen werkt. dan is het makkelijker vind ik om op mijn desktop in Anjuta (voor C) in te stellen dat mijn tab knop 4 spaties genereerd, en als ik op backspace klik ze ook allemaal weg gaan. Als die files dan later naar SVN geschreven worden, heb ik dat probleem niet meer.

[TaraWij]

Niekk schreef op zaterdag 12 juli 2008 @ 12:18:
Misschien een kleine offtopic, maar wordt deze manier van programmeren dan als "onduidelijk" beschouwd ? Ik programmeer zoals weinig mensen doen, maar vind het wel lekker werken.

Wil hier nu geen discussie om gaan beginnen, maar de meeste programmeren op die tweede manier omdat het dan minder in een blok samenkleeft en er meer nadruk is op de condities. Maar niet iedereen leest de code op dezelfde manier (leuk om dat te bestuderen ) dus het kan zijn dat jij telkens de oneven regels snel leest... Is verder ook een beetje vergelijkbaar met tekst, het opdelen in alinea's.

[Niekk]

de officiele regels voor C zijn nog raarder vind ik.

code:

void bla(int i)
{
    // "Functies" op deze manier
}

int main()
{
    if() {
        while(true) {
            en if's en while's weer zo. (en dan dus ook for etc, en ook } else {)
        }
    }
}

[ Voor 3% gewijzigd door Niekk op 12-07-2008 13:28 ]

[Verwijderd]

l0c4lh0st schreef op zaterdag 12 juli 2008 @ 13:07:
[...]

De echte WTF is hier denk ik toch wel het niet gebruiken van http_build_query()...

Zo kan je die code hierboven namelijk ombouwen naar:

PHP:

function url_werkt_niet($key,$value)
{
        return http_build_query(array_merge($_GET, array($key=>$value)), null, '&');
}

En die ? zet je er natuurlijk buiten de url_werkt_niet() functie voor.

Dus omdat hij een blijkbaar bestaande functie aan het herschrijven is, waar hij wellicht nog iets van opsteekt ook, is het gelijk fout ?

Dat het dubbel werk is ben ik met je eens, maar niet per definitie fout.

[g4wx3]

ik had inderdaad nog niet gehoord van deze functie. weer wat bijgeleerd. Hartelijk dank.

[Verwijderd]

g4wx3 schreef op zaterdag 12 juli 2008 @ 09:14:
foreach($params as $key=>$value );
{
$params_arr[] = $key.'='.urlencode($value);
}
[/code]

Deze is zelfs, uiteraard in een iets andere vorm, ooit eens ingeschoten als bug in de java runtime Je bent dus lang niet de enige die een dergelijke fout ooit eens heeft gemaakt

[Niekk]

Verwijderd schreef op zaterdag 12 juli 2008 @ 18:04:
[...]

Deze is zelfs, uiteraard in een iets andere vorm, ooit eens ingeschoten als bug in de java runtime Je bent dus lang niet de enige die een dergelijke fout ooit eens heeft gemaakt

.. ?
Dat stukje was PHP, dus waarom praat jij dan over JAVA? Ik volg het even niet meer.

[user109731]

Niekk schreef op zaterdag 12 juli 2008 @ 19:56:
[...]

.. ?
Dat stukje was PHP, dus waarom praat jij dan over JAVA? Ik volg het even niet meer.

Hij geeft aan dat zulke fouten vaker voorkomen, bijvoorbeeld in Java.

Het valt me op dat do..while loops weinig gebruikt worden. Dan zie je zoiets:

C++:

/* skip header */
string line;
line = file.readLine();

while (isHeader(line)) {
  line = file.readLine();
}

Met een do..while zonder code duplicatie:

C++:

/* skip header */
string line;
do {
  line = file.readLine();
} while (isHeader(line));

[Verwijderd]

Nouja, omdat die 2e constructie wellicht veel onbekender is bij programmeurs ?

Ik heb er mijn allereerste C# (e)book nog eens op nageslagen (het eerste boek waaruit wij op het HBO programmeerles kregen), daarin zie je ook alleen de eerste constructie terug.

In het volgende boek staat deze constructie wel, maar dan slaan we de basis natuurlijk over...waardoor de meeste studenten het dus alsnog niet leren kennen.

[ Voor 28% gewijzigd door Verwijderd op 12-07-2008 20:45 ]

[Haan]

Er staat mij iets bij dat ergens in een boek werd afgeraden om de do-while te gebruiken, maar ik zou eigenlijk niet meer weten waarom dat zou zijn.

[fleppuhstein]

JanDM schreef op zaterdag 12 juli 2008 @ 20:37:
[...]

Hij geeft aan dat zulke fouten vaker voorkomen, bijvoorbeeld in Java.

Het valt me op dat do..while loops weinig gebruikt worden. Dan zie je zoiets:

C++:

/* skip header */
string line;
line = file.readLine();

while (isHeader(line)) {
  line = file.readLine();
}

Met een do..while zonder code duplicatie:

C++:

/* skip header */
string line;
do {
  line = file.readLine();
} while (isHeader(line));

Zie dit nog wel regelmatig, is ook geleerd tijdens programeren met C++, While is voorwaarde controle vooraf, DoWhile is voorwaarde controle achteraf

[Chip.]

Inderdaad daarmee verzorg je dus dat je code na do { altijd 1x word uitgevoerd. Maar do while loop is ook equivalent aan:

C++:

do {
   foo();
} while (conditie);

==

while (true) {
   foo();
   if (!conditie) break;
}

[ Voor 45% gewijzigd door Chip. op 12-07-2008 21:50 ]

[g4wx3]

hmm, ik heb waarschijnlijk een eigenaardige hersenkronkel, maar maak wel graag gebruik vaak do-while, op gepast moment uiteraard.

ook heb ik de switch graag:
Dit stukje komt uit het eerste bestand dat ik open had staan:

PHP:

<?php
        switch (true)
        {
            case isset($_POST['delete']):
            
                $query = 'DELETE FROM `store` WHERE `id` = '.$productid.' LIMIT 1;';
                $db->query($query);

            break;
            case isset($_POST['update']):
                $query = 'SELECT * FROM `store` WHERE id='.$productid.' LIMIT 1;';
                $db->query($query);
                $product = $db->fetch();
                $title = $product['title'];
                $description = $product['description'];
                $ref = $product['ref'];
                $price = $product['price'];
                
                include('resources/apps/store/product_p1.php');
            break;
        }
?>

Zoiets kan dus ook met if, of if elseif, maar ik vind het overzichtelijker, en flexibeler zo.

[ Voor 4% gewijzigd door g4wx3 op 12-07-2008 22:40 ]

[Verwijderd]

Het zal aan mij liggen, ik vind switch enorm handig, maar in jou voorbeeld eigenlijk helemaal niets. Gebruik switch wel veel tijdens tekst-verwerk dingen, met iets als

Java:

switch (string.charAt(index)) {
}

Maar jou ding: Wat als zowel update als delete is gezet <gerommel met input waarschijnlijk>, maar toch. Vind dit nou juist niet overzichtelijker en flexibeler dan ifs.

[frickY]

Ik zie daar ook totaal de meerwaarde niet van een switch, en alleen maar de foutgevoeligheid bij het vergeten van een break.

Enige keren dat ik een switch gebruik is wanneer meerdere condities dezelfde uitvoer moeten geven, voor de rest altijd elseif's. Als je dan een accolade vergeet heb je tenminste nog een parse-error

[ Voor 12% gewijzigd door frickY op 12-07-2008 23:22 ]

[Verwijderd]

g4wx3 schreef op zaterdag 12 juli 2008 @ 22:36:
hmm, ik heb waarschijnlijk een eigenaardige hersenkronkel, maar maak wel graag gebruik vaak do-while, op gepast moment uiteraard.

ook heb ik de switch graag:
Dit stukje komt uit het eerste bestand dat ik open had staan:

PHP:

<?php
        switch (true)
        {
            case isset($_POST['delete']):
            
                $query = 'DELETE FROM `store` WHERE `id` = '.$productid.' LIMIT 1;';
                $db->query($query);

            break;
            case isset($_POST['update']):
                $query = 'SELECT * FROM `store` WHERE id='.$productid.' LIMIT 1;';
                $db->query($query);
                $product = $db->fetch();
                $title = $product['title'];
                $description = $product['description'];
                $ref = $product['ref'];
                $price = $product['price'];
                
                include('resources/apps/store/product_p1.php');
            break;
        }
?>

Zoiets kan dus ook met if, of if elseif, maar ik vind het overzichtelijker, en flexibeler zo.

Ik vind het vreselijk.

PHP:

<?php
// ...
if ( $contract= $model->contract->getRecordById ( $request->contract_id ) ) ) {
   switch ( $request->action ) {
      case 'edit':
         $this->handleEditRequest ( $request, $contract );
         break;
      case 'resign':
         $this->handleResignRequest ( $request, $contract );
         break;
   }
}
// ...
?>

Beter nog (want weg is je switch):

PHP:

<?php
// ...
if ( $contract= $model->contract->getRecordById ( $request->contract_id ) ) ) {
   call_user_func (
      array ( $this, sprintf ( 'handle%sRequest', convert::dash2camel ( $request->action ) ) ),
      array ( $request, $contract )
   );
}
// ...
?>

En dan natuurlijk functies als:

PHP:

<?php
// ...
/**
 * Blah blah
 *
 * @param Request $request The request object that is to be handled.
 * @param ContractRecord $contract The contract object that is to be resigned if possible.
 * @return boolean TRUE if the contract could be resigned, FALSE otherwise.
 */
public function handleResignRequest ( Request $request, ContractRecord $contract ) {
   $model = $this->getModel ();
   $view  = $this->getView ();

   if ( $result = $contract->resign ( $model, $request->resign_date ) ) {
      $message = "Het contract is opgezegd per %s.";
   } else {
      $message = "Het contract kan pas worden opgezegd per %s.";
   }

   $view->message = sprintf (
      nls::translate ( $message ),
      $contract->getDisplayValue ( $contract->entity->resign_date )
   );

   return $result;
}
// ...
?>

Iets dergelijks is een stuk eleganter dan overal strooien met mysql_query, $db->query, $_POST en allerlei low-level stuff. Daar wil je je op applicatieniveau toch helemaal niet meer mee bezighouden? Uiteraard was dit even snel ingeklopte code, maar het gaat om het idee.

[Niekk]

Wow! Dit zie ik voor het eerst. Kent PHP typecasting ? In C doen "we" inderdaad:

code:

int nice_stuff(int i, int j) { /* deze line bedoel ik dan */
    return i + j;
}

maar kent PHP dat ? want PHP is een taal zonder types, toch ?!

[ Voor 6% gewijzigd door Niekk op 13-07-2008 11:45 ]

[Voutloos]

Niekk schreef op zondag 13 juli 2008 @ 11:35:
maar kent PHP dat ? want PHP is een taal zonder types, toch ?!

Sinds PHP5 kan je opgeven of parameters arrays of objecten zijn. De andere standaard types kan je stupide genoeg nog niets mee.

Verder kent PHP wél types en kan je wél casten. Anders is de conversie tussen standaard types automagisch, maar die is vaak genoeg ongewenst (string '123abc' wordt int 123 ). Anyway, ga je mond spoelen en lees het hoofdstuk over data types nog een keer.

[ Voor 3% gewijzigd door Voutloos op 13-07-2008 11:46 ]

[Zoijar]

PHP is idd worst-of-both-worlds: wel gezeur met type conversie, maar geen type safety

[Jaap-Jan]

Leuke vergelijking:

In PHP:
Hoeveel is 'appel' + 'peer'? Antwoord: 0.
Hoeveel is 'appel' + '42'? Antwoord: 42.
Hoeveel is 'appel' + 42? Antwoord: 42.

In Python:

code:

>>> 'appel' + 'peer'
'appelpeer'
>>> 'appel' + '42'
'appel42'
>>> 'appel' + 42
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot concatenate 'str' and 'int' objects

Ik weet wel wat ik logischer vind.

[Verwijderd]

Maar dat komt meer omdat de + in Python/Java/C(#) twee functies heeft die in PHP zijn opgesplitst naar 2 operators...namenlijk:
Numeriek optellen: +
Concat strings: .

In alle overige genoemde talen hangt het dus van de objecten links en rechts van de + af wat er gebeurt, en wanneer er geen match gevonden wordt krijg je een exception.

Bij PHP gaat ie gewoon alles op proberen te tellen . Daarbij komt inderdaad wel kijken dat PHP heel makkelijk getallen ziet in/maakt van niet-integer-objecten .

[Voutloos]

Leuk, maar dat soort voorbeelden is vaak genoeg ook wel erg geforceerd. Ik weet wel wanneer ik een sommetje doe of wat strings aan elkaar plak, en daar zijn aparte operators voor. Ik ben geen php weak typing jehova, maar er valt best mee te werken.

[Niekk]

Voutloos schreef op zondag 13 juli 2008 @ 11:46:
[...]
Sinds PHP5 kan je opgeven of parameters arrays of objecten zijn. De andere standaard types kan je stupide genoeg nog niets mee.

Verder kent PHP wél types en kan je wél casten. Anders is de conversie tussen standaard types automagisch, maar die is vaak genoeg ongewenst (string '123abc' wordt int 123 ). Anyway, ga je mond spoelen en lees het hoofdstuk over data types nog een keer.

Klopt. Ik vind dat PHP een taal zou moeten zijn die zich wel eits aantrekt van types. Dit voorkomt zoveel fouten. je kan opgeven of iets een array of object moet zijn, maar dit vind ik nutteloos. Waarom niet int vs string o.i.d. ? Dat is juist waar PHP "moeite" mee heeft. (zoals dat 123 voorbeeld dat je gaf)

[Voutloos]

Het is halfbakken en het voorkomt hiipe features als method overloading. Het string '123abc' is natuurlijk net zo geforceerd als wat ik in voorgaande post zei.

[Niekk]

Voutloos schreef op zondag 13 juli 2008 @ 13:00:
Het is halfbakken en het voorkomt hiipe features als method overloading. Het string '123abc' is natuurlijk net zo geforceerd als wat ik in voorgaande post zei.

je hebt wel gelijk, ik moet zeggen dat ik er niet zo erg veel last van heb. Maar 't is niet goed vind ik.

[fleppuhstein]

Jaap-Jan schreef op zondag 13 juli 2008 @ 12:10:
Leuke vergelijking:

In PHP:
Hoeveel is 'appel' + 'peer'? Antwoord: 0.
Hoeveel is 'appel' + '42'? Antwoord: 42.
Hoeveel is 'appel' + 42? Antwoord: 42.

In Python:

code:

>>> 'appel' + 'peer'
'appelpeer'
>>> 'appel' + '42'
'appel42'
>>> 'appel' + 42
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot concatenate 'str' and 'int' objects

Ik weet wel wat ik logischer vind.

In deze lijn kan ook snel de volgende fout gemaakt worden:

PHP:

<?php

if (0 == "") {
    echo "This is wrong!";
}

?>

[Creepy]

Jaap-Jan schreef op zondag 13 juli 2008 @ 12:10:
Leuke vergelijking:

In PHP:
Hoeveel is 'appel' + 'peer'? Antwoord: 0.
Hoeveel is 'appel' + '42'? Antwoord: 42.
Hoeveel is 'appel' + 42? Antwoord: 42.

In Python:

code:

>>> 'appel' + 'peer'
'appelpeer'
>>> 'appel' + '42'
'appel42'
>>> 'appel' + 42
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot concatenate 'str' and 'int' objects

Ik weet wel wat ik logischer vind.

Dan vergeet je voor het gemak dat PHP een string concatenation operator heeft?

En je laat het leukste voorbeeld weg

PHP:

echo "40 appels" + "50 peren";

Geeft 90

[ Voor 4% gewijzigd door Creepy op 13-07-2008 14:13 ]

[Verwijderd]

90 wat ?

[g4wx3]

Inderdaad, ik, ik ken geen andere talen dan PHP en JS, maarik zou het toch veel aangenamer vinden als php stricter was met gegevenstypes.
Ik heb er opzich geen last van, maar vind het wel een onlogica dat je appelen en peren (zogezegd) bij elkaar kan optellen, dat zou een fout moeten geven, net als if('1'==1) false zou moeten returnen. Dan weet je pas of je programma zonder flaws is geschreven

@hierboven HAHAHA, die is geweldig!

[ Voor 24% gewijzigd door g4wx3 op 13-07-2008 14:24 ]

[Robtimus]

Verwijderd schreef op zondag 13 juli 2008 @ 14:14:
90 wat ?

Stuks fruit natuurlijk

[RayNbow]

Creepy schreef op zondag 13 juli 2008 @ 14:12:
En je laat het leukste voorbeeld weg

PHP:

echo "40 appels" + "50 peren";

Geeft 90

Iedereen weet dat de peer de tegenpool is van de appel. Het antwoord dat PHP dus geeft is dus fout. Het juiste antwoord moet zijn: "10 peren".

[.oisyn]

Niekk schreef op zaterdag 12 juli 2008 @ 13:28:
de officiele regels voor C zijn nog raarder vind ik.

Officiele C regels? Kom op zeg . Er is K&R style, maar er zijn geen officiele regels voor C.

Wouser schreef op zaterdag 12 juli 2008 @ 21:48:
Inderdaad daarmee verzorg je dus dat je code na do { altijd 1x word uitgevoerd. Maar do while loop is ook equivalent aan:

C++:

do {
   foo();
} while (conditie);

==

while (true) {
   foo();
   if (!conditie) break;
}

Nee, dat is het niet. Een continue in de loop zal in het eerste geval conditie opnieuw checken, maar in het tweede geval niet.

Verwijderd schreef op zaterdag 12 juli 2008 @ 23:59:
Beter nog (want weg is je switch):

PHP:

<?php
// ...
if ( $contract= $model->contract->getRecordById ( $request->contract_id ) ) ) {
   call_user_func (
      array ( $this, sprintf ( 'handle%sRequest', convert::dash2camel ( $request->action ) ) ),
      array ( $request, $contract )
   );
}

Ik vind dat allesbehalve beter. Als er een keer een foute waarde in $request->action staat ben je de sjaak (zeker als die foute waarde toevallig ook nog eens resulteert in een daadwerkelijke functie). Met een switch is je code duidelijker en veiliger.

g4wx3 schreef op zondag 13 juli 2008 @ 14:21:
Ik heb er opzich geen last van, maar vind het wel een onlogica dat je appelen en peren (zogezegd) bij elkaar kan optellen, dat zou een fout moeten geven, net als if('1'==1) false zou moeten returnen. Dan weet je pas of je programma zonder flaws is geschreven

Als je dat wilt dan kun je === en !== gebruiken - die controleert ook of de typen overeen komen. Op zich vind ik het niet raar dat "1"==1 gelijk is aan true. Ik vind het wel raar dat "boom" == 0 gelijk is aan true.

[ Voor 97% gewijzigd door .oisyn op 13-07-2008 17:32 ]

[g4wx3]

Goeie tip! was vergeten dat je ook === kon doen. (ga meteen wat code verzetten)

[Niekk]

.oisyn schreef op zondag 13 juli 2008 @ 17:18:
[...]

Officiele C regels? Kom op zeg . Er is K&R style, maar er zijn geen officiele regels voor C.

ok, de benaming "officiele" was misschien ietsje overdreven, maar ik verwees hiermee inderdaad naar K&R. Dit wordt door de meeste programmeurs tochwel als "de standaard" gezien. (ikzelf houd me er ook niet aan )

[chris]

fleppuhstein schreef op zondag 13 juli 2008 @ 13:58:
[...]


In deze lijn kan ook snel de volgende fout gemaakt worden:

PHP:

<?php

if (0 == "") {
    echo "This is wrong!";
}

?>

Sterker nog, wat is de uitkomst van deze expressie:

PHP:

in_array("hello", array(0,1,2));

Dit is een (versimpelde) versie van wat wij vandaag tegenkwamen in een stuk code. In PHP gaat dit dus compleet mis:

PHP:

0 == "hi";
0 == "test";

[Yeroon1986]

Deze code kwam ik herhaaldelijk tegen in het Projectbeheerapp (classic ASP!!!) wat hier draait:

Visual Basic:

iAantalArchief = 0
while oRS.Eof=false
   if oRS.EOF=false then
      iAantalArchief=iAantalArchief+1
   end if
   oRs.MoveNext
wend

Het RecordSet hierboven wordt gevuld door deze SQL:

SQL:

if (@iTabsel=1)
begin
select MeldingID, Datum, Omschrijving, Notitie, tblMeldingType.Type, AntwoordOpMelding, tblGebruikers.VolledigeNaam, ObjectType, ObjectID, tblMelding.Datum_ingevoerd
from ((tblMelding left join tblMeldingType on tblMelding.MeldingType = tblMeldingType.MeldingTypeID) left join tblGebruikers on tblMelding.Gebruiker_Ingevoerd=tblGebruikers.GebruikerID) join tblMeldingOntvanger on tblMelding.MeldingID=tblMeldingOntvanger.Melding
where tblMelding.AntwoordOpMelding is null and tblMelding.Datum_Verwijderd is null and tblMelding.KlantID=@iKlantID
and tblMeldingOntvanger.Gebruiker=@iGebruikerID and not (tblMeldingOntvanger.Gelezen is null)
and getdate()>=tblMelding.Datum 
order by tblMelding.Datum_ingevoerd DESC, omschrijving
end
else
begin
SELECT     tblMelding.MeldingID, tblMelding.Datum, tblMelding.Omschrijving, tblMelding.Notitie, tblMeldingType.Type, tblMelding.AntwoordOpMelding, 
                      tblGebruikers.VolledigeNaam, tblMelding.ObjectType, tblMelding.ObjectID, tblMelding.Datum_Ingevoerd
FROM         tblMelding LEFT OUTER JOIN
                      tblGebruikers ON tblMelding.Gebruiker_Ingevoerd = tblGebruikers.GebruikerID LEFT OUTER JOIN
                      tblMeldingType ON tblMelding.MeldingType = tblMeldingType.MeldingTypeID
WHERE     (tblMelding.Gebruiker_Ingevoerd = @iGebruikerID) AND (tblMelding.KlantID = @iKlantID) AND (tblMelding.AntwoordOpMelding IS NULL) and (getdate()>=tblMelding.Datum)
order by tblMelding.Datum_ingevoerd DESC, omschrijving
end

Heeft blijkbaar nog nooit van een COUNT gehoord ...

En ook deze (Kon 'm zo snel niet meer vinden, maar het kwam hierop neer):

Visual Basic:

while (conditie<10)
   if (conditie<10) then
      'code hier
   end if
wend

[Verwijderd]

Double check to be double sure ?

[daanmsvl]

Code Complete (2nd edition) is ook een heerlijk boek vol met allerlei "coding horror" maar, belangrijker, hoe je het dan wel moet doen.

[Woy]

Yeroon1986 schreef op dinsdag 15 juli 2008 @ 15:00:

Visual Basic:

while (conditie<10)
   if (conditie<10) then
      'code hier
   end if
wend

Tja mischie heeft na de controle in de while een andere thread conditie wel veranderd

[Zyppora]

rwb schreef op dinsdag 15 juli 2008 @ 16:22:
[...]

Tja mischie heeft na de controle in de while een andere thread conditie wel veranderd

Dan zou die thread dat ook na de if controle kunnen doen Het is sowieso good practice om blokken code met variables die door meerdere threads te benaderen zijn, synchronized uit te laten voeren (als zoiets bestaat in VB).

[ Voor 6% gewijzigd door Zyppora op 15-07-2008 16:44 ]

[Haan]

Verwijderd schreef op dinsdag 15 juli 2008 @ 15:18:
Double check to be double sure ?

Als er verder niets meer met condition gebeurt, heb je ook een mooie endless loop

[Verwijderd]

Haan schreef op dinsdag 15 juli 2008 @ 17:04:
[...]

Als er verder niets meer met condition gebeurt, heb je ook een mooie endless loop

Niet al binnen die loop wordt gewacht op input of als de loop wordt gebroken op een bepaalde value van de conditie of wat dan ook. Hoe vaak ik al niet

code:

while True:
  if condition == 0:
    break
  if condition == 1:
    continue

Heb meegemaakt Daarbij kan de loop gebroken worden met een exception of andersoortige interventie. Als dit binnen een thread draait kan de thread gewoon gesloten worden etc etc etc.

_{-- edit}
goedemorgen, als er inderdaad niks mee gebeurd is ie endless

[ Voor 20% gewijzigd door Verwijderd op 15-07-2008 17:11 ]

[Yeroon1986]

haha, er worden geen threads gebruikt. Bestaat ook niet in ASP (VBscript dus) voor zover ik weet! In de while-loop wordt wel wat met die conditite gedaan, Ik liet het voorbeeld zien om dat er een dubbele check werd gedaan die volstrekt overbodig is.

[Haan]

Verwijderd schreef op dinsdag 15 juli 2008 @ 17:08:
[...]

Niet al binnen die loop wordt gewacht op input of als de loop wordt gebroken op een bepaalde value van de conditie of wat dan ook. Hoe vaak ik al niet

code:

while True:
  if condition == 0:
    break
  if condition == 1:
    continue

Heb meegemaakt Daarbij kan de loop gebroken worden met een exception of andersoortige interventie. Als dit binnen een thread draait kan de thread gewoon gesloten worden etc etc etc.

Dat voorbeeld is imho ook vrij ranzige code

[Woy]

Yeroon1986 schreef op woensdag 16 juli 2008 @ 09:07:
haha, er worden geen threads gebruikt. Bestaat ook niet in ASP (VBscript dus) voor zover ik weet! In de while-loop wordt wel wat met die conditite gedaan, Ik liet het voorbeeld zien om dat er een dubbele check werd gedaan die volstrekt overbodig is.

Ach als er wel thread gebruikt werden zou het nog net zo fout zijn.

[daniëlpunt]

chris schreef op maandag 14 juli 2008 @ 15:32:
[...]


Sterker nog, wat is de uitkomst van deze expressie:

PHP:

in_array("hello", array(0,1,2));

Dit is een (versimpelde) versie van wat wij vandaag tegenkwamen in een stuk code. In PHP gaat dit dus compleet mis:

PHP:

0 == "hi";
0 == "test";

Wat denk je dat hier uit komt?

PHP:

in_array("hello", array(0,1,2), true);

[Mozin]

Kwam ik tegen in een van onze projecten, het is niet echt fout, maar wel een beetje omslachtig .

code:

if (tblZoek.Visible == false)
{
  // Doe iets
}
else if (tblZoek.Visible == true) 
{
  // Doe iets anders 
}

[Sebazzz]

Het is omslachtig maar wel duidelijk. Niet per definitie slecht.

C#:

if (!tblZoek.Visible){
  // Doe iets
} else {
  // Doe iets anders 
}

[daniëlpunt]

Of deze

code:

if (expression)
{
    
} else
{
    doeIets();
}

En dan ook geen stukje commentaar of iets.

[Janoz]

@Sebazzz:
Dan zou ik er eerder

C#:

if (tblZoek.Visible){
  // Doe iets anders
} else {
  // Doe iets 
}

van maken. De negatie zie je snel over het hoofd.

@super-muffin:
Soms wordt in de code-guidelines opgegeven dat je niet met een negatie mag werken om de reden die ik hierboven noem. Dan krijg je inderdaad dergelijke constructies. Echt fout zou ik ze niet willen noemen (tenzij het een gevolg is van een ontwikkelaar die helemaal geen negatie kent)

Ik zou echter wel een stukje commentaar in het lege blok opnemen. Iets als '\\do nothing'.

[Icelus]

super-muffin schreef op woensdag 16 juli 2008 @ 10:21:
Of deze

code:

if (expression)
{
    
} else
{
    doeIets();
}

En dan ook geen stukje commentaar of iets.

Gereserveerd voor toekomstige uitbreidingen

Ook leuk:

PHP:

$x = 0100;

if ( $x == 100 ) {
  // Code die nooit uitgevoerd wordt.
}

[Niekk]

Stond daar letterlijk "code die nooit uitgevoerd wordt" of wat moet ik me er van voorstellen ?

[LuCarD]

Mozin schreef op woensdag 16 juli 2008 @ 10:06:
Kwam ik tegen in een van onze projecten, het is niet echt fout, maar wel een beetje omslachtig .

code:

if (tblZoek.Visible == false)
{
  // Doe iets
}
else if (tblZoek.Visible == true) 
{
  // Doe iets anders 
}

En wat als tblZoek.Visible Null is?

[Icelus]

Niekk schreef op woensdag 16 juli 2008 @ 10:29:
Stond daar letterlijk "code die nooit uitgevoerd wordt" of wat moet ik me er van voorstellen ?

Nee, dit is een voorbeeld (De code wordt ook niet uitgevoerd).

[ Voor 7% gewijzigd door Icelus op 16-07-2008 10:37 ]

[Verwijderd]

Ik kwam zojuist een mooie tegen:

C#:

        private static bool IsBool( string arg )
        {
            try
            {
                Convert.ToBoolean(arg);
                return true;
            }
            catch
            {
                return false;
            }
        }

Dat moet toch eenvoudiger kunnen

[Verwijderd]

Verwijderd schreef op woensdag 16 juli 2008 @ 11:32:
Ik kwam zojuist een mooie tegen:

C#:

        private static bool IsBool( string arg )
        {
            try
            {
                Convert.ToBoolean(arg);
                return true;
            }
            catch
            {
                return false;
            }
        }

Dat moet toch eenvoudiger kunnen

Is op zich wel slim. De method ToBoolean geeft een boolean, die je in principe direct kan returnen, maar vergeet de ConversionException niet.

[LuCarD]

Verwijderd schreef op woensdag 16 juli 2008 @ 11:41:
[...]


Is op zich wel slim. De method ToBoolean geeft een boolean, die je in principe direct kan returnen, maar vergeet de ConversionException niet.

Nope. de functie is IsBool. Er word dus alleen gecontrolleerd of the waarde een boolean of waarde die geconverteerd kan worden naar boolen bevat.

Als bedoeling zou zijn om waarde van de boolean terug te geven, dan is de functie fout en werkt hij niet correct.

[Niemand_Anders]

Janoz schreef op woensdag 16 juli 2008 @ 10:24:
@super-muffin:
Soms wordt in de code-guidelines opgegeven dat je niet met een negatie mag werken om de reden die ik hierboven noem. Dan krijg je inderdaad dergelijke constructies. Echt fout zou ik ze niet willen noemen (tenzij het een gevolg is van een ontwikkelaar die helemaal geen negatie kent)

Ik zou echter wel een stukje commentaar in het lege blok opnemen. Iets als '\\do nothing'.

Dan zou ik zelf eerder iets gebruiken zoals

C#:

if (tblZoek.Visible == false)
{
  //do iets
}

Doe hetzelfde als de negative, is alleen wat meer verboze.

Zag vanochtend trouwens ook een zeer slecht voorbeeld

C#:

try
{
   cmd.Connection.Open();
   cmd.ExecuteNonQuery();
}
catch { //just ignore exception.. }
finally
{
   cmd.Connection.Close();
}

Persoonlijk ga ik al als een stier tekeer als een developer een statement als catch(Exception ex) gebruikt (je behoort alleen fouten af te vangen welke je verwacht), echter na het zien van bovenstaande code (van een ervaren programmeur) ben ik even 10 minuten buiten gaan staan.

Het negeren van excepties is een echte no-no in mijn boek. Ook was deze developer 'vergeten' logging te gebruiken. Ook geen controle of er wel records zijn veranderd (ExecuteNonQuery geeft het aantal gewijzigde records terug).

De developer in kwestie mag vanavond in zijn vrije tijd alsnog een juiste implementatie schrijven.

[Niemand_Anders]

Verwijderd schreef op woensdag 16 juli 2008 @ 11:41:
[...]


Is op zich wel slim. De method ToBoolean geeft een boolean, die je in principe direct kan returnen, maar vergeet de ConversionException niet.

Boolean.TryParse is veel handiger en heeft ingebouwde foutcontrole.

C#:

function IsBool(string arg)
{
  bool result;
  return Boolean.TryParse(arg, out result);

}

[YakuzA]

Niemand_Anders schreef op woensdag 16 juli 2008 @ 11:54:
[...]

Boolean.TryParse is veel handiger en heeft ingebouwde foutcontrole.

C#:

function IsBool(string arg)
{
  bool result;
  return Boolean.TryParse(arg, out result);

}

Een probleem is wel dat dit een ander resultaat geeft:

When this method returns, if the conversion succeeded, contains true if value is equivalent to TrueString or false if value is equivalent to FalseString. If the conversion failed, contains false.

Tryparse geeft ook false terug als de bool waarde van wat gechecked word false is.

[Janoz]

Niemand_Anders schreef op woensdag 16 juli 2008 @ 11:45:

Het negeren van excepties is een echte no-no in mijn boek. Ook was deze developer 'vergeten' logging te gebruiken. Ook geen controle of er wel records zijn veranderd (ExecuteNonQuery geeft het aantal gewijzigde records terug).

Toch moet ik zeggen dat ik dat nog wel in mijn code ergens heb zitten, maar het gaat dan wel over een heel specifiek geval. Het is dan wel zo dat ik een specifieke exception afvang en in commentaar heb staan dat hij geignored kan worden. Hierbij valt te denken (ik praat over java) aan de verplichte InteruptedException wanneer je sleep gebruikt en het niet uitmaakt of iets onderbroken wordt of volledig de gestelde pauze doorloopt.

Of bijvoorbeeld het volgende stukje code:

Java:

int result = DEFAULT;
try {
  result = Integer.parseInt(someString);
} catch (NumberFormatException nfe) {
  //do nothing
}

Maar in alle andere gevallen wil ik inderdaad minimaal een
LOG.warn("beschrijvende melding",throwable);
in de catch body staan.

[Marcj]

Janoz schreef op woensdag 16 juli 2008 @ 12:13:
[...]

Toch moet ik zeggen dat ik dat nog wel in mijn code ergens heb zitten, maar het gaat dan wel over een heel specifiek geval. Het is dan wel zo dat ik een specifieke exception afvang en in commentaar heb staan dat hij geignored kan worden. Hierbij valt te denken (ik praat over java) aan de verplichte InteruptedException wanneer je sleep gebruikt en het niet uitmaakt of iets onderbroken wordt of volledig de gestelde pauze doorloopt.

Of bijvoorbeeld het volgende stukje code:

Java:

int result = DEFAULT;
try {
  result = Integer.parseInt(someString);
} catch (NumberFormatException nfe) {
  //do nothing
}

Maar in alle andere gevallen wil ik inderdaad minimaal een
LOG.warn("beschrijvende melding",throwable);
in de catch body staan.

Zelfs in dit geval zou je toch een melding willen geven dat de ingevoerde string geen juiste invoer was en dat je dus maar een default waarde gebruikt. Nu gaat hij een standaard waarde stilletjes gebruiken zonder dat je weet dat er foute invoer was...

[Erkens]

Marcj schreef op woensdag 16 juli 2008 @ 12:25:
[...]


Zelfs in dit geval zou je toch een melding willen geven dat de ingevoerde string geen juiste invoer was en dat je dus maar een default waarde gebruikt. Nu gaat hij een standaard waarde stilletjes gebruiken zonder dat je weet dat er foute invoer was...

Afhankelijk van de situatie kan ik me indenken dat je niet altijd een melding wilt geven, een gebruiker zit er vaak niet op te wachten, en een logfile vullen met dat soort meldingen is ook niet echt superhandig. Maar nogmaals, afhankelijk van de situatie

[Marcj]

Erkens schreef op woensdag 16 juli 2008 @ 12:28:
[...]

Afhankelijk van de situatie kan ik me indenken dat je niet altijd een melding wilt geven, een gebruiker zit er vaak niet op te wachten, en een logfile vullen met dat soort meldingen is ook niet echt superhandig. Maar nogmaals, afhankelijk van de situatie

Noem eens een voorbeeld?

[Niemand_Anders]

YakuzA schreef op woensdag 16 juli 2008 @ 12:10:
[...]


Een probleem is wel dat dit een ander resultaat geeft:

[...]


Tryparse geeft ook false terug als de bool waarde van wat gechecked word false is.

Er wordt niets met 'result' zelf gedaan. Het gaat puur om de return value van TryParse en die geeft alleen maar aan of de conversie is gelukt.De geconverteerde waarde wordt via de tweede parameters (out result) terug gegeven.

Het resultaat is dus niet anders.

Uit de MSDN (System.Boolean.TryParse):

Return Value
Type: System..::.Boolean

true if value was converted successfully; otherwise, false.

[Verwijderd]

Mozin schreef op woensdag 16 juli 2008 @ 10:06:
Kwam ik tegen in een van onze projecten, het is niet echt fout, maar wel een beetje omslachtig .

code:

if (tblZoek.Visible == false)
{
  // Doe iets
}
else if (tblZoek.Visible == true) 
{
  // Doe iets anders 
}

Dit duid dus echt op een beginnende programmeur, die totaal geen overzicht heeft over boolean logica en if/else constructies...want als je dat wel snapt, ga je dit niet voor de lol zo neerzetten.

LuCarD schreef op woensdag 16 juli 2008 @ 10:34:
[...]

En wat als tblZoek.Visible Null is?

Dat zal deze nooit uit zichzelf zijn. Default value van de Visible propertie is true, en alleen wanneer jij deze in runtime op null zet kan deze null worden.

[ Voor 22% gewijzigd door Verwijderd op 16-07-2008 12:58 ]

[Erkens]

Marcj schreef op woensdag 16 juli 2008 @ 12:37:
[...]

Noem eens een voorbeeld?

Je geeft niet voor niets een default value op, dus er zal wel een situatie te bedenken zijn dat je een string wilt gebruiken als integer en als dat niet kan een "default" value wilt gebruiken en no questions asked

Maar als het was geschreven als:

Java:

int result;
try {
  result = Integer.parseInt(someString);
} catch (NumberFormatException nfe) {
  result = DEFAULT;
}

Had je er geen probleem mee gehad?

[Verwijderd]

Verwijderd schreef op woensdag 16 juli 2008 @ 12:56:
[...]

Dit duid dus echt op een beginnende programmeur, die totaal geen overzicht heeft over boolean logica en if/else constructies...want als je dat wel snapt, ga je dit niet voor de lol zo neerzetten.


[...]

Dat zal deze nooit uit zichzelf zijn. Default value van de Visible propertie is true, en alleen wanneer jij deze in runtime op null zet kan deze null worden.

Mwah toch zie je dat soort constructies wel veel hoor, zeker op embedded systemen waarbij geheugen beperkt is en je dus variabelen geen waarde geeft tenzij echt nodig.

Dan is het vrij standaard dat iets null kan zijn en kom je er dus met een simpele if niet uit. Al zou ik dan gewoon een switch gebruiken en geen if. (Afhankelijk van de taal en de compiler, sommige compilers zijn hier niet super efficient mee, zeker als je een default of een null waarde hebt waarin je verder niets doet)

Wel is het duidelijk dat dit niet aan de orde was in het voorbeeld, maar ik heb genoeg code gezien waarbij veel if statements op die manier in elkaar zitten.

[BM]

Verwijderd schreef op woensdag 16 juli 2008 @ 12:56:
[...]

Dat zal deze nooit uit zichzelf zijn. Default value van de Visible propertie is true, en alleen wanneer jij deze in runtime op null zet kan deze null worden.

Als ik anders probeer .Visible van een control op null te zetten krijg ik mooi de volgene error van Visual Studio

code:

Cannot convert null to 'bool' because it is a value type

Edit:
Bovenstaand verhaal maakt het natuurlijk wel iets anders

[ Voor 6% gewijzigd door BM op 16-07-2008 13:09 ]

[Niemand_Anders]

Janoz schreef op woensdag 16 juli 2008 @ 12:13:
[...]

Toch moet ik zeggen dat ik dat nog wel in mijn code ergens heb zitten, maar het gaat dan wel over een heel specifiek geval. Het is dan wel zo dat ik een specifieke exception afvang en in commentaar heb staan dat hij geignored kan worden. Hierbij valt te denken (ik praat over java) aan de verplichte InteruptedException wanneer je sleep gebruikt en het niet uitmaakt of iets onderbroken wordt of volledig de gestelde pauze doorloopt.

Zoals aangegeven had ik al aangegeven dat verwachte excepties zoals de interupt bij een tread gewoon afgevangen mogen worden. Echter blind het generieke exception afvangen en daar niets mee doen is een doodzonde. Op het moment dat een developer de generieke exceptie wrapped in een custom exception, dan heb ik er (veel) minder problemen mee.

Of bijvoorbeeld het volgende stukje code:

Java:

int result = DEFAULT;
try {
  result = Integer.parseInt(someString);
} catch (NumberFormatException nfe) {
  //do nothing
}

Alle variabelen welke via input van derden (input controls) komt dient te worden gevalideerd. Dus het formulier had het ongeldige nummer al moeten afvangen.

Gewoon stoïcijns doorgaan en met default waardes verder werken kan ervoor zorgen dat het resultaat uiteindelijk anders is dan verwacht. Wij zijn voornamelijk actief in de financiele sector en afgegeven (lening/lease) offertes zijn bindend. Een adviseur moet er vanuit kunnen gaan dat de offerte correct wordt berekend, ook als hij ongeldige waardes invoert. Hij hoort dan op zijn fouten gewezen te worden.

Juist dit soort excepties op basis van externe waardes loggen wij zodat hierover later analyses kunnen worden losgelaten. Als heel veel adviseurs dezelfde invoer fouten maken, dan wil je dat als development bedrijf weten. Hier kun je dan op inspringen.

Maar in alle andere gevallen wil ik inderdaad minimaal een
LOG.warn("beschrijvende melding",throwable);
in de catch body staan.

Ik heb zelfs programmeurs gehad welke aangaven geen logging te gebruiken vanwege de negatieve impact op de performance. Ook onze final releases worden gewoon met debug symbols verscheept. Bij productie fouten is een leesbare stacktrace van onschatbare waarde. De ingeleverde performance neem ik dan heel erg graag voor lief als ik dan bij een probleem weet dat het probleem optrad in bestand x.cs op regel y in plaats van 'RenderReport() +631'.

[Verwijderd]

Verwijderd schreef op woensdag 16 juli 2008 @ 13:04:
[...]

Mwah toch zie je dat soort constructies wel veel hoor, zeker op embedded systemen waarbij geheugen beperkt is en je dus variabelen geen waarde geeft tenzij echt nodig.

Dan is het vrij standaard dat iets null kan zijn en kom je er dus met een simpele if niet uit. Al zou ik dan gewoon een switch gebruiken en geen if. (Afhankelijk van de taal en de compiler, sommige compilers zijn hier niet super efficient mee, zeker als je een default of een null waarde hebt waarin je verder niets doet)

Wel is het duidelijk dat dit niet aan de orde was in het voorbeeld, maar ik heb genoeg code gezien waarbij veel if statements op die manier in elkaar zitten.

Dat is inderdaad een ander verhaal...want hier was het inderdaad niet aan de orde. Hier is het blijkbaar ook geen nullable property (je kan best een nullable bool aanmaken), dat wist ik nog niet . Bedankt BM voor het uitproberen .

[daanmsvl]

Niemand_Anders schreef op woensdag 16 juli 2008 @ 11:45:
[...]

*knip*

Persoonlijk ga ik al als een stier tekeer als een developer een statement als catch(Exception ex) gebruikt (je behoort alleen fouten af te vangen welke je verwacht), echter na het zien van bovenstaande code (van een ervaren programmeur) ben ik even 10 minuten buiten gaan staan.

Waarom hoor je alleen fouten af te vangen welke je verwacht? Wat als er een fout optreed die je niet verwacht?!? Ik bedoel: Kan je dit voor mij beredeneren?

[Tubby]

Niemand_Anders schreef op woensdag 16 juli 2008 @ 13:55:
[...]
Ik heb zelfs programmeurs gehad welke aangaven geen logging te gebruiken vanwege de negatieve impact op de performance. Ook onze final releases worden gewoon met debug symbols verscheept. Bij productie fouten is een leesbare stacktrace van onschatbare waarde. De ingeleverde performance neem ik dan heel erg graag voor lief als ik dan bij een probleem weet dat het probleem optrad in bestand x.cs op regel y in plaats van 'RenderReport() +631'.

Inleveren van performance is ook onzine als je je log statements tussen if statements zet. Dan merk je er runtime niets van als je je loglevel op error of warn hebt staan. Maar voor debuggen is het erg fijn als je je loglevel even kan aanpassen naar debug

Java:

if(log.isDebugEnabled()) 
{
  log.debug("dump van grote collection var: "+hugeCollection);
}

[Soultaker]

Niemand_Anders schreef op woensdag 16 juli 2008 @ 13:55:
Ik heb zelfs programmeurs gehad welke aangaven geen logging te gebruiken vanwege de negatieve impact op de performance.

Hangt er een beetje vanaf waar/hoe vaak die logging code aangeroepen wordt, natuurlijk.

Ook onze final releases worden gewoon met debug symbols verscheept. Bij productie fouten is een leesbare stacktrace van onschatbare waarde.

De aanwezigheid/afwezigheid van debug symbols maakt voor performance niet echt uit, je moet alleen grotere binaries doorsturen/opslaan/inladen, en daarom is het "netter" om ze in een productieomgeving achterwege te laten. Voor sommige mensen speelt ook nog dat de aanwezigheid van debuginformatie cracking/reverse engineering eenvoudiger maakt.

Maar je weet hopelijk wel dat je b.v. een coredump van een gestripte binary prima kunt debuggen met de originele niet-gestripte variant? Je kunt een build mét debug symbols maken, een gestripte versie deployen, en coredumps uit de productieomgeving lokaal analyseren zonder enige verlies van functionaliteit. (Betekent wel dat je inderdaad in de productieomgeving geen stacktraces kunt generen, maar debuggen wil je daar toch niet doen.)

Een groter probleem is dat core dumps lastiger te analyseren worden naarmate je meer optimalisaties toepast. (Optimalisatienivo's waarbij de stack frames niet volledig worden opgebouwd zijn bijvoorbeeld heel irritant) Je zou dan eigenlijk met weinig/geen optimalisaties willen builden, maar dat heeft natuurlijk wél een significant effect op de performance.

[Woy]

daanmsvl schreef op woensdag 16 juli 2008 @ 14:36:
[...]

Waarom hoor je alleen fouten af te vangen welke je verwacht? Wat als er een fout optreed die je niet verwacht?!? Ik bedoel: Kan je dit voor mij beredeneren?

Fouten die je niet verwacht moeten gewoon doorkomen tot het hoogste nivo en alleen eventueel opgevangen te worden in een uncaught exception handler die een dikke vette foutmelding, of minstens een grote rode log wegschrijft.

Fouten dienen namenlijk afgehandeld te worden, en als je niet weet wat er fout is gegaan kun je het ook niet goed afhandelen. Als er een fout optreed waar je niet op gerekend had dan is er blijkbaar wat mis met het programma.

[Nick_S]

daanmsvl schreef op woensdag 16 juli 2008 @ 14:36:
[...]

Waarom hoor je alleen fouten af te vangen welke je verwacht? Wat als er een fout optreed die je niet verwacht?!? Ik bedoel: Kan je dit voor mij beredeneren?

Omdat je voor fouten die je niet verwacht ook geen afhandeling kan geven. Dit zal dus ook niet door jouw laag afgehandeld moeten worden, maar door de laag er boven (of hoger) tot het uiteindelijk door de GUI, VM o.i.d. wordt afgevangen, die er wel wat mee kan. (Melding naar gebruiker geven, VM plat gooien) Fouten opslokken of half afvangen heeft niemand wat aan.

Dit soort constructie "verbergt" ook vaak andere, programmeer, fouten, zoals NullPointerExceptions.
Bijvoorbeeld:

Java:

Product product = productDAO.getProduct();
try {
   product.verwerk();
} catch (Exception exception) {
   throw new ProductNotFoundException();
}

Dit is in ieder geval netter (en ook efficienter):

Java:

Product product = productDAO.getProduct();
if (product == null) {
    throw new ProductNotFoundException();
} else {
    product.verwerk();
}

Zeker als product.verwerk() ook nog een exceptie kan gooien. Bij het eerste voorbeeld slok je deze dus op met een ProductNotFoundException. Bij het tweede voorbeeld zou je deze exceptie wel expliciet te zien krijgen.

[Janoz]

@MarcJ & Niemand_Anders:
Dat mijn stukje invoer van een gebruiker zou afhandelen en de gebruiker daardoor geen melding zou krijgen is een aanname die jullie doen en die helemaal niet uit mijn code voorbeeld blijkt .

[daanmsvl]

@Nick_S & RWB: helder, dank

[ Voor 38% gewijzigd door daanmsvl op 16-07-2008 15:37 . Reden: vergeten ]

[denheer]

In een financieel pakket kwam ik o.a. dit juweeltje tegen:

Visual Basic:

antw = vbNo
While antw = vbNo
    antw = MsgBox("Geen invoer records, dus geen exportbestand. ", _
    vbYesNo + vbDefaultButton2 + vbCritical, App.EXEName)
Wend

Waarom iemand hier een vbYesNo neerzet en bij vbNo de msg opnieuw laat zien is mij een raadsel.

[Niemand_Anders]

Janoz schreef op woensdag 16 juli 2008 @ 15:25:
@MarcJ & Niemand_Anders:
Dat mijn stukje invoer van een gebruiker zou afhandelen en de gebruiker daardoor geen melding zou krijgen is een aanname die jullie doen en die helemaal niet uit mijn code voorbeeld blijkt .

Ik neem aan dat je applicatie zelf getallen niet als string doorgeeft, dus is de aanname dat de invoer van buitenaf (url parameters, form post, command line arguments, etc) komt zeer plausibel.

Conversie fouten mogen gewoon niet genegeerd worden. In het minste geval moet de fout worden gelogged (bijvoorbeeld bij een automatische import van een product lijst).

[Marcj]

Janoz schreef op woensdag 16 juli 2008 @ 15:25:
@MarcJ & Niemand_Anders:
Dat mijn stukje invoer van een gebruiker zou afhandelen en de gebruiker daardoor geen melding zou krijgen is een aanname die jullie doen en die helemaal niet uit mijn code voorbeeld blijkt .

Daarom vroeg ik ook om een voorbeeld te geven. Wanneer ga je een String parsen als int (of een ander type), welke geen gebruikersinvoer is op een of andere manier?

[Niemand_Anders]

denheer schreef op woensdag 16 juli 2008 @ 15:45:
In een financieel pakket kwam ik o.a. dit juweeltje tegen:

Visual Basic:

antw = vbNo
While antw = vbNo
    antw = MsgBox("Geen invoer records, dus geen exportbestand. ", _
    vbYesNo + vbDefaultButton2 + vbCritical, App.EXEName)
Wend

Waarom iemand hier een vbYesNo neerzet en bij vbNo de msg opnieuw laat zien is mij een raadsel.

Ha ha, en dan ook nog de vbNo default maken...