[Alg] Slechtste programmeervoorbeelden deel 3

[LuCarD]

Nick_S schreef op woensdag 16 juli 2008 @ 15:18:
[...]

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.

Ik ben geen java expert. Maar als je het nou zo oplost

Java:

Product product = productDAO.getProduct();
try {
   product.verwerk();
} 
catch(NullException Exception) {
  throw new ProductNotFoundException();
}
catch (Exception exception) {
// throw same exception once more
 throw new Exception();
}

[Creepy]

Als je de exceptie 1 op 1 doorgooit hoef je die natuurlijk niet af te vangen. dus die tweede catch is totaal overbodig wat mij betreft. Daarnaast, als je weet dat die methode een null kan teruggeven lijkt mij het eenvoudiger om met een if te checken of dat ook zo is of niet. Dan gebruik ik toch echt liever de code van Nick_S.

Los daarvan: een exceptie vangen en gooien is duurder dan een simpele if.

[HawVer]

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.

Met de gedachte dat de gebruiker dit wel moet accepteren.

[Janoz]

LOL

Ik dacht, ik zoek ff het stukje code in een util jar van me op waarin ik deze constructie gebruik. (onderdeel van een uitbreiding op de standaard Property class in java waarbij enkele conversies ingebouwd zijn. Dat maakt het erg makkelijk om property bestanden in te lezen met meerdere types)

En daar zie ik het volgende :

Java:

    /**
     * Searches for the property with the specified key in this 
     * property list. The method returns the default value argument
     * if the property is not found. It will also return the default
     * if a property is found, but can not be converted to an Integer.
     *  
     * @param key
     * @param defaultValue
     * @return The integer value of the property, or the default if 
     * the property doesn't exist
     * @see java.util.Properties#getProperty(String)
     */
    public Integer getProperty(String key, Integer defaultValue) {
        try {
            defaultValue = new Integer(this.getProperty(key));
        } catch (NumberFormatException nfe) {
            LOG.info("Unable to retrieve integer, returning default.");
        }
        return defaultValue;
    }

Blijkt dus dat ik zelf ook gewoon een log message wegschrijf ..

[NetForce1]

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


Ik ben geen java expert. Maar als je het nou zo oplost

Java:

Product product = productDAO.getProduct();
try {
   product.verwerk();
} 
catch(NullException Exception) {
  throw new ProductNotFoundException();
}
catch (Exception exception) {
// throw same exception once more
 throw new Exception();
}

Dan wordt je dus mooi op het verkeerde been gezet als de methode verwerk() een npe gooit.

[Nick_S]

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


Ik ben geen java expert. Maar als je het nou zo oplost

Java:

Product product = productDAO.getProduct();
try {
   product.verwerk();
} 
catch(NullException Exception) {
  throw new ProductNotFoundException();
}
catch (Exception exception) {
// throw same exception once more
 throw new Exception();
}

Als je het zo zou oplossen (afvangen van NPE's) dan zou ik nog harder uit m'n stekker gaan, dan het afvangen van Exception. Als je daarbij ook nog een new Exception() aanmaakt, dan is het een vermelding waard op The Daily WTF . Dit is alles behalve netjes programmeren.

[Niemand_Anders]

LuCarD schreef op woensdag 16 juli 2008 @ 16:11:
[...]
Ik ben geen java expert. Maar als je het nou zo oplost

Java:

Product product = productDAO.getProduct();
try {
   product.verwerk();
} 
catch(NullException Exception) {
  throw new ProductNotFoundException();
}
catch (Exception exception) {
// throw same exception once more
 throw new Exception();
}

Probleem is dat elke exceptie een afgeleide is van Exception is. Op deze manier zet je een FileNotFoundException (welke aanvullende informatie zoals het opgevraagde bestand) om naar een algemene exceptie waarmee je die extra info kwijt raakt. Je hebt dan alleen nog maar de stacktrace en de beschrijving van de foutmelding.

Overigens kun je ook gewoon in de catch slechts 'throw' aanroepen waarmee de originele exception weer wordt opgegooid. Veel libraries vangen ook de algemene exceptions af, maar throwen vervolgens hun eigen exception waarbij de orginele exception als InnerException wordt doorgezet.

Het blijft echter verstandig om alleen de fouten af te vangen welke je logischer kunt c.q. mag verwachten en waarbij een goede afhandeling mogelijk is. Een algemene catch kun je eventueel plaatsen in de Main functie als catchall voor onverwachte excepties zoals te weinig geheugen.

[Nick_S]

Niemand_Anders schreef op woensdag 16 juli 2008 @ 17:17:
[...]
Je hebt dan alleen nog maar de stacktrace en de beschrijving van de foutmelding.

Aanvulling: je hebt dan alleen nog maar de stacktrace vanaf het moment waar je deze gooide en niet meer de informatie die in de originele stacktrace stond.
Code zoals:

Java:

} catch (DeeperLayerException exception) {
   throw new CurrentLayerException("My beautifull message");
}

Of zelfs:

Java:

} catch (DeeperLayerException exception) {
   throw new CurrentLayerException("My beautifull message, cause: " + exception.getMessage());
}

vind ik ook niet correct. I.m.o. zal altijd de oorzaak van de exceptie mee genomen moeten worden, dus:

Java:

} catch (DeeperLayerException exception) {
   throw new CurrentLayerException("My beautifull message, cause: " + exception.getMessage(), exception);
}

(Waarbij de String toevoeging van de originele exceptie optioneel is)

onverwachte excepties zoals te weinig geheugen.

Dat zijn de zogeheten RuntimeExceptions, waar je over het algemeen weinig mee kan. (Hoe zou je bijvoorbeeld een OutOfMemoryException willen afhandelen?

[BHR]

Janoz schreef op woensdag 16 juli 2008 @ 16:47:

Java:

        try {
            defaultValue = new Integer(this.getProperty(key));
        } catch (NumberFormatException nfe) {
            LOG.info("Unable to retrieve integer, returning default.");
        } 

Blijkt dus dat ik zelf ook gewoon een log message wegschrijf ..

Ik heb toch zo'n hekel aan dit type logmeldingen.. Probeer je een kritieke fout op te lossen en dan zie je zo'n logmelding. Dan heb ik echt een "aargh.. om welke key gaat het dan !? wie heeft dat er *niet* bij gezet."-momentje .

[Verwijderd]

Nick_S schreef op woensdag 16 juli 2008 @ 17:24:
Dat zijn de zogeheten RuntimeExceptions, waar je over het algemeen weinig mee kan. (Hoe zou je bijvoorbeeld een OutOfMemoryException willen afhandelen?

Daarom hebben ze daar gelukkig een Error van gemaakt en is het dus een OutOfMemoryError. Error is een afgeleide van Throwable en niet van RuntimeException. Je kunt dus vrij veilig Exception/RuntimeException vangen als je daar aanleiding toe hebt.

[Nick_S]

Verwijderd schreef op donderdag 17 juli 2008 @ 07:56:
[...]

Daarom hebben ze daar gelukkig een Error van gemaakt en is het dus een OutOfMemoryError. Error is een afgeleide van Throwable en niet van RuntimeException. Je kunt dus vrij veilig Exception/RuntimeException vangen als je daar aanleiding toe hebt.

Got me there. Note to self: niet altijd praten over OOME, maar het beessie bij de naam noemen, dan weet je de naam tenminste.

[AW_Bos]

Ik heb van een kennis wat sourcecode gekregen van zijn site (staat ter download omdat hij er niks meer mee deed).
Ok, zijn PHP-ervaring is mimimaal, maar zag er ernstig uit
meerdere geneste if-statements die erin staan terwijl je die in 1 statement kan voegen.
Laat ik maar niks zeggen over de shorttags <?, en de onleesbaarheid .

Ikzelf ben nu bezig met een eigen CMS die opgebouwd is in TemplateLite (Smarty fork, en nog sneller), en modulair zal gaan werken. Die code is echt ...

[g4wx3]

Ik ben ooit een klasse begonnen om wat formulieren makkelijk in een te steken. Naarmate ik meer dingen nodig had, heb ik deze er ook op geımplementeerd. Hij is nog niet af, maar hij voldoet aan mijn behoeften. (aangezien ik hem zelf steeds uitbreid)
Ik zou graag de 300 regels code met jullie delen, vooral om hem te verbeteren, maar ook dat jullie er ook gebruik van kunnen maken.
Mijn vraag: Zijn er geïntreseerden? Waar kan ik dit het beste posten?

*De klasse voldoet aan mijn behoefte, ik vraag niemand code werk.
Ik heb nooit PHP oid gestudeerd, maar op deze manier zou ik graag wel wat extra ervarng willen opdoen.

EDIT:

Een typisch voorbeeld om de klasse te gebruiken:

PHP:

<?php

$form = new FORM('setup0');

$form->set_title('Setup database connection');
$form->set_method('post');
$form->set_action('index.php');

$form->set_input('server');
$form->server->set_label('Database url');
$form->server->set_type('text');
$form->server->set_value($server);

$form->set_input('username');
$form->username->set_label('Username');
$form->username->set_type('text');
$form->username->set_value($username);

$form->set_input('password');
$form->password->set_label('Password');
$form->password->set_type('text');
$form->password->set_value($password);

$form->set_input('submit');
$form->submit->set_type('submit');
$form->submit->set_value('Next');
?>

*set_input is was een slechte naam voor wat de methode eigenlijk doet:
Het maakt een nieuw object van een andere classe met deze naam. In deze clase zijn methoden om je input velden (ea) op te stellen
Zo zijn er dus tal van slordigheden in de classe, die ik al over het hoofd zie ondertussen.

[ Voor 47% gewijzigd door g4wx3 op 21-07-2008 23:43 ]

[Gomez12]

Q: Wat is eigenlijk het devies met commentaar?

Op dit moment ben ik met nog een aantal mensen bezig aan een project en daar komt op zich alleen het hoogstnoodzakelijke commentaar in voor. Iedereen die erbij betrokken is kan de huidige code zo lezen en schrijven, hier is heel weinig geen commentaar voor nodig.

Nu hebben we een nieuwe aanwinst bij ons project en die kan de code niet lezen en schrijven. Hij vraagt dan ook om meer commentaar, alleen voor de huidige proggers is het gewoon duidelijk...

Net zoals je aan een wiskundige geen stelling van pythagoras hoeft uit te leggen, aan een C-progger geen pointers hoeft uit te leggen, volstaat onze huidige commentaar vorm goed voor de huidige proggers.
Nu is de vraag, zijn er regels wat er wel / niet gecommentariseerd moet worden of is dit meer een groepsgevoel?

Want ik gok dat als de nieuwe progger in dit topic code gaat posten ( nadat hij nederlands geleerd heeft ) dat velen het met hem eens zouden zijn dat het slechte code betreft, maar de huidige proggers snappen het 100%, wij zijn ook best bereid om wat meer commentaar te schrijven, maar we gaan niet elke regel becommentariseren...

offtopic:
Het betreft hier geen bedrijf, maar een OpenSource programma. Wij zijn dus blij met ongeveer elke extra progger, keiharde kenniseisen zijn dus ook niet echt te stellen

[Gomez12]

g4wx3 schreef op maandag 21 juli 2008 @ 23:38:
Een typisch voorbeeld om de klasse te gebruiken:

PHP:

<?php

$form = new FORM('setup0');

$form->set_title('Setup database connection');
$form->set_method('post');
$form->set_action('index.php');

$form->set_input('server');
$form->server->set_label('Database url');
$form->server->set_type('text');
$form->server->set_value($server);

$form->set_input('username');
$form->username->set_label('Username');
$form->username->set_type('text');
$form->username->set_value($username);

$form->set_input('password');
$form->password->set_label('Password');
$form->password->set_type('text');
$form->password->set_value($password);

$form->set_input('submit');
$form->submit->set_type('submit');
$form->submit->set_value('Next');
?>

Vraagje, niet lullig bedoeld maar wat voor nut heeft deze klasse? In een template is dit bij mij 6 regels code, bij jou 20?
Doet deze klasse aan input validatie ofzo?
Kan ik er iets mee in een print-layout ofzo?
Schakelt hij zichzelf uit in een rss-feed?

Sowieso snap ik over het algemeen al niet het aanmaken van classes voor het genereren van html output...
Als ik 20 regels php nodig heb voor het genereren van 6 regels html output dan moet ik wel een verdomd goede reden hebben om de php-manier te pakken ipv de html manier.
MVC scheiding is leuk, maar imho bereik ik dat in dit voorbeeld ook door een html template te bakken met daarin 3 variabelen. Dan kan ik daarnaast een print template neerzetten waar dit helemaal niet in voorkomt, een rss template waar dit ook niet in voorkomt etc etc.

[g4wx3]

dat voorbeeldje deed niet meer dan het printen van deze code;

HTML:

<form method="post" action="index.php">
<fieldset>
<legend>Setup database connection</legend>
<input type="hidden" name="form" value="setup0">
<ul class="formmargin">
<li><label for="server"><span>Database url</span><input id="server" name="server" value="localhost" type="text" class="input"></label></li>
<li><label for="username"><span>Username</span><input id="username" name="username" value="root" type="text" class="input"></label></li>
<li><label for="password"><span>Password</span><input id="password" name="password" value="root" type="text" class="input"></label></li>
<li><input value="Next" type="submit" class="input submit"></li>
</ul>
</fieldset>
</form>

Zeker ik nu de code voor me zie, ben ik blij dat ik alles met een klasse parse (al m'n html trouwens)

Werkt echt veel overzichtelijker vind ik. En als ik iets wil aanpassen, kan ik dat in alle forms tegelijk. Wil ik juist iets afwijkend, dan pas ik de klasse een beetje aan.
De klasse regelt ook alles, zodanig dat de html altijd goed is zonder dat je je er druk om moet maken. Ook ander velden zijn ondersteund uiteraard. Een file-veld zorgt ervor dat de form multipart is ed. Niet zomaar 300 regels code.( al zal het altijd wel efficienter kunnen, leesbaarheid vs effecientie...)
Doch begrijp ik dat iemand er niet de moeite in gaat steken als je maar 1 form hebt. Daarom dat ik de code wil delen.

Echter ben ik een site aan het ontwikkelen met veel forms (in modal windows, als wizard)
Helaas geen form-parser. Weet niet hoe ik dat zou moeten aanpakken. te veel variabelen

[ Voor 9% gewijzigd door g4wx3 op 22-07-2008 00:17 ]

[Gomez12]

g4wx3 schreef op dinsdag 22 juli 2008 @ 00:09:
dat voorbeeldje deed niet meer dan het printen van deze code;

HTML:

<form method="post" action="index.php">
<fieldset>
<legend>Setup database connection</legend>
<input type="hidden" name="form" value="setup0">
<ul class="formmargin">
<li><label for="server"><span>Database url</span><input id="server" name="server" value="localhost" type="text" class="input"></label></li>
<li><label for="username"><span>Username</span><input id="username" name="username" value="root" type="text" class="input"></label></li>
<li><label for="password"><span>Password</span><input id="password" name="password" value="root" type="text" class="input"></label></li>
<li><input value="Next" type="submit" class="input submit"></li>
</ul>
</fieldset>
</form>

Zeker ik nu de code voor me zie, ben ik blij dat ik alles met een klasse parse (al m'n html trouwens)

Tsja, laat ik het zo zeggen daar verschil ik van mening over. IMHO ben je dan meer bezig met een paar extra parsing lagen erbovenop te bouwen.

De geproduceerde html wil ik zo af toe nog wel eens aanpassen ( mobile phone sites bijv. )
Zo af en toe wil ik de hele form niet publiceren ( pdf / print-variant bijv. )
Zo af en toe wil ik extra javascript aan een input veld hangen ( rich client suggest box bijv. )

Omdat al de bovengenoemde suggesties niet alleen maar voor forms opgaan, maar meer voor de totale pagina voel ik meer voor een template voor de betreffende client die alleen de view laag aanpast waardoor de business logica wel gecached kan worden ipv een classe die een beetje zelfstandig output genereerd...

Sowieso dient al mijn business logica ongeacht het platform uitgevoerd te worden. Oftewel er moet in dit geval altijd om een login gevraagd worden, hoe het login scherm eruitziet dat is imho geen php-werk meer, maar gewoon template werk.

Op zich is het idee achter je classe niet verkeerd, alleen verwacht ik ipv $form = new form de tekst $template->form = new form. De classe bepaalt geen output, de template bepaalt de output, de classe kan alleen iets aangeven aan de template...

[g4wx3]

ik zie wat je bedoeld.
Ipv html te genereren in de classe van html-objecten, het doen in de template.

De html objecten, zoals form, bouw ik eerst op, zoals voorbeeld, en geef ze daarna door aan de template:
$template->new_object($form),
De hele pagina krijg je met volgend commando
$template->get_html()

Dez methode doet echter alleen maar het oprvragen van html, van de opgegeven objecten.
$form->get_html().
Ipv data op te vragen, en zelf html te maken met die data.


Ik zal erover nadenken als het project al uitgeefbaar is.

*Javascript is mogelijk op iedere deel van het form, alle elementen zijn bereikbaar via javascript.
"unobstructive javascript"

[HawVer]

#$%@#$ Collega van mij heeft een trigger gemaakt die automatisch verkoopregels opsplitst. Nou werkt het toewijzen van artikelen niet meer, automatisch bestellen werkt niet meer, voorraad wordt niet goed bijgehouden. Of we dat even willen aanpassen...

[Woy]

g4wx3 schreef op maandag 21 juli 2008 @ 23:38:
Ik ben ooit een klasse begonnen om wat formulieren makkelijk in een te steken. Naarmate ik meer dingen nodig had, heb ik deze er ook op geımplementeerd. Hij is nog niet af, maar hij voldoet aan mijn behoeften. (aangezien ik hem zelf steeds uitbreid)
Ik zou graag de 300 regels code met jullie delen, vooral om hem te verbeteren, maar ook dat jullie er ook gebruik van kunnen maken.
Mijn vraag: Zijn er geïntreseerden? Waar kan ik dit het beste posten?

*De klasse voldoet aan mijn behoefte, ik vraag niemand code werk.
Ik heb nooit PHP oid gestudeerd, maar op deze manier zou ik graag wel wat extra ervarng willen opdoen.

EDIT:

Een typisch voorbeeld om de klasse te gebruiken:

PHP:

<?php

$form = new FORM('setup0');

$form->set_title('Setup database connection');
$form->set_method('post');
$form->set_action('index.php');

$form->set_input('server');
$form->server->set_label('Database url');
$form->server->set_type('text');
$form->server->set_value($server);

$form->set_input('username');
$form->username->set_label('Username');
$form->username->set_type('text');
$form->username->set_value($username);

$form->set_input('password');
$form->password->set_label('Password');
$form->password->set_type('text');
$form->password->set_value($password);

$form->set_input('submit');
$form->submit->set_type('submit');
$form->submit->set_value('Next');
?>

*set_input is was een slechte naam voor wat de methode eigenlijk doet:
Het maakt een nieuw object van een andere classe met deze naam. In deze clase zijn methoden om je input velden (ea) op te stellen
Zo zijn er dus tal van slordigheden in de classe, die ik al over het hoofd zie ondertussen.

Waarom zet je dit in het Slechtste programmeervoorbeelden topic? Vind je het zelf een slecht voorbeeld?

[ Voor 89% gewijzigd door Woy op 22-07-2008 09:03 ]

[TeeDee]

g4wx3 schreef op dinsdag 22 juli 2008 @ 00:09:
Zeker ik nu de code voor me zie, ben ik blij dat ik alles met een klasse parse (al m'n html trouwens)

Pardon? Waarom wil je in godsnaam alle HTML parsen door PHP? Je hebt sowieso al de tegenargumenten van Gomez12, maar stel je eens een kleine wijziging voor als je ineens op asp.net aan de slag moet en al de html wordt in de codebehind aangemaakt.

offtopic:
buiten het feit dat ik het een rare opvatting vind, waarom staat dit in dit topic?

[Janoz]

Gomez12 schreef op maandag 21 juli 2008 @ 23:41:
Q: Wat is eigenlijk het devies met commentaar?

Op dit moment ben ik met nog een aantal mensen bezig aan een project en daar komt op zich alleen het hoogstnoodzakelijke commentaar in voor. Iedereen die erbij betrokken is kan de huidige code zo lezen en schrijven, hier is heel weinig geen commentaar voor nodig.

Nu hebben we een nieuwe aanwinst bij ons project en die kan de code niet lezen en schrijven. Hij vraagt dan ook om meer commentaar, alleen voor de huidige proggers is het gewoon duidelijk...

Net zoals je aan een wiskundige geen stelling van pythagoras hoeft uit te leggen, aan een C-progger geen pointers hoeft uit te leggen, volstaat onze huidige commentaar vorm goed voor de huidige proggers.
Nu is de vraag, zijn er regels wat er wel / niet gecommentariseerd moet worden of is dit meer een groepsgevoel?

Want ik gok dat als de nieuwe progger in dit topic code gaat posten ( nadat hij nederlands geleerd heeft ) dat velen het met hem eens zouden zijn dat het slechte code betreft, maar de huidige proggers snappen het 100%, wij zijn ook best bereid om wat meer commentaar te schrijven, maar we gaan niet elke regel becommentariseren...

offtopic:
Het betreft hier geen bedrijf, maar een OpenSource programma. Wij zijn dus blij met ongeveer elke extra progger, keiharde kenniseisen zijn dus ook niet echt te stellen

Ik denk dat je met "onze huidige commentaar vorm goed voor de huidige proggers" behoorlijk de crux te pakken hebt. Blijkbaar volstaat het alleen voor programmeurs die al in de code zitten. Zeker met een open source project lijkt het me dat je dan te weinig commentaar hebt.

Met zekerheid kan ik het natuurlijk niet zeggen zonder dat ik een stuk code heb gezien en/of het niveau van de nieuwe progger ken. In mijn optiek moet iig van een methode of functie de pre en post condities opgegeven worden zodat je, enkel aan het stuk commentaar kunt zien wat de methode doet (let op, niet 'hoe', maar 'wat'!), wat alle parameters zijn, wat er aan de parameters veranderd is nadat de methode uitgevoerd is, wat er terug gegeven wordt en hoe het op randcondities reageert (mogen parameters null zijn bv).

Daarnaast moet je bij wat niet voor de hand liggende constructies of een optimalisatie aangeven waarom je dat gedaan hebt. Stel je hebt een lus die je uit efficientie overwegingen van achter naar voor laat lopen, beschrijf dan waarom je dat gedaan hebt zodat een volgende programmeur er niet een beter leesbare van voor naar achter lus van maakt. Hetzelfde geld ook met een '+1' of '-1' die je vaak bij indexen gebruikt.

[LinuX-TUX]

HawVer schreef op dinsdag 22 juli 2008 @ 08:59:
#$%@#$ Collega van mij heeft een trigger gemaakt die automatisch verkoopregels opsplitst. Nou werkt het toewijzen van artikelen niet meer, automatisch bestellen werkt niet meer, voorraad wordt niet goed bijgehouden. Of we dat even willen aanpassen...

offtopic:
Doet me denken aan: http://halbot.haluze.sk/images/2008-06/4231_idiots.png uit sh4d0wman in "Het grote grappige plaatjes topic deel 18"

[ Voor 8% gewijzigd door LinuX-TUX op 22-07-2008 09:26 ]

[Verwijderd]

rwb schreef op dinsdag 22 juli 2008 @ 09:03:
[...]

Waarom zet je dit in het Slechtste programmeervoorbeelden topic? Vind je het zelf een slecht voorbeeld?

Mijn vraag: Zijn er geïntreseerden? Waar kan ik dit het beste posten?

Hij zit dus iig in het verkeerde topic, maar het mooie is dat er wel commentaar op komt

[Guldan]

Gomez12 schreef op maandag 21 juli 2008 @ 23:41:
Q: Wat is eigenlijk het devies met commentaar?

Op dit moment ben ik met nog een aantal mensen bezig aan een project en daar komt op zich alleen het hoogstnoodzakelijke commentaar in voor. Iedereen die erbij betrokken is kan de huidige code zo lezen en schrijven, hier is heel weinig geen commentaar voor nodig.

Nu hebben we een nieuwe aanwinst bij ons project en die kan de code niet lezen en schrijven. Hij vraagt dan ook om meer commentaar, alleen voor de huidige proggers is het gewoon duidelijk...
[/offtopic]

Ik zou persoonlijk een iets andere denkwijze pakken en denken... Stel je dat of een van je collega's over een 4tal maand (waarin je de helemaal niet met het project bezig bent geweest) het weer opent en er iets moet aan passen. Snappen jij en je collega's dan nog waar het over gaat met het huidige commentaar? nee, dan moet je er meer bijzetten en als je het wel snapt dan kan je het zo laten. Je kan ook gewoon ff een paar simpele richtlijnen op papier zetten m.b.t het commentaar zodat je het net wat uitgebreider maakt en de nieuweling het ook snapt. De gouden middenweg dus.

[Cartman!]

g4wx3 schreef op maandag 21 juli 2008 @ 23:38:
Een typisch voorbeeld om de klasse te gebruiken:

PHP:

<?php

$form = new FORM('setup0');
?>

Kijk eens naar Zend_Form

[HawVer]

LinuX-TUX schreef op dinsdag 22 juli 2008 @ 09:25:
[...]

offtopic:
Doet me denken aan: http://halbot.haluze.sk/images/2008-06/4231_idiots.png uit sh4d0wman in "Het grote grappige plaatjes topic deel 18"

die ga ik hier rondsturen..

[418O2]

Vooropgesteld: Ik ben _geen_ goede programmeur. Kan niet abstract genoeg denken. Doe ook niet supermoeilijke applicaties, maar ik red mezelf prima.

Voor een klant ben ik bezig om een applicatie bugfree te maken. Het is een vrij uitgebreide, niet georganiseerd, niet object-georienteerde sequentieel geprogrammeerde applicatie. Paar ergenissen

Elke pagina heeft een eigen html opmaak zonder stylesheet en wordt in een frame geladen.
Tabellen hebben vrijwel nooit auto-increment key's. De key's zijn user-input
Er is NIET over nagedacht.

Ergenissen!

PHP:

 if(!$flag_odb && !$flag_odb && preg_match("/^;/",$regel))
         {
            $flag_act = true; 
         }

[ Voor 9% gewijzigd door 418O2 op 23-07-2008 12:19 ]

[Michali]

Hehe, 1 keer controleren is niet genoeg, voor de zekerheid nog maar een keertje.

Beetje vreemd ingesprongen ook.

[AtleX]

Michali schreef op woensdag 23 juli 2008 @ 15:31:
Beetje vreemd ingesprongen ook.

Ik zat pas geleden code te bekijken waar het eerste niveau 5 spaties ingesproken was, het 2e 8 spaties, en de rest 9 spaties, dus:

code:

if (true)
{
     // 1e niveau
     {
        // 2e niveau
        {
         // 3e niveau
         {
         // 4e niveau
         {
         }
         }
        }
     }
}

Totaal onleesbaar.

[ Voor 8% gewijzigd door AtleX op 23-07-2008 15:39 ]

[Woy]

In dit geval zal het vreemde inspringen waarschijnlijk komen omdat het gecopy paste is en dus eigenlijk al een paar nivo's diep zit.

[Gomez12]

AtleX schreef op woensdag 23 juli 2008 @ 15:39:
[...]

Ik zat pas geleden code te bekijken waar het eerste niveau 5 spaties ingesproken was, het 2e 8 spaties, en de rest 9 spaties, dus:

code:

if (true)
{
     // 1e niveau
     {
        // 2e niveau
        {
         // 3e niveau
         {
         // 4e niveau
         {
         }
         }
        }
     }
}

Totaal onleesbaar.

Tsja, hangt ervan af. Als jij een coding standaard hanteert die je tekstbreedte limiteert op 80 tekens en je spreekt af dat je onder normale omstandigheden maar max 2-niveaus diep mag gaan dan kan ik dit best begrijpen en heen ten dage ken ik nog steeds enkele bedrijven die dit soort coding standards aanhangen.

Zo hebben wij bijvoorbeeld voor svn exports een macro eraan hangen die indent op 2 spaces en afbreekt na 80 tekens. Op 1600x1200 is dit een ramp om te lezen ( deze macro hangt dus niet aan de checkout ) maar op een server-console van 80x40 is dit weer perfect te lezen.

[tweakerbee]

Java:

TermEnum terms = ir.terms()
while(terms.term()!=null) {
    term = terms.term();
    // doe iets met term
    terms.next();
}

Betrapte ik mijzelf net op (geschreven toen ik net bezig was met Java. Het is geen hele grote wtf, maar toch...

spoiler:

terms.next() geeft inderdaad een boolean terug

[4of9]

misschien moet je iets aan je naamgeving doen.

terms.term()
term, terms, TermEnum... niet echt duidelijk wat nu een term, terms, etc. allemaal doen/zijn voor iemand die jou code aan gaat passen, of voor jezelf als je na 6 maanden weer eens naar je code kijkt.

In java is het toch gebruikelijk om get en set methoden te schrijven:

terms.getTerm(); etc.

[Marcj]

En de next() functie zou volgens mij ook prima een object kunnen teruggeven. Als je deze dan hasNext() noemt...

[.oisyn]

4of9 schreef op vrijdag 25 juli 2008 @ 13:39:
misschien moet je iets aan je naamgeving doen.

terms.term()
term, terms, TermEnum... niet echt duidelijk wat nu een term, terms, etc. allemaal doen/zijn voor iemand die jou code aan gaat passen, of voor jezelf als je na 6 maanden weer eens naar je code kijkt.

Ik vind je opmerking onzinnig en toepasbaar op elke willekeurige 6 regels code uit elk project. Jij weet niet wat de context is, en daarom ook niet wat met 'term' bedoeld wordt. Wat niet wegneemt dat 'term' wel een gewoon woord is wat in meerdere contexten gewoon valide gebruikt kan worden.

Dit nog even volledig naast het feit dat TermEnum waarschijnlijk niet eens z'n eigen klasse is: [google=TermEnum]

[Salandur]

waarom implementeer je niet de Iterator interface? dan heb je gelijk de juiste naamgeving te pakken

[Robtimus]

4of9 schreef op vrijdag 25 juli 2008 @ 13:39:
misschien moet je iets aan je naamgeving doen.

terms.term()
term, terms, TermEnum... niet echt duidelijk wat nu een term, terms, etc. allemaal doen/zijn voor iemand die jou code aan gaat passen, of voor jezelf als je na 6 maanden weer eens naar je code kijkt.

In java is het toch gebruikelijk om get en set methoden te schrijven:

terms.getTerm(); etc.

*kuch* Javadoc *kuch*

Elke class, method of field (iig public en protected) hoort dat gewoon te hebben, met een duidelijke uitleg over wat het doel is en bij methods wat ze doen.

Dat zou dus voor term() en TermEnum het geval moeten zijn.

Maar ik ben het ook met Salandur eens, dit zou gewoon een Iterator (of desnoods Enumeration) moeten zijn.

[4of9]

.oisyn schreef op vrijdag 25 juli 2008 @ 15:24:
[...]

Ik vind je opmerking onzinnig en toepasbaar op elke willekeurige 6 regels code uit elk project. Jij weet niet wat de context is, en daarom ook niet wat met 'term' bedoeld wordt. Wat niet wegneemt dat 'term' wel een gewoon woord is wat in meerdere contexten gewoon valide gebruikt kan worden.

Dit nog even volledig naast het feit dat TermEnum waarschijnlijk niet eens z'n eigen klasse is: [google=TermEnum]

Wat ik bedoelde is dat bijna alle variabelen en methoden etc. "Iets"met term erin hebben. term, terms, term(), TermEnum. Ik vind dat gewoon niet helder. Ik zie ook wel eens code waar heel veel ints in loopjes gebruikt worden , i, j, y, z en dat allemaal door elkaar gebruikt. Ik vind dat niet echt duidelijk. Zeker niet als je na 6 maanden weer naar je code kijkt en je moet er een bugje uithalen.

Ik zeg ook niet dat term niet valide is, ik vind het alleen niet duidelijk. Maar dat is meer een discussie over onderhoudbare en leesbare code. Als je bijvoorbeeld het boek "code complete" leest staat daar erg veel over in.

[RobIII]

4of9 schreef op vrijdag 25 juli 2008 @ 19:27:
Wat ik bedoelde is dat bijna alle variabelen en methoden etc. "Iets"met term erin hebben. term, terms, term(), TermEnum. Ik vind dat gewoon niet helder.

Java:

CustomerEnum customers = ir.customers()
while(customers.customer()!=null) {
    customer = customers.customer();
    // doe iets met customer
    customers.next();
}

Tja.... ik zie het verschil niet zo; kom dit dagelijks tegen (los van de WTF dan )

[.oisyn]

Exact. Je hebt een lijstje met termen. Goh, hoe zou je dat nou noemen... 'terms' wellicht?

Idd, als je functie 8 pagina's beslaat en je gebruikt de variabele daarna nog eens dan is het wellicht handiger om wat specifieker te zijn in bepaalde situaties. Maar die situatie is hier niet evident, en als je functie 8 pagina's beslaat is er wel meer aan de hand. Mijn punt blijft dat je over deze 6 regels code zonder context weinig over naamgeving ('terms' en 'term', de rest is niet eens in de handen van de poster) kunt zeggen. Variabelen met een korte lifetime behoeven geen 30 karakter namen die hun doel tot in detail beschrijven - dat blijkt namelijk gewoon heel duidelijk uit de lokale code.

[ Voor 76% gewijzigd door .oisyn op 25-07-2008 20:29 ]

[Verwijderd]

HawVer schreef op dinsdag 22 juli 2008 @ 08:59:
#$%@#$ Collega van mij heeft een trigger gemaakt die automatisch verkoopregels opsplitst. Nou werkt het toewijzen van artikelen niet meer, automatisch bestellen werkt niet meer, voorraad wordt niet goed bijgehouden. Of we dat even willen aanpassen...

Dat heeft weinig of niets te maken met slechtste programmeervoorbeelden te maken, maar alles met beroerde quality assurance (testen!) en je klant(en) opzadelen met wijzigingen die nog niet eens 't beta stadium hebben gehaald.
Elke ontwikkelaar weet dat 'ie bij wijzigingen in de business logic andere dingen omzeep kan helpen, en kan dit testen voor 't deel dat 'ie kan overzien, maar da's meestal niet voldoende.

Vandaar het belang van unit tests, uitgebreide testscripts en 1 of meerdere personen buiten het ontwikkelteam die de wijziging vrijgeeft voor release nadat alle tests goed zijn doorlopen.

[Verwijderd]

418O2 schreef op woensdag 23 juli 2008 @ 12:18:
Tabellen hebben vrijwel nooit auto-increment key's. De key's zijn user-input
Er is NIET over nagedacht.

Ik ken jouw situatie verder niet, maar op mijn werk heeft geen enkele tabel een synthetische (auto-increment/identity/whatever) key.
Bij de dynamische tabellen wordt de key gegenereerd door een stored procedure, en bij de statische tabellen (stamgegevens) is 't idd aan de user om de key in te geven (wel met voldoende checks natuurlijk).
Niks mis mee om in bv een landentabel de landcode als PK op te nemen, of in een artikelentabel de PLU-code. Beiden dienen sowieso al uniek te zijn, dus zijn uitstekend geschikt om als primary key te dienen.

[Gomez12]

Verwijderd schreef op zaterdag 26 juli 2008 @ 00:25:
[...]
Dat heeft weinig of niets te maken met slechtste programmeervoorbeelden te maken, maar alles met beroerde quality assurance (testen!) en je klant(en) opzadelen met wijzigingen die nog niet eens 't beta stadium hebben gehaald.
Elke ontwikkelaar weet dat 'ie bij wijzigingen in de business logic andere dingen omzeep kan helpen, en kan dit testen voor 't deel dat 'ie kan overzien, maar da's meestal niet voldoende.

Vandaar het belang van unit tests, uitgebreide testscripts en 1 of meerdere personen buiten het ontwikkelteam die de wijziging vrijgeeft voor release nadat alle tests goed zijn doorlopen.

En je zal er versteld van staan hoeveel programmeerbedrijfjes hier nog nooit van gehoord hebben.
Ik ken redelijk wat programmeurs en hun test-omgevingen. Ongeveer 90% van de test-omgevingen is niet reeel als ik het met een klant van hun vergelijk.

Mensen buiten het ontwikkelteam die wijzigingen vrijgeven is leuk in theorie, maar bij bedrijven met weinig personeel krijg je of een telefoniste die niet 100% snapt hoe het programma werkt of iemand van binnen het ontwikkelteam. En als je een beetje maatwerk doet en veel snel moet opleveren wordt het testen alleen maar erger...

[Gomez12]

Verwijderd schreef op zaterdag 26 juli 2008 @ 00:59:
[...]
Niks mis mee om in bv een landentabel de landcode als PK op te nemen, of in een artikelentabel de PLU-code. Beiden dienen sowieso al uniek te zijn, dus zijn uitstekend geschikt om als primary key te dienen.

In theorie kan een landcode veranderen en vaker voorkomen. Theoretisch kan je hier dus een probleem mee krijgen.

PLU codes zijn voor zover ik weet altijd 100% tijdsgebonden, ze moeten uniek zijn op een enkel moment, maar als je de ene eruitgooit dan kan je er best een ander artikel aan hangen. Dus imho rampzalig voor je historisch overzicht...

Op zich is het allemaal niet erg als je het leuk vind om tussen je historie en je actieve data andere PK's te hebben voor dezelfde artikelen. Maar zolang je niet aan BI doet lijkt me dit alleen maar moeilijk doen... Neem gewoon een unieke PK die ook uniek blijft...

[Verwijderd]

4of9 schreef op vrijdag 25 juli 2008 @ 13:39:
In java is het toch gebruikelijk om get en set methoden te schrijven:

terms.getTerm(); etc.

Jep, net als in alle andere OO omgevingen.
Maar als je dan terms.getTerm() gaat aanroepen (als je dat al kunt) ipv de terms.term property die zelf terms.getTerm() doet, ga je voorbij aan het hele OO idee.
Getters en setters zijn niet public, en horen aangesproken te worden door de bijbehorende property.

[Verwijderd]

Gomez12 schreef op zaterdag 26 juli 2008 @ 01:08:
In theorie kan een landcode veranderen en vaker voorkomen. Theoretisch kan je hier dus een probleem mee krijgen.

In theorie zou dat kunnen, maar dan vallen een aantal ISO standaards om. De kans daarop is dus erg klein.

PLU codes zijn voor zover ik weet altijd 100% tijdsgebonden, ze moeten uniek zijn op een enkel moment, maar als je de ene eruitgooit dan kan je er best een ander artikel aan hangen. Dus imho rampzalig voor je historisch overzicht...

Artikel codes blijven hardnekkig PLU codes genoemd worden, maar zijn al lang niet meer gebonden aan een bepaalde toets op de kassa. En zowel op de database als client side is prima af te vangen dat een eenmaal ingesteld artikel niet vervangen kan/mag worden wanneer deze in het verleden al gebruikt is bij die PLU.

Dus het niet gebruiken van synthetische keys hoeft je statistieken / business intelligence / data mining routines absoluut niet te benadelen.
Bij het gebruik van auto increment / identity keys moet je in je applicatie ook zorgen dat je bv. geen doublures krijgt om je statistieken niet te vervuilen, dus dat maakt eigenlijk niks uit.

[Zoijar]

Ik schreef deze een paar dagen terug... heeft me wat tijd gekost om te debuggen. Twee containers en de ene moet uitgebreid worden zodat ze uiteindelijk evenveel elementen bevatten.

C++:

for (int i=0; i<container2.size() - container1.size(); ++i) {
   container1.push_back(filler_item);
}

Oh, en deze zat er ook per ongeluk tussen

C++:

for (size_t y=height-1; y >= 0; --y) { // do stuff }

*zucht*

[ Voor 18% gewijzigd door Zoijar op 26-07-2008 10:44 ]

[MLM]

Hmm, gevalletje meer koffie of meer slaap nodig. De eerste is inderdaad echt moeilijk te vinden, ZEKER als je em zelf geschreven hebt.

De 2e zie ik zo snel niet, tenzij height 0 is...

[Zoijar]

MLM schreef op zaterdag 26 juli 2008 @ 10:58:
Hmm, gevalletje meer koffie of meer slaap nodig. De eerste is inderdaad echt moeilijk te vinden, ZEKER als je em zelf geschreven hebt.

De 2e zie ik zo snel niet, tenzij height 0 is...

Nee, height is niet 0. Die is dan ook lastig te zien size_t is wel unsigned... (hier tenminste)

[Jaap-Jan]

Los daarvan lijkt het mij handiger te zijn om een while- loop te gebruiken:

C++:

while (container1.size() < container2.size()) {
   container1.push_back(filler_item);
}

Of als je van micro- optimalisaties houdt en niet constant size() wil aanroepen:

C++:

int add_fillers = container2.size() - container1.size();

for (int i = 0; i < add_fillers; ++i) {
    container1.push_back(filler_item);
}

Bij die tweede, als dit er letterlijk zo stond, dan heb je je sluitbracket uitgecommentarieerd. Dat is toch niet de WTF hier

[Zoijar]

Jaap-Jan schreef op zaterdag 26 juli 2008 @ 11:44:
Los daarvan lijkt het mij handiger te zijn om een while- loop te gebruiken:

C++:

while (container1.size() < container2.size()) {
   container1.push_back(filler_item);
}

Of als je van micro- optimalisaties houdt en niet constant size() wil aanroepen:

Het is nu die tweede geworden. while is eigenlijk nog simpeler idd.

Bij die tweede, als dit er letterlijk zo stond, dan heb je je sluitbracket uitgecommentarieerd. Dat is toch niet de WTF hier

Oh, sorry, nee dat is het niet. Denk je dat deze loop ooit eindigt? Een unsigned type is meestal wel groter gelijk 0

[ Voor 10% gewijzigd door Zoijar op 26-07-2008 12:34 ]

[PrisonerOfPain]

Jaap-Jan schreef op zaterdag 26 juli 2008 @ 11:44:
Of als je van micro- optimalisaties houdt en niet constant size() wil aanroepen:

In het geval van een vector en een deque is de performance van size() O(1) maar over het algemeen moet je uit gaan van een O(n) performance voor die operatie; in dat geval is het zeker verstandig om toe te passen.

[RayNbow]

Zoijar schreef op zaterdag 26 juli 2008 @ 12:34:
[...]

Oh, sorry, nee dat is het niet. Denk je dat deze loop ooit eindigt? Een unsigned type is meestal wel groter gelijk 0

Deze fout heb ik een keer gemaakt bij het uitbreiden van een compiler voor een simpele taal. Unsigned ints zijn evil voor lusconstructies.

[.oisyn]

Zoijar schreef op zaterdag 26 juli 2008 @ 12:34:
[...]

Het is nu die tweede geworden. while is eigenlijk nog simpeler idd.

Noem me gek, maar:

C++:

container1.resize(container2.size() - container1.size(), filler_item);

Of iets als:

C++:

std::fill_n(std::back_inserter(container1), container2.size() - container1.size(), filler_item);

maar dan prefereer ik toch die eerste, wegens het feit dat hij altijd maar 1 herallocatie doet als nodig (tenzij het een list is natuurlijk, maar dan maakt het niet uit, dus zelfs als je het type van de container niet weet is de eerste variant handiger).

[ Voor 40% gewijzigd door .oisyn op 26-07-2008 15:14 ]

[Jaap-Jan]

.oisyn schreef op zaterdag 26 juli 2008 @ 15:09:
[...]

Noem me gek, maar:

C++:

container1.resize(container2.size() - container1.size(), filler_item);

Of iets als:

C++:

std::fill_n(std::back_inserter(container1), container2.size() - container1.size(), filler_item);

maar dan prefereer ik toch die eerste, (...)

Ik niet, want die is fout :

C++:

container1.resize(container2.size(), filler_item);

[Zoijar]

True, maar ik moest nog wat andere dingen doen in die loop, zoals de objecten initialiseren

[Paul C]

Wilde ik net verder gaan met een projectje dat al even stil ligt, kom ik dit tegen:

PHP:

if($user['imageurl'] != "" AND FALSE) {
    echo "<img src=\"" . $user['imageurl'] . "\">";
}

Tja, als je niet wilt escapen?

[Verwijderd]

Mwah, zoiets wordt wel vaker gedaan hoor, zo raar is dat niet.

Al is het wel vreemd in deze situatie kan dat gewoon gewoonte zijn.

Bij het debuggen en testen vind ik een dergelijke constructie (al zou ik em vooraan zetten en wat commentaar erbij wie wanneer waarom dat daar neer heeft gezet) beter dan een hele lading regels wegcommenten.

(Los van het feit dat de image zo geen alt eigenschap heeft en je even moet validaten of er wel een URL in die image gepropt is, maar ik neem aan dat die validatie al eerder plaatsvindt. Toch? )

[ Voor 23% gewijzigd door Verwijderd op 12-08-2008 00:09 ]

[Paul C]

Daar ben ik het dan weer niet helemaal mee eens. Als je namelijk weg comment is door de syntax highlighting meteen duidelijk dat de code buiten werking is gesteld, maar zo ziet het er in eerste instantie gewoon als code uit. Het valt zeker niet op als het ook nog eens een paar levels diep zit genest, dan moet je echt even goed de code lezen.

[Erkens]

Tijdens het debuggen zelf doe ik dat soort dingen ook, maar zodra ik klaar ben gaat het er gewoon weer uit. Het is vooral handig om 'else if' constructies te testen zonder de hele boel te moeten verbouwen

[g4wx3]

dit doe ik ook vaak eigenlijk. Het gebeurd wel eens dat ik dat ondertussen vergeten ben, en zit te zoeken waarom iets niet gaat, of dat ik juist nooit meer last ervan heb, dus zogenaamde spahetti code..

Ja dat is niet goed, maar als ik voel dat iets zo goed als af is ga ik wel eens opnieuw alles na optimaliseren en herbewerken, daar heb ik dan ook wel veel tijd voor nodig, omdat ik soms de hele logica wel veranderen.

[mithras]

Voeg dan die message toe via een debuggin layer oid. Die vangt alle debug zooi op. Dan kan je dat optioneel naar bestand, stdout of /dev/null sturen

[Haan]

Even voor mijn begrip, wat gebeurt er in dat stukje php?

[Zoijar]

Haan schreef op dinsdag 12 augustus 2008 @ 13:00:
Even voor mijn begrip, wat gebeurt er in dat stukje php?

niet bijzonder veel

Maar ik gebruik dat soort contructies ook regelmatig om even iets uit te zetten.

[ Voor 17% gewijzigd door Zoijar op 12-08-2008 13:05 ]

[Haan]

Zoijar schreef op dinsdag 12 augustus 2008 @ 13:05:
[...]

niet bijzonder veel

Maar ik gebruik dat soort contructies ook regelmatig om even iets uit te zetten.

Herformulering van de vraag dan maar: Wat is die constructie hier dan?

[Zyppora]

Die 'AND FALSE' zorgt ervoor dat de conditie voor dat if statement altijd een 'false' oplevert, en dat de conditional statements nooit uitgevoerd worden (bijvoorbeeld om de else statements te testen). Persoonlijk zou ik, net als sommige anderen hier, gewoon kiezen om wat lijnen weg te commentariseren, maar op deze manier kan het ook.

[ Voor 25% gewijzigd door Zyppora op 12-08-2008 14:02 ]

[.oisyn]

Wegcommenten kan in dit geval wel, maar als je in de conditie een functie aanroept die je wilt blijven aanroepen, maar ongeacht de conditie de true of juist de false-case wilt uitvoeren, dan kan commenten al niet meer.

[Zoijar]

Het gaat mij vaker om een stuk code als dit:

C++:

if (some-condition) {
   // do stuff
   // for 50 lines
} else {
  // do other stuff
  // for 50 lines
}

Als je daar alleen de "else" code uit wilt voeren, dan moet je bij een comment de if() weghalen vanaf, zeg, regel 0, tot de "} else" op regel 50. Dat is irritant

[HawVer]

Zoijar schreef op dinsdag 12 augustus 2008 @ 17:04:
Het gaat mij vaker om een stuk code als dit:

C++:

if (some-condition) {
   // do stuff
   // for 50 lines
} else {
  // do other stuff
  // for 50 lines
}

Als je daar alleen de "else" code uit wilt voeren, dan moet je bij een comment de if() weghalen vanaf, zeg, regel 0, tot de "} else" op regel 50. Dat is irritant

50 regels per accolade zou ik persoonlijk een aparte methode van maken.

[.oisyn]

Daarnaast is zo'n stuk wegcommenten ook maar een paar keystrokes in een degelijke IDE

[Zoijar]

.oisyn schreef op dinsdag 12 augustus 2008 @ 18:13:
Daarnaast is zo'n stuk wegcommenten ook maar een paar keystrokes in een degelijke IDE

Maar je maakt snel een fout later, als je het steeds weer comment en uncomment. Dan vergeet je een keer een accolade en krijg je allemaal vage compiler errors, of je uncomment een stukje oorpronkelijk commented code en veradert zo de functionaliteit... Uiteraard is het commenten zelf een kwestie van shift-pagedown-pagedown-ctrl-k-c

[Haan]

Zoijar schreef op dinsdag 12 augustus 2008 @ 19:15:
[...]
Uiteraard is het commenten zelf een kwestie van shift-pagedown-pagedown-ctrl-k-c

Of gewoon een 1 muisklik op de juiste knop in Visual Studio

Ik kom ook weer wat moois van mijzelf tegen:

C#:

public void Bla()
{
  try
  {
     //doe iets
  }
  catch (AnException)
  { 
    //handel af
  }
  catch { throw; }
}

En dat bij iedere try-catch in het project

[.oisyn]

Haan schreef op donderdag 14 augustus 2008 @ 15:12:
[...]

Of gewoon een 1 muisklik op de juiste knop in Visual Studio

Ik durf wel te stellen dat een stuk of 5 keystrokes sneller is dan 1 muisklik als je aan het coden bent

[CodeCaster]

quote: http://nl.php.net/manual/en/function.session-start.php#83498

PHP:

function session_secure(){
    // wrapped for the php entry....
    $alph =array('A','a','B','b','C','c','D','d','E',
    'e','F','f','G','g','H','h','I','i','J','K','k',
    'L','l','M','m','N','n','O','o','P','p','Q','q',
    'R','r','S','s','T','t','U','u','V','v','W','w',
    'X','x','Y','y','Z','z');
    for($i=0;$i<rand(10,20);$i++){
        $tmp[] =$alph[rand(0,count($alph))];
        $tmp[] =rand(0,9);
    }
    return implode("",shuffle($tmp));
}

There are quicker ways like md5(time()*rand()), however the function above is completely random, and will render an attackers hijacking task almost impossible.

Ah yes, completely random...

[.oisyn]

Heh, dork. Mooi ook hoe hij elke keer rand() in de conditie van z'n for-loop aanroept.
Z'n code bugt trouwens op regel 9.

[ Voor 17% gewijzigd door .oisyn op 24-08-2008 23:17 ]

[Soultaker]

Stompzinige functie natuurlijk, maar door meerdere malen rand() aan te roepen genereert hij wel een meer random key dan een MD5 hash van de tijd en rand(), aangezien PHP's RAND_MAX onder Windows bijvoorbeeld slechts 32K is, en de tijd in seconden vaak te raden is.

Effectief is de weakest link nu dus waarschijnlijk PHPs automatische random seeding (of eventuele handmatige, maar die is hier niet te zien).

[RobIII]

Soultaker schreef op zondag 24 augustus 2008 @ 23:15:
Effectief is de weakest link nu dus waarschijnlijk PHPs automatische random seeding (of eventuele handmatige, maar die is hier niet te zien).

Dat PHP's eigennaardigheden 'm hier redden maakt het geen mindere WTF

[Verwijderd]

Mwah je wil eigenlijk ook niet iedere keer als je de functie aanroept gaan seeden.

[Soultaker]

RobIII schreef op zondag 24 augustus 2008 @ 23:18:
Dat PHP's eigennaardigheden 'm hier redden maakt het geen mindere WTF

Meer een geval van elk-nadeel-heb-ze-voordeel.

[ Voor 64% gewijzigd door Soultaker op 24-08-2008 23:34 ]

[.oisyn]

Soultaker schreef op zondag 24 augustus 2008 @ 23:15:
Effectief is de weakest link nu dus waarschijnlijk PHPs automatische random seeding (of eventuele handmatige, maar die is hier niet te zien).

Heb even in de sourcecode geneusd...

C:

// php_rand.h //////////////
#define GENERATE_SEED() (((long) (time(0) * getpid())) ^ ((long) (1000000.0 * php_combined_lcg(TSRMLS_C))))

// lcg.c ////////////////
/*
 * combinedLCG() returns a pseudo random number in the range of (0, 1).
 * The function combines two CGs with periods of 
 * 2^31 - 85 and 2^31 - 249. The period of this function
 * is equal to the product of both primes.
 */

#define MODMULT(a, b, c, m, s) q = s/a;s=b*(s-a*q)-c*q;if(s<0)s+=m

static void lcg_seed(TSRMLS_D);

PHPAPI double php_combined_lcg(TSRMLS_D)
{
    php_int32 q;
    php_int32 z;
    
    if (!LCG(seeded)) {
        lcg_seed(TSRMLS_C);
    }

    MODMULT(53668, 40014, 12211, 2147483563L, LCG(s1));
    MODMULT(52774, 40692, 3791, 2147483399L, LCG(s2));

    z = LCG(s1) - LCG(s2);
    if (z < 1) {
        z += 2147483562;
    }

    return z * 4.656613e-10;
}

static void lcg_seed(TSRMLS_D)
{
    struct timeval tv;

    if (gettimeofday(&tv, NULL) == 0) {
        LCG(s1) = tv.tv_sec ^ (~tv.tv_usec);
    } else {
        LCG(s1) = 1;
    }
#ifdef ZTS
    LCG(s2) = (long) tsrm_thread_id();
#else
    LCG(s2) = (long) getpid();
#endif

    LCG(seeded) = 1;
}

Oftewel puur en alleen afhankelijk van de process id en de huidige tijd in een microseconde granulariteit.

.edit: HAHAHA, de grootste grap is nog wel PHP's eigen documentatie van de getmypid() functie :

quote: http://nl.php.net/getmypid

Warning
Process IDs are not unique, thus they are a weak entropy source. We recommend against relying on pids in security-dependent contexts.

[ Voor 9% gewijzigd door .oisyn op 24-08-2008 23:42 ]

[CodeCaster]

Op de randomness na werd ik na het nog eens doorlezen van de code nieuwsgierig, en heb het even getest. De code is niet uit te voeren of functioneert niet omdat:
4: de 'j' mist
9: kans op een unidentified index (moet count-1 zijn) zoals .oisyn al aangaf
12: shuffle retourneert true of false, de gegeven array wordt geshuffled (by reference is dat?), niet geretourneerd.

Failer than fail

[ Voor 5% gewijzigd door CodeCaster op 24-08-2008 23:45 ]

[RobIII]

CodeCaster schreef op zondag 24 augustus 2008 @ 23:43:
Op de randomness na werd ik na het nog eens doorlezen van de code nieuwsgierig, en heb het even getest. De code is niet uit te voeren of functioneert niet omdat:
4: de 'j' mist
9: kans op een unidentified index (moet count-1 zijn) zoals .oisyn al aangaf
12: shuffle retourneert true of false, de gegeven array wordt geshuffled (by reference is dat?), niet geretourneerd.

Failer than fail

Da's dan ook precies 1 van de redenen waarom ik de PHP documentatie zo vind zuigen voor beginners; je hebt gewoon bij 'serieuze documentatie' allemaal meuk staan die beginners blind copy/pasten. Waarom plempen ze die (doorgaans useless) code niet achter een linkje of op een forum of whatever in plaats van op dezelfde pagina?

[Verwijderd]

Mwah soms staan er ook wel eens nuttige dingen bij.

Maar ze mogen best wat meer modden daar.

PHP documentatie is nooit echt iets geweest om over naar huis te schrijven en dat is eigenlijk alleen maar erger geworden.

[Feanathiel]

Waarom het gebeurd weet ik ook niet maar, omcasten (en controleren) van een variabele zie ik ook nog wel eens zo gebeuren:

code:

if( !! var ) { ... }

[opagrover]

Ik heb ooit eens een hele tijd gezocht naar een probleem met mijn code, zeer laat op de avond. Er was een stuk script dat wat met files en filenames moest doen.

if ($strFilename != "." || $strFilename != "/") {
... doe iets
}

En hij deed iets altijd! Het duurde even voordat ik het inzicht had dat een string nooit twee waarden tergelijketijd is, dus dat hij altijd niet . of niet / is.

[prototype]

opagrover schreef op maandag 25 augustus 2008 @ 14:58:
Ik heb ooit eens een hele tijd gezocht naar een probleem met mijn code, zeer laat op de avond. Er was een stuk script dat wat met files en filenames moest doen.

if ($strFilename != "." || $strFilename != "/") {
... doe iets
}

En hij deed iets altijd! Het duurde even voordat ik het inzicht had dat een string nooit twee waarden tergelijketijd is, dus dat hij altijd niet . of niet / is.

Dan denk ik dat de daadwerkelijke "WTF" je beredenering is.

Wat betreft het PHP gebash hier, hoe erg ik het ook waardeer (trust me, als geen ander ), zijn de mensen van Zend niet onderhand aan het overwegen om gewoon BC te breken en de taal zelf te fixen in een versie 7?

[ Voor 15% gewijzigd door prototype op 25-08-2008 15:16 ]

[Eijkb]

Uit "Show hier je website":

MrJey schreef op maandag 04 augustus 2008 @ 20:31:
By the way:

Deze code zorgt ervoor dat je geen geel driehoekje ziet.

code:

<script language="JavaScript"> 

function blockError(){return true;}

window.onerror = blockError;

</script>

Inmiddels herschreven tot:

code:

<script language="JavaScript"> 
function underCarpet(){return true;}
window.onerror = underCarpet;
</script>

[RayNbow]

Eijkb schreef op maandag 25 augustus 2008 @ 22:19:
Uit "Show hier je website":


[...]


Inmiddels herschreven tot:

code:

<script language="JavaScript"> 
function underCarpet(){return true;}
window.onerror = underCarpet;
</script>

Dit is toch véél beter?
 

JavaScript:

function constf(a) {
    return function(b){return a}
}
window.onerror = constf(true); // Functional Programming At Its Best :p

Alleen jammer dat const een keyword is in Javascript.

Edit:
Of voor wat Basic herinneringen...
 

JavaScript:

resumenext = constf(true);
window.onerror = resumenext;

[ Voor 11% gewijzigd door RayNbow op 25-08-2008 22:41 ]

[NMe]

Ik heb even wat berichtjes afgesplitst: PHP als loose typed taal.

[Sebazzz]

Mag Hyves erbij

PHP:

error_reporting(E_ALL);

Dit doe je simpelweg niet op een productiewebsite met weet ik hoeveel bezoekers.

[Verwijderd]

Mwah, dat heeft niets met PHP te maken.

In iedere taal moet je voor fatsoenlijke error afhandeling zorgen, dat ze dat bij Hyves niet doen... tjah.

Geeft ook wel aan dat de techniek niet op de 1e plaats hoeft te staan om een succesvolle site te runnen.

[kenneth]

Verwijderd schreef op dinsdag 09 september 2008 @ 15:35:
Mwah, dat heeft niets met PHP te maken.

Wie zegt dat dan?

[Verwijderd]

Verwijderd schreef op dinsdag 09 september 2008 @ 15:35:
Mwah, dat heeft niets met PHP te maken.

In iedere taal moet je voor fatsoenlijke error afhandeling zorgen, dat ze dat bij Hyves niet doen... tjah.

Geeft ook wel aan dat de techniek niet op de 1e plaats hoeft te staan om een succesvolle site te runnen.

Techniek niet op de eerste plaats bij Hyves?!

[Verwijderd]

kenneth schreef op dinsdag 09 september 2008 @ 16:19:
[...]
Wie zegt dat dan?

Sebazzz met het PHP voorbeeld, we weten niet of het zo inderdaad is bij Hyves en de fout staat los van PHP verder.

Verwijderd schreef op dinsdag 09 september 2008 @ 16:36:
[...]

Techniek niet op de eerste plaats bij Hyves?!

Lijkt me niet als ze niet eens aan fatsoenlijke error afhandeling doen.

Een error openbaar op een productieomgeving is toch wel het ergste ongeveer.

[writser]

Uit een ander topic

*snip*

Ook niet best

Zeker niet best gezien de topicwaarschuwing. Zet aub geen andere topics/users in de zeik wil je?

[ Voor 95% gewijzigd door Creepy op 09-09-2008 17:14 ]

[418O2]

Verwijderd schreef op dinsdag 09 september 2008 @ 16:41:
[...]

Sebazzz met het PHP voorbeeld, we weten niet of het zo inderdaad is bij Hyves en de fout staat los van PHP verder.


[...]

Lijkt me niet als ze niet eens aan fatsoenlijke error afhandeling doen.

Een error openbaar op een productieomgeving is toch wel het ergste ongeveer.

Dat is niet netjes, maar ik heb wel de overtuiging dat Hyves wel een bijzonder complexe techniek huisvest.

[Verwijderd]

Er kan altijd wat blijven steken, maar Hyves is juist een technisch hoogstandje op het gebied van webtechniek. Het is niet alsof er geen bugs in andere productiesoftware voorkomen, nietwaar

[Kwastie]

Verwijderd schreef op dinsdag 09 september 2008 @ 17:10:
Er kan altijd wat blijven steken, maar Hyves is juist een technisch hoogstandje op het gebied van webtechniek. Het is niet alsof er geen bugs in andere productiesoftware voorkomen, nietwaar

Ze hadden om z'n minst een error handler kunnen instellen die bijvoorbeeld errors in een log schrijft. En sowieso wil je niet dat je gebruikers fouten (met "technische informatie") voorgeschoteld krijgt.

[kenneth]

Verwijderd schreef op dinsdag 09 september 2008 @ 16:41:
[...]

Sebazzz met het PHP voorbeeld, we weten niet of het zo inderdaad is bij Hyves en de fout staat los van PHP verder.

Dat hij die code in PHP geeft zegt toch niet gelijk dat hij de schuld aan PHP geeft?

Verwijderd schreef op dinsdag 09 september 2008 @ 17:10:
Er kan altijd wat blijven steken, maar Hyves is juist een technisch hoogstandje op het gebied van webtechniek. Het is niet alsof er geen bugs in andere productiesoftware voorkomen, nietwaar

Als Hyves dat al is, dan vraag ik me af wat webapps als facebook en gmail wel niet zijn