[alg] Slechtste programmeervoorbeelden deel 4

[Verwijderd]

link0007 schreef op zaterdag 08 mei 2010 @ 15:02:
[...]

Datatypes datatypes.. Je moet niet zo in hokjes denken joh!

Inderdaad, het is toch veel handiger als je een variabele overal voor kunt gebruiken...

[Afvalzak]

Vandaag had ik nog een mooie op mijn werk, een database gemaakt in Access met een aantal spelfouten.
In de tabelnamen/kolomnamen, voorbeeld:

Hoofdrubrieken was: Hooftdrubrieken
Ontvangen: Ontvagen
en nog wat dingen. Programma is gemaakt door een 'professioneel' bedrijf.
Kan me niet voorstellen dat dit met een goed datamodel gebeurtd was, en als meer dan 1 persoon er naar had gekeken.

[ Voor 1% gewijzigd door Afvalzak op 08-05-2010 20:12 . Reden: spelvaut ;) ]

[twiFight]

afvalzak schreef op zaterdag 08 mei 2010 @ 18:26:
Vandaag had ik nog een mooie op mijn werk, een database gemaakt in Access met een aantal spelfouten.
In de tabelnamen/kolomnamen, voorbeeld:

Hoofdrubrieken was: Hooftdrubrieken
Ontvangen: Ontvagen
en nog wat dingen. Programma is gemaakt door een 'professioneel' bedrijf.
Kan me niet voorstellen dat dit met een goed datamodel gebeurt gebeurd was, en als meer dan 1 persoon er naar had gekeken.

Natuurlijk niet in een post waarin je spellingsfouten belachelijk maakt zelf ook fouten maken hè

[HuHu]

afvalzak schreef op zaterdag 08 mei 2010 @ 18:26:
Vandaag had ik nog een mooie op mijn werk, een database gemaakt in Access met een aantal spelfouten.
In de tabelnamen/kolomnamen, voorbeeld:

Hoofdrubrieken was: Hooftdrubrieken
Ontvangen: Ontvagen
en nog wat dingen. Programma is gemaakt door een 'professioneel' bedrijf.
Kan me niet voorstellen dat dit met een goed datamodel gebeurt was, en als meer dan 1 persoon er naar had gekeken.

Misschien hadden ze wel H.O.O.F.T.D.-rubrieken ontworpen, waarmee ze vage problemen konden ontvagen.

En dat ga jij afkraken? Het gaat je gewoon boven de pet zeker?

.

[Verwijderd]

...en bij 'ontvagen' kan ik me ook nog wel wat voorstellen, al klinkt het meer als een procedure dan een kolomnaam: Ontvagen(vage data)

Nee, hier hebben duidelijk professionals aan gewerkt die op veel hogere niveaus zaten te denken dan aan datatypes en spellingsconventies gebonden drones zoals wij...

[Afvalzak]

LOL, we hebben nog een hoop te leren

Nooit geweten dat in een vrij simpel boekhoud programma zoveel filosofische achtergrond zou kunnen zitten

[ Voor 59% gewijzigd door Afvalzak op 10-05-2010 00:51 ]

[Chip.]

afvalzak schreef op zaterdag 08 mei 2010 @ 18:26:
Vandaag had ik nog een mooie op mijn werk, een database gemaakt in Access met een aantal spelfouten.
In de tabelnamen/kolomnamen, voorbeeld:

Hoofdrubrieken was: Hooftdrubrieken
Ontvangen: Ontvagen
en nog wat dingen. Programma is gemaakt door een 'professioneel' bedrijf.
Kan me niet voorstellen dat dit met een goed datamodel gebeurtd was, en als meer dan 1 persoon er naar had gekeken.

Misschien door een buitenlands bedrijf?

[.Gertjan.]

Wouser schreef op maandag 10 mei 2010 @ 01:16:
[...]

Misschien door een buitenlands bedrijf?

De wonderen van offshoring Nederlandse code gewoon over de schutting gooien naar India ofzo

Maar ik zie ook zo vaak spelfouten in code (en ben zelf ook niet heilig). Maar dat is vaak te verklaren doordat we alles netjes in het Engels doen en er helaas geen enkele spellingscontrole in je IDE zit (en sommige Engelse woorden zijn nou eenmaal lastig te spellen voor non-native speakers). Op die manier krijg je dus spelfouten in je source, maar ook in je documentatie en geloof me als je daar pas laat achterkomt laat je die spelfouten gewoon zitten in veel gevallen (en om consistent te blijven ga je zelf ook de "foute" versie gebruiken).

Heb overigens wel ooit spellcheck in mijn IDE visual studio gehad, maar die deed geloof ik alleen je comments. Maar voor Engelse code hebben we gelukkig ook nog FXCop, die doet ook een stukje naming check.

[YopY]

afvalzak schreef op zaterdag 08 mei 2010 @ 18:26:
Vandaag had ik nog een mooie op mijn werk, een database gemaakt in Access met een aantal spelfouten.
In de tabelnamen/kolomnamen, voorbeeld:

Hoofdrubrieken was: Hooftdrubrieken
Ontvangen: Ontvagen
en nog wat dingen. Programma is gemaakt door een 'professioneel' bedrijf.
Kan me niet voorstellen dat dit met een goed datamodel gebeurtd was, en als meer dan 1 persoon er naar had gekeken.

Ontvagen, . Was d'r maar een goeie tool die dat met software kon doen . Iets vergelijkbaars is er in een applicatie van mij geslopen - de originele auteur had een typfout gemaakt (een JSON veld genaamd 'decription'), en degene die de Flash frontend daarvoor maakte had dat gewoon overgenomen. Ach, als het maar niet verandert is het best.

quote: .Gertjan.

en er helaas geen enkele spellingscontrole in je IDE zit

welles, . Tenminste, IntelliJ IDEA heeft het voor identifiers en dergelijke, en de meeste andere IDE's sowieso voor comments. Daar moet ik overigens eens wat tijd aan besteden.

[Otherside1982]

YopY schreef op maandag 10 mei 2010 @ 09:28:
Iets vergelijkbaars is er in een applicatie van mij geslopen - de originele auteur had een typfout gemaakt (een JSON veld genaamd 'decription'), en degene die de Flash frontend daarvoor maakte had dat gewoon overgenomen. Ach, als het maar niet verandert is het best.

Is dat dan een typfout van description of van decryption

[418O2]

Ik heb ook wel eens onderhoud aan applicaties gedaan waarbij ik echt geen variabelenamen durfde te verbeteren. Die zat zo beroerd in elkaar dat het risico dat het als een kaartenhuis in elkaar zou donderen zo groot was, dat je het maar beter kan laten zoals het is. Het hoort niet, maar soms is het tijdswijs gezien beter

[Afvalzak]

Wouser schreef op maandag 10 mei 2010 @ 01:16:
[...]

Misschien door een buitenlands bedrijf?

Nee, was het maar zo'n feest

[Janoz]

418O2 schreef op maandag 10 mei 2010 @ 11:48:
Ik heb ook wel eens onderhoud aan applicaties gedaan waarbij ik echt geen variabelenamen durfde te verbeteren. Die zat zo beroerd in elkaar dat het risico dat het als een kaartenhuis in elkaar zou donderen zo groot was, dat je het maar beter kan laten zoals het is. Het hoort niet, maar soms is het tijdswijs gezien beter

Unittests en refactor tooling FTW

[418O2]

Janoz schreef op maandag 10 mei 2010 @ 13:13:
[...]

Unittests en refactor tooling FTW

Van een applicatie die in php was gemaakt met een ondoorzichtige opzet met een deel van de code in Javascript (het server/clientside verhaal was nog niet begrepen door de ontwikkelaar) wil je geen unittests doen. Dat was gewoon dweilen met de kraan open.

[Janoz]

Andersom. Juist refactor tools zijn bij dergelijke applicaties niet tot nauwelijks mogelijk. Sowieso is dat bij php bijna onmogelijk omdat je complete code dynamisch in elkaar gehangen kan worden en je op een bepaald punt geen enkele garantie hebt over de context. En als javascript er dan ook nog door verweven zit wordt het wel heel lastig.

Unittesten zijn juist heel goed mogelijk met een tool als selenium.

[YopY]

Sowieso wordt ik telkens minder een fan van het gebruik van verschillende omgevingen door elkaar, mede doordat je niet gemakkelijk identifiers over je gehele applicatie kunt refactoren. Als ik (om mijn vorige voorbeeld weer aan te halen) een backend heb die een veld 'decription' terugstuurt naar een Javascript aanroeper, kan ik dat niet op een plek vervangen. Of dat in HTML plaatsen. De IDE is gewoon niet bewust van de koppeling tussen de twee.

Nu zijn er projecten waarbij gegevens naar een andere taal (XML, HTML) vertaald worden binnen de code zelf waardoor het iets makkelijker wordt... maar ook dat is nog niet optimaal.

Ik wil gewoon dat mijn IDE bewust wordt van de objecten die ik in JSP gebruik, en me keihard uitscheldt als ik iets verkeerd doe. Of dat het genereren van je applicatie en de HTML en Javascript dat daarbij hoort gewoon in dezelfde taal kan, zonder dat je jezelf in vreemde bochten hoeft te wringen of onoverzichtelijke en/of saaie code hoeft te schrijven.

Zoiets heb ik wel eens gedaan in Zend Framework, maar dat kan ik niet echt handig noemen...

[.Gertjan.]

YopY schreef op maandag 10 mei 2010 @ 14:54:
Sowieso wordt ik telkens minder een fan van het gebruik van verschillende omgevingen door elkaar, mede doordat je niet gemakkelijk identifiers over je gehele applicatie kunt refactoren.

Gewoon een replace all uitvoeren
Zo ooit een refactoring gedaan om Id om te zetten naar ID, find en replace op id naar ID
Dat is best wel gruwelijk mis gegaan Hidden werd HIDden enz...

[.oisyn]

Amateur, je weet toch dat je dan "whole word only" aan moet zetten

* .oisyn is find&replace koning

[ Voor 25% gewijzigd door .oisyn op 10-05-2010 16:52 ]

[Phyxion]

.oisyn schreef op maandag 10 mei 2010 @ 16:51:
Amateur, je weet toch dat je dan "whole word only" aan moet zetten

* .oisyn is find&replace koning

Klinkt als brak pakket zonder refactoringmogelijkheden

[Verwijderd]

Dat leidt je af uit de optie "Whole word only"?

[Matis]

Verwijderd schreef op maandag 10 mei 2010 @ 17:01:
Dat leidt je af uit de optie "Whole word only"?

Nee, ik denk uit het feit dat hij daar find&replace voor gebruikt, ipv de refactortool welke in de IDE zit

[Janoz]

.oisyn schreef op maandag 10 mei 2010 @ 16:51:
* .oisyn is find&replace koning

Tja, dat krijg je met die VS gebruikers he . Bij ons aan de java kant hadden we in 2003 al fatsoenlijke refactor mogelijkheden

[.oisyn]

Met refactoring rename je elke referentie naar dezelfde variabele, niet alle variabelen die een dergelijke naam hebben.

Het verbaast me eerlijk gezegd dat mensen hier doen alsof je met refactoring features nooit meer find&replace nodig zou hebben. Waarschijnljik dezelfde mensen die de overige dingen met de hand doen

[ Voor 46% gewijzigd door .oisyn op 10-05-2010 17:06 ]

[MBV]

@Janoz: Wel eens alle someVeryLongPrefix door shortPrefix vervangen in meerdere variabelenamen in Java? find/replace is ideaal, maar niet als je het 20x moet doen

find/replace is trouwens voor watjes, lang leve grep/sed/awk

[.oisyn]

Pff, waar heb je grep/sed/awk voor nodig als je gewoon een find&replace in all files mét regex kunt doen vanuit je IDE

[Verwijderd]

Janoz schreef op maandag 10 mei 2010 @ 14:03:
Andersom. Juist refactor tools zijn bij dergelijke applicaties niet tot nauwelijks mogelijk. Sowieso is dat bij php bijna onmogelijk omdat je complete code dynamisch in elkaar gehangen kan worden en je op een bepaald punt geen enkele garantie hebt over de context.

Volgens mij ben jij stiekem wel een IntelliJ IDEA gebruiker en heb je dus de tool die heel aardig php kan refactoren al in handen

[Grijze Vos]

De beste find and replace IDE is uiteraard vim. Even een expressie uitpoepen om een bepaald attribuut uit een bepaalde html tag te veranderen. Probleem is dan wel dat die shit zo complex is dat je 20 minuten verder bent voor je die expressie uitgevogeld hebt.

Oh, die goeie oude php-om-4-uur-snacht tijd.

.oisyn schreef op maandag 10 mei 2010 @ 17:38:
Pff, waar heb je grep/sed/awk voor nodig als je gewoon een find&replace in all files mét regex kunt doen vanuit je IDE

Dat kan niet in VS toch?

[ Voor 29% gewijzigd door Grijze Vos op 10-05-2010 18:13 ]

[.oisyn]

Jawel hoor, al eeuwen

[Kef]

Grijze Vos schreef op maandag 10 mei 2010 @ 18:05:
De beste find and replace IDE is uiteraard vim. Even een expressie uitpoepen om een bepaald attribuut uit een bepaalde html tag te veranderen. Probleem is dan wel dat die shit zo complex is dat je 20 minuten verder bent voor je die expressie uitgevogeld hebt.

Oh, die goeie oude php-om-4-uur-snacht tijd.


[...]

Dat kan niet in VS toch?

Dat is wel mogelijk.

[Alex)]

Jetbrains (van R# en IntelliJ IDEA) is inmiddels ook bezig met een PHP-editor, PhpStorm genaamd. Free trial te vinden op http://www.jetbrains.com/phpstorm/index.html

[Phyxion]

.oisyn schreef op maandag 10 mei 2010 @ 17:04:
Met refactoring rename je elke referentie naar dezelfde variabele, niet alle variabelen die een dergelijke naam hebben.

Het verbaast me eerlijk gezegd dat mensen hier doen alsof je met refactoring features nooit meer find&replace nodig zou hebben. Waarschijnljik dezelfde mensen die de overige dingen met de hand doen

Tsja dan kan je je in eerste instantie ook afvragen waarom je het uberhaupt nodig hebt en het niet meteen goed doet als je zo begint.

[Janoz]

Verwijderd schreef op maandag 10 mei 2010 @ 18:01:
[...]
Volgens mij ben jij stiekem wel een IntelliJ IDEA gebruiker en heb je dus de tool die heel aardig php kan refactoren al in handen

In 2002 heeft IDEA mij doen overstappen vanaf Emacs. Jaren met alle plezier mee gewerkt. Helaas heb ik, toen ik bij dat bedrijf weg ging, nooit meer in een omgeving gezeten waar ze die IDE gebruikten. Sindsdien eigenlijk alleen nog maar eclipse en afgeleiden gebruikt. Eigenlijk was Eclipse toen altijd mijn tweede keuze gebleven, maar ik heb geen idee hope ze nu tegenover elkaar staan. Hoorde laatst wel dat IDEA tegenwoordig ook een community versie heeft. Ben er alleen nog niet aan toe gekomen om die weer eens te gaan proberen.

Meest vermakelijke blijven toch de VS reclames.
MS : Bla bla nieuwe feature waardoor je nog productiever bent
Jnz: Hmm, hadden ze dat nog niet dan

.oisyn schreef op maandag 10 mei 2010 @ 17:04:
Met refactoring rename je elke referentie naar dezelfde variabele, niet alle variabelen die een dergelijke naam hebben.

Klopt. Maar mijn originele opmerking was in de context van kaartenhuissoftware. En daar heb je het liefst dat een tool ook context aware is. Daarmee wil ik absoluut niet zeggen dat find&replace overbodig is.

Het verbaast me eerlijk gezegd dat mensen hier doen alsof je met refactoring features nooit meer find&replace nodig zou hebben. Waarschijnljik dezelfde mensen die de overige dingen met de hand doen

Ik denk dat het aantal mensen die enkel find & replace (en afgeleiden als sed) gebruiken en eigenlijk geen idee hebben dat er refactor tooling bestaat die hun werk een stuk efficienter zou kunnen maken, een stuk groter is dan de groep die jij nu aanhaalt.

Phyxion schreef op maandag 10 mei 2010 @ 19:23:
[...]

Tsja dan kan je je in eerste instantie ook afvragen waarom je het uberhaupt nodig hebt en het niet meteen goed doet als je zo begint.

Omdat je niet altijd degene hoeft te zijn die met je huidige project begonnen is.

[ Voor 41% gewijzigd door Janoz op 10-05-2010 20:26 ]

[MBV]

Grijze Vos schreef op maandag 10 mei 2010 @ 18:05:
Dat kan niet in VS toch?

Jij werkte toch al een paar jaar standaard in .NET?

.oisyn schreef op maandag 10 mei 2010 @ 17:38:
Pff, waar heb je grep/sed/awk voor nodig als je gewoon een find&replace in all files mét regex kunt doen vanuit je IDE

Regexen zijn echt veel minder goed te gebruiken dan SED. Ik wil in regel X iets veranderen als in regel X+1 iets gebeurt, veel plezier. Of even snel debug-output van een analyse van 3 uur filteren op de 5 interessante gevallen... Ik zorg altijd dat ik op z'n minst cygwin in de buurt heb

[.oisyn]

Janoz schreef op maandag 10 mei 2010 @ 20:20:
Ik denk dat het aantal mensen die enkel find & replace (en afgeleiden als sed) gebruiken en eigenlijk geen idee hebben dat er refactor tooling bestaat die hun werk een stuk efficienter zou kunnen maken, een stuk groter is dan de groep die jij nu aanhaalt.

Volgens mij heb ik dan ook niets over die groep gezegd. En je snapt toch ook wel dat ik met zo'n opmerking kom als men ineens over refactoring tools begint te roepen als ik het over find&replace heb? Wie de bal kaatst kan 'm terug verwachten

[ Voor 3% gewijzigd door .oisyn op 10-05-2010 22:55 ]

[Davio]

Ik wil nog wel wat toevoegen over dat refactoren / unit testen niet altijd kan.

Ik werk veel met Progress / OpenEdge en die compiler is niet heel slim.
Dat ligt ook aan de taal, die in de praktijk veelal procedure based is en nog niet echt object oriented, al komt daar (heel) langzaam verandering in.

Zo kun je makkelijk code compileren die niet werkt omdat een bepaalde procedure helemaal niet bestaat.
Als je bijvoorbeeld zegt: RUN "filename.p" dan compileert dat wel goed, maar krijg je een run-time error als het bestand er niet is.

Een voordeel is dan weer dat je on the fly nieuwe procedures kunt bakken en kunt runnen, maar toch is het in de debugging-fase van je programma erg lastig. Daarbij wordt die methodiek zelden gebruikt, want dan kun je beter een procedure maken met bepaalde input parameters in plaats van die procedure tijdens runtime uit te schrijven, wat ook weer erg error prone is, omdat je dan niet kunt syntax checken.

[Grijze Vos]

MBV schreef op maandag 10 mei 2010 @ 22:47:
[...]

Jij werkte toch al een paar jaar standaard in .NET?

Yup, kun je nagaan, nog nooit echt nodig gehad.

Davio schreef op maandag 10 mei 2010 @ 22:59:
Zo kun je makkelijk code compileren die niet werkt omdat een bepaalde procedure helemaal niet bestaat.

Dat heeft niet zo zeer met het procedurele te maken, maar met het feit dat die compiler geen of weinig statische semantische analyse doet. Dat is ook bij procedurele talen gewoon wel mogelijk hoor.

[ Voor 48% gewijzigd door Grijze Vos op 11-05-2010 00:38 ]

[Verwijderd]

Grijze Vos schreef op dinsdag 11 mei 2010 @ 00:35:
Yup, kun je nagaan, nog nooit echt nodig gehad.

Resharper heh, dan pas wordt die 1000-dollar-notepad een IDE

[Alex)]

Nee, dan wordt een goede IDE een geweldige IDE

[YopY]

Grijze Vos schreef op maandag 10 mei 2010 @ 18:05:
De beste find and replace IDE is uiteraard vim. Even een expressie uitpoepen om een bepaald attribuut uit een bepaalde html tag te veranderen. Probleem is dan wel dat die shit zo complex is dat je 20 minuten verder bent voor je die expressie uitgevogeld hebt.

Some people, when confronted with a problem, think “I know, I’ll use regular expressions!” Now they have two problems.

Doe mij maar gewoon find & replace, . Regular expressions snap ik gewoon niet.

Phyxion schreef op maandag 10 mei 2010 @ 19:23:
[...]

Tsja dan kan je je in eerste instantie ook afvragen waarom je het uberhaupt nodig hebt en het niet meteen goed doet als je zo begint.

Omdat je in het begin niet kunt voorspellen wat er allemaal gaat veranderen. Anders was het hele concept 'refactoring' niet nodig, .

[Grijze Vos]

YopY schreef op dinsdag 11 mei 2010 @ 09:22:
[...]


Some people, when confronted with a problem, think “I know, I’ll use regular expressions!” Now they have two problems.

Doe mij maar gewoon find & replace, . Regular expressions snap ik gewoon niet.

Daarom zei ik ook expressie en niet reguliere expressie Overigens behoort kennis van reguliere expressies m.i. toch echt tot de basis kennis van een programmeur. Mgoed, ik zit zelf al weer een tijd in het veld van de taaltechnologie, dan schrik je niet echt van wat regex.

[MBV]

Grijze Vos schreef op dinsdag 11 mei 2010 @ 11:16:
[...]

Daarom zei ik ook expressie en niet reguliere expressie Overigens behoort kennis van reguliere expressies m.i. toch echt tot de basis kennis van een programmeur. Mgoed, ik zit zelf al weer een tijd in het veld van de taaltechnologie, dan schrik je niet echt van wat regex.

Lang leve GLT!

[Jrz]

Grijze Vos schreef op dinsdag 11 mei 2010 @ 11:16:
[...]

Daarom zei ik ook expressie en niet reguliere expressie Overigens behoort kennis van reguliere expressies m.i. toch echt tot de basis kennis van een programmeur. Mgoed, ik zit zelf al weer een tijd in het veld van de taaltechnologie, dan schrik je niet echt van wat regex.

Wat een onzin zeg. Ik vind dat de basiskennis van een programmeur inhoudt:
* assembler
* c
* java
* php
* ruby/python
* netwerken
* rdbms
* filesystems
* memory management
* virtual machines
* garbage collection
* threading
etc etc.

[Davio]

Vergeet Wiskunde B niet.

[OxiMoron]

- Klingon
- Knowing how to kill a jabberwockey

[.oisyn]

Jrz schreef op dinsdag 11 mei 2010 @ 13:47:
[...]

Wat een onzin zeg. Ik vind dat de basiskennis van een programmeur inhoudt:
* assembler
* c
* java
* php
* ruby/python
* netwerken
* rdbms
* filesystems
* memory management
* virtual machines
* garbage collection
* threading
etc etc.

Wat een onzin zeg.

[RayNbow]

Ik mis Haskell in dat rijtje

[remco_k]

Ik maakte zelf nog weleens een foutje - als gevolg van de formatterings standaard van een collega.
Stel; ik doe een aanpassing aan een bestaande app, waar iets extra's moet gebeuren als er niet aan de conditie wordt voldaan.

Als voorbeeld is dit de orginele code:

C++:

if (someCondition) 
   doSomething();
else 
   doSomethingElse();

En ik trap(te) er vrijwel altijd in en maakte er dit van:

C++:

if (someCondition) 
   doSomething();
else 
   doSomethingElse();
   doSomethingElse2();

En tja, dan heb je een bug of undocumented feature gemaakt.

Ik haat deze formattering en zelf schrijf ik het dan ook het liefst altijd met accolades. Simpelweg omdat ik het duidelijker vindt en de kans op fouten (m.i.) veel kleiner maakt.
Orgineel zou ik zo hebben gedaan:

C++:

if (someCondition) {
   doSomething();
} else {
   doSomethingElse();
}

En de aanpassing uiteraard:

C++:

if (someCondition) {
   doSomething();
} else {
   doSomethingElse();
   doSomethingElse2();
}

Ik probeer m'n collega waat op te voeden, maar die is van de wat oudere stempel. Lukt niet echt.
Dus blijf ik (natuurlijk) gewoon opletten. Zodra ik wat aanpassingen moet plegen aan zijn project(en) dan verander ik het gewoon waar ik overal moet zijn.

[kenneth]

RayNbow schreef op dinsdag 11 mei 2010 @ 14:44:
Ik mis Haskell in dat rijtje

Ik mis handvaardigheid (NAND-poortjes snijden uit silicium).

[ Voor 54% gewijzigd door kenneth op 11-05-2010 14:47 ]

[.oisyn]

remco_k schreef op dinsdag 11 mei 2010 @ 14:47:
En ik trap(te) er vrijwel altijd in en maakte er dit van:

C++:

if (someCondition) 
   doSomething();
else 
   doSomethingElse();
   doSomethingElse2();

En tja, dan heb je een bug of undocumented feature gemaakt.

Ik haat deze formattering en zelf schrijf ik het dan ook het liefst altijd met accolades. Simpelweg omdat ik het duidelijker vindt en de kans op fouten (m.i.) veel kleiner maakt.
Orgineel zou ik zo hebben gedaan:

C++:

if (someCondition) {
   doSomething();
} else {
   doSomethingElse();
}

Ergens is dat ook het nadeel van accolades openen op dezelfde regel. Als je gewend bent dat het zo staat:

C++:

if (someCondition)
{
   doSomething();
   doSomething2();
}
else
{
   doSomethingElse();
   doSomethingElse2();
}

dan schrijf je imho ook niet snel

C++:

if (someCondition) 
   doSomething();
else 
   doSomethingElse();
   doSomethingElse2();

Omdat er dan duidelijk accolades missen.

Andere voordelen zijn dat je makkelijker de if of het hele else blok uit kunt commenten

[mux]

remco_k schreef op dinsdag 11 mei 2010 @ 14:47:
Als voorbeeld is dit de orginele code:

C++:

if (someCondition) 
   doSomething();
else 
   doSomethingElse();

En ik trap(te) er vrijwel altijd in en maakte er dit van:

C++:

if (someCondition) 
   doSomething();
else 
   doSomethingElse();
   doSomethingElse2();

Als ik één statement uitvoer na een if/else, gooi ik het op dezelfde regel, anders gaat het op de volgende regel met accolades eromheen. Op die manier ben ik nog nooit de mist in gegaan.

Wel natuurlijk met de vergeten puntkomma achter een lege for/while-loop....

[ Voor 42% gewijzigd door mux op 11-05-2010 14:54 ]

[Janoz]

@remco_k: Gewoon opnemen in je codeformat template en elk bestand waar je aan werkt eerst de IDE een schop geven om die overal toe te passen.

[Davio]

ssj3gohan schreef op dinsdag 11 mei 2010 @ 14:54:
[...]


Als ik één statement uitvoer na een if/else, gooi ik het op dezelfde regel, anders gaat het op de volgende regel met accolades eromheen. Op die manier ben ik nog nooit de mist in gegaan.

Wel natuurlijk met de vergeten puntkomma achter een lege for/while-loop....

Ik gebruik altijd accolades; als er maar één statement volgt dan optimaliseert de compiler dat toch wel.

Grootste voordeel is dat je makkelijk achteraf statements toe kunt voegen.

[D-Raven]

Wat ik zo vaak voorbij zie komen...

C#:

<%# if(String.IsNullOrEmpty(Eval("VeldNaam").ToString()))  {..} %>

[.oisyn]

vaak?

[D-Raven]

Helaas wel ja. Komt uit een project wat al 6 jaar oud is. Je wilt niet weten wat voor dingen ik tegenkom. Af en toe noem ik werken aan dit project wel eens een "creatief potje mijnenveger".

[YopY]

Jrz schreef op dinsdag 11 mei 2010 @ 13:47:
[...]

Wat een onzin zeg. Ik vind dat de basiskennis van een programmeur inhoudt:
* assembler
* c
* java
* php
* ruby/python
* netwerken
* rdbms
* filesystems
* memory management
* virtual machines
* garbage collection
* threading
etc etc.

Ontbreekt nog aan Common Sense, logica, abstract nadenken, nadenken algemeen, leergierigheid / nieuwsgierigheid, omgang met (en najagen van) kritiek, etc.

Ik hoef Assembler niet te kennen om toch stevige en goeie apps neer te zetten. Ik hoef geen RDBMS te kennen om mijn zooi in bestandjes op te slaan. Ik hoef niks van threading te weten bij de meeste apps. Ik hoef niks te weten over virtual machines als mijn programma gewoon werkt. Van filesystemen hoef ik ook niets te weten, aangezien een beetje programmeeromgeving daar gewoon een abstractielaag bovenop gelegd heeft. Etc.

remco_k schreef op dinsdag 11 mei 2010 @ 14:47:
Ik maakte zelf nog weleens een foutje - als gevolg van de formatterings standaard van een collega.
[...]

Misschien moeten jullie overstappen op een taal zonder accolades, waar indentatie in dit geval belangrijk is? Of een analysetool maken die dit soort potentiele bugs eruit haalt, door óf te detecteren als er twee dingen zo bij elkaar staan, óf door gewoon keihard te roepen 'D'r staan geen accolades om!'.

Zo heb ik mijn Eclipse zo ingericht dat hij altijd automagisch accolades neerzet (en nog wat andere dingen doet) zodra je op Save drukt. Dan kun je het ook niet vergeten.

ssj3gohan schreef op dinsdag 11 mei 2010 @ 14:54:
Wel natuurlijk met de vergeten puntkomma achter een lege for/while-loop....

Vergeten? De puntkomma achter je if / else / while ipv open-accolade juist neerzetten, probeer die maar eens weer te vinden . Da's het nadeel van puntkomma-talen, je begint ze overal achter te zetten;

[Steffannnn]

Zo heb ik mijn Eclipse zo ingericht dat hij altijd automagisch accolades neerzet (en nog wat andere dingen doet) zodra je op Save drukt. Dan kun je het ook niet vergeten.

Om vervolgens bugs te hebben omdat eclipse ze niet goed neer zet, tenminste niet zoals jij zou willen

[.Gertjan.]

D-Raven schreef op dinsdag 11 mei 2010 @ 15:15:
Wat ik zo vaak voorbij zie komen...

C#:

<%# if(String.IsNullOrEmpty(Eval("VeldNaam").ToString()))  {..} %>

Gaat dat niet mis als er een null in staat? Of zit ik er nou naast? Eval geeft toch een object terug? En voor zover ik weet heeft null geen ToString.

Kun je beter zeggen:

C#:

<%# if(String.IsNullOrEmpty("" + Eval("VeldNaam")))  {..} %>

[.oisyn]

De code checkt ook niet of VeldNaam zelf null is, maar of de ToString() methode null of "" teruggeeft. Wellicht kan VeldNaam in dat stukje code wel gewoon nooit null zijn

[.Gertjan.]

.oisyn schreef op dinsdag 11 mei 2010 @ 16:53:
De code checkt ook niet of VeldNaam zelf null is, maar of de ToString() methode null of "" teruggeeft. Wellicht kan VeldNaam in dat stukje code wel gewoon nooit null zijn

Dan begreep ik het toch goed Maar een ToString() aanroepen op iets wat in theorie null kan zijn is wel gevaarlijk. Overigens zal een ToString() nooit null terug geven. Dus de code rammelt op meerdere vlakken
Maar daar is dit topic ook voor

[.oisyn]

.Gertjan. schreef op dinsdag 11 mei 2010 @ 17:07:
Overigens zal een ToString() nooit null terug geven.

C#:

class MyClass
{
    public override string ToString() { return null; }
}

Voldoet natuurlijk niet aan de guidelines, maar gezien andere regels code uit het project zou dit zomaar kunnen

[mux]

YopY schreef op dinsdag 11 mei 2010 @ 16:25:
[...]


Vergeten? De puntkomma achter je if / else / while ipv open-accolade juist neerzetten, probeer die maar eens weer te vinden . Da's het nadeel van puntkomma-talen, je begint ze overal achter te zetten;

Gelukkig werk ik vooral met script/programmeertalen waar de compilers zo slim zijn dat ze dat soort foutjes dan weer wél begrijpen. Die lege loops en unbalanced parentheses echter, die laten je, zeker in andermans code, nogal eens lang zoeken.

[Sebazzz]

YopY schreef op dinsdag 11 mei 2010 @ 16:25:
[...]

Vergeten? De puntkomma achter je if / else / while ipv open-accolade juist neerzetten, probeer die maar eens weer te vinden . Da's het nadeel van puntkomma-talen, je begint ze overal achter te zetten;

Oh, je typt liever een verhaaltjestaal zoals VB?

[D-Raven]

.Gertjan. schreef op dinsdag 11 mei 2010 @ 16:42:
[...]


Gaat dat niet mis als er een null in staat? Of zit ik er nou naast? Eval geeft toch een object terug? En voor zover ik weet heeft null geen ToString.

Kun je beter zeggen:

C#:

<%# if(String.IsNullOrEmpty("" + Eval("VeldNaam")))  {..} %>

Dat gaat inderdaad mis als er null in staat. Dat was ook het probleem zegmaar . Het werd voornamelijk gebruikt bij velden waarvan het credo was "ja maar deze zou nooit null moeten zijn".

Maar jou voorbeeld is ook niet super Zowiezo zou ik String.IsNullOrEmpty alleen maar gebruiken als het veld ook daadwerkelijk een string is. Dan krijg je dus zoiets.

C#:

<%# if(String.IsNullOrEmpty((string)Eval("VeldNaam")))  {..} %>

[.Gertjan.]

D-Raven schreef op dinsdag 11 mei 2010 @ 18:52:
[...]


Dat gaat inderdaad mis als er null in staat. Dat was ook het probleem zegmaar . Het werd voornamelijk gebruikt bij velden waarvan het credo was "ja maar deze zou nooit null moeten zijn".

Maar jou voorbeeld is ook niet super Zowiezo zou ik String.IsNullOrEmpty alleen maar gebruiken als het veld ook daadwerkelijk een string is. Dan krijg je dus zoiets.

C#:

<%# if(String.IsNullOrEmpty((string)Eval("VeldNaam")))  {..} %>

Mmmm, hoe reageert een cast naar string als er null in staat? Gaat dat ook niet mis of mag je een null naar ieder willekeurig type casten?

[.oisyn]

Natuurlijk mag dat. Voor het type waarnaar je cast is null toch ook een geldige waarde?

[Jrz]

YopY schreef op dinsdag 11 mei 2010 @ 16:25:
[...]


Ontbreekt nog aan Common Sense, logica, abstract nadenken, nadenken algemeen, leergierigheid / nieuwsgierigheid, omgang met (en najagen van) kritiek, etc.

Ik hoef Assembler niet te kennen om toch stevige en goeie apps neer te zetten. Ik hoef geen RDBMS te kennen om mijn zooi in bestandjes op te slaan. Ik hoef niks van threading te weten bij de meeste apps. Ik hoef niks te weten over virtual machines als mijn programma gewoon werkt. Van filesystemen hoef ik ook niets te weten, aangezien een beetje programmeeromgeving daar gewoon een abstractielaag bovenop gelegd heeft. Etc.

Klopt, maar regex is ook niet voor alles nodig

[.Gertjan.]

.oisyn schreef op dinsdag 11 mei 2010 @ 23:19:
Natuurlijk mag dat. Voor het type waarnaar je cast is null toch ook een geldige waarde?

Mmm dat is wel weer zo maar het toch vraag ik het me af of bijvoorbeeld onderstaande constructie mag:

C#:

class MyClass {
  public int? myInt { get; set; }
  public string myString { get; set; }
}

public void Test() {
  MyClass mc = new MyClass(); //myInt and myString are null
  mc.myInt = (int?)mc.myString;
}

Want de compiler zal hier waarschuwen. Het geval met de Eval zal waarschijnlijk pas tijdens uitvoeren worden gechecked en misschien worden toegestaan, maar bovenstaande levert toch fouten op?

edit:

Grappig, de compiler waarschuwt over het feit dat string niet naar een int? mag worden gecast. Pas je de code aan zodat de int? naar een object gaat dan vind de compiler het wel goed en loopt de code ook door...

C#:

public void Test() {
    MyClass mc = new MyClass(); //myInt and myString are null
    object o = mc.myString;
    mc.myInt = (int?)o;
}

Het is wel logisch dat nulls naar ieder type kunnen worden gecast, maar zoals boven zal de compiler het soms weigeren (daarom dacht ik ook dat het altijd mis zou gaan). Maar eval geeft een object terug (en weet niet wat het type was van het object dat hij terug gaf) en zal dus inderdaad in het geval van null gecast kunnen worden naar alle types die null accepteren, op het moment dat er WEL iets terugkomt loop je pas tegen problemen aan.

Weer wat geleerd

[ Voor 36% gewijzigd door .Gertjan. op 12-05-2010 09:31 ]

[YopY]

Steffannnn schreef op dinsdag 11 mei 2010 @ 16:29:
[...]

Om vervolgens bugs te hebben omdat eclipse ze niet goed neer zet, tenminste niet zoals jij zou willen

Dat is mij nog niet voorgekomen. Misschien omdat accolades redelijk triviaal zijn, of misschien omdat, als je accolades toevoegt aan een bestaand rijtje opdrachten, hij de sluit-tag gelijk plaatst, zonder die om de opdrachten heen te zetten.

En anders kun je de opdrachten selecteren, alt + shift + Z, 3 en iets intypen.

Sebazzz schreef op dinsdag 11 mei 2010 @ 18:37:
[...]

Oh, je typt liever een verhaaltjestaal zoals VB?

code:

HAI
CAN HAS STDIO?
I HAS A VAR
IM IN YR LOOP
    UP VAR!!1
    VISIBLE VAR
    IZ VAR BIGGER THAN 10? KTHXBYE
IM OUTTA YR LOOP
KTHXBYE

Ik heb nog geen voorkeur. Geef mij maar iets expliciets als Java, voorlopig. Alhoewel dat mogelijk nog veel meer explicieter wordt.

code:

@Entity
@Table(name="entities",uniqueConstraints = {@UniqueConstraint(columnNames={"month", "day"})})
class SomeEntity {
  private @NonNull SomeObject myObject;
  public SomeObject setSomeObject(@NonNull SomeObject someObject) {
    this.myObject = someObject;
  }
}

bijvoorbeeld. Volgens mij zijn d'r wel overdrevener voorbeelden te vinden, .

Jrz schreef op woensdag 12 mei 2010 @ 00:41:
Klopt, maar regex is ook niet voor alles nodig

Nope. Alleen als je text moet matchen, en dan alleen pas als het op een zodanig complexe manier moet dat een eenvoudiger manier (zoals een API call naar contains() of zoiets) niet voldoet. Gelukkig zijn regexes slechts voor een zeer specifiek vakgebied bedoeld.

[Davio]

Ik gebruik regex veel voor clientside validatie, bijvoorbeeld e-mails, telefoonnummers, postcodes, wachtwoorden, dat soort dingen.

En ja, natuurlijk wordt er ook nog serverside gevalideerd.

[RobIII]

Davio schreef op woensdag 12 mei 2010 @ 09:42:
bijvoorbeeld e-mails

En juist hiervoor zijn regexes eigenlijk ellende; of je staat enkel "simpele" e-mail adressen toe, of je regex is onleesbaar.

Davio schreef op woensdag 12 mei 2010 @ 09:42:
telefoonnummers, postcodes

Die varieëren weer vaak per land bijvoorbeeld; iets wat je regex na een paar 'ondersteunde' notaties onleesbaar maakt.

Davio schreef op woensdag 12 mei 2010 @ 09:42:
wachtwoorden

Daar is een regex dan IMHO weer overkill voor; je doet een check op x-lengte, min x lower/uppercase en min x cijfers; dat is in een paar regels leesbare code makkelijker samen te vatten dan een regex (IMHO).

[ Voor 7% gewijzigd door RobIII op 12-05-2010 10:00 ]

[Davio]

RobIII schreef op woensdag 12 mei 2010 @ 09:56:
[...]

En juist hiervoor zijn regexes eigenlijk ellende; of je staat enkel "simpele" e-mail adressen toe, of je regex is onleesbaar.

Nou ja, wij staan gewoon simpele adressen toe.
Het is er de gebruiker aan gelegen om te zorgen dat zijn e-mailadres klopt voor als hij zijn wachtwoord kwijt is.
Verder wordt de registratie van gebruikers voor ons geregeld bij een fysieke instantie waarbij ze identificatie nodig hebben, we zullen dus weinig vervuiling hebben van nep-gebruikers.

RobIII schreef op woensdag 12 mei 2010 @ 09:56:
[...]

Die varieëren weer vaak per land bijvoorbeeld; iets wat je regex na een paar 'ondersteunde' notaties onleesbaar maakt.

Onze gebruikers komen per definitie alleen uit Nederland en mogen alleen gsm-nummers gebruiken, wat dit juist erg makkelijk maakt.

RobIII schreef op woensdag 12 mei 2010 @ 09:56:
[...]

Daar is een regex dan IMHO weer overkill voor; je doet een check op x-lengte, min x lower/uppercase en min x cijfers; dat is in een paar regels leesbare code makkelijker samen te vatten dan een regex (IMHO).

Wij maken gebruik van Backbase, die doet gewoon verschillende checks na elkaar en als er één niet goed is, dan mislukt de validatie.

In ons geval werkt het zo:

XML:

<minLength value="8" />
<pattern value=".*\d.*" />
<pattern value=".*[A-Z].*" />
<pattern value=".*[a-z].*" /> 
<pattern value=".*[#\$\*\+\-].*" />

[YopY]

Davio schreef op woensdag 12 mei 2010 @ 10:44:
Wij maken gebruik van Backbase, die doet gewoon verschillende checks na elkaar en als er één niet goed is, dan mislukt de validatie.

In ons geval werkt het zo:

XML:

<minLength value="8" />
<pattern value=".*\d.*" />
<pattern value=".*[A-Z].*" />
<pattern value=".*[a-z].*" /> 
<pattern value=".*[#\$\*\+\-].*" />

Leuk, vier patterns compilen, één voor één over de gehele string laten halen... Oké, het is misschien muggenziften, maar qua performance is zo'n aanpak 'suboptimaal'. Dat kan ook in één expressie.

Oh ja, voor valideren van complexe of gestructureerde invoer (emails, internepadressen) is regex ook wel weer goed. Voor wachtwoorden zou ik echter kiezen voor een validatie die alleen standaard ASCII tekens toestaat en die een bepaalde complexiteit garandeert. Complexiteit kun je dan weer via een bepaalde formule berekenen. Of dat sneller is dan een regex laten matchen is wat anders, maar het is beter dan een foutmelding als 'je wachtwoord moet een speciaal teken bevatten'. deze is wel een grappig voorbeeld van zoiets (heel grafisch).

[Grijze Vos]

Mja, hier was ik al bang voor. Je zegt regex en mensen denken meteen aan validatie van een of andere string en daar houdt het op. Met reguliere expressies druk je reguliere grammatica's uit. Als ik zeg dat je regex moet kennen bedoel ik daarmee dat je de theorie van reguliere grammatica's behoort te kennen. Inclusief de limitaties van deze grammatica's. Zo zou je ook moeten weten wat context vrije grammatica's zijn. Ik zeg niet dat je uit je hoofd reguliere expressies van een A4tje moet kunnen schrijven, maar dat je de kern zaken kent. Helaas blijkt maar al te vaak dat die kennis niet aanwezig is bij mensen.

@Jrz
ik hoop dat dat lijstje van je niet al te serieus is bedoeld. Talen hoor je niet te leren, je leert taal paradigma's. Dat je die leert door de talen te gebruiken lijkt me niet meer dan logisch. Ik zie vaker de tendens dat mensen helemaal niet door hebben dat wat ze uiteindelijk leren concepten zijn, en niet de "instanties" van die concepten die ze in de praktijk tegen komen.

Misschien is dit onderwerp een apart topic waardig: "De skillset van de software-engineer".

[Davio]

YopY schreef op woensdag 12 mei 2010 @ 11:57:
[...]


Leuk, vier patterns compilen, één voor één over de gehele string laten halen... Oké, het is misschien muggenziften, maar qua performance is zo'n aanpak 'suboptimaal'. Dat kan ook in één expressie.

Oh ja, voor valideren van complexe of gestructureerde invoer (emails, internepadressen) is regex ook wel weer goed. Voor wachtwoorden zou ik echter kiezen voor een validatie die alleen standaard ASCII tekens toestaat en die een bepaalde complexiteit garandeert. Complexiteit kun je dan weer via een bepaalde formule berekenen. Of dat sneller is dan een regex laten matchen is wat anders, maar het is beter dan een foutmelding als 'je wachtwoord moet een speciaal teken bevatten'. deze is wel een grappig voorbeeld van zoiets (heel grafisch).

Ik heb het geprobeerd om binnen één expressie te vangen, maar Backbase slikt dat niet helemaal goed (komt door backreferences misschien).

Natuurlijk is deze validatie sub-optimaal, maar de check gebeurt alleen als mensen hun wachtwoord willen wijzigen; initieel wordt er een wachtwoord gegenereerd. Die zal dan één keer gewijzigd worden, maar niet veel vaker.

Ik heb niet gekozen voor deze manier van wachtwoord-complexiteit, maar zo wil de klant het graag.

En backspace is ook een standaard ASCII teken, maar die wil je niet opslaan lijkt me.


Verder snap ik dat Regex meer kan dan string-validatie, maar daar wordt het in de praktijk nu eenmaal veel voor gebruikt.

[Verwijderd]

Grijze Vos schreef op woensdag 12 mei 2010 @ 12:03:
Mja, hier was ik al bang voor. Je zegt regex en mensen denken meteen aan validatie van een of andere string en daar houdt het op. Met reguliere expressies druk je reguliere grammatica's uit.

RegEx stamt af van de Automata Theory, welke je overal in terug ziet (denk aan compilers, IDE's, editors) en hiermee druk je dus inderdaad reguliere grammatica uit.

_{Ik wou dit even vermelden voor de mensen met interesse hierin}

[Davio]

Ah ja, al die meuk heb ik nog gehad op de uni met het vak "Grammatica's en Ontleden", moesten we non-deterministische automata omzetten naar deterministische.

[kenneth]

Niet echt een slecht programmeervoorbeeld maar past het best in dit topic:

http://www.doxdesk.com/img/updates/20091116-so-large.gif

Kijk ook naar de waarderingen van de antwoorden

[BarôZZa]

Herkenbaar. Tegenwoordig word echt voor elke Javascript scheet het JQuery draak erbij gehaald (en yes, ik begrijp de grap).

[ZpAz]

BarôZZa schreef op donderdag 13 mei 2010 @ 21:25:
Herkenbaar. Tegenwoordig word echt voor elke Javascript scheet het JQuery draak erbij gehaald (en yes, ik begrijp de grap).

jQuery draak? jQuery is minified 17! kb, daar kan je met moeite een GOT smiley voor laden bij wijze van spreken. Daarnaast neemt het zoveel werk uit handen, ik include jQuery standaard nu in al mijn projecten.

En qua performance maakt het voor de meeste dingen ook geen moer uit, misschien dat je bepaalde dingen iets kan optimaliseren, maar dat zal vaak micro-optimalisatie zijn.

Voordat men denkt dat ik alleen jQueriaans kan en geen JS, dat is niet het geval, maar 'draak'?

Bovenstaande link is dan wel weer leuk

[ Voor 3% gewijzigd door ZpAz op 13-05-2010 22:46 ]

[BarôZZa]

17kb vind ik een aardige draak(24kb volgens jquery.com) als je vervolgens ziet dat mensen scripts schrijven die je in 10 regels normale Javascript kan plempen.

[kenneth]

Maakt dat JQuery een draak of de programmeurs?

Aldus iemand die in zijn hele leven 0 regels JQuery en 10 regels Javascript heeft geschreven

[CoolGamer]

17kB (of 24kB) wat eenmalig ingeladen hoeft te worden is tegenwoordig niet zo heel veel. Dus om het nou gelijk een "draak" te noemen vind ik overdreven. Als je het makkelijk vindt werken met jQuery, ondanks je er een script mee schrijft wat zonder jQuery in 10 regels geschreven kon worden, dan zou ik het toch gewoon doen. Wat maakt die bijna te verwaarlozen extra downloadtijd nou uit als het programmeren makkelijker gaat of het programmeren gaat zoals je gewend bent.

[crisp]

Mja, als ik dit soort dingen zie onderaan elke pagina terwijl de site zelf al prototype + scriptaculous gebruikt dan vraag ik me wel eens af of ze ueberhaupt wel devvers hebben die iets weten van javascript:

HTML:

<script src="http://static.webwereld.nl/javascript/jquery-1.2.6.min.js" type="text/javascript"></script>
<script type="text/javascript">
    var $j = jQuery.noConflict(); 
    $j(document).ready( function() {
        $j('a[@href^="http://"]').click( function() {
            pageTracker._trackPageview('/outgoing/' + $j(this).attr('href'));
            return true;
        });
    });
</script>

[BarôZZa]

Het punt is dat als je ook maar een beetje Javascript kan, dat je in 99% van de gevallen JQuery niet nodig hebt. Daarnaast vind ik het over het algemeen enorm ranzige en onleesbare code opleveren. Maar in de meeste gevallen (zoals het voorbeeld hierboven) lijkt het toch gebruikt te worden voor copypasta scriptjes. Vaak met een overdaad aan overbodige animatietjes.

Overigens wil ik niet beweren dat JQuery totaal geen nut heeft. Ik ben het alleen nog niet echt tegengekomen.

[ Voor 13% gewijzigd door BarôZZa op 14-05-2010 03:46 ]

[Alex)]

Ik vind jQuery erg handig voor de webapp die ik nu bij een klant mee-ontwikkel. Ze gebruikten daar eerst ASP.NET AJAX, maar om nou een volledige roundtrip naar de server te doen, om de display van een objectje op none te zetten? Daarnaast gebruik ik jQuery voor wat animaties en DOM-transformaties, zoals het wrappen van nodes (zoals WebParts).

Maar nee, Prototype/Script.aculo.us/Dojo/whatever komt er verder niet in. Pure jQuery.

[kunnen]

crisp schreef op vrijdag 14 mei 2010 @ 00:38:
Mja, als ik dit soort dingen zie onderaan elke pagina terwijl de site zelf al prototype + scriptaculous gebruikt dan vraag ik me wel eens af of ze ueberhaupt wel devvers hebben die iets weten van javascript:

HTML:

<script src="http://static.webwereld.nl/javascript/jquery-1.2.6.min.js" type="text/javascript"></script>
<script type="text/javascript">
    var $j = jQuery.noConflict(); 
    $j(document).ready( function() {
        $j('a[@href^="http://"]').click( function() {
            pageTracker._trackPageview('/outgoing/' + $j(this).attr('href'));
            return true;
        });
    });
</script>

Wat is daar mis mee?

[danslo]

ThomasB schreef op vrijdag 14 mei 2010 @ 05:43:
[...]

Wat is daar mis mee?

Met het scriptje zelf niet veel Denk eerder dat crisp doelde op het feit dat het nogal overkill is om een heel framework daarvoor in te laden als prototype / scriptaculous al gebruikt worden. Riekt een beetje naar copy/paste.

Overigens @crisp, er zit nog een scriptje onder dat ook van jQuery gebruik maakt (niet dat dat moeilijk in prototype te doen is).

[ Voor 15% gewijzigd door danslo op 14-05-2010 06:33 ]

[.Gertjan.]

BarôZZa schreef op vrijdag 14 mei 2010 @ 03:45:
Het punt is dat als je ook maar een beetje Javascript kan, dat je in 99% van de gevallen JQuery niet nodig hebt. Daarnaast vind ik het over het algemeen enorm ranzige en onleesbare code opleveren. Maar in de meeste gevallen (zoals het voorbeeld hierboven) lijkt het toch gebruikt te worden voor copypasta scriptjes. Vaak met een overdaad aan overbodige animatietjes.

Overigens wil ik niet beweren dat JQuery totaal geen nut heeft. Ik ben het alleen nog niet echt tegengekomen.

Daar ben ik het helemaal mee eens. Ik vind JQuery over het algemeen ook niet echt lekker lezen. Het gebruik van een $ teken is grappig, maar als je vervolgens werkelijk alles daarmee kunt opzoeken komt de boel niet ten goede. Zelf gebruik ik meestal een set standaard functies die ik door de jaren heen heb opgebouwd en dat bevalt me prima ($id, $class welke elementen terug geven). Voor een nieuw projectje wilde eens kijken wat JQuery kon betekenen, maar op de een of andere manier kwam ik er gewoon niet lekker uit. De lange aaneenschakeling van functies achter elkaar zorgde voor verwarring. Zo krijg je niet echt makkelijk een screen element terug in jQuery (hij heeft een echte wrapper ofzo er omheen) terwijl ik graag toch mijn element in een variabele wil hebben en daar mijn acties op wil doen.

Ook is het nadelig dat wanneer je iets zoekt op classname je bijvoorbeeld de . ervoor moet zetten. Dat is weer lastig als je bijvoorbeeld de classname aan de hand van een andere classname wilt bepalen, want je moet altijd die . erbij zetten.

Project wat ik momenteel doe heeft ook wat jQuery, maar dat is zoals jij al aangeeft vooral voor copypaste code of standaard componenten de rest is gewoon plain old handcrafted javascript.

[danslo]

.Gertjan. schreef op vrijdag 14 mei 2010 @ 08:08:
[...]
Het gebruik van een $ teken is grappig, maar als je vervolgens werkelijk alles daarmee kunt opzoeken komt de boel niet ten goede.

Waarom niet?

De lange aaneenschakeling van functies achter elkaar zorgde voor verwarring.

Method chaining is juist één van de voordelen van jQuery imo.

Zo krijg je niet echt makkelijk een screen element terug in jQuery (hij heeft een echte wrapper ofzo er omheen) terwijl ik graag toch mijn element in een variabele wil hebben en daar mijn acties op wil doen.

Wat wil je daar precies mee doen dan? jQuery maakt die 'acties' die je op het object dat je terug krijgt uit wilt voeren alleen maar eenvoudiger. Ik noem alleen nog maar .css(), .html(), .attr().

Ook is het nadelig dat wanneer je iets zoekt op classname je bijvoorbeeld de . ervoor moet zetten. Dat is weer lastig als je bijvoorbeeld de classname aan de hand van een andere classname wilt bepalen, want je moet altijd die . erbij zetten.

Volkomen consistent met CSS selectors. Hoe is dit een nadeel?

[crisp]

ThomasB schreef op vrijdag 14 mei 2010 @ 05:43:
[...]

Wat is daar mis mee?

Dat ze jQuery gebruiken voor slechts een heel klein stukje functionaliteit dat in net zoveel regels framework-onafhankelijk had kunnen worden geschreven, of gebruik makend van prototype.

Vergeet niet dat 'maar het is maar 17KB en meestal al gecached' niet de enige invloed is op de pageload, javascript moet ook nog geparsed worden. Daarbij blijkt in de praktijk dat cache-miss vaker voorkomt dan je denkt.

cls schreef op vrijdag 14 mei 2010 @ 06:31:
[...]
Overigens @crisp, er zit nog een scriptje onder dat ook van jQuery gebruik maakt (niet dat dat moeilijk in prototype te doen is).

Ah, je bedoelt deze:

JavaScript:

/* we need jQuery!!!! */

function checkAds()
{
    $j('.adsBlock').each(function() {
        var img = $j(this).find("img");
        if (img.length > 0)
        {
            if(img.attr('src').indexOf('817-grey.gif') > -1)
            {
                $j(this).hide();
            }
        }
    });
}
checkAds();

Maar ook dat is simpel zonder jQuery (en eventueel mbv prototype) te schrijven...

---

Overigens ben ik zelf geen jQuery fan; method chaining vind ik onduidelijk en lastig te debuggen, en daarbij heeft jQuery in mijn ogen teveel 'magic' functies die op basis van de input compleet andere dingen doen waardoor je code nog meer inboet aan duidelijkheid en consistentie. Verder heb ik het idee dat jQuery je snel verleidt tot het schrijven van inefficiente code; door de mate van abstractie heb je daar niet echt overzicht meer op.

Vaak krijg ik het idee dat 'brevity' een soort van algeheel doel is van jQuery zonder dat het op bepaalde punten nou echt functionaliteit toevoegt boven standaard DOM functies (maar misschien ben ik daarin biased omdat ik geen oudere browsers hoef te ondersteunen ).

[ Voor 24% gewijzigd door crisp op 14-05-2010 10:24 ]

[.Gertjan.]

cls schreef op vrijdag 14 mei 2010 @ 08:58:
[...]

Waarom niet?

Als je tig dingen kunt doen met een selector is het niet altijd direct duidelijk wat iemand doet als hij deze gebruikt en als je nergens een duidelijk overzicht hebt van wat mogelijk is komt het op mijn nogal complex over. Een intellisense zou ook leuk zijn, maar dat is helaas niet mogelijk. Je kunt veel en dan raak je nogal eens afgeleid van de hoofdzaak.

[...]

Method chaining is juist één van de voordelen van jQuery imo.

Is een voordeel (als je weet wat je doet), maar of het de leesbaarheid ten goede komt voor mensen die nog niet zo ervaren ermee zijn is de vraag. Ik had het nog nooit gebruikt en dan is een voorbeeld waar tig functies aan elkaar zijn gehangen best complex.

[...]

Wat wil je daar precies mee doen dan? jQuery maakt die 'acties' die je op het object dat je terug krijgt uit wilt voeren alleen maar eenvoudiger. Ik noem alleen nog maar .css(), .html(), .attr().

Misschien ben ik zelf te veel gehecht aan basis JS waardoor ik liever zelf appendchild en dergelijke wil toepassen. Ook wil ik in sommige scripten het object waarmee ik werk onthouden in plaats van iedere keer het item te moeten vragen aan jQuery. Ik plemp liever de div waarmee ik bijvoorbeeld werk in een var waarna ik ermee aan de slag ga in plaats van steeds met jQuery dat ding te moeten opvragen.

[...]

Volkomen consistent met CSS selectors. Hoe is dit een nadeel?

Omdat als je bijvoorbeeld een css-class toevoegt je de . niet gebruikt. CSS consistent is leuk maar in HTML gebruik je toch ook geen . en # bij je class en ID? Ook als je de attributen van een element opvraagt zit er geen # of . in.


Het is denk ik gewoon een kwestie van wat je gewend bent. Ik zeg niet dat het per definitie slecht is, maar het heeft door de vele mogelijkheden misschien een afschrikwekkend effect. Misschien dat een goede tutorial helpt, maar op de site van jQuery zelf werd ik ook niet veel wijzer qua voorbeelden (geloof dat een van de eerste voorbeelden al een complete AJAX call was).


edit:
Overigens vind ik de voordelen van het leren van jQuery niet echt opwegen tegen de winst die ik zou maken als ik het ken. Ik schrijf momenteel vrij rap mijn javascript en kan in vrij weinig regels code bereiken wat ik wil. Waarom zou ik dan vrij veel tijd investeren in het leren van een framework (wat op het eerste oog niet erg duidelijk is en voor de beginnen meer zal lijken op abracadabra).

[ Voor 8% gewijzigd door .Gertjan. op 14-05-2010 10:26 ]

[YopY]

Zaken als leesbaarheid en efficiëntie is afhankelijk van de ontwikkelaar, niet van het gebruikte framework.

Verder heb ik nog te weinig ervaring met Javascript en JQuery om nuttig commentaar te geven. Ik heb sowieso een hekel aan Javascript, JQuery of niet. Heb een dag gezwoegd op een dingetje die een totaalprijs moet berekenen als je een checkbox inklikt bijvoorbeeld.

[mux]

Tsja, zolang er nog with(), constructor en prototype bestaat zie ik weinig in jQuery.... Het verhoogt bovendien bepaald niet je begrip van js en zijn interactie met het DOM en je browser als je de hele tijd jQuery gebruikt. Voordeel is dat een stukje browsercompatabiliteit vóór jou wordt gedaan, maar eerlijk gezegd maak ik iets liever ietsjes minder mooi of pixel perfect dan dat ik ga zitten hacken.

[Haan]

.Gertjan. schreef op vrijdag 14 mei 2010 @ 10:20:
[...]

Als je tig dingen kunt doen met een selector is het niet altijd direct duidelijk wat iemand doet als hij deze gebruikt en als je nergens een duidelijk overzicht hebt van wat mogelijk is komt het op mijn nogal complex over. Een intellisense zou ook leuk zijn, maar dat is helaas niet mogelijk. Je kunt veel en dan raak je nogal eens afgeleid van de hoofdzaak.

Visual Studio biedt volledige IntelliSense ondersteuning voor jQuery

Ook wil ik in sommige scripten het object waarmee ik werk onthouden in plaats van iedere keer het item te moeten vragen aan jQuery. Ik plemp liever de div waarmee ik bijvoorbeeld werk in een var waarna ik ermee aan de slag ga in plaats van steeds met jQuery dat ding te moeten opvragen.

Wat houdt je tegen om een jQuery object in een variabele te stoppen

JavaScript:

var div = $("#myDiv");
div.css("background-color", "#123456");

En gaan zeuren dat je een framework moet gaan leren vind ik een erg slecht argument. Op die manier leer je dus nooit iets nieuws, en zal je jezelf niet verder ontwikkelen in je vakgebied. Voor mij geeft het feit dat Microsoft is gestopt met het ontwikkelen van hun AJAX library, en in plaats daarvan is gaan samenwerken met het jQuery team, al goed aan dat er heel veel potentie in jQuery zit. Maar zoals bij alles geldt natuurlijk dat je het met beleid moet toepassen. Als je alleen voor het hiden van een divje jQuery gaat gebruiken, ben je wellicht niet zo handig bezig.

[ Voor 50% gewijzigd door Haan op 14-05-2010 10:55 ]

[.Gertjan.]

Haan schreef op vrijdag 14 mei 2010 @ 10:44:
[...]

Visual Studio biedt volledige IntelliSense ondersteuning voor jQuery

Ow dat wist ik niet eens. Krijg je dan ook comments/documentatie erbij of alleen de mogelijk parameters?

[...]

Wat houdt je tegen om een jQuery object in een variabele te stoppen

JavaScript:

var div = $("#myDiv");
div.css("background-color", "#123456");

Je hebt dan niet echt een dom-element in je variabele, maar een wrapper van jQuery volgens mij. Het zeggen van .className werkt volgens mij niet op deze variabele. Je zult dan op die variabele dus ook jQuery moeten gebruiken, op zich logisch, maar in mijn ogen maakt dat het wel lastiger om toe te passen. Je moet of volledig op jQuery gaan of niet. Als je nou gewoon normale DOM elementen terug krijgt dan is het sneller toe te passen.

Het kan overigens ook zo zijn dat je wel DOM elementen terug krijgt, maar dat ik iets anders fout had gedaan.

Ik heb het iig geprobeerd een kans te geven, maar na een tijd prutsen en iets niet werkend krijgen weer uit mijn code gesloopt. Het kan zijn dat ik de dom ben, of te ongeduldig, maar ik zag er op dat moment weinig in.

En gaan zeuren dat je een framework moet gaan leren vind ik een erg slecht argument. Op die manier leer je dus nooit iets nieuws, en zal je jezelf niet verder ontwikkelen in je vakgebied. Voor mij geeft het feit dat Microsoft is gestopt met het ontwikkelen van hun AJAX library, en in plaats daarvan is gaan samenwerken met het jQuery team, al goed aan dat er heel veel potentie in jQuery zit. Maar zoals bij alles geldt natuurlijk dat je het met beleid moet toepassen. Als je alleen voor het hiden van een divje jQuery gaat gebruiken, ben je wellicht niet zo handig bezig.

Om nieuwe dingen te leren en me verder ontwikkelen heb ik echt geen jQuery voor nodig hoor . Om iets nieuws te leren moet je altijd kijken of je er profijt van hebt anders is het toch een kansloze investering. Ik zal jQuery niet per definitie uit de weg gaan, maar ik zie er nu nog niet zoveel in. Als ik ergens een tutorial/handleiding zie met daarin mooie voorbeelden die goed zijn uitgelegd komt er misschien een WAUW moment.

Overigens dat MS jQuery adopteert maakt jQuery niet per definitie goed . Er zal allicht iets in zitten (anders wordt het ook niet gebruikt), maar ieder heeft zo zijn eigen voorkeur. Voor AJAX requests vind ik het zelf gewoon overkill. Dat kan ik zelf ook in een paar regels (herbruikbare) code. Er zitten wel een aantal leuke "special effects" in, maar voor de toepassingen die ik maak heb ik die niet nodig. Dus voor mij zit er vrij weinig in jQuery om mij over te laten stappen. Het ophalen van items met een bepaalde class/id heb ik ook functies voor die het net zo makkelijk doen als jQuery.

[ Voor 39% gewijzigd door .Gertjan. op 14-05-2010 11:02 ]

[Michali]

ssj3gohan schreef op vrijdag 14 mei 2010 @ 10:31:
Het verhoogt bovendien bepaald niet je begrip van js en zijn interactie met het DOM en je browser als je de hele tijd jQuery gebruikt.

Dat is nou niet een nadeel van jQuery te noemen. Dat is het probleem dat de programmeur JS gewoon niet snapt.

.Gertjan. schreef op vrijdag 14 mei 2010 @ 10:55:
Je hebt dan niet echt een dom-element in je variabele, maar een wrapper van jQuery volgens mij. Het zeggen van .className werkt volgens mij niet op deze variabele. Je zult dan op die variabele dus ook jQuery moeten gebruiken, op zich logisch, maar in mijn ogen maakt dat het wel lastiger om toe te passen. Je moet of volledig op jQuery gaan of niet. Als je nou gewoon normale DOM elementen terug krijgt dan is het sneller toe te passen.

Via get() kun je altijd bij het gewrapte DOM-element. Voor de meeste taken zul je deze echter niet nodig hebben, aangezien jQuery hier al ondersteuning voor biedt. Maar de mogelijkheid bestaat wel degelijk. .className zul je bijvoorbeeld niet vaak hoeven te gebruiken, aangezien je beschikt over add/remove/hasClass().

[ Voor 54% gewijzigd door Michali op 14-05-2010 11:09 ]

[.Gertjan.]

Michali schreef op vrijdag 14 mei 2010 @ 11:06:
[...]

Dat is nou niet een nadeel van jQuery te noemen. Dat is het probleem dat de programmeur JS gewoon niet snapt.

Nee, de developer wordt afhankelijk van jQuery en zal op een gegeven moment niet meer weten wat er onder water gebeurt. Heeft voordelen, maar ook nadelen, als er ergens iets mis gaat zal de developer niet direct weten waar te zoeken (en de frameworkcode van jQuery is vrij complex waardoor je daar ook de weg kwijt raakt).

[...]

Via get() kun je altijd bij het gewrapte DOM-element. Voor de meeste taken zul je deze echter niet nodig hebben, aangezien jQuery hier al ondersteuning voor biedt. Maar de mogelijkheid bestaat wel degelijk. .className zul je bijvoorbeeld niet vaak hoeven te gebruiken, aangezien je beschikt over add/remove/hasClass().

Ah, dat wist ik dus niet Iemand dan misschien tips voor goede tutorials die te gebruiken zijn om jQuery te leren, je kunt er veel mee, maar ook weet te veel (na een dag werken kunnen mijn hersentjes dat niet altijd aan)

Een goede tutorial is zeer welkom (en misschien roep ik na het lezen van de tutorial ook wel dat jQuery top is en dat ik niet snap dat mensen het niet top vinden). Dus beste jQuery fans, overtuig me

[Haan]

.Gertjan. schreef op vrijdag 14 mei 2010 @ 10:55:
[...]
Ow dat wist ik niet eens. Krijg je dan ook comments/documentatie erbij of alleen de mogelijk parameters?

Je krijgt echt comments met beschrijving, zie bijv. dit screenshot:

[.Gertjan.]

Haan schreef op vrijdag 14 mei 2010 @ 11:15:
[...]

Je krijgt echt comments met beschrijving, zie bijv. dit screenshot:
[afbeelding]

Oeh, I like . Neem aan dat dat VS 2010 is? Kijk dat nodigt dan wel weer uit om wat meer met jQuery te gaan doen.