Gathering of Tweakers

Het is alweer tijd voor deel 3 van deze succesvolle topicreeks.

Vorige delen:
[alg] slechtste prog voorbeelden.
[alg] Slechtste programmeervoorbeelden deel 2

Regels:
Uiteraard is het in dit topic niet de bedoeling dat andere users en/of topics aangehaald worden om ze voor gek te zetten. Lachen om je eigen code, of over dingen die je "wel eens tegengekomen bent" is prima, maar hou het onderling netjes.

Daarnaast is het niet de bedoeling dat je hier maar even snel een kort vraagje komt stellen. Als een vraag niet topicwaardig is, dan is hij wat dit forum betreft ook niet postwaardig.

Ik gisteren nog...
JavaScript:

1	...this.getElementsByTagName('img')[0]...

Het ging over een <a> met daarin een <img> die dynamisch was aangemaakt (via JS, userscripts)... iets zegt me dat gewoon "this.firstChild" ook had volstaan... (dit was btw in een onclick-eventhandler)

Alex) wijzigde dit bericht 21-07-2007 16:13 (8%)

Afhankelijk van het feit of het mogelijk is dat er whitespace of andere elementen binnen dat a element kunnen staan. Als dat niet zo is, had firstChild inderdaad wel volstaan. En dat scheelt flink wat overhead

JavaScript:

1 2 3 4 5

var link = document.createElement('a'); var image = document.createElement('img'); link.appendChild(image);

Daar zit geen whitespace tussen de <a> en de <img>, lijkt me...

@ oisyn, implode gaat hier helaas niet werken, tenzij ik met een 2de array ga werken natuurlijk.

quote:

Alex) schreef op zaterdag 21 juli 2007 @ 16:12:
Ik gisteren nog...
JavaScript:

1	...this.getElementsByTagName('img')[0]...

Het ging over een <a> met daarin een <img> die dynamisch was aangemaakt (via JS, userscripts)... iets zegt me dat gewoon "this.firstChild" ook had volstaan... (dit was btw in een onclick-eventhandler)

Ergens heb je wel gelijk. Je moet dan wel blijven opletten of het een dynamische img is of een die er al was. Bij de laatste is een enter al genoeg om je script te verpesten. Om fouten voor te zijn had ik waarschijnlijk ook 'jouw' constructie genomen. (Of de reference die je toch al hebt bij het dynamisch aanmaken gebruiken)

quote:

xtra schreef op maandag 23 juli 2007 @ 14:38:
[...]

Ergens heb je wel gelijk. Je moet dan wel blijven opletten of het een dynamische img is of een die er al was. Bij de laatste is een enter al genoeg om je script te verpesten. Om fouten voor te zijn had ik waarschijnlijk ook 'jouw' constructie genomen. (Of de reference die je toch al hebt bij het dynamisch aanmaken gebruiken)

Het is dynamisch aangemaakt - geen extra tekens dus

Aan die references heb ik niets omdat het om code binnen een eventhandler gaat en je dan dus een scope-issue krijgt... tenzij je ergens een public array (o.i.d.) bijhoudt met daarin alle objecten... maar dat maakt niet uit, inmiddels heb ik alles werkend. IE deed moeilijk, dus ik heb uiteindelijk mijn hele mooie document.createElement-constructie overboord moeten gooien en het moeten vervangen door iets met innerHTML

Het leek wel alsof IE de DOM niet updatete, in Fx had ik geen problemen maar IE vertelde doodleuk dat hij het object niet kende

Een abstracte klasse Document hebben waarop een hoop algemene afhandeling wordt gedaan.
Waarin een property staat met een harde verwijzing, zoiets als dit.
C#:

1	public virtual VenderXGrid Grid { get; }

En dan vervolgens een Document implementatie te hebben waarbij je VendorYGrid wilt gebruiken....

"Maar we wisselen toch nooit van Grid?" ...

quote:

Deathraven schreef op maandag 23 juli 2007 @ 15:27:
Een abstracte klasse Document hebben waarop een hoop algemene afhandeling wordt gedaan.
Waarin een property staat met een harde verwijzing, zoiets als dit.
C#:

1	public virtual VenderXGrid Grid { get; }

En dan vervolgens een Document implementatie te hebben waarbij je VendorYGrid wilt gebruiken....

"Maar we wisselen toch nooit van Grid?" ...

Mja ik vind het nog niet eens zo'n gekke gedachtengang. Ten eerste is het in heel veel gevallen zo dat er inderdaad nooit van vendor wordt gewisseld in de levensduur van een product. Daarnaast zou de enige oplossing zijn een generieke interface te maken die door zowel VendorX en VendorY worden geimplementeerd. Dit is veel werk en error-prone. Ik kan me goed voorstellen dat je zo'n ontwikkeling laat wachten tot het moment echt daar is. (wat misschien wel nu is )

Tjah daar valt ook wel weer iets voor te zeggen. Tis alleen nogal een rotwerk om uiteindelijk alles te gaan refactoren. Helemaal als je niet in een keer alles kan/mag omzetten. Dan moet je namelijk dubbele code gaan opnemen zodat de 2 dingen toch nog naast elkaar gebruikt kunnen worden (for the time being) ... bleeeehh

code:

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

var ajaxRequest; try{ ajaxRequest = new XMLHttpRequest(); } catch (e){ try{ ajaxRequest = new ActiveXObject("Msxml2.XMLHTTP"); } catch (e) { try{ ajaxRequest = new ActiveXObject("Microsoft.XMLHTTP"); } catch (e){ alert("Sorry, Notepad will not work with your browser."); return false; } } }

O my...

Ik kwam vandaag ook een mooie tegen:
Java:

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

if (wrappedData.length>32) {             // It is a wrapped RSA Private key without key reference info             return wrappedData;         }         else if (wrappedData.length<32) {             // It is a wrapped DES or 2DES key without key reference info             return wrappedData;         }         else {             // It is a wrapped DES or 2DES key with key reference info             int length = wrappedData[16];             byte[] wrappedDesKey = new byte[length];             System.arraycopy(wrappedData, 0, wrappedDesKey, 0, length);             return wrappedDesKey;         }

Volgens mij is 1 if zonder else's genoeg

quote:

Standeman schreef op vrijdag 03 augustus 2007 @ 15:29:
Ik kwam vandaag ook een mooie tegen:
Java:

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

if (wrappedData.length>32) {             // It is a wrapped RSA Private key without key reference info             return wrappedData;         }         else if (wrappedData.length<32) {             // It is a wrapped DES or 2DES key without key reference info             return wrappedData;         }         else {             // It is a wrapped DES or 2DES key with key reference info             int length = wrappedData[16];             byte[] wrappedDesKey = new byte[length];             System.arraycopy(wrappedData, 0, wrappedDesKey, 0, length);             return wrappedDesKey;         }

Volgens mij is 1 if zonder else's genoeg

ow? echt waar? en wat als de key exact 32 chars lang is?

quote:

LuCarD schreef op vrijdag 03 augustus 2007 @ 15:36:
[...]
ow? echt waar? en wat als de key exact 32 chars lang is?

Beter lezen

Het kan inderdaad met 1 if zonder else.

quote:

TRRoads schreef op vrijdag 03 augustus 2007 @ 15:39:
[...]

Beter lezen

Het kan inderdaad met 1 if zonder else.

hmm ik ging er vanuit dat hij een gedeelte code had weggelaten...

Hoewel het niet eens zo'n grote WTF is. Het kan goed zijn dat er eerst 3 verschillende acties stonden, maar bij achteraf nadenken en aanpassen dat dit eruit is gekomen.

Het maakt verder ook weinig uit denk ik, een beetje compiler zal dat stukje wel voor de je optimaliseren denk ik en anders nog.

Het was ook meer de leesbaarheid waar ik me aan stoorde.. En een echt grote WTF was het idd niet.

quote:

Standeman schreef op vrijdag 03 augustus 2007 @ 15:57:
Het was ook meer de leesbaarheid waar ik me aan stoorde.. En een echt grote WTF was het idd niet.

Ja maar, ja maar, er staat toch commentaar in?

Echt een 'slecht programmeervoorbeeld' is het niet maar toch een 'leuk' foutje/bugje dat ik vanmorgen had gemaakt.
Java:

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

quote:

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

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

Ik moest zelf ook even in de Java API kijken voordat ik het zag

quote:

Standeman schreef op vrijdag 03 augustus 2007 @ 15:29:
Ik kwam vandaag ook een mooie tegen:
Java:

1

...

Volgens mij is 1 if zonder else's genoeg

Daar ben ik het niet mee eens. Wat nou als er bij "wrapped DES or 2DES key without key reference info" opeens een extra functie moet worden toegevoegd?

De drie mogelijkheden zijn er gemaakt om de drie verschillende type keys duidelijk in de programmacode te scheiden, en ook om aan te tonen hoe je kunt zien of het een x, y of z key is. Het kan inderdaad korter, maar leesbaarder word het er niet op.

quote:

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

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

Oei oei, die is sneaky zeg

TRRoads wijzigde dit bericht 14-08-2007 16:58 (4%)

Nou zie ik geen toString() en/of assignment, maar volgens komt dat meer omdat dat gewoon weggelaten is in de quote. De issue is volgens mij wel dat er geen constructor bestaat voor char. Wel voor int, maar een char is toch niet impliciet te converteren naar int in Java, of wel?

.oisyn wijzigde dit bericht 14-08-2007 17:05 (11%)

quote:

TRRoads schreef op dinsdag 14 augustus 2007 @ 16:57:
[...]

Oei oei, die is sneaky zeg

offtopic:
Java ook altijd

Lol, ik had hem door.

Maar serieus, ik had hem al weleens gezien bij Java Puzzlers. Lekkere instinker.

Mark, ik neem aan dat dat statement gewoon ergens in real life code stond, tussen een stel ifs en zo? Dan kijk je er zo overheen.

quote:

.oisyn schreef op dinsdag 14 augustus 2007 @ 17:04:
Nou zie ik geen toString() en/of assignment, maar volgens komt dat meer omdat dat gewoon weggelaten is in de quote. De issue is volgens mij wel dat er geen constructor bestaat voor char. Wel voor int, maar een char is toch niet impliciet te converteren naar int in Java, of wel?

Wel dus. Jammergenoeg in zulke gevallen.

Wat het overigens lulliger maakt, is dat append(char) wel bestaat.

JKVA wijzigde dit bericht 14-08-2007 17:07 (7%)