[alg] Slechtste programmeervoorbeelden deel 4

[Bosmonster]

Daar is niks mis mee, maar wel een beetje weird dat PHP de code als string ingevoerd wil hebben. Wordt er nou niet bepaald mooier op...

[LuCarD]

.oisyn schreef op woensdag 17 april 2013 @ 12:32:
Niets mis met currying.

Nog nooit eerder gehoord over currying.... hmmm.. ik wordt er niet bepaald enthousaister na wat lezen. Maar kennelijk is het een geaccepteerde coding standaard

meer info:
http://zaemis.blogspot.nl/2009/06/currying-in-php.html

Enige gebruik die ik me kan voorstellen en zelf ook wel gebruik is de callback function. Maar om nou te zeggen goh wat een duidelijke code wordt het.... Nee.

Maar dat is een persoonlijke mening..

[.oisyn]

Bosmonster schreef op woensdag 17 april 2013 @ 12:38:
Daar is niks mis mee, maar wel een beetje weird dat PHP de code als string ingevoerd wil hebben. Wordt er nou niet bepaald mooier op...

Ik denk dat we het allemaal wel eens kunnen zijn dat create_function() inderdaad een gedrocht is . Maar dat een implemenatie van een op zich handige feature last heeft van de taal waarin hij geimplementeerd is maakt het niet direct een slecht codevoorbeeld. Maar gelukkig ondersteunt PHP tegenwoordig ook closures

LuCarD schreef op woensdag 17 april 2013 @ 12:51:
[...]


Nog nooit eerder gehoord over currying.... hmmm.. ik wordt er niet bepaald enthousaister na wat lezen. Maar kennelijk is het een geaccepteerde coding standaard

Het is vooral gangbaar in functionele talen. Je 'angst' is vooral gebaseerd op het feit dat je het niet kent omdat je het nauwelijks ziet in imperatieve talen, laat staan in PHP. Maar dat maakt het niet direct een raar of onleesbaar paradigma.

[ Voor 36% gewijzigd door .oisyn op 17-04-2013 13:02 ]

[LuCarD]

.oisyn schreef op woensdag 17 april 2013 @ 12:57:
[...]
Het is vooral gangbaar in functionele talen. Je 'angst' is vooral gebaseerd op het feit dat je het niet kent omdat je het nauwelijks ziet in imperatieve talen, laat staan in PHP. Maar dat maakt het niet direct een raar of onleesbaar paradigma.

Eens.... Mijn "angst" is gebaseerd op mijn ervaring, of in dit geval gebrek aan ervaring

[Intru]

Voor het leukere curry-werk kan je beter eens kijken bij Haskell: http://www.haskell.org/haskellwiki/Currying

[RayNbow]

Het leukere curry-werk vind je in Haskell's type-system.

[We Are Borg]

Maar eens een van mijn blunders delen Deze is van vandaag

PHP:

 $Query = "Select * From Table Where Order = '1'"

En maar afvragen waar die SQL syntax error vandaan komt

MySQL ja......

[Matis]

Ik weet niet wat ik erger vind, de integer die als char wordt gebruikt (al kom je er mee weg), geen LIKE voor het comparen van een string of het feit dat de zowel de tabel- en kolomnamen als ook de MySQL-statements met een hoofdletter worden geschreven.
Tevens vind ik het gevaarlijk om de regel in PHP niet af te sluiten met een ;
Ook de variabele beginnen met een hoofdletter zie je ook niet vaak in PHP, maar is niet per definiete slecht, zolang je het maar consequent doet.

Het is inderdaad in mijn ogen een viervoudig slecht programmeervoorbeeld. Pareltje

PHP:

$query = "SELECT * FROM tablename WHERE order = 1";
// of
$query = "SELECT * FROM tablename WHERE order LIKE '1'";

Zoiets zou mijn voorkeur genieten, maar smaken verschillen

[ Voor 22% gewijzigd door Matis op 19-04-2013 20:27 ]

[Olaf van der Spek]

Order zal wel een keyword zijn, `order` dus...
Voor strings heb je geen like nodig.

[ Voor 29% gewijzigd door Olaf van der Spek op 19-04-2013 22:15 ]

[Keiichi]

Olaf van der Spek schreef op vrijdag 19 april 2013 @ 22:14:
Order zal wel een keyword zijn, `order` dus...
Voor strings heb je geen like nodig.

One difference - apart from the possibility to use wildcards with LIKE - is in trailing spaces: The = operator ignores trailing space, but LIKE does not.

hier heb je al een rede waarom LIKE beter is (vind ik)

[.oisyn]

Het lijkt me praktischer om ervoor te zorgen dat je die trailing spaces uit je data filtert voor je ze in de db stopt.

[Onbekend]

Ik denk dat 'like' langzamer op de database is dan '='. En daarnaast weet je toch wat je wilt zoeken in de database? Alleen als je een stuk tekst hebt waarvan je niet weet hoe het precies geschreven is is like wel handig.

[Styxxy]

Olaf van der Spek schreef op vrijdag 19 april 2013 @ 22:14:
Order zal wel een keyword zijn, `order` dus...
Voor strings heb je geen like nodig.

En als je het correcte datatype gebruikt (int) dan heb je geen probleem anyway...

[We Are Borg]

Matis schreef op vrijdag 19 april 2013 @ 20:21:
Ik weet niet wat ik erger vind, de integer die als char wordt gebruikt (al kom je er mee weg), geen LIKE voor het comparen van een string of het feit dat de zowel de tabel- en kolomnamen als ook de MySQL-statements met een hoofdletter worden geschreven.
Tevens vind ik het gevaarlijk om de regel in PHP niet af te sluiten met een ;
Ook de variabele beginnen met een hoofdletter zie je ook niet vaak in PHP, maar is niet per definiete slecht, zolang je het maar consequent doet.

Het is inderdaad in mijn ogen een viervoudig slecht programmeervoorbeeld. Pareltje

PHP:

$query = "SELECT * FROM tablename WHERE order = 1";
// of
$query = "SELECT * FROM tablename WHERE order LIKE '1'";

Zoiets zou mijn voorkeur genieten, maar smaken verschillen

Die tabelnaam en kolomnaam is gelukkig altijd met kleine letter, in dit voorbeeld per ongeluk hoofdletters gebruikt . Probleem was dat je je kolomnaam geen order mag noemen. Net als je je columnaam geen delete mag noemen, waar ik eerder mijn hoofd over had gebroken. Deze ezel maakt dus 2 keer dezelfde fout

[PatrickH89]

Dat probleem heb je niet als je er gewoon voor zorgt dat je columnames beschrijven wat er daadwerkelijk in zit. Wat zit er nou weer in een kolom 'delete'? Of was het een boolean die eigenlijk 'deleted' (of zelfs is_deleted?) had moeten heten? Zelfde met 'order', moet dat geen 'order_id' (oid) zijn?

[ Voor 4% gewijzigd door PatrickH89 op 20-04-2013 12:13 ]

[HuHu]

We Are Borg schreef op zaterdag 20 april 2013 @ 11:59:
[...]

Die tabelnaam en kolomnaam is gelukkig altijd met kleine letter, in dit voorbeeld per ongeluk hoofdletters gebruikt . Probleem was dat je je kolomnaam geen order mag noemen. Net als je je columnaam geen delete mag noemen, waar ik eerder mijn hoofd over had gebroken. Deze ezel maakt dus 2 keer dezelfde fout

Mag wel, maar dan moet je er backticks omheen zetten:

SQL:

SELECT `column` FROM `table` WHERE `order` = 1;

[Tanuki]

HuHu schreef op zaterdag 20 april 2013 @ 12:18:
[...]

Mag wel, maar dan moet je er backticks omheen zetten:

SQL:

SELECT `column` FROM `table` WHERE `order` = 1;

Ranzig!

[PrisonerOfPain]

Tanuki schreef op zaterdag 20 april 2013 @ 15:15:
[...]

Ranzig!

Wat een onzin.

[F.West98]

Idd, die zet ik er altijd omheen. Just in case

[Verwijderd]

Tanuki schreef op zaterdag 20 april 2013 @ 15:15:

Ranzig!

Wat vind je ranzig? Het op deze manier toch mogelijk maken om reserved words te gebruiken voor tabelnamen, of vind je de backtick quotes lelijk?

In het eerste geval: daar ben ik het mee eens.
In het tweede geval: je kunt niet programmeren. Het is altijd verstandig om in geval van twijfel backtick quotes te gebruiken. Als je queries genereert aan de hand van een configuratie, zul je sowieso je namen moeten escapen wil je exceptions voorkomen.

[We Are Borg]

Dat wist ik niet van die quotes. Dan nog maar beter niet. In het geval van delete, omschreef dat een recht of iemand dat mocht. Dan vind ik de kolom naam delete best ok. In het geval van order kan je nderdaad kiezen voor ordernr of orderid

[HuHu]

We Are Borg schreef op zaterdag 20 april 2013 @ 18:14:
Dat wist ik niet van die quotes. Dan nog maar beter niet. In het geval van delete, omschreef dat een recht of iemand dat mocht. Dan vind ik de kolom naam delete best ok. In het geval van order kan je nderdaad kiezen voor ordernr of orderid

Dan kun je de kolom wellicht "can_delete" noemen.

[Voutloos]

Check. Enkel 'delete' is wmb wel een slechte kolom- of variabele naam. Een enkel werkwoordje licht niets toe, een kolom met die naam zou ook kunnen betekenen dat waarde verwijderd is of moet worden etc.

offtopic:
'can_delete' is wel een tikkie Nederlands, wellicht is 'may_delete' of 'delete_allowed' wat netter.

[Onbekend]

Ik zou het dan zo noemen als de regel verwijderd is: Deleted of Removed.
Of als het een toegestaan is om de regel op "verwijderd" te zetetn dan: AllowDelete of PermissionDelete.

[Tanuki]

PrisonerOfPain schreef op zaterdag 20 april 2013 @ 15:24:
[...]


Wat een onzin.

Geen onzin. Ga een echt DBMS gebruiken. Het gebruiken van reserved words als tabel- of kolomnamen is altijd bad practice. Een DBMS zou zoiets nooit moeten toelaten. En zou al helemaal niet een "speciale syntax" moeten verzinnen ervoor.

Verwijderd schreef op zaterdag 20 april 2013 @ 17:01:
[...]

Wat vind je ranzig? Het op deze manier toch mogelijk maken om reserved words te gebruiken voor tabelnamen, of vind je de backtick quotes lelijk?

In het eerste geval: daar ben ik het mee eens.
In het tweede geval: je kunt niet programmeren. Het is altijd verstandig om in geval van twijfel backtick quotes te gebruiken. Als je queries genereert aan de hand van een configuratie, zul je sowieso je namen moeten escapen wil je exceptions voorkomen.

"Het op deze manier toch mogelijk maken om reserved words te gebruiken voor tabelnamen" Deze zin heeft 2 tegenstrijdigheden. Gereserveerde woorden mogelijk maken... Waar ben je dan toch mee bezig?

"Je kunt niet programmeren": Het feit dat ik wel of niet kan programmeren staat compleet los van mijn mening hierover. Daarom ga ik ook absoluut niet in discussie over dat statement.

"Het is altijd verstandig om in geval van twijfel backtick quotes te gebruiken." In geval van twijfel krijg je, bij een goed DBMS, een dikke vette exception bij het aanmaken van de tabel. En terecht; die woorden zijn niet voor niks reserved en afgeraden om te gebruiken.

Het gebruik van backticks is gewoon een heel slechte gewoonte. Als je dan toch al MySQL moet gebruiken, maak er dan het beste van en probeer het zo standaard mogelijk te houden. Vroeg of laat ga je toch een keer willen overstappen naar een echt DBMS, dan kun je niet eens je tabel- en kolomnamen zo houden... De rest is ook al zo'n gedoe om te porten, dan moet je je dáár óók nog eens zorgen over gaan maken.

"Als je queries genereert aan de hand van een configuratie, zul je sowieso je namen moeten escapen wil je exceptions voorkomen." Zoals jij het in deze zin verwoordt, klinkt het als een bad practice. En precies daarom heeft het die naam... Niet doen.
Er zijn tig andere manieren om het wèl netjes te doen.

[CoolGamer]

Alle belangrijke DBMS'en hebben ondersteuning voor het escapen van kolom- en tabelnamen. Dus je hoeft je daar geen zorgen om te maken. Als je in je domein entiteiten hebt waarvan de naam overeen komt met een reserved keyword, is het vaak duidelijker als je dan toch voor die naam kiest. Anders moet je een nieuwe naam gaan verzinnen speciaal om het in de database te kunnen opslaan. Verschillende namen geven aan hetzelfde is ook iets wat vaak genoeg verwarring oplevert in een project, dus als het even kan moet je dat voorkomen.

[Gomez12]

Tanuki schreef op zaterdag 20 april 2013 @ 22:46:
[...]

Geen onzin. Ga een echt DBMS gebruiken. Het gebruiken van reserved words als tabel- of kolomnamen is altijd bad practice. Een DBMS zou zoiets nooit moeten toelaten. En zou al helemaal niet een "speciale syntax" moeten verzinnen ervoor.

Ehm, een echt DBMS moet simpelweg onderdeel zijn van het totaalpakket en daarom met alles kunnen omgaan, een echt DBMS gaat mij niet vertellen dat ik een domein-model wat bijv al 10 jaar bestaat maar moet aanpassen omdat ik het anders niet het DBMS inkrijg.

Het is bad practice om het te doen, maar het zou nog slechtere practice zijn als een DBMS het totaal niet toelaat.

In jouw wereld ga je dan ook hele domein-modellen omgooien als er een nieuwe versie van je DBMS is die weer nieuwe reserved words bevat? Gewoon consequent backticks gebruiken en je gaat nu en in de toekomst nooit last hebben van die reserved words.

Hoe ik het altijd bekijk is heel simpel : Zonder backticks dan heb je idd te maken met reserved words die het DBMS niet toestaat, met backticks heb je niets meer te maken met reserved words qua DBMS, ga je ze door elkaar mixen dan creeert je echter een zooitje.

[CodeCaster]

Tanuki schreef op zaterdag 20 april 2013 @ 22:46:
[...]

Geen onzin. Ga een echt DBMS gebruiken. Het gebruiken van reserved words als tabel- of kolomnamen is altijd bad practice. Een DBMS zou zoiets nooit moeten toelaten. En zou al helemaal niet een "speciale syntax" moeten verzinnen ervoor.

Kun je eens van je stokpaard komen en vertellen wát er zo verschrikkelijk slecht is aan een kolom '[input]' te noemen, in plaats van telkens herhalen dat het toch wel van de zotten is dát het kan (terwijl ieder DBMS er escape-syntaxis voor heeft)?

[ Voor 4% gewijzigd door CodeCaster op 21-04-2013 10:31 ]

[HuHu]

Tanuki schreef op zaterdag 20 april 2013 @ 22:46:

[..]

Vroeg of laat ga je toch een keer willen overstappen naar een echt DBMS, dan kun je niet eens je tabel- en kolomnamen zo houden...

Noem er eens één.

[leuk_he]

CodeCaster schreef op zondag 21 april 2013 @ 10:26:
[...]

Kun je eens van je stokpaard komen en vertellen wát er zo verschrikkelijk slecht is aan een kolom '[input]' te noemen, in plaats van telkens herhalen dat het toch wel van de zotten is dát het kan (terwijl ieder DBMS er escape-syntaxis voor heeft)?

Omdat je binnen 2 dagen een support tool tegen komt (kuch ...toad...), die niet aan de juiste escaping doet, waardoor je door de vreemde kolom namen bepaalde tabellen niet kunt beheren. De ontwerper van de database krijgt daarvan de schuld. (nou ja,... altijd de computer de schuld geven, nooit mensen, want als je naar andere mensen wijst zullen ze ooit terugwijzen).

Stel je voor dat je er tegenaanloopt dat je een export niet kunt inlezen omdat iemand een kolomnaam "`delete`" heeft gebruikt... dan heb je echt een WTF moment moment.

[PrisonerOfPain]

Tanuki schreef op zaterdag 20 april 2013 @ 22:46:
[...]

Geen onzin. Ga een echt DBMS gebruiken. Het gebruiken van reserved words als tabel- of kolomnamen is altijd bad practice. Een DBMS zou zoiets nooit moeten toelaten. En zou al helemaal niet een "speciale syntax" moeten verzinnen ervoor.

1. Ik gebruik geen DBMSen in mijn dagelijks leven. Verder slaat dat geflame op mysql natuurlijk nergens op.
2. Ieder andere DBMS heeft ook support voor het escapen van reserved words in tabel & kolom namen.
3. "Speciale syntax", ammehoela. Dat jij het niet snapt wil niet zeggen dat het niet nodig is. Of zijn de quotes om strings ook 'speciale syntax', want dan moeten we dat ook maar afschaffen.
4.
5. Weet je, laat ook maar.

[Ram0n]

Nice... Gedownload bestand bevat een spatie achteraan de extensie ("filename.ext "), en in Windows 7 kan ik die nu op geen enkele manier gebruiken. Wat ik er ook mee doe (hernoemen, verplaatsen, openen vanuit een programma, etc), telkens krijg ik de melding dat bestand niet bestaat. Zelfs de 8.3-notatie gebruiken in een prompt werkt niet

[Alex)]

Dit al geprobeerd?

ren "filename.ext " "filename.ext"

Wel een leuke bug

[Ram0n]

Jep, werkte ook niet, maar het is me net gelukt via de oplossing in probleem 6 alhier

ren "\\?\d:\download\file.ext " "file.ext"

[Verwijderd]

CodeCaster schreef op zondag 21 april 2013 @ 10:26:
Kun je eens .. vertellen wát er zo verschrikkelijk slecht is aan een kolom '[input]' te noemen, in plaats van telkens herhalen dat het toch wel van de zotten is dát het kan (terwijl ieder DBMS er escape-syntaxis voor heeft)?

In theorie zou het wel kunnen. Maar in de praktijk kan je zwaar in de problemen komen met scripting, migraties of updaten. Wat reserved keywords betreft is een "t_" of "p_" net zoveel moeite als ' er omheen te gooien.

[Jegorex]

Dus omdat sommigen de fout maken door geen `backticks` te gebruiken om hun kolomnamen moeten de mensen die het wel doen er maar voor opdraaien?

[.oisyn]

Wat sowieso een nonargument is, mensen die het niet gebruiken en toch een reserved-word-kolom in hun query moeten gebruiken komen er snel genoeg achter dat hun query een syntax error geeft.

[CodeCaster]

leuk_he schreef op zondag 21 april 2013 @ 12:23:
Omdat je binnen 2 dagen een support tool tegen komt (kuch ...toad...), die niet aan de juiste escaping doet

Verwijderd schreef op maandag 22 april 2013 @ 10:09:in de praktijk kan je zwaar in de problemen komen met scripting, migraties of updaten.

Met zulke brakke tools heb ik gelukkig nooit hoeven werken. Kan zo'n tool dan wel omgaan met vendor-specifieke keywords in SP's, computed fields en sequences, of ben je dagelijks aan het baggeren om om de tekortkomingen van een onderhoudspakket heen te werken?

Wat reserved keywords betreft is een "t_" of "p_" net zoveel moeite als ' er omheen te gooien.

Want prefixes zijn niet ranzig, helemaal niet wanneer ze worden gebruikt om bovengenoemde tekortkomingen te verdoezelen? Kolomnamen zijn, net als variabelennamen, helemaal niet interessant voor de computer, ze zijn er voor de developer...

[ Voor 5% gewijzigd door CodeCaster op 22-04-2013 16:21 ]

[Hmail]

CodeCaster schreef op maandag 22 april 2013 @ 16:20:
Kolomnamen zijn, net als variabelennamen, helemaal niet interessant voor de computer, ze zijn er voor de developer...

En precies om die reden blijf ik ook stug de kolom waarin de volgorde van rijen aangegeven wordt `order` noemen. Dat is m.i. ook de enige naam die ècht aangeeft wat de kolom doet. Spaties in tabelnamen word ik dan weer niet gelukkig van, maar ik zie niet echt het probleem van de backticks of square brackets.

[Dido]

Hmail schreef op maandag 22 april 2013 @ 16:27:
En precies om die reden blijf ik ook stug de kolom waarin de volgorde van rijen aangegeven wordt `order` noemen. Dat is m.i. ook de enige naam die ècht aangeeft wat de kolom doet. Spaties in tabelnamen word ik dan weer niet gelukkig van, maar ik zie niet echt het probleem van de backticks of square brackets.

Mja... zo'n kolom zou ik sequence noemen. In ordersystemen betekent order namelijk een bestelling, geen volgorde

[Spockz]

Deze hele discussie zou er niet zijn als in SQL werd afgedwongen dat je veldnamen tussen backticks moet zetten. Maw, altijd je veldnamen quoten verhelpt je problemen. En sequence is inderdaad een betere naam.

[ Voor 11% gewijzigd door Spockz op 23-04-2013 10:01 ]

[BM]

Nu het hierboven over prefixes gaat, tijdje terug keek ik bij een collega mee naar een testprojectje wat ie aan het opzetten was, waar hij de veldnamen in zijn tabellen een _PK en _FK suffix meegaf. Dat leek mij toch ook niet helemaal ideaal

[Onbekend]

Nee, dat moet je als prefix doen.
Bij het opvragen van de databaseobjecten weet je direct wat voor type/functie een bepaald opject heeft zonder andere eigenschappen op te moeten vragen.

[MBV]

Ja fijn, laten we alles in hungarian notation doen, daar wordt de code leesbaar van!

[Davio]

Ach, met de standaard toevoeging "ID" weet je toch ook al een hoop?

TabelID is PK van die tabel, AndereTabelID is een FK.

[HuHu]

Davio schreef op dinsdag 23 april 2013 @ 11:08:
Ach, met de standaard toevoeging "ID" weet je toch ook al een hoop?

TabelID is PK van die tabel, AndereTabelID is een FK.

Ik zou een id-kolom dat in Tabel zit niet de naam TabelID geven, maar gewoon ID. Er is geen noodzaak om kolommen die in een tabel zitten nogmaals te prefixen met de tabelnaam.

[Davio]

HuHu schreef op dinsdag 23 april 2013 @ 11:19:
[...]

Ik zou een id-kolom dat in Tabel zit niet de naam TabelID geven, maar gewoon ID. Er is geen noodzaak om kolommen die in een tabel zitten nogmaals te prefixen met de tabelnaam.

Dat is waar, maar ik denk dat het in de praktijk gebeurt zodat zowel de FK-kolommen als de oorspronkelijke PK-kolom exact dezelfde naam hebben.

[Verwijderd]

Davio schreef op dinsdag 23 april 2013 @ 12:09:
[...]

Dat is waar, maar ik denk dat het in de praktijk gebeurt zodat zowel de FK-kolommen als de oorspronkelijke PK-kolom exact dezelfde naam hebben.

Da's heel erg nuttig ja. Want `table.table_id` is zo veel duidelijker dan `table.id`.

Ik heb echt een hekel aan dergelijke prefixes. Maar goed, iedereen moet maar doen wat ze zelf fijn vinden. Zolang ik er maar niet in hoef te werken.

[Davio]

Gheghe, zei niet zelf dat het supernuttig was, maar in het wild kom je de vreemdste dingen tegen.

[Styxxy]

Verwijderd schreef op dinsdag 23 april 2013 @ 15:20:
[...]
Da's heel erg nuttig ja. Want `table.table_id` is zo veel duidelijker dan `table.id`.

Ik heb echt een hekel aan dergelijke prefixes. Maar goed, iedereen moet maar doen wat ze zelf fijn vinden. Zolang ik er maar niet in hoef te werken.

Ik stoor me daar nu niet bepaald aan. Op zich is dat nu niet zo'n slecht iets hoor, ik zie het probleem niet zo direct.

Er zijn heel wat andere zaken waar ik me eerder over zou gaan ergeren...

[MBV]

Je hebt ook aliassen voor tabellen, nodig voor self-joins en nuttig voor lange tabelnamen. x.tableID is soms wel duidelijker dan x.ID

[_js_]

MBV schreef op dinsdag 23 april 2013 @ 17:52:
Je hebt ook aliassen [...] nodig voor [...] lange tabelnamen. x.tableID is soms wel duidelijker dan x.ID

Dan moet je nog de lange naam typen

[MBV]

Zoals ik het vaak gebruikt zag worden:

SQL:

select x.voornaam, x.voorvoegsel, x.achternaam, x.adres, baas.achternaam baas
from ERP_BELACHELIJKE_TABELNAAM x
left join ERP_BELACHELIJKE_TABELNAAM baas
   on x.BaasID = baas.ERP_BELACHELIJKE_TABELNAAM_ID

Dan hoef je die lange naam maar 1x te typen Voeg nog een stuk of 10 where-clauses toe, en misschien zie je het nut ervan in.

[Styxxy]

_js_ schreef op dinsdag 23 april 2013 @ 18:10:
[...]
Dan moet je nog de lange naam typen

Lang leve IntelliSense . Ik moet nooit veel letters typen, gewoon op TAB rammen en verder gaan.

[ Voor 16% gewijzigd door Styxxy op 23-04-2013 19:05 ]

[Matis]

Verwijderd schreef op dinsdag 23 april 2013 @ 15:20:
Da's heel erg nuttig ja. Want `table.table_id` is zo veel duidelijker dan `table.id`.

Ik heb echt een hekel aan dergelijke prefixes. Maar goed, iedereen moet maar doen wat ze zelf fijn vinden. Zolang ik er maar niet in hoef te werken.

wat ik meestal doe is table_x.id en de FK naar dat veld heet dan table_y.table_x_id. Op die manier doet Doctrine het ook, als je die automagisch jouw tabellen laat genereren.

[HuHu]

MBV schreef op dinsdag 23 april 2013 @ 18:42:
Zoals ik het vaak gebruikt zag worden:

SQL:

select x.voornaam, x.voorvoegsel, x.achternaam, x.adres, baas.achternaam baas
from ERP_BELACHELIJKE_TABELNAAM x
left join ERP_BELACHELIJKE_TABELNAAM baas
   on x.BaasID = baas.ERP_BELACHELIJKE_TABELNAAM_ID

Dan hoef je die lange naam maar 1x te typen Voeg nog een stuk of 10 where-clauses toe, en misschien zie je het nut ervan in.

En nu zelfs nog een keer minder, als je geen overbodige prefixes zou gebruiken:

SQL:

select x.voornaam, x.voorvoegsel, x.achternaam, x.adres, baas.achternaam baas
from ERP_BELACHELIJKE_TABELNAAM x
left join ERP_BELACHELIJKE_TABELNAAM baas
   on x.BaasID = baas.ID

[Verwijderd]

Matis schreef op dinsdag 23 april 2013 @ 19:05:
[...]

wat ik meestal doe is table_x.id en de FK naar dat veld heet dan table_y.table_x_id. Op die manier doet Doctrine het ook, als je die automagisch jouw tabellen laat genereren.

Mijn voorbeeld ging over de PK, dus table_x.id ipv table_x.table_x_id. En dan gebruik ik inderdaad wel table_y.table_x_id. Is in mijn ogen de meest logische manier.

[Davio]

HuHu schreef op dinsdag 23 april 2013 @ 22:24:
[...]

En nu zelfs nog een keer minder, als je geen overbodige prefixes zou gebruiken:

SQL:

select x.voornaam, x.voorvoegsel, x.achternaam, x.adres, baas.achternaam baas
from ERP_BELACHELIJKE_TABELNAAM x
left join ERP_BELACHELIJKE_TABELNAAM baas
   on x.BaasID = baas.ID

Ah, een left join, moet toch heerlijk zijn zonder baas?

[Feanathiel]

BM schreef op dinsdag 23 april 2013 @ 10:32:
..., waar hij de veldnamen in zijn tabellen een _PK en _FK suffix meegaf...

Onbekend schreef op dinsdag 23 april 2013 @ 10:41:
Nee, dat moet je als prefix doen...

Opzich wel mooi altijd.. Als we Hongaarse notatie gebruiken in code is het verkeerd, doen we dat in SQL dan hoor je er niemand over .

[Ozzie]

Zolang het maar consistent is vind ik het prima. Het word pas vervelend als de ene tabel in je database wel prefixes heeft en de andere niet. Dan moet je echt constant in je datamodel kijken ook al wil je iets simpels doen.

[Davio]

Nog mooier, ik werk nu met een database met tig tabellen, begint al met tabel BACKUPX tot BACKUPY (uiteraard all caps) in dezelfde database als de tabellen waarvan (vermoed ik) een backup gemaakt is.

Stamtabellen krijgen steevast de naam FOO_FOO, want je hebt ook koppeltabellen FOO_BAR, dus moet FOO_FOO zo genoemd worden. Alleen FOO was blijkbaar niet genoeg.

Verder is er geen enkele consistentie in namen. FOOID heet in een andere tabel weer FOOZID.

En last but not least houden ze er niet van om originele tabellen uit te breiden (zal wel bepaalde software om zeep helpen) en heb je dus allerlei tabellen van het type FOO_BAR_UITBREIDING.

Zoals de heer Dijkshoorn zou zeggen: Een milde steniging voor wie dit bedacht heeft.

[MBV]

milde?

En trouwens: jij werkt ermee, waarom gooi je backupX en co niet in een andere database, om te beginnen?

[Verwijderd]

In de database van een klant ben ik een zeer opmerkelijke database-structuur tegengekomen.

Tabelnamen:
rate1, rate2, …, rate986, rate987

En in die tabellen staan dan velden als:
F000172, F000173, F000174, F000175

Ik heb geen idee waar het precies (of ongeveer) voor gebruikt wordt. Maar ik ben ook heel erg blij dat ik er niet mee hoef te werken!

[HeSitated]

Verwijderd schreef op donderdag 25 april 2013 @ 13:56:
Ik heb geen idee waar het precies (of ongeveer) voor gebruikt wordt. Maar ik ben ook heel erg blij dat ik er niet mee hoef te werken!

Ach, ik heb op een klus gezeten daar heten de kolommen A, B, C t/m M....

Maar goed over dat bedrijf kan ik een heel boek schrijven....

[F.West98]

Bij mij op stage maken ze dus voor elk invoerveld en zoekveld een nieuwe tabel aan waaruit die info wordt gehaald
En instellingen is elke instelling nieuwe kolom en één rij. (ik werk altijd met naam/waarde en dan elke instelling als rij)

[Matis]

F.West98 schreef op vrijdag 26 april 2013 @ 20:39:
Bij mij op stage maken ze dus voor elk invoerveld en zoekveld een nieuwe tabel aan waaruit die info wordt gehaald
En instellingen is elke instelling nieuwe kolom en één rij. (ik werk altijd met naam/waarde en dan elke instelling als rij)

De database is in ieder geval geoptimaliseerd to Boyce-Codd-normaalvorm

[RickPt]

code:

            if (BrochureTextBox.Text.Trim().Length > 0)
            {
                NewAd.BrochureURL = BrochureTextBox.Text.Trim();
            }
            else
            {
                NewAd.BrochureURL = string.Empty;
            }
            if (Foto360TextBox.Text.Trim().Length > 0)
            {
                NewAd.Foto360URL = Foto360TextBox.Text.Trim();
            }
            else
            {
                NewAd.Foto360URL = string.Empty;
            }
            if (VideoTextBox.Text.Trim().Length > 0)
            {
                NewAd.VideoURL = VideoTextBox.Text.Trim();
            }
            else
            {
                NewAd.VideoURL = string.Empty;
            }

i.p.v

code:

NewAd.BrochureURL = BrochureTextBox.Text.Trim();
NewAd.Foto360URL = Foto360TextBox.Text.Trim();
NewAd.VideoURL = VideoTextBox.Text.Trim();

Schiet mij maar lek

[ Voor 13% gewijzigd door RickPt op 03-05-2013 13:09 ]

[Orion84]

Je kan zo wel makkelijk een alternatieve default string kiezen om te gebruiken als de tekstbox leeg is (of alleen whitespace bevat), maar zo puur dit stukje code bezien is jouw alternatief inderdaad een stuk simpeler.

Wat ik overigens opvallender vind is dat de inhoud van tekstboxen (van een webformulier?) blijkbaar klakkeloos worden overgenomen in de velden van die NewAd variabele die ongetwijfeld later de database in verdwijnen en weer worden opgehaald om ergens een webpagina mee op te bouwen. Ziet er uit als XSS waiting to happen...

[ Voor 3% gewijzigd door Orion84 op 03-05-2013 13:15 ]

[Olaf van der Spek]

Orion84 schreef op vrijdag 03 mei 2013 @ 13:14:
Ziet er uit als XSS waiting to happen...

Hoezo? HTML escaping doe je tijdens output, niet tijdens input. En SQL escaping doe je ook niet handmatig (hoop ik).

[kenneth]

Waarom zou je het niet klakkeloos overnemen? Pas bij output pas je HTML encoding toe, toch?

Olaf

[ Voor 5% gewijzigd door kenneth op 03-05-2013 13:34 ]

[Orion84]

Dat is inderdaad ook een optie ja, om je output te valideren. Maar als je in een tekstbox een URL verwacht, wat houdt je dan tegen om direct die input te valideren, voordat je het opslaat? Voordeel is dat je dan ook meteen feedback aan de gebruiker kan geven dat hetgeen hij heeft ingevuld niet juist is.

Maar goed, dat is met zo'n beperkt voorbeeld natuurlijk ook maar een beetje loos commentaar, want wellicht wordt dat allemaal al op andere plekken / manieren afgehandeld.

[Davio]

Niet echt een slecht programmeervoorbeeld, maar meer een ergernis, de Debug.WriteLine(string message, string category) overload.

C#:

// Werkt niet als verwacht
Debug.WriteLine("Some info: {0}", info);
// Dit wel
Debug.WriteLine("Some info: {0}, extra info: {1}", info, extraInfo);
// Dit uiteraard ook
Debug.WriteLine("Some info: " + info);
// En dit ook met primitive types
Debug.WriteLine("Some int: {0}", someInt);

[RickPt]

Orion84 schreef op vrijdag 03 mei 2013 @ 13:38:
Dat is inderdaad ook een optie ja, om je output te valideren. Maar als je in een tekstbox een URL verwacht, wat houdt je dan tegen om direct die input te valideren, voordat je het opslaat? Voordeel is dat je dan ook meteen feedback aan de gebruiker kan geven dat hetgeen hij heeft ingevuld niet juist is.

Maar goed, dat is met zo'n beperkt voorbeeld natuurlijk ook maar een beetje loos commentaar, want wellicht wordt dat allemaal al op andere plekken / manieren afgehandeld.

Verdere uitleg heb ik niet gegeven omdat ik de onnodige if statements wou laten zien. De input wordt door middel van een regex gevalideerd, dus XSS is gelukkig niet aan de orde.

[PatrickH89]

Orion84 schreef op vrijdag 03 mei 2013 @ 13:38:
Dat is inderdaad ook een optie ja, om je output te valideren. Maar als je in een tekstbox een URL verwacht, wat houdt je dan tegen om direct die input te valideren, voordat je het opslaat? Voordeel is dat je dan ook meteen feedback aan de gebruiker kan geven dat hetgeen hij heeft ingevuld niet juist is.

Maar goed, dat is met zo'n beperkt voorbeeld natuurlijk ook maar een beetje loos commentaar, want wellicht wordt dat allemaal al op andere plekken / manieren afgehandeld.

Bij input zorg je ervoor dat je krijgt wat je wilt hebben met validatie, maar dat is geen reden om de output dan niet te 'escapen' voor HTML.

RickPt schreef op vrijdag 03 mei 2013 @ 13:46:
[...]


Verdere uitleg heb ik niet gegeven omdat ik de onnodige if statements wou laten zien. De input wordt door middel van een regex gevalideerd, dus XSS is gelukkig niet aan de orde.

Lijkt me niet echt een optimale methode, regexes gebruik je niet om XSS te voorkomen. Ik weet niet precies om wat voor taal dat gaat, maar bij de output escape je met de methods die daarvoor bedoeld zijn, niet met een regex.

[Mint]

RickPt schreef op vrijdag 03 mei 2013 @ 13:46:
[...]


Verdere uitleg heb ik niet gegeven omdat ik de onnodige if statements wou laten zien. De input wordt door middel van een regex gevalideerd, dus XSS is gelukkig niet aan de orde.

XSS wellicht niet, maar DoS kan dan weer wel. Is maar net waar je je tegen wilt beschermen natuurlijk.

[Orion84]

PatrickH89 schreef op vrijdag 03 mei 2013 @ 13:55:
[...]


Bij input zorg je ervoor dat je krijgt wat je wilt hebben met validatie, maar dat is geen reden om de output dan niet te 'escapen' voor HTML.

Waar zie jij mij beweren dat je output niet moet escapen / valideren / sanitizen? Het enige wat ik aangaf is dat ik het opmerkelijk vond dat de inhoud van tekstboxen ogenschijnlijk zonder enige validatie in een variabele wordt gestopt. En dat zelfs al doe je verderop ergens aan het opschonen van je output, dat het in mijn ogen nog steeds goed is om je input ook te valideren.

[...]
Lijkt me niet echt een optimale methode, regexes gebruik je niet om XSS te voorkomen. Ik weet niet precies om wat voor taal dat gaat, maar bij de output escape je met de methods die daarvoor bedoeld zijn, niet met een regex.

Als je met die regex checkt dat er alleen een valide URL kan worden ingevoerd en niet allerlei malafide code, dan kan dat wel degelijk helpen om XSS te voorkomen.

RickPt schreef op vrijdag 03 mei 2013 @ 13:46:
[...]
Verdere uitleg heb ik niet gegeven omdat ik de onnodige if statements wou laten zien. De input wordt door middel van een regex gevalideerd, dus XSS is gelukkig niet aan de orde.

Ah, check, dat is het risico van reageren op code snippits, zonder de context kan je zomaar fouten spotten die geen fouten blijken te zijn

[ Voor 17% gewijzigd door Orion84 op 03-05-2013 14:12 ]

[Olaf van der Spek]

Orion84 schreef op vrijdag 03 mei 2013 @ 14:08:
Als je met die regex checkt dat er alleen een valide URL kan worden ingevoerd en niet allerlei malafide code, dan kan dat wel degelijk helpen om XSS te voorkomen.

Het punt is dat de verantwoordelijkheid voor het voorkomen van XSS ligt bij de output code, niet bij de input code. Als jij denkt dat jouw input code helpt XSS te voorkomen vertrouw je je output code blijkbaar niet.

[Orion84]

Olaf van der Spek schreef op vrijdag 03 mei 2013 @ 14:22:
[...]

Het punt is dat de verantwoordelijkheid voor het voorkomen van XSS ligt bij de output code, niet bij de input code. Als jij denkt dat jouw input code helpt XSS te voorkomen vertrouw je je output code blijkbaar niet.

Als de output opschoning 100% op orde is, dan draagt je input validatie inderdaad weinig bij aan het voorkomen van XSS en ik ben het met je eens dat de verantwoordelijkheid om XSS te voorkomen aan de output kant ligt.

Als ik echter code zie waar user input (die duidelijk aan een bepaald format zou moeten voldoen) zonder enige validatie in een variabele verdwijnt, dan heb ik er weinig vertrouwen in dat er verderop ineens wel netjes output escaping wordt toegepast. Vandaar dat ik dat aan de kaak stelde.

Maar goed, die aanname dat input validatie (en output opschoning) ontbrak was dus onjuist, aangezien het code fragment dus gestript was puur om die if/else constructie te tonen.

[ Voor 9% gewijzigd door Orion84 op 03-05-2013 14:43 ]

[Zubzub]

maand geleden tegengekomen (van een collega, een "senior")

code:

public String getSomeProperty(SomeObject obj){
 try{
  return obj.getFoo().getBar().getBazz();
 }catch(NullPointerException e){
  return null;
 }
}

en nee er zat geen tijdsdruk of 3rd party code of dergelijke achter

[azerty]

Zubzub schreef op zaterdag 04 mei 2013 @ 13:32:
maand geleden tegengekomen (van een collega, een "senior")

code:

public String getSomeProperty(SomeObject obj){
 try{
  return obj.getFoo().getBar().getBazz();
 }catch(NullPointerException e){
  return null;
 }
}

en nee er zat geen tijdsdruk of 3rd party code of dergelijke achter

Maar dat is toch nodig? Want als obj.getFoo() null returnt kan er natuurlijk geen getBar() op opgeroepen worden, en moet dat dus opgevangen worden zodat er toch een null terug gegeven kan worden

[MBV]

edit:
bij nader inzien niet handig om hier neer te zetten.

[ Voor 84% gewijzigd door MBV op 04-05-2013 18:28 ]

[raptorix]

Kwam laatst code tegen waar een freelancer het fijn vond om een mailtje met 90 velden met een string concat op te bouwen

Sowieso was string concat ze favoriete hobby, overal waar je normaal in .net repeaters zou gebruiken ging ie code behind de complete HTML opbouwen en in een literal aan de voorkant plaatsen.

[RayNbow]

Zubzub schreef op zaterdag 04 mei 2013 @ 13:32:
maand geleden tegengekomen (van een collega, een "senior")

code:

public String getSomeProperty(SomeObject obj){
 try{
  return obj.getFoo().getBar().getBazz();
 }catch(NullPointerException e){
  return null;
 }
}

De Maybe monad in disgusie?

[Alex)]

raptorix schreef op dinsdag 07 mei 2013 @ 11:53:
waar je normaal in .net repeaters zou gebruiken

Ik gebruik nooit repeaters, ik gebruik ListView

[kenneth]

RayNbow schreef op dinsdag 07 mei 2013 @ 12:06:
[...]

De Maybe monad in disgusie?

Ipv al dat moeilijke gedoe met lambda's

[Davio]

Zubzub schreef op zaterdag 04 mei 2013 @ 13:32:
maand geleden tegengekomen (van een collega, een "senior")

code:

public String getSomeProperty(SomeObject obj){
 try{
  return obj.getFoo().getBar().getBazz();
 }catch(NullPointerException e){
  return null;
 }
}

en nee er zat geen tijdsdruk of 3rd party code of dergelijke achter

Nou ja, je moet natuurlijk wel blijven oppassen met de return value:

code:

int length;
try{
  length = getSomeProperty(obj).Length;
 }catch(NullPointerException e){
  length = 0;
}

[smiegles]

code:

$i=0;
$sql = "SELECT * FROM accounts";
$result = $db->query($sql);
if($login !== ""){
    while(($m = $db->NextRecord())){
        $username = $m['username'];
        $password = $m['password'];
        // $version[++$i] = $m['version'];
        if($username == $gnaam AND $password == $WW){
            header ("Location: index.php?version=$version");
        }
    }
}

vond ik in het intranet van mijn school

[Zoijar]

smiegles schreef op woensdag 08 mei 2013 @ 22:28:

code:

$i=0;
$sql = "SELECT * FROM accounts";
$result = $db->query($sql);
if($login !== ""){
    while(($m = $db->NextRecord())){
        $username = $m['username'];
        $password = $m['password'];
        // $version[++$i] = $m['version'];
        if($username == $gnaam AND $password == $WW){
            header ("Location: index.php?version=$version");
        }
    }
}

vond ik in het intranet van mijn school

Ach, in ieder geval geen sql injections mogelijk Het kon erger

[smiegles]

En dan moet ik helaas antwoorden dat die er ook zijn .

En helaas ook deze :

code:

if(!empty($_SESSION['WW']) and !empty($_SESSION['gnaam'])){
    $gnaam =$_SESSION['gnaam'];
    $WW = $_SESSION['WW'] ;
    $login = $_SESSION['login'];
} else {
    header('Location: login.php');
}

[ Voor 1% gewijzigd door smiegles op 09-05-2013 03:48 . Reden: Spellingfout ]

[Tarabass]

smiegles schreef op woensdag 08 mei 2013 @ 22:28:

code:

$i=0;
$sql = "SELECT * FROM accounts";
$result = $db->query($sql);
if($login !== ""){
    while(($m = $db->NextRecord())){
        $username = $m['username'];
        $password = $m['password'];
        // $version[++$i] = $m['version'];
        if($username == $gnaam AND $password == $WW){
            header ("Location: index.php?version=$version");
        }
    }
}

vond ik in het intranet van mijn school

Je zal maar een miljoen gebruikers hebben en de gebruiker die zich inlogt is pas net lid

[PeaceNlove]

Tarabass schreef op donderdag 09 mei 2013 @ 09:55:
[...]
Je zal maar een miljoen gebruikers hebben en de gebruiker die zich inlogt is pas net lid

Ik heb ongeveer hetzelfde voorbeeld gezien in een ASP.Net applicatie en daar ging de boel al met 200 gebruikers al behoorlijk traag op deze manier.

[IStealYourGun]

Ik vond dit grappig:

code:

public int EntryAndReturnCunt(Point source, Point destination)

Mogelijk zit ik al wat te lang achter de PC.

Edit: OMG en nu heb ik zin om het zo te laten staan om te zien of mijn promotor effectief mijn code nakijkt.

[ Voor 26% gewijzigd door IStealYourGun op 20-05-2013 20:42 ]

[Tarabass]

IStealYourGun schreef op maandag 20 mei 2013 @ 20:41:
Ik vond dit grappig:

code:

public int EntryAndReturnCunt(Point source, Point destination)

Mogelijk zit ik al wat te lang achter de PC.

Edit: OMG en nu heb ik zin om het zo te laten staan om te zien of mijn promotor effectief mijn code nakijkt.

Hij is leuk! Helaas zou dat bij ons door stylecop er al uitgepikt worden

[Alex)]

Hoezo? Er zitten geen spelfouten in hoor.

[De_Bastaard]

Zolang het werkt

[Gropah]

De_Bastaard schreef op maandag 20 mei 2013 @ 21:56:
Zolang het werkt

Dus jij wilt zeggen dat dit ook goed is om in te leveren?

code:

#include                                     <math.h>
#include                                   <sys/time.h>
#include                                   <X11/Xlib.h>
#include                                  <X11/keysym.h>
                                          double L ,o ,P
                                         ,_=dt,T,Z,D=1,d,
                                         s[999],E,h= 8,I,
                                         J,K,w[999],M,m,O
                                        ,n[999],j=33e-3,i=
                                        1E3,r,t, u,v ,W,S=
                                        74.5,l=221,X=7.26,
                                        a,B,A=32.2,c, F,H;
                                        int N,q, C, y,p,U;
                                       Window z; char f[52]
                                    ; GC k; main(){ Display*e=
 XOpenDisplay( 0); z=RootWindow(e,0); for (XSetForeground(e,k=XCreateGC (e,z,0,0),BlackPixel(e,0))
; scanf("%lf%lf%lf",y +n,w+y, y+s)+1; y ++); XSelectInput(e,z= XCreateSimpleWindow(e,z,0,0,400,400,
0,0,WhitePixel(e,0) ),KeyPressMask); for(XMapWindow(e,z); ; T=sin(O)){ struct timeval G={ 0,dt*1e6}
; K= cos(j); N=1e4; M+= H*_; Z=D*K; F+=_*P; r=E*K; W=cos( O); m=K*W; H=K*T; O+=D*_*F/ K+d/K*E*_; B=
sin(j); a=B*T*D-E*W; XClearWindow(e,z); t=T*E+ D*B*W; j+=d*_*D-_*F*E; P=W*E*B-T*D; for (o+=(I=D*W+E
*T*B,E*d/K *B+v+B/K*F*D)*_; p<y; ){ T=p[s]+i; E=c-p[w]; D=n[p]-L; K=D*m-B*T-H*E; if(p [n]+w[ p]+p[s
]== 0|K <fabs(W=T*r-I*E +D*P) |fabs(D=t *D+Z *T-a *E)> K)N=1e4; else{ q=W/K *4E2+2e2; C= 2E2+4e2/ K
 *D; N-1E4&& XDrawLine(e ,z,k,N ,U,q,C); N=q; U=C; } ++p; } L+=_* (X*t +P*M+m*l); T=X*X+ l*l+M *M;
  XDrawString(e,z,k ,20,380,f,17); D=v/l*15; i+=(B *l-M*r -X*Z)*_; for(; XPending(e); u *=CS!=N){
                                   XEvent z; XNextEvent(e ,&z);
                                       ++*((N=XLookupKeysym
                                         (&z.xkey,0))-IT?
                                         N-LT? UP-N?& E:&
                                         J:& u: &h); --*(
                                         DN -N? N-DT ?N==
                                         RT?&u: & W:&h:&J
                                          ); } m=15*F/l;
                                          c+=(I=M/ l,l*H
                                          +I*M+a*X)*_; H
                                          =A*r+v*X-F*l+(
                                          E=.1+X*4.9/l,t
                                          =T*m/32-I*T/24
                                           )/S; K=F*M+(
                                           h* 1e4/l-(T+
                                           E*5*T*E)/3e2
                                           )/S-X*d-B*A;
                                           a=2.63 /l*d;
                                           X+=( d*l-T/S
                                            *(.19*E +a
                                            *.64+J/1e3
                                            )-M* v +A*
                                            Z)*_; l +=
                                            K *_; W=d;
                                            sprintf(f,
                                            "%5d  %3d"
                                            "%7d",p =l
                                           /1.7,(C=9E3+
                              O*57.3)%0550,(int)i); d+=T*(.45-14/l*
                             X-a*130-J* .14)*_/125e2+F*_*v; P=(T*(47
                             *I-m* 52+E*94 *D-t*.38+u*.21*E) /1e2+W*
                             179*v)/2312; select(p=0,0,0,0,&G); v-=(
                              W*F-T*(.63*m-I*.086+m*E*19-D*25-.11*u
                               )/107e2)*_; D=cos(o); E=sin(o); } }

[azerty]

Of dit?

code:

#  include<stdio.h>//  .IOCCC                                         Fluid-  #
#  include <unistd.h>  //2012                                         _Sim!_  #
#  include<complex.h>  //||||                     ,____.              IOCCC-  #
#  define              h for(                     x=011;              2012/*  #
#  */-1>x              ++;)b[                     x]//-'              winner  #
#  define              f(p,e)                                         for(/*  #
#  */p=a;              e,p<r;                                        p+=5)//  #
#  define              z(e,i)                                        f(p,p/*  #
## */[i]=e)f(q,w=cabs  (d=*p-  *q)/2-     1)if(0  <(x=1-      w))p[i]+=w*/// ##
   double complex a [  97687]  ,*p,*q     ,*r=a,  w=0,d;    int x,y;char b/* ##
## */[6856]="\x1b[2J"  "\x1b"  "[1;1H     ", *o=  b, *t;   int main   (){/** ##
## */for(              ;0<(x=  getc (     stdin)  );)w=x  >10?32<     x?4[/* ##
## */*r++              =w,r]=  w+1,*r     =r[5]=  x==35,  r+=9:0      ,w-I/* ##
## */:(x=              w+2);;  for(;;     puts(o  ),o=b+  4){z(p      [1]*/* ##
## */9,2)              w;z(G,  3)(d*(     3-p[2]  -q[2])  *P+p[4      ]*V-/* ##
## */q[4]              *V)/p[  2];h=0     ;f(p,(  t=b+10  +(x=*p      *I)+/* ##
## */80*(              y=*p/2  ),*p+=p    [4]+=p  [3]/10  *!p[1])     )x=0/* ##
## */ <=x              &&x<79   &&0<=y&&y<23?1[1  [*t|=8   ,t]|=4,t+=80]=1/* ##
## */, *t              |=2:0;    h=" '`-.|//,\\"  "|\\_"    "\\/\x23\n"[x/** ##
## */%80-              9?x[b]      :16];;usleep(  12321)      ;}return 0;}/* ##
####                                                                       ####
###############################################################################
**###########################################################################*/

[Tarabass]

Kom dit tegen in een 'soort van frameworkje':

C#:

 
public static string ConvertToMD5(string Value)
{
    MD5CryptoServiceProvider x = new MD5CryptoServiceProvider();

    byte[] data = Encoding.ASCII.GetBytes(Value);
    data = x.ComputeHash(data);

    string ret = "";

    for (int i = 0; i < data.Length; i++)
        ret += data[i].ToString("x2").ToLower();

    return ret;
}
 

Dan heb je een aantal zaken niet goed begrepen. Excuus zoals altijd; "Ach, heb ik zo van het internet geplukt waarschijnlijk"

[Davio]

Hihi, .NET gebruikt intern UTF-8 toch?

Dan zou het mijns inziens zinvoller zijn om een Encoding.UTF8.GetBytes te doen.
Naast dat je BitConverter.ToString(data) kunt doen natuurlijk.
Of eventueel de Base64-representatie als je het toch als string op wilt slaan.

[ Voor 17% gewijzigd door Davio op 21-05-2013 11:31 ]

[Zoijar]

Gropah schreef op maandag 20 mei 2013 @ 23:11:
Dus jij wilt zeggen dat dit ook goed is om in te leveren?

Zoiets mag alleen als het zichzelf print...