Programmeer ergenissen top 10 :)

[Verwijderd]

Op zondag 30 december 2001 17:36 schreef marcusk het volgende:
[Otis: Compiler weet precies waar ';' moet]
Het voorbeeld van curry684 lijkt mij toch perfect aan te geven dat dat niet het geval is.

Het 2e voorbeeld levert geen error op, dus zal de compiler geen ';' inserten. Die ';' zou alleen moeten worden toegevoegd waar een echte ERROR plaatsvind, dus bv:

code:

while(array[i++])
result +=i
result *=2;

Dit levert een error op, want 'result *=2;' is een unexpected statement in de tokenparser-handler voor assignmentexpressies. Whitespace skippend komt de ';' dan achter de i te staan.

Wilde curry voorbeeld 1, maar tikte voorbeeld 2, dan krijgt hij geen syntax error, de boel compileert gewoon. Hij krijgt echter een bug, want de code is SEMANTISCH niet correct.

Daar is echter de ';' niet voor. Die is voor het afscheiden van statements, iets wat de compiler, mits de syntax solide is, heel goed zelf kan.

[mbravenboer]

Je moet de ; denk ik ook niet zien als een vergissing van de taal-ontwerper, die dacht dat het een noodzakelijke constructie was. Ik denk dat de ; in een imperatieve taal een stuk duidelijk biedt. Bovendien geeft het de compiler mee gelegenheid om te analyseren wat jij bedoelt als hij een fout vindt. Zonder een duidelijke scheiding tussen statements zou dat een stukje lastiger zijn.

Als jij bijvoorbeeld een component wilt gebruiken die voor de toepassing van de compiler overal ; inserts, vind ik dat prima. Ik zou het echter liever geen feature maken van de compiler als geheel.

Dat functionele talen geen ; hebben is logisch: ze hebben over het algemeen geen side-effects en dus ook geen statements. Een statement zonder side-effect is immers zinloos.

Overigens kennen andere niet imperatieve talen soms ook ; . In Stratego is het de sequentiele compositie van strategien. Ik vind dat wel een aardige notie en zou dan ook liever de ; gebruiken als sequentiele compositie van statements. Het is in dat geval dus geen afsluiting van statements, maar een scheiding van statements.

[Verwijderd]

Even resumerend, want anders blijf ik tikken:
Een compiler is een verzamelnaam van een serie taken die uitgevoerd moeten worden. Het is voor veel talen een checker die achteraf bepaalt wat ingevoerd is correct is en waar dat dan wel/niet zo is, de correcte invoer omzet in een uitvoer, de uitvoer eventueel optimaliseert en tenslotte in de final output omzet.

Vanaf het punt dat de invoer correct is, is het een one-way street naar de final output. Omdat de invoer correct is, dwz syntactisch correct, DUS is er een uitvoer mogelijk, gaat dit altijd goed. De fases ervoor echter, zijn lastig: de initiele invoer kan niet correct zijn. Omdat men achteraf checkt (veelal) of dit het geval is of niet, is het pragmatischer om deze fases zo te laten verlopen dat het proces van compileren zoveel mogelijk te laten slagen. Omdat de fase 'correcte-invoer -> output' altijd slaagt, is alleen dat gedeelte ervoor van belang. Waarom zou je daar niet wensen dat DAT gedeelte van de compiler je zoveel mogelijk helpt? Dat heeft imho niets met pure input -> output compilatie te maken, omdat dat daarna pas komt.

Over de ';': je kunt als taalontwerper er voor kiezen statementdelimiters te gebruiken, immers je compiler wordt een stuk simpeler (elke keer dat je een statement delimiter vindt is het zaak de handler te verlaten). Echter, het is onnodig, omdat je dmv lookaheads kunt besluiten of er een nieuw statement begint of niet. Het geheel wordt wel wat complexer, maar je vermijdt onnodige errors gemaakt door de programmeur.

Over uit de hoogte doen: zie het niet zo. Denk niet dat je uniek bent of dat sukkels zoals ik de fase waarin jij/jullie nu in zitten niet hebben doorgemaakt. Mijn kijk op softwarebouw is een totaal andere dan de meerderheid hier. Echter ik draai ook al wat langer mee. Wat me dan opvalt is dat gemiddelde mening hier is echter al zo oud is en, en dit vind ik echt heel jammer, niet vernieuwend: er zitten nauwelijks echt vernieuwende visies tussen. Men predikt de aloude leuzen, en houdt conservatief vast aan alom bekende zaken, generaliserend gedacht. Zet die dingen eens aan de kant, ga eens een stap van de materie afstaan en kijk eens met andere ogen naar wat je aan het doen bent en waarom, en wat de kernpunten zijn van WAT je eigenlijk wilt doen en of je daar ook idd alle tijd mee bezig bent of dat je veelvuldig met andere zaken bezig bent omdat je niet genoeg geholpen wordt door je tools.

Ik schuif overigens het 'maar ik vind het juist leuk' even terzijde, iedereen die het leuk vindt om in de regen van Amsterdam naar Den Haag te lopen zal ontkennen dat auto's of treinen enig nut hebben.

[mbravenboer]

Otis: Vanaf het punt dat de invoer correct is, is het een one-way street naar de final output. Omdat de invoer correct is, dwz syntactisch correct, DUS is er een uitvoer mogelijk, gaat dit altijd goed.

Syntaxtische correctheid is slechts 1 van de eerste stappen in de compiler. Met syntactische correctheid doel ik nu op het juist zijn van de code met de grammatica van een taal. De semantische analyse (na de abstract parse tree fase) is de hoofdtaak van de compiler en daar kan nog een heleboel misgaan.

Omdat de fase 'correcte-invoer -> output' altijd slaagt, is alleen dat gedeelte ervoor van belang. Waarom zou je daar niet wensen dat DAT gedeelte van de compiler je zoveel mogelijk helpt? Dat heeft imho niets met pure input -> output compilatie te maken, omdat dat daarna pas komt.

Als je uitgaat van een correct stukje code is de rest van het compileer traject inderdaad niet zo erg interessant. Een belangrijke taak van de compiler is echter juist om de correctheid te controleren. De syntax is hierbij maar stap 1 van het verhaal. Het traject na de syntax (dus vanaf de abstract parse tree) is dus wel degelijk zeer relevant.

Mijn hele punt is nu juist dat je het corrigeren van incorrecte syntax en de semantische analyse + transformatie fase moet scheiden.Je krijgt dus twee gescheiden onderdelen: transformatie naar een correcte syntax en een compilatie fase van een correcte syntax naar een output. Tijdens deze tweede fase vind semantische analyse plaats, waar dus wel degelijk nog iets mis kan gaan. De eerste fase kan je een apart component van de compiler maken, maar wat mij betreft past het beter in een IDE.

De syntax van een taal is je macht: met behulp van deze syntax bepaal je wat er moet gebeuren. Daarom wil ik er ook zeker van zijn dat de compiler het eens is met deze syntax en niet zelf aan het fantaseren slaat.

Over de ';'

Je gaat totaal niet op mijn argumenten in (trouwens ook niet op mijn duidelijke unicode verhaal). Ik ben het volledig met je eens dat de ; niet nodig is. Het is echter niet de vraag of hij nodig is, maar of hij wenselijk is. Ik zeg: ja, want het schept duidelijkheid en een compiler kan beter begrijpen wat ik bedoelde en zo betere meldingen geven over incorrecte code.

Dat het parse-technische (veel) complexer is ben ik eigenlijk niet helemaal met je eens. Je hebt volgens mij niet meer look-ahead nodig omdat je in voortdurend op je huidige positie weet of hier een statement afgesloten zou moeten worden als je white-space tegenkomt.

Denk niet dat je uniek bent of dat sukkels zoals ik de fase waarin jij/jullie nu in zitten niet hebben doorgemaakt. Mijn kijk op softwarebouw is een totaal andere dan de meerderheid hier. Echter ik draai ook al wat langer mee.

Ik vind het zo grappig dat jij voortdurend kritiek hebt op anderen omdat ze 'atijd' gelijk denken te hebben. Verder doe je volgens jou ook niet uit de hoogte. Terwijl je dit meldt moet je echter nog even melden dat jij veel langer meeloopt, waarmee je impliceert dat onze mening verkeerd is en die van jouw goed.

Wat me dan opvalt is dat gemiddelde mening hier is echter al zo oud is en, en dit vind ik echt heel jammer, niet vernieuwend: er zitten nauwelijks echt vernieuwende visies tussen.

Mwah, dat vind ik wel meevallen. Misschien dat ik op sommige punten een conservatieve mening heb, maar dat is niet per definitie verkeerd. Dit zegt niet zoveel over 'vernieuwend' bezig zijn. Daarmee impliceer je namelijk dat die vernieuwingen ook beter zijn. Dat zijn ze in mijn ogen dus niet. Verder vinden anderen (nee, niet speciaal hier op GoT) wel dat ik vernieuwend bezig ben, maar nog belangrijker: ik vond zelf dat ik leuk bezig ben. Dat jij dat niet vindt, word ik echt niet heet of koud van . Zolang mijn artikelen maar gepubliceerd worden en ideeen verder uitgedacht worden door anderen vind ik het prima.

[Verwijderd]

Waar ik me toch eens verschrikkelijk aan erger, zijn die kl*te headers in PHP. Ik zou eens willen dat je ze overal kon neerzetten ongeacht de output .

[mbravenboer]

Markuz: Waar ik me toch eens verschrikkelijk aan erger, zijn die kl*te headers in PHP. Ik zou eens willen dat je ze overal kon neerzetten ongeacht de output .

Toch leuk tussendoor .

Lijkt dit je niet een beetje onhandig ivm de combinatie van de aard van het HTTP protocol en performance?

[Verwijderd]

Moeten ze daar dus ook maar eens een oplossing voor vinden .

[Verwijderd]

Op zondag 30 december 2001 17:52 schreef Otis het volgende:
Het 2e voorbeeld levert geen error op, dus zal de compiler geen ';' inserten.

Het zogenaamde dummy statement..

[Verwijderd]

Op zondag 30 december 2001 20:15 schreef GDOG het volgende:

[..]

Het zogenaamde dummy statement..

[Joror]

Op zondag 30 december 2001 20:03 schreef Markuz het volgende:
Moeten ze daar dus ook maar eens een oplossing voor vinden .

[offtopic-post reply]
Als je echt wil is er een eenvoudige oplossing, met gebruik van de php output buffers:

Zet
"ob_start();"
als eerste regel in je code, eenvoudig te doen in een include file

En als laatste in je code
"
echo ob_get_contents();
ob_end_clean();
"
Ook te doen in een include file.

Maar dit is een non-oplossing, omdat in het HTML protocol *juist* direct "on the spot" geflusht wordt, waardoor paginas voorbereid kunnen worden terwijl de HTMLcode binnenkomt, halve paginas kunnen worden getoond enz.
[/offtopic-post reply]

[Netman768]

Als ik in VB een icoon in de taakbalk zet en het programma draai vanuit de compiler zit ik me vaak dood te ergeren (voornamelijk aan mezelf). Als je dan namelijk op de stopknop drukt wordt het programma met een End beeindigd wat betekend dat het icoon niet uit de balk gehaald wordt en het proggie vastloopt, daarmee de compiler meeslepend.

weg aangepaste source......

[mbravenboer]

Pr3d4t0r: [VB zuigt] Geen lazy evaluation is ook wel

Dat VB geen lazy-evaluation kent is vrij logisch, want dat is absoluut niet mogelijk in een taal met side-effects. C++, C, Java, Pascal, Delphi, VB, C# en ga zo maar door zijn allemaal talen met side-effects. Op zich vind ik die (in ieder geval om deze reden) dus nog wel meevallen .

Stricte functionele talen, waar geen side-effects zijn, bieden wel lazy-evaluation. Hier kom je echter een stuk exotischer uit: Haskell, Miranda, Clean etc.

[Verwijderd]

Op zondag 30 december 2001 19:52 schreef mbravenboer het volgende:
[Otis: Vanaf het punt dat de invoer correct is, is het een one-way street naar de final output. Omdat de invoer correct is, dwz syntactisch correct, DUS is er een uitvoer mogelijk, gaat dit altijd goed.]
Syntaxtische correctheid is slechts 1 van de eerste stappen in de compiler. Met syntactische correctheid doel ik nu op het juist zijn van de code met de grammatica van een taal. De semantische analyse (na de abstract parse tree fase) is de hoofdtaak van de compiler en daar kan nog een heleboel misgaan.

Humor. de semantische analyze is iets wat komt kijken bij optimalisatie, immers, daar kun je door diepere interpretatie van wat er gebeurt, kijken of er wat te optimaliseren valt. Echter 3GL talen bevatten in de compile-stap geen semantische analyzes, er is immers een 1:1 afbeelding te realiseren tussen syntactisch correcte programmatext en een output. Let wel: een 3GL concludeert pas of iets SYNTACTISCH correct is in de tokenparser (dus of bv een for header is afgesloten met een haakje)! Dezelfde plek waar initiele emitting plaatsvindt.

Ik begrijp derhalve niet waar je op doelt met je 'er kan nog van alles mis gaan'. Wellicht interpreteer ik je teksten foutief. (no pun intended)

[Otis: Omdat de fase 'correcte-invoer -> output' altijd slaagt, is alleen dat gedeelte ervoor van belang. Waarom zou je daar niet wensen dat DAT gedeelte van de compiler je zoveel mogelijk helpt? Dat heeft imho niets met pure input -> output compilatie te maken, omdat dat daarna pas komt.]
Als je uitgaat van een correct stukje code is de rest van het compileer traject inderdaad niet zo erg interessant. Een belangrijke taak van de compiler is echter juist om de correctheid te controleren. De syntax is hierbij maar stap 1 van het verhaal. Het traject na de syntax (dus vanaf de abstract parse tree) is dus wel degelijk zeer relevant.

Dat klopt, maar wanneer weet je of de syntax van de geboden tekst correct is? Als je die compleet hebt doorlopen en hebt getest, bv of een 'end' is vermeldt na een 'begin' en men niet een end of file of bv een nieuwe functie header tegenkomt. Als je geen emitting laat plaatsvinden tijdens je tokenparser, maar daarin hooguit de syntaxis fixt waar nodig en waar MOGELIJK, krijg je daarna een syntactisch correcte input die door de tokenparser _ALTIJD_ tot code kan worden omgezet. Je moet wel eenduidig code KUNNEN fixen natuurlijk.

Mijn hele punt is nu juist dat je het corrigeren van incorrecte syntax en de semantische analyse + transformatie fase moet scheiden.Je krijgt dus twee gescheiden onderdelen: transformatie naar een correcte syntax en een compilatie fase van een correcte syntax naar een output. Tijdens deze tweede fase vind semantische analyse plaats, waar dus wel degelijk nog iets mis kan gaan. De eerste fase kan je een apart component van de compiler maken, maar wat mij betreft past het beter in een IDE.

Dit is niet juist. Een correcte syntaxis zal altijd zonder fouten compileren naar EEN output. Immers, hoe kun je anders ooit een goed kloppende syntax compileren? Wat jij, naar ik aanneem, bedoelt is de analyze van volgorde van tokens in bv een if handler, of een for() handler. Maar dat is nog steeds syntax checking! Pas als dat naar behoren gedaan is, kun je overgaan tot het compileren van de opgebouwde datastructuren naar een output, de transformatie van wat is aangeboden in tokens naar statements in de doeltaal. Eventueel door meerdere passes gevolgd.

De syntax van een taal is je macht: met behulp van deze syntax bepaal je wat er moet gebeuren. Daarom wil ik er ook zeker van zijn dat de compiler het eens is met deze syntax en niet zelf aan het fantaseren slaat.

Dat kun je sowieso niet. Weet jij hoe een compiler jouw 3GL programmatext compileert naar machinecode? En of dat allemaal precies klopt met wat je verwachtte? Dat kun je niet. Je neemt het maar aan, wat terecht is, anders schreef je het zelf wel in assembler. Ik ben het met je eens dat een compiler alleen DIE code moet fixen die eenduidig gefixt KAN worden. Gelukkig is dat veelal het geval. Op goed geluk statements toevoegen zonder enige vorm van feedback lijkt me ook niet te prefereren, maar jij weet net zo goed als ik dat ik daar niet op doelde.

[Otis: Over de ';']
Je gaat totaal niet op mijn argumenten in (trouwens ook niet op mijn duidelijke unicode verhaal). Ik ben het volledig met je eens dat de ; niet nodig is. Het is echter niet de vraag of hij nodig is, maar of hij wenselijk is. Ik zeg: ja, want het schept duidelijkheid en een compiler kan beter begrijpen wat ik bedoelde en zo betere meldingen geven over incorrecte code.

Over je argumenten mbt het unicode verhaal: dat Kanji characters het case-sensitive/insensitive aspect niet kennen zou al genoeg moeten zijn voor het afschaffen van case-sensitiviteit. Immers: een 6 jarige die kan lezen zal "KoekJe" en "Koekje" beide als "koekje" zien, wat correct is, want beide keren staat dat er. Exact wat iemand met Kanji characters bereikt en wil bereiken. Overigens snap ik het gebruik van Kanji characters in variabelen niet, wanneer de rest van de taalstatements incl API volledig van het Engels zijn afgeleid. Dit geeft IMHO aan dat case sensitiviteit (wat inhoudt: semantisch hetzelfde, syntactisch verschillend) WEL wenselijk is in beschavingen met een latijns alfabet, maar niet in een beschaving met een anderssoortig alfabet. Raar. Geeft je dit niet te denken dat het wellicht gevolg-bestrijding is?

Over of het wenselijk is: daar kun je over discussieren, ikzelf vind het lastig, echter als ik zou moeten kiezen tussen EOL delimiters zoals in VB en ';' dan kies ik voor de ';'. Echter, als ik kijk naar T-SQL waar ik geen van beide heb, dan vind ik dat wel een verademing en mis ze totaal niet. Maar gewenning kan je ingeven dat je ze wel wilt. Echter, imho is het ballast wat 1) errors oplevert en 2) niet echt iets toevoegt aan de leesbaarheid van de code

Dat het parse-technische (veel) complexer is ben ik eigenlijk niet helemaal met je eens. Je hebt volgens mij niet meer look-ahead nodig omdat je in voortdurend op je huidige positie weet of hier een statement afgesloten zou moeten worden als je white-space tegenkomt.

Lijkt me niet: ik kan een tab, EOL of spaties toevoegen zonder dat dat duidt op een statement wat afgesloten is. Wat ik bedoelde met complexer is dat een handler van een statement t.a.t. kan stoppen wanneer hij een ';' token ziet. Een syntax die dat niet gebruikt zal moeten testen welk token wel en niet kan, waardoor de handlers complexer worden. Verder gebruiken veel C compilers geen lookahead, omdat de ';' dat overbodig maakt: zodra je die ziet ben je klaar, en je hoeft die ';' niet te bewaren. Dus je kunt met het huidige token al bepalen wat je moet doen, zonder vooruit te kijken. (vandaar geen lookahead, en waarom ik het aanhaalde, dat je dat bij het ontbreken van een statement delimiter wel nodig hebt).

[Otis: Denk niet dat je uniek bent of dat sukkels zoals ik de fase waarin jij/jullie nu in zitten niet hebben doorgemaakt. Mijn kijk op softwarebouw is een totaal andere dan de meerderheid hier. Echter ik draai ook al wat langer mee.]
Ik vind het zo grappig dat jij voortdurend kritiek hebt op anderen omdat ze 'atijd' gelijk denken te hebben. Verder doe je volgens jou ook niet uit de hoogte. Terwijl je dit meldt moet je echter nog even melden dat jij veel langer meeloopt, waarmee je impliceert dat onze mening verkeerd is en die van jouw goed.

1) Wellicht niet tot je doorgedrongen, maar ik vermeldde dat 'ik veel langer meedraai' erbij als reden waarom mijn mening anders is.
2) Omdat ik langer meedraai zegt niets over de validatie van mijn mening, alleen dat hij anders is OMDAT ik langer meedraai.
3) Ik impliceer helemaal niks omtrent de kwaliteit van jouw mening tov de mijne. Jouw mening blijft prima binnen platgetreden paden, dus hoe kan ik twijfelen aan jouw mening?

[Wat me dan opvalt is dat gemiddelde mening hier is echter al zo oud is en, en dit vind ik echt heel jammer, niet vernieuwend: er zitten nauwelijks echt vernieuwende visies tussen.]
Mwah, dat vind ik wel meevallen. Misschien dat ik op sommige punten een conservatieve mening heb, maar dat is niet per definitie verkeerd. Dit zegt niet zoveel over 'vernieuwend' bezig zijn. Daarmee impliceer je namelijk dat die vernieuwingen ook beter zijn. Dat zijn ze in mijn ogen dus niet.

Vernieuwing bereik je sowieso niet door op betreden paden te blijven. Vernieuwing bereik je WEL door anders tegen de materie aan te kijken. Dat resulteert iig in verandering, of dat beter is zal moeten uitwijzen. Een groot scala aan veranderingen zal net als de geschiedenis uit heeft gewezen, een verbetering opleveren.

Dat ze in jouw ogen niet 'beter' zijn, ligt voor de hand: jouw mening houdt in dat je op bestaande paden vernieuwing zoekt, of althans ruimte tot verandering. Die zal er ongetwijfeld zijn, maar op lange duur zal het je niet brengen wat je zoekt. Ik vind dat jammer, maar wel naar verwachting: [generaliserend]de gemiddelde inf. student denkt meer in details dan in grote lijnen, waardoor de focus niet op waar werkelijk de vernieuwing gehaald kan worden wordt gericht, maar op de enigzinds bekende gebieden[/generaliserend]. Enkelen, en laat ik mezelf daar even buitenplaatsen ter bevordering van de discussie, denken anders dan anderen en komen met op het oog bizarre veranderingen op bestaande thema's veel verder. Wat tot gevolg heeft dat na een lange tijd de mensen die eerst kritisch waren hen volgen met "hij had gelijk!". Ik vind het jammer dat er zo weinig meningen zijn hier die ECHT veranderend zouden kunnen zijn.

Verder vinden anderen (nee, niet speciaal hier op GoT) wel dat ik vernieuwend bezig ben, maar nog belangrijker: ik vond zelf dat ik leuk bezig ben. Dat jij dat niet vindt, word ik echt niet heet of koud van . Zolang mijn artikelen maar gepubliceerd worden en ideeen verder uitgedacht worden door anderen vind ik het prima.

Ik heb al vermeld dat wat je LEUK vindt om te doen (bv het programmeren van een OS puur omdat je dat interesseert en leuk vindt) niet relevant is voor argumentatie waarom iets beter zou KUNNEN en eigenlijk zou MOETEN. Die laatste zin van je is overigens wel iets van pot-ketel, denk je ook niet? Of had jij het niet over wie er uit de hoogte deed .

Welke artikelen bedoel je overigens? Wetenschappelijke publicaties of artikelen op sites?

[Verwijderd]

Op zondag 30 december 2001 20:26 schreef mbravenboer het volgende:

[..]

Dat VB geen lazy-evaluation kent is vrij logisch, want dat is absoluut niet mogelijk in een taal met side-effects. C++, C, Java, Pascal, Delphi, VB, C# en ga zo maar door zijn allemaal talen met side-effects. Op zich vind ik die (in ieder geval om deze reden) dus nog wel meevallen .

Overigens zou je:
Dim oFoo as object
Dim i as integer

set oFoo = CreateObject("mypackage.myclass")
i=oFoo.mymethod()

als lazy evaluation kunnen beschouwen, VB evalueert oFoo pas at runtime, wat je als een vorm van lazy evaluation kunt beschouwen

[mbravenboer]

Otis: Ik begrijp derhalve niet waar je op doelt met je 'er kan nog van alles mis gaan'. Wellicht interpreteer ik je teksten foutief. (no pun intended)

Tja, het ligt er maar aan wat je onder semantische-analyse verstaat . Ik heb nog even nagekeken in mijn boek en die vermeldt dit:

The semantic analysis fase of a compiler connects variable definitions to their uses, checks that each expression has a correct type and translates the abstract syntax into a simpler representation suitable for generating machine code.

Volgens deze analyse valt type-checking dus ook onder semantische analyse en uiteraard kan daar van alles misgaan. Syntaxtische correctheid wordt (in de stukken die ik heb gelezen) alleen correctheid tov een grammatica bedoeld. De semantiek vakt hier dus meestal niet onder. Je kunt bij semanische analyse ook denken aan het opzoeken van lexical-scopes etc.

Semantische analyse kan je natuurlijk ook als optimalisering zijn, maar meestal wordt dat apart aangeduid met control-flow analyse, dataflow-analyse, loop-optimalisatie, pipeling en scheduling etc.

Maar goed, het hangt dus vooral af van je definitie. Spraakverwarring is nu vast opgeheven .

Dat klopt, maar wanneer weet je of de syntax van de geboden tekst correct is? Als je die compleet hebt doorlopen en hebt getest, bv of een 'end' is vermeldt na een 'begin' en men niet een end of file of bv een nieuwe functie header tegenkomt. Als je geen emitting laat plaatsvinden tijdens je tokenparser, maar daarin hooguit de syntaxis fixt waar nodig en waar MOGELIJK, krijg je daarna een syntactisch correcte input die door de tokenparser _ALTIJD_ tot code kan worden omgezet.

Nou ja, dat hangt er dus vanaf wat je onder syntaxtische correctheid verstaat. Mij is geleerd dat dat correctheid ten opzichte van een grammatica is. Dat wil echter niet zeggen dat het programma ook uitgevoerd kan worden: er kunnen type-fouten in zitten. Dat hoort volgens mij bij semantische analyse en zeker niet in een parser. De parser levert een parse-tree. Deze zet je over het algemeen eerst om naar een abstracte-syntax-tree en deze ga je type-checken en verder analyseren.

Dit is niet juist. Een correcte syntaxis zal altijd zonder fouten compileren naar EEN output.

Hangt er dus vanaf wat je onder 'een correcte syntaxis' verstaat .[quote]
fantaseren Dat kun je sowieso niet. Weet jij hoe een compiler jouw 3GL programmatext compileert naar machinecode? [/b]
Ja, sterker nog: ik ben er op dit moment zelf een aan het schrijven .

maar jij weet net zo goed als ik dat ik daar niet op doelde.

Uiteraard . Dat begrijp ik heel goed. Het is ook zeker niet mijn bedoeling om over je goede idee heen te praten. Wat wel mijn bedoeling is: het component wat de syntax corrigeert een duidelijk los component te maken en nog steeds een strakke definitie van je taal te maken die dan als tussen-stap wordt gebruikt.

Overigens snap ik het gebruik van Kanji characters in variabelen niet, wanneer de rest van de taalstatements incl API volledig van het Engels zijn afgeleid. Dit geeft IMHO aan dat case sensitiviteit (wat inhoudt: semantisch hetzelfde, syntactisch verschillend) WEL wenselijk is in beschavingen met een latijns alfabet, maar niet in een beschaving met een anderssoortig alfabet. Raar. Geeft je dit niet te denken dat het wellicht gevolg-bestrijding is?

Ik begrijp niet helemaal waar je op doelt. Ik probeerde duidelijk te maken dat onze min of meer equivalent notie van kleine en hoofdletters slechts 1 specifiek geval is. Uiteraard ben ik het volledig met je eens dat het op dit moment merkwaardig is om niet in het Engels, of in ieder geval in het latijnse alfabet te programmeren, maar voor een verre toekomst is het nog geeneens zo'n gek idee. Misschien moeten API functies zelfs in meerdere talen worden aangeboden terwijl ze hetzelfde zijn .

Maar goed, ik snap je punt en mijn unicode tegenvoorbeeld is op dit moment niet zo sterk, maar ik blijf toch bij mijn mening dat het onduidelijk werkt in een formele definitie van een taal. Dat een IDE of een component voor de compiler je helpt om vergissingen recht te breien (want het blijven toch vaak vergissingen) vind ik prachtig.

Lijkt me niet: ik kan een tab, EOL of spaties toevoegen zonder dat dat duidt op een statement wat afgesloten is.

Hum, dat vraag ik me af. White-space kan altijd geelimineerd worden tot 1 character als het dient als scheiding tussen statements. Je kunt white-space dus gewoon opeten tot het volgende token. Bij dit token zal je moeten beslissen of dit token een nieuwe statement aangeeft of niet. Dat zorgt verder niet voor grote problemen.

Wat ik bedoelde met complexer is dat een handler van een statement t.a.t. kan stoppen wanneer hij een ';' token ziet. Een syntax die dat niet gebruikt zal moeten testen welk token wel en niet kan, waardoor de handlers complexer worden.

Daar zit wel wat in, complexer is het wel.

[over langer meerdraaien]

Dat heb ik dan inderdaad verkeerd opgevat. Ik las wellicht teveel tussen de regels door .

Ik impliceer helemaal niks omtrent de kwaliteit van jouw mening tov de mijne. Jouw mening blijft prima binnen platgetreden paden, dus hoe kan ik twijfelen aan jouw mening?

.

Ik vind het jammer dat er zo weinig meningen zijn hier die ECHT veranderend zouden kunnen zijn.

Ach, ik hoop dat ik je nog eens kan verbazen .

Die laatste zin van je is overigens wel iets van pot-ketel, denk je ook niet? Of had jij het niet over wie er uit de hoogte deed .

hehe . Hij was een beetje bijdehand, dat geef ik toe .

Welke artikelen bedoel je overigens? Wetenschappelijke publicaties of artikelen op sites?

In eerste instantie wetenschappelijk. 1 artikel is al gesubmit maar moet nog aangepast worden, 2 andere zijn in voorbereiding. Ze gaan alle drie over nieuwe ideeen op programma-transformatie gebeid. Eentje behandelt een implementatie voor dynamische instructie-selectie met herschrijf-regels, waardoor je altijd de beste tile verdeling krijgt (itt tot het greedy Maximal Munch algoritme, wat je vast wel kent). Ik ga in de toekomst echter ook wat stukken schrijven voor de Nederlandstalige Java site, maar die worden vrij informeel en toepassings-gericht. 1 XML gerelateerd idee is aardig interessant en dat wil ik daarom ook op internationale sites insturen .

[mbravenboer]

Otis:
set oFoo = CreateObject("mypackage.myclass")
i=oFoo.mymethod()

Ik ken de semantiek van dit stukje niet, maar ik neem aan dat de instantie van oFoo altijd wordt aangemaakt voordat naar de statement i=mymethod() wordt gegaan?

als lazy evaluation kunnen beschouwen, VB evalueert oFoo pas at runtime, wat je als een vorm van lazy evaluation kunt beschouwen

Hum.... mwah... . Het hangt uiteraard van je definitie van lazy-evaluation af, maar dit vind ik toch wel een zeer matige vorm . Normaal gesproken wordt onder lazy-evaluation natuurlijk het uitstellen van een berekening verstaan totdat het resultaat van deze berekening ook daadwerkelijk nodig is. In dit geval is daar natuurlijk geen sprake van: er wordt gewoon altijd een instantie van die klasse aangemaakt. De methode zal ook altijd aangeroepen worden. Dan is gelijk duidelijk waarom dit in een taal met side-effects niet mogelijk is.

[Verwijderd]

Big time ergernis
Microsoft heeft bij het maken van VB componenten gewoon niet nagedacht dat property's wel leuk standaard zouden kunnen zijn. Zo kan je bij de tekstbox etc allemaal wel de tekstkleur aanpassen, maar probeer dat maar eens met de date/time picker ( MS Component ), kan dus gewoon niet, en dat is voor mijn huidige app erg k_t, kan ik weer een usercontrol gaan maken.

[Verwijderd]

Op zondag 30 december 2001 21:39 schreef mbravenboer het volgende:
[runtime evaluation van created object]

Ik ken de semantiek van dit stukje niet, maar ik neem aan dat de instantie van oFoo altijd wordt aangemaakt voordat naar de statement i=mymethod() wordt gegaan?

Ja dat klopt, maar je weet at compile time verder niets over het object, er is dus ook geen code gegenereert die altijd klopt bij de assignment. Als de method niet bestaat of geeft geen integer terug, dan krijg je een runtime error. Vziw valt dit imho wel onder lazy evaluation omdat de compiler de expressies niet evalueert, maar dat dit at runtime gebeurt. Talen met lazy evaluation hebben dit altijd, daar evalueert een compiler nooit een expressie. Procedurele talen leven zich overigens niet echt voor lazy evaluation, naast het feit of het nut van lazy evaluation nu zo wereldschokkend is.

[..]
Hum.... mwah... . Het hangt uiteraard van je definitie van lazy-evaluation af, maar dit vind ik toch wel een zeer matige vorm . Normaal gesproken wordt onder lazy-evaluation natuurlijk het uitstellen van een berekening verstaan totdat het resultaat van deze berekening ook daadwerkelijk nodig is. In dit geval is daar natuurlijk geen sprake van: er wordt gewoon altijd een instantie van die klasse aangemaakt. De methode zal ook altijd aangeroepen worden. Dan is gelijk duidelijk waarom dit in een taal met side-effects niet mogelijk is.

Dat klopt, het is niet een schoolvoorbeeld , maar het leek me wel eentje waarbij je aangeeft dat de compiler met dit stukje code wel degelijk lazy evaluation achtige technieken toepast: de code die wordt gegenereert bevat extra code maar niet de code die je zou verwachten, wanneer je oFoo niet als Object definieert, maar als mypackage.myclass type. Maar verder kon ik niet echt op een goed voorbeeld komen. VB6 heeft nog wel een val() statement (dus niet een libcall) die getallen uit strings leest, maar geen eval() statement zoals vbscript, waar je commando's at runtime mee kunt executeren, die in stringvorm als argument worden meegegeven.

[Verwijderd]

Op zondag 30 december 2001 21:12 schreef Otis het volgende:
Overigens zou je:

Dim oFoo as object
Dim i as integer
set oFoo = CreateObject("mypackage.myclass")
i=oFoo.mymethod()

als lazy evaluation kunnen beschouwen, VB evalueert oFoo pas at runtime, wat je als een vorm van lazy evaluation kunt beschouwen

Dit is geen lazy evaluation maar gewoon runtime binden van objecten.
Lazy evaluation noem ik:

code:

manyNumbers :: [Int]
manyNumbers = [1..938383]

doubleNumbers :: [Int] -> [Int]
doubleNumbers = map (2 *)

main :: [Int]
main = take 3 (doubleNumbers infiniteNumbers)

De functie main levert [2,4,6] op.

take is een functie die een int en een lijst neemt en de eerste drie elementen oplevert.
map is een functie die een lijst neemt en een functie en dat op elk element los laat. In dit geval maal twee.

In Haskell word echt niet elk element van de oneindige lijst integers vermedigvuldigd met twee. Dit gedrag valt wel te emuleren in een imperatieve taal, maar het word een redelijke brei code.

Lazy evalutaion is dat waardes of functies die waardes opleveren pas berekend worden als ze nodig zijn, niet het instantieren van objecten als ze nodig zijn.

De volgende code zou ik nog wel een verkapte vorm van lazy evaluation willen noemen, maar die moet je dan wel met de hand uitprogrammeren.

code:

public class EMail
{
  private string rawString;
  private string sender;

  public EMail(string rawString)
  {
    this.rawString = rawString;
  }
  public string Sender
  {
    get
    {
    if(sender == null)
      sender = ParseSenderFromRawString();
    return sender;
    }
  }
}

Nog meteen een ergenis(je) van C#.
Het niet kunnen onderscheiden van access protector voor de get en set van een property. In een sommige gevallen zou ik best de get public willen hebben terwijl de set protected is. Nu moet je dat met lossen functies oplossen of twee properties. Terwijl het volgens mij in MSIL best zou kunnen, daar is een property gewoon een verwijzing naar twee losse functies:

code:

.property instance string Text()
{
  .set instance void System.Windows.Forms.Control::set_Text(string)
  .get instance string System.Windows.Forms.Control::get_Text()
} // end of property Control::Text

[Verwijderd]

• veranderende APIs (moet je bijvoorbeeld weer overal #ifdef's toevoegen om het op beide versies te laten werken of een overlappende functie toevoegen)

• domme gebruikers (met het prototype voorbeeld "het werkt niet, help")

• domme mede-developers (bijvoorbeeld eentje die over de hele code 100000000 #ifdef's toevoegt omdat een functie in de API is verandert en niet op het slimme idee komt er 1 overlappende funtie overheen te gooien in plaats van al die #ifdefs) - ben je dubbel zo lang bezig om dat weer recht te trekken

• het feit dat je compiler volledig gek gaat doen als je een ; of " vergeten bent. Moet ie uiteraard van mijn code afblijven maar vertel dan tenminste dat er een ; of " mist in plaats van gek te gaan doen

[curry684]

Op maandag 31 december 2001 13:59 schreef beelzebubu het volgende:
• het feit dat je compiler volledig gek gaat doen als je een ; of " vergeten bent. Moet ie uiteraard van mijn code afblijven maar vertel dan tenminste dat er een ; of " mist in plaats van gek te gaan doen

Ik snap echt geen hol van dit hele geemmer... de originele kwestie gaat over stupiditeiten van programmeertalen, dit gaat over stupiditeiten van programmeurs.

In C++ is er toevallig voor gekozen dat je een instructie moet afsluiten met een puntkomma. Dit is niet bij ALLE instructies nodig, maar bij conditionals en loop-statements WEL (zie mijn eerdere voorbeeld). In plaats van een onduidelijke wirwar ervan te maken heeft men vervolgens ervoor gekozen om de puntkomma overal vereist te maken, wat toevallig voor heel leesbare code zorgt. In VB moet je 1 statement per regel gebruiken, en kun je dus niet aan de volgende methodiek:

code:

switch(l_Value)
  {
  case 0:   printf("Nul");       break;
  case 1:   printf("Een");       break;
  case 2:   printf("Twee");     break;
  case 3:   printf("Drie");     break;
  default:  printf("Illegal value"); break;
  }

Ik gebruik zelf altijd maar 1 statement per regel, maar de mogelijkheid is er wel indien handig/nodig/overzichtelijk.

Sowieso, als ik het volgende stukje code in VC++ inklop:

code:

t_UInt4  l_Piet
t_UInt4  l_Baas;

meldt het ding vriendelijk:

error C2146: syntax error : missing ';' before identifier 't_UInt4'

What's the problem?!?

Onduidelijke errors komen alleen als er een ambigue situatie ontstaat. Sowieso zal het ding hier proberen verder te compileren en nog een stapel errors gooien op 'undefined identifier l_Piet', maar dat is logisch: daarom begin je ook altijd bovenaan de lijst met compiler errors te fixen.

En nogmaals: die compiler heeft maar met z'n klauwen van mijn code af te blijven. Als ik een autocorrect optie wil hebben installeer ik die zelf wel.

[mbravenboer]

solar: Dit is geen lazy evaluation maar gewoon runtime binden van objecten.
Lazy evaluation noem ik:

Prachtig voorbeeld .

In Haskell word echt niet elk element van de oneindige lijst integers vermedigvuldigd met twee. Dit gedrag valt wel te emuleren in een imperatieve taal, maar het word een redelijke brei code.

Precies, kijk maar eens hier :
[topic=197726/1/25]

Lazy evalutaion is dat waardes of functies die waardes opleveren pas berekend worden als ze nodig zijn, niet het instantieren van objecten als ze nodig zijn.

Exact.

Nog meteen een ergenis(je) van C#. Het niet kunnen onderscheiden van access protector voor de get en set van een property. In een sommige gevallen zou ik best de get public willen hebben terwijl de set protected is.

Hum, das best een goed punt.... daar was ik nog geeneens tegenaan gelopen .

Nu moet je dat met lossen functies oplossen of twee properties. Terwijl het volgens mij in MSIL best zou kunnen, daar is een property gewoon een verwijzing naar twee losse functies.

Precies, het is complete suiker. Kijk maar eens wat voor SOAP message er wordt verstuurd in .NET Remoting als je een property remote gebruikt .

[johnwoo]

Op maandag 31 december 2001 14:53 schreef curry684 het volgende:

[..]

In VB moet je 1 statement per regel gebruiken, en kun je dus niet aan de volgende methodiek:

code:

switch(l_Value)
  {
  case 0:   printf("Nul");       break;
  case 1:   printf("Een");       break;
  case 2:   printf("Twee");     break;
  case 3:   printf("Drie");     break;
  default:  printf("Illegal value"); break;
  }

In VB mag je ook gewoon meerdere statements per regel gebruiken hoor:

code:

For Index = 0 To 10: Debug.Print Str$(Index): Next Index

(ok niet echt netjes om een loopje op 1 regel te zetten maar het gaat om het idee )

[Orphix]

[beetje offtopic]
Waarom is de ';' in C++ na een class { } nodig?!
Ik heb dit altijd als overbodig gezien
[/beetje offtopic]

[whoami]

Op maandag 31 december 2001 15:29 schreef Orphix het volgende:
[beetje offtopic]
Waarom is de ';' in C++ na een class { } nodig?!
Ik heb dit altijd als overbodig gezien
[/beetje offtopic]

...is in C# weggelaten.

[Verwijderd]

Op maandag 31 december 2001 15:49 schreef whoami het volgende:
[..]
...is in C# weggelaten.

Gelukkig wel ja. Grappige is dat in java syntax wel een ; na een inner class mag, alleen in de base library hebben ze dit soms wel, maar niet overal gedaan, tijdens compileren van de base libs van java 1.3.1 met J# kwam ik bergen warnings tegen dat deze vergeten waren

[.oisyn]

Op maandag 31 december 2001 15:29 schreef Orphix het volgende:
[beetje offtopic]
Waarom is de ';' in C++ na een class { } nodig?!
Ik heb dit altijd als overbodig gezien
[/beetje offtopic]

Omdat je nog variabelen kunt declareren na de class

code:

class Blaat
{
} blaat1, blaat2;

[raptorix]

Op zaterdag 29 december 2001 15:22 schreef MarcKonings het volgende:

[..]

Talen die NIET casesensitive zijn, nodigen uit tot slordige code. Zeker talen waarbij variabelen niet gedeclareerd hoeven te worden, zijn een bron van ellende en het opsporen van bugs kan heel vervelend zijn.

Wat een onzin, je kan niet eens in Camelstyle werken in sommige talen omdat anders de functies niet meer kloppen, geef me overigens 1 GOEDE reden aan wat het voordeel van case sensitivity zou zijn.

[Verwijderd]

Op maandag 31 december 2001 17:20 schreef raptorix het volgende:

[..]

Wat een onzin, je kan niet eens in Camelstyle werken in sommige talen omdat anders de functies niet meer kloppen, geef me overigens 1 GOEDE reden aan wat het voordeel van case sensitivity zou zijn.

Case-sensitivity dwingt je consequent te blijven.
Ik ken genoeg mensen die zonder case-sensitivity een var de ene keer 'ditIsEenVar' noemen, en de volgende keer 'ditiseenvar' en weer een andere keer 'DITISEENVAR'.
Wordt er dus niet overzichterlijker op...

[Gumbo!]

Grootste programmeer ergenis vindt ik dat ik niet kan programmeren

Lees er erg veel over alleen blijft niet in mijn kop vast zitten
Goed voornemen voor 2002... beter geheugen aanschaffen!!

[curry684]

Op maandag 31 december 2001 15:29 schreef Orphix het volgende:
[beetje offtopic]
Waarom is de ';' in C++ na een class { } nodig?!
Ik heb dit altijd als overbodig gezien
[/beetje offtopic]

OiSyN bedoelde het goed maar zei het fout

Je kunt de class behalve alleen declareren ook meteen instantieren. Vooral handig bij static private subclasses:

code:

class SomeComponent
{
public:
  // Troep

private:
  // Manager subclass for all instances
  static class MyManager
    {
    public:
                 MyManager();
    virtual    ~MyManager();

    // Meer troep
    } m_Manager;
};

[.oisyn]

Op maandag 31 december 2001 17:20 schreef raptorix het volgende:

[..]

Wat een onzin, je kan niet eens in Camelstyle werken in sommige talen omdat anders de functies niet meer kloppen, geef me overigens 1 GOEDE reden aan wat het voordeel van case sensitivity zou zijn.

jonge, als jij nou even fijn die discussie hierboven gaat lezen tussen mbravenboer, otis en mij

[.oisyn]

Op maandag 31 december 2001 17:45 schreef curry684 het volgende:

[..]

OiSyN bedoelde het goed maar zei het fout

neeheeeeej, ik zei het goed, maar jij begreep me verkeerd

[Verwijderd]

Op maandag 31 december 2001 17:45 schreef curry684 het volgende:

[..]

OiSyN bedoelde het goed maar zei het fout

Je kunt de class behalve alleen declareren ook meteen instantieren. Vooral handig bij static private subclasses:

Precies. Daarbij komt dat een class definitie afstamt van de struct declaratie uit C, wat de ';' nodig heeft voor de zaken waar OiSyN over sprak.

[Verwijderd]

totaal off-topic:

'de cap' die lachend 4 ton vraagt voor (delphi) code waar dit soort zaken in zitten:

code:

try
 [..]
except
 on e:exception do raise;
end;

of, nog een leuke:

code:

for i:=0 to 10 do
  begin
    i:=1;
    [..]
  end;

[vinnux]

Ergenissen over Java :

Java beweert platforafhankelijk te zijn.
Maar dit is absoluut niet het geval. Dezelfde code kan op een andere machine soms hele andere dingen doen.
Een van deze eigenaardigheden heb ik gevonden bij het afhandelen van Socket Exceptions.
Op een Win32 krijg je netjes een Connection Refused Exception terwijl je op een SUN/Solaris machine die Exception niet terugkrijgt, maar een algemenere Exception.

Het zal vast zo zijn dat dit bij meer Exceptions zo is.
Dit kan heeeeel erg irritant zijn.

En staat het ergens genoteerd ? Ik heb het nog niet gezien.
Iemand wel.

Ook bij het gebruik van AWT zijn er een hele boel problemen waar je tegenaanloopt als je voor meerdere platformen een GUI maakt. Eventhandling bijvoorbeeld is som erg verschillend.

Zo dit zijn mijn ergenissen

[raptorix]

Op maandag 31 december 2001 17:55 schreef OiSyN het volgende:

[..]

jonge, als jij nou even fijn die discussie hierboven gaat lezen tussen mbravenboer, otis en mij

Had geen tijd om 8 * 25 berichten te lezen

[curry684]

Op maandag 31 december 2001 18:08 schreef hezik het volgende:
totaal off-topic:

'de cap' die lachend 4 ton vraagt voor (delphi) code waar dit soort zaken in zitten:

Ik heb ooit wat maintenance moeten verrichten op een commercieel VB-project. Bleek dat *IEDERE* van de enkele duizenden functies begon met de volgende regel:

code:

on error resume next

Echt vet gelachen, daarna hard gejankt natuurlijk

Alle variabelen hadden ook duidelijke namen: a, aa, b, c, dd, i

* curry684 heeft tot op de dag van vandaag een beetje frustraties over die opdracht.

[Speedpete]

Ik vraag me weleens af waarom sommige aanroepen zo verrekte lang moeten zijn...

'addActionListener' is mij teveel letters. Zo hebben veel talen van die lange aanroepen.

Al ben ik over VB wel heel tevreden dat ie automatisch een " zet achter een stringetje of hoofdletters aanpast.

[edit]
* Speedpete gebruikt ook altijd duidelijke variabelen.
i, j, k, l, m, var1, var2, myStr1, etc. etc.

Maakt het des te moeilijker voor anderen om je code te jatten

Heb ooit ergens gelezen hoe je er voor kan zorgen dat je code amper gejat wordt, de tip: gebruik rare vars.

bijv:

code:

Dim hond as Boolean
Dim kat as Integer
Dim mevrouw_de_vries as string

private sub printerklep()
    if hond then
      kat = 5
    else
      mevrouw_de_vries = "Blaat"
    end if
end sub

Als buitenstaander zal dat ZWAAR irritant zijn.
[edit]

[Crazy D]

Op woensdag 02 januari 2002 13:14 schreef Speedpete het volgende:
Ik vraag me weleens af waarom sommige aanroepen zo verrekte lang moeten zijn...

'addActionListener' is mij teveel letters. Zo hebben veel talen van die lange aanroepen.

Tjah wat wil je dan, aAL? Niet echt duidelijk... of addActList dat maakt het er imho ook niet echt duidelijker op...

[drm]

Op vrijdag 28 december 2001 20:52 schreef wasigh het volgende:
PHP + Strings: een ' en een " hebben een andere functie?

Waarom zouden ze hetzelfde "moeten" zijn, dan

[Verwijderd]

Op woensdag 02 januari 2002 13:14 schreef Speedpete het volgende:
Heb ooit ergens gelezen hoe je er voor kan zorgen dat je code amper gejat wordt, de tip: gebruik rare vars.

...

Als buitenstaander zal dat ZWAAR irritant zijn.

Dan maak je het voor je zelf ook lastiger. In zo'n geval kan je beter een obfuscator gebruiken in je release versie.

[drm]

Het enige voordeel wat ik kan bedenken mbt. case-sensitivity is het punt wat mbravenboer noemde, nl. dat wij in het westen niet de enige op de wereld zijn.

Ikzelf heb me het meest bezig gehouden met de C familie van talen (C, C++, Java, later PHP ivm webdev) en casesensitivity is dan geen ergernis maar een gewoonte. En dan kom je al heel gauw op codeconventies terecht.

Hoe doe je de naamgeving? Als je tijdens het coden de naam van een variabele mag veranderen, wat blijft er dan over van de consequente naamgeving, als je niet gedwongen wordt die toe te blijven passen?

Ik ben zelf heel erg voor constanten met HOOFDLETTERS_EN_UNDERSCORES, klassenamen met HoofdEnKleineLetters, en functienamen en variabelen met kleineLetterBeginnend

variabelenamen zo min mogelijk gecombineerde woorden. Liever "waarde" dan "waardeDieDitBevat" en ga zo maar door. Dan wordt case-sensititivity een hulpstuk om consequent naamgevingen te gebruiken.


Mijn grootste ergernis aan PHP is dat je er zo ongelooflijk lui van wordt, en dat komt vaak op codevervuiling. Zo kwam ik laatst in een stuk code een $i = 0; ofzo tegen. Verder deed ik niets met $i en had ik er niets voor gedaan, dus dat sloeg helemaal nergens op.

Ook in PHP vind ik het verschil tussen == en === nogal eens irritant. PHP is eigenlijk te slap om echt nette en strakke programmastructuren in te schrijven, maar het blijft een taal/parser die ik zal moeten gebruiken voor mijn werk... Ik word liever op mijn vingers getikt door een compiler of parser, dan dat ik een flauwe codert word

Verder ben ik het zoals altijd eens met mbravenboer en OiSyN

[Verwijderd]

Constanten in hoofdletters vind ik zelf niet zo'n succes, hoewel ik er niet echt een probleem mee heb en ook wel eens gebruik. Het schreewt alleen zo erg. Maar dat kan aan mij liggen; ik heb eens met code moeten werken waarbij alle functies in uppercase stonden. Om gek van te worden.

[drm]

Op woensdag 02 januari 2002 14:14 schreef lnfinitive het volgende:
Constanten in hoofdletters vind ik zelf niet zo'n succes, hoewel ik er niet echt een probleem mee heb en ook wel eens gebruik. Het schreewt alleen zo erg. Maar dat kan aan mij liggen; ik heb eens met code moeten werken waarbij alle functies in uppercase stonden. Om gek van te worden.

het is natuurlijk een keuze. Ik gebruik het liefst zo min mogelijk constanten en macros, maar je kan altijd zien dat het spul is wat constant is :-)

[Verwijderd]

- 't onbreken van een (bool)?'thenreturn':'elsereturn' constructie in bijv. delphi.

- meer tijd spenderen aan het instellen van je project dan aan 't coden zelf in VC++.

- het ontbreken van een fatsoenlijke IDE bij grafische ontwikkeltools (JBuilder heeft mij errug lang ge-ergerd.. wat een bagger omgeving zeg).

- het ontbreken van int++ en int-- in delphi, en het niet ter plekke kunnen declareren van variabelen

- baggertrage compilers (nogmaals een JBuilder frustratie.. dat zo'n compiler van de makers van delphi af kan komen zeg..)

kheb echt nog nooit in een fijnere ontwikkelomgeving gewerkt als in delphi (inspringen met cltr-u en -i, keypoints met ctrl-cijfertje.. dat soort heerlijke features).. zelfs VC++ kan er niet aan tippen.

[drm]

Ik heb altijd een voorliefde gehad voor de Turbo IDE van Borland (DOS text-based IDE). Geweldig. Alle simpele instellingen zijn te doen en geen overbodige melpfuncties.

[.oisyn]

Op woensdag 02 januari 2002 15:10 schreef abraxas het volgende:
kheb echt nog nooit in een fijnere ontwikkelomgeving gewerkt als in delphi (inspringen met cltr-u en -i, keypoints met ctrl-cijfertje.. dat soort heerlijke features).. zelfs VC++ kan er niet aan tippen.

inspringen kan in VC++ ook (en je kan zelf de sneltoetsen binden). Die keypoints zijn er (geloof ik) niet, maar ik weet zeker dat VC++ heel wat meer functionaliteit bevalt dan jij denkt
Het lekkere van VC++ vind ik dat het gewoon compleet aanpasbaar is... Je kunt menu's en toolbars aanmaken en aanpassen, sneltoetsen configureren, plug-ins voor programmeren, en zeker met de Visual Assist plug-in heb je een gigantisch goeie intellisense en syntax coloring

meer tijd spenderen aan het instellen van je project dan aan 't coden zelf in VC++.

hier ben ik het ook absoluut niet mee eens. Het is new project, projectje uitkiezen, even instellen, en klaar. 2 minuten werk! Dat valt toch best mee...

[.oisyn]

.edit: hmmmz verkeerde topic

[MSalters]

Op maandag 31 december 2001 16:30 schreef OiSyN het volgende:

[..]

Omdat je nog variabelen kunt declareren na de class

code:

class Blaat
{
} blaat1, blaat2;

en functies

[curry684]

Op woensdag 02 januari 2002 15:02 schreef drm het volgende:
het is natuurlijk een keuze. Ik gebruik het liefst zo min mogelijk constanten en macros, maar je kan altijd zien dat het spul is wat constant is :-)

Tja... gebruik dan een echt leesbaar en handig systeem:

code:

int    g_GlobalValue     = 50;
const int   c_ConstantValue   = 10;

typedef enum
  {
  e_SdtAnEnumerate      = 1,
  e_SdtAnotherEnumerate  = 2,
  e_SdtSomeThirdEnumerate     = 3,
  } t_SomeDataType;

class MyPersonalClass
{
public:
  MyPersonalClass(int p_SomeParameter)
    {
    t_SomeDataType   l_LocalVariable = e_SdtAnEnumerate;

    m_SomeMemberVariable = p_SomeMemberVariable;
    }

private:
  int           m_SomeMemberVariable;
};

[curry684]

Op woensdag 02 januari 2002 15:10 schreef abraxas het volgende:
kheb echt nog nooit in een fijnere ontwikkelomgeving gewerkt als in delphi (inspringen met cltr-u en -i, keypoints met ctrl-cijfertje.. dat soort heerlijke features).. zelfs VC++ kan er niet aan tippen.

Ik gebruik dagelijks VC++ en BCB (zelfde IDE als Delphi), ennuh:
• In Delphi/BCB is het ctrl+SHIFT+i en ctrl+SHIFT+u voor inspringen
• Ik vind persoonlijk TAB en shift-TAB zoals in VB/VC++ veel handiger dan de Borland-variant

[Verwijderd]

Wat ik vervelend vind is dat we op de Haagse Hogeschool met JBuilder ineens bij elkaar kunnen klikken wat we maar willen, maar die sjablonen die er standaard inzitten zijn g5%&*&(*__&&EREDY irritant! Ik ben dan echt 10 minuten bezig met slepen, verwijderen enz. Het is dan wel een handig proggie want knoppen enzo invoegen gaat 10 kee zo snel. Maar maak het dan ook goed af!

Tweede ergernis is slecht tot geen commentaar bij OS of wat dan ook. Leg dan tenminste uit wat iets doet en niet hoe het dat dan doet, anders zie je het gewoon niet.

[itsme]

[php] Error on line 129 als je een ";"vergeten bent .. kan ik weer gaan tellen in notepad

(ik ben er overigens vorig jaar (30 december dus) achter gekomen dat er een statusbalk in notpad zit )

[Verwijderd]

Op woensdag 02 januari 2002 18:46 schreef curry684 het volgende:

[..]

Ik gebruik dagelijks VC++ en BCB (zelfde IDE als Delphi), ennuh:
• In Delphi/BCB is het ctrl+SHIFT+i en ctrl+SHIFT+u voor inspringen
• Ik vind persoonlijk TAB en shift-TAB zoals in VB/VC++ veel handiger dan de Borland-variant

ctrl-shift of ctrl, what's the difference tis voor mij een automatisme... das met wel meer dingen die ik niet zo zou kunnen herinneren, maar ga ik ze typen, dan weet ik 't wel (zoals wachtwoorden).

nou ben ik trouwens niet zo enorm bekend met VC++, dus wellicht ben ik daar wat te voorbarig over geweest 1 ding is me heel duidelijk doch, delphi is default prima te gebruiken en in VC++ zal je eerst toch je workspace flink moeten instellen, en voor een VC++-n00b als ik kan dat best nog lastig zijn (wel errug handig dat je die config er ook als 1 regel in kan pasten btw).

[Verwijderd]

Ik erger me niet echt aan een programmeer taal... meer aan de mensen:

- Mensen die zonodig tabs gebruiken om in te springen in code.

- de MSDN documentatie... staat veel in, maar helaas klopt het niet altijd zoals het staat beschreven.

[curry684]

Op woensdag 02 januari 2002 19:39 schreef vicz het volgende:
Ik erger me niet echt aan een programmeer taal... meer aan de mensen:
- Mensen die zonodig tabs gebruiken om in te springen in code.

Neuh da's het probleem niet zo (ik gebruik ook tabs ), het wordt pas erg als ze expres de optie 'Replace tabs with spaces' uitzetten

- de MSDN documentatie... staat veel in, maar helaas klopt het niet altijd zoals het staat beschreven.

Ik kom zelden een echte fout tegen, MSDN heeft meer last van wilde 'omissies' (probeer een keertje voor de lol WinINet asynchroon aan de praat te krijgen.....)

Liever vrijwel altijd correcte documentatie dan geen documentatie, of een 'zoek maar op in de kernel-source'

[.oisyn]

Op woensdag 02 januari 2002 19:39 schreef vicz het volgende:
Ik erger me niet echt aan een programmeer taal... meer aan de mensen:

- Mensen die zonodig tabs gebruiken om in te springen in code.

uhm... jij gebruikt spaties? Lekker fijn als je het weer terug wil indenten. Bovendien dwing je dan andere mensen die jouw code lezen ook jouw aantal spaties te gebruiken, met tabs heb je dat niet omdat iedereen dat zelf in kan stellen

- de MSDN documentatie... staat veel in, maar helaas klopt het niet altijd zoals het staat beschreven.

Ik heb een hoop gelezen en uitgeprobeerd, en ik ben nog nooit iets tegen gekomen wat niet klopt (meer van die foutjes die je zelf veroorzaakt door het niet goed lezen van de MSDN (remarks stukje vergeten bijvoorbeeld))

[curry684]

Op woensdag 02 januari 2002 19:55 schreef OiSyN het volgende:
uhm... jij gebruikt spaties? Lekker fijn als je het weer terug wil indenten.

Daarvoor heb je dus net shift-TAB en/of ctrl-shift-u?

Bovendien dwing je dan andere mensen die jouw code lezen ook jouw aantal spaties te gebruiken, met tabs heb je dat niet omdat iedereen dat zelf in kan stellen

Ja inderdaad, je dwingt andere mensen om de code in hetzelfde formaat te lezen als waarin het leesbaar is geschreven. Ik vind het dodelijk irritant als ik sourcecode op websites eerst moet vernaggelen in Wordpad of een IDE omdat IE toevallig standaard 4 spaties als tabsize gebruikt en die code dan onleesbaar is.

Stel het volgende stukje compleet uit mijn duim:

code:

// Return immediately if no indentation requested
if(p_IndentMode == e_ImNone)
  return;

// Check for generic indentation
else if(p_IndentMode == e_ImGeneric &&
      l_LineLength > 0 &&
      p_IndentSize > 0)
  {
  return PerformGenericIndent(p_IndentSize);
  }

// Check for smart indentation
else if(p_IndentMode == e_ImSmart &&
      p_IndentSize > l_LineLength)
  {
  // Make sure the license is sufficient and correct libraries are present
  if(g_Configuration->LicenseType() >= e_LtProfessional &&
     g_Configuration->LibraryVersions() >= c_VersionId)
    {
    return PerformSmartIndent(p_IndentSize);
    }
  // Otherwise just do the generic indent
  else
    {
    return PerformGenericIndent(p_IndentSize);
    }
  }

// All other cases throw exception
else throw EIllegalParameters("ApplyIndent",
                    "Wrong license type or our software\n"
                    "sucks bigtime and crashed.");

Dit is een mooi opgemaakt stukje code... totdat je het door een andere tab-size flikkert, dan blijft er geen kont van over.

[.oisyn]

Op woensdag 02 januari 2002 21:08 schreef curry684 het volgende:

[..]

Daarvoor heb je dus net shift-TAB en/of ctrl-shift-u?

niet alle editors hebben dat

Ja inderdaad, je dwingt andere mensen om de code in hetzelfde formaat te lezen als waarin het leesbaar is geschreven. Ik vind het dodelijk irritant als ik sourcecode op websites eerst moet vernaggelen in Wordpad of een IDE omdat IE toevallig standaard 4 spaties als tabsize gebruikt en die code dan onleesbaar is.

IE gebruikt 6 spaties

Stel het volgende stukje compleet uit mijn duim:

code:

... code ...

Dit is een mooi opgemaakt stukje code...

Daar ben ik het sowieso al niet mee eens, ik vind het een zootje

totdat je het door een andere tab-size flikkert, dan blijft er geen kont van over.

Hmmmja jij indenteert ook zo dat het afhankelijk is van de vorige regel (bijvoorbeeld haakjesopenen bij een functie). Dat doe ik dus niet en dan heb je er verder ook totaal geen last van met andere tab settings (gelukkig kan ik andermans code met VC++ heerlijk tabifyen zodat ik het wel in mijn eigen settings kan bekijken)

[Verwijderd]

Op woensdag 02 januari 2002 13:14 schreef Speedpete het volgende:
Ik vraag me weleens af waarom sommige aanroepen zo verrekte lang moeten zijn...
'addActionListener' is mij teveel letters. Zo hebben veel talen van die lange aanroepen.

Dit is juist beter. Fatsoenlijke IDE's hebben code-completion wat minder tikwerk is, maar je code is wel duidelijker!

[edit]
* Speedpete gebruikt ook altijd duidelijke variabelen.
i, j, k, l, m, var1, var2, myStr1, etc. etc.
Maakt het des te moeilijker voor anderen om je code te jatten

:'(
Dit is voor mij ook een ergenis, voor een korte methode is het meestal niet zo erg, maar als dit klasse variablen zijn of variabelen van een groter algoritme is het vreselijk puzzelwerk om iets uit te zoeken. Gebruik dan liever xxxIndex ipv i of j etc. Om van k,l,m, varX maar niet te spreken en myStr1

Heb ooit ergens gelezen hoe je er voor kan zorgen dat je code amper gejat wordt, de tip: gebruik rare vars.

Gebruik een obfuscator, makkelijker als je je code wilt aanpassen en is nog lastiger te rippen.

[drm]

curry684:
Tja... gebruik dan een echt leesbaar en handig systeem:

code:

meuk

Dat is natuurlijk maar net wat je leesbaar of handig vindt. Ik vind jouw code ook prima leesbaar, maar ik ben het op mijn manier gewend. Daarnaast heb ik een ******hekel aan underscores, omdat ik dat prima vind te lezen maar echt kloterig te schrijven. 1 van de weinige toetsen die ik vaak missla

Ik heb de meeste "conventies" (lees:gebruiken) gewoon overgenomen van de standard library van C(++) zoals hij bij Borland C++ 3.1 geleverd werd, met wat aanpassinkjes, en ik vind het prima leesbaar. Een jaar of 2 geleden kreeg ik van een klasgenoot ook nog wat tips, en toen we samen een projectje gingen kloppen konden we het allebei lezen alsof het allemaal eigen code was.

Dat is natuurlijk the main idea:
wanneer andere mensen het lezen je ze het niet onmogelijk maakt (tenzij je natuurlijk een obfuscator wilt gebruiken).

Ga ajb niet als een obfuscator zitten coden ;)@Speedpete

[Verwijderd]

Op vrijdag 28 december 2001 20:24 schreef bobo1on1 het volgende:

[..]

Daar is een hele simpele oplossing voor:
status.caption = " het werkt " & chr(x) & "ok" & chr(x) & " "

waarbij x dus het ASCII nr is van "

Nog veel simpeler:

code:

status.Caption = " het werkt ""ok"" "

En ' is echt niet beter als " hoor! Als je de ' (zoals in Pascal) gebruikt dan zit je met het zelfde probleem als je dit teken (') in een string wilt gebruiken.

Wat betreft de subs en functions ( ()-probleem ); gewoon Call blabla(bla, bla) gebruiken! Al blijft het shit!

[curry684]

Op woensdag 02 januari 2002 22:02 schreef OiSyN het volgende:
IE gebruikt 6 spaties

Het was ter illustratie moppie

All the more reason overigens: iemand ooit 6 spaties als tab in een source-editor gebruikt?

Over mijn mooie stukje code:

Daar ben ik het sowieso al niet mee eens, ik vind het een zootje

Hmmmja jij indenteert ook zo dat het afhankelijk is van de vorige regel (bijvoorbeeld haakjesopenen bij een functie).

Hangt er vanaf wanneer je iets als een zootje gaat definieren:
• Ik zorg ervoor dat alles binnen een IF-statement gelijk geindent is, de alternatieven zijn hier: 6 schermen brede statements of een ENORM zootje van scheve troep.
• Ik plaats bij ingewikkelde functiecalls 1 parameter op 1 regel, geindenteerd achter het haakje inderdaad. Dit zorgt ervoor dat je in 1 klap ziet binnen welke context een bepaalde operatie gebeurt, en welke parameter je zit te modifyen als je iets vermeukt.

Dat doe ik dus niet en dan heb je er verder ook totaal geen last van met andere tab settings (gelukkig kan ik andermans code met VC++ heerlijk tabifyen zodat ik het wel in mijn eigen settings kan bekijken)

Ik daag je uit: herschrijf mijn stukje code hierboven eens in jouw stijl. Wil ik wel eens zien welke duidelijker is... en ja ik heb er expres zulke spaghettilogica ingestopt.

Verder zei Drm:

Dat is natuurlijk maar net wat je leesbaar of handig vindt. Ik vind jouw code ook prima leesbaar, maar ik ben het op mijn manier gewend. Daarnaast heb ik een ******hekel aan underscores, omdat ik dat prima vind te lezen maar echt kloterig te schrijven. 1 van de weinige toetsen die ik vaak missla

Die underscore hoort bij de scope-aanduiding. Kun je voor mijn part ook weglaten, maar de prefix zelf is wel gruwelijk nuttig. Zie bijvoorbeeld waarom ik de Hungarian notatie zo ranzig vind:

code:

volatile int   dwIndex;

class MyClass
{
private:
  int       dwIndex;

public:
  MyClass(int dwIndex = 1)
    {
    int dwIndex = 0;
    
    // Vul hier een stukje code in dat de member-index
    // initialiseert met de parameter-index, en in de
    // globale index bijhoudt welke class er het laatst
    // aangemaakt is. Leef je uit    ;)
    }
};

Dan heb ik toch liever mijn variant (speciaal voor jou zonder underscores ):

code:

int  gIndex;

class MyClass
{
private:
  int       mIndex;

public:
  MyClass(int pIndex = 1)
    {
    int lIndex = 0;

    mIndex = pIndex;
    gIndex = pIndex;
    }
};

Want wat voegt die Hungarian nou eigenlijk toe? Dat die index een dword is? Goh ik had zelf ook wel kunnen bedenken dat het geen string zou zijn. En bij m_Name ga ik evenzo niet aan een int of een bool denken.

* curry684 vindt Hungarian een van de achterlijkste uitvindingen ooit

[.oisyn]

Op donderdag 03 januari 2002 19:04 schreef curry684 het volgende:
Ik daag je uit: herschrijf mijn stukje code hierboven eens in jouw stijl. Wil ik wel eens zien welke duidelijker is... en ja ik heb er expres zulke spaghettilogica ingestopt.

ik vond het een zootje omdat je de accolades ook indenteerd... dat komt (voor mij dan) nogal onnatuurlijk over. 'T is waarschijnlijk een gewenning, maar als ik het zo voor het eerst zie vind ik het een zootje Maar misschien is een zootje een verkeerd woord, want een zootje == chaos, en dat is jouw code nou ook weer niet

maar goed:

code:

if (p_IndentMode == e_ImNone)
    return;    // Return immediately if no indentation requested

// Check for generic indentation
else if ((p_IndentMode == e_ImGeneric) && (l_LineLength > 0) &&
    (p_IndentSize > 0))
{
    return PerformGenericIndent (p_IndentSize);
}

// Check for smart indentation
else if ((p_IndentMode == e_ImSmart) && (p_IndentSize > l_LineLength))
{
    // Make sure the license is sufficient and correct libraries are present
    if ((g_Configuration->LicenseType () >= e_LtProfessional) &&
      (g_Configuration->LibraryVersions () >= c_VersionId))
    {
      return PerformSmartIndent (p_IndentSize);
    }
    else // Otherwise just do the generic indent
    {
      return PerformGenericIndent (p_IndentSize);
    }
}
else // All other cases throw exception
{
    throw EIllegalParameters ("ApplyIndent",
      "Wrong license type or our software\nsucks bigtime and crashed.");
}

maar mijn naming conventions zijn heel anders, dus ik zal het nog een keer posten maar dan hoe ik zelf de variabelen en functies zou noemen:

code:

if (indentMode == INDENTMODE_NONE)
    return;    // Return immediately if no indentation requested

// Check for generic indentation
else if ((indentMode == INDENTMODE_GENERIC) && (lineLength > 0) &&
    (indentSize > 0))
{
    return performGenericIndent (indentSize);
}

// Check for smart indentation
else if ((indentMode == INDENTMODE_SMART) && (indentSize > lineLength))
{
    // Make sure the license is sufficient and correct libraries are present
    if ((configuration->getLicenseType () >= LICENSE_PROFESSIONAL) &&
      (configuration->getLibraryVersions () >= versionID))
    {
      return performSmartIndent (indentSize);
    }
    else // Otherwise just do the generic indent
    {
      return performGenericIndent (indentSize);
    }
}
else // All other cases throw exception
{
    throw IllegalParameterException ("ApplyIndent",
      "Wrong license type or our software\nsucks bigtime and crashed.");
}

en even de oude code ter vergelijking

code:

// Return immediately if no indentation requested
if(p_IndentMode == e_ImNone)
  return;
// Check for generic indentation
else if(p_IndentMode == e_ImGeneric &&
      l_LineLength > 0 &&
      p_IndentSize > 0)
  {
  return PerformGenericIndent(p_IndentSize);
  }

// Check for smart indentation
else if(p_IndentMode == e_ImSmart &&
      p_IndentSize > l_LineLength)
  {
  // Make sure the license is sufficient and correct libraries are present
  if(g_Configuration->LicenseType() >= e_LtProfessional &&
     g_Configuration->LibraryVersions() >= c_VersionId)
    {
    return PerformSmartIndent(p_IndentSize);
    }
  // Otherwise just do the generic indent
  else
    {
    return PerformGenericIndent(p_IndentSize);
    }
  }

// All other cases throw exception
else throw EIllegalParameters("ApplyIndent",
                    "Wrong license type or our software\n"
                    "sucks bigtime and crashed.");

[.oisyn]

curry684:

code:

MyClass(int dwIndex = 1)
{
    int dwIndex = 0;
    
    // Vul hier een stukje code in dat de member-index
    // initialiseert met de parameter-index, en in de
    // globale index bijhoudt welke class er het laatst
    // aangemaakt is. Leef je uit    ;)
}

volgens mij kan dat helemaal niet, aangezien locale variabelen en parameters dezelfde scope hebben

dus even afgezien van dat wordt het

code:

MyClass (int dwIndex = 1)
{
    this->dwIndex = dwIndex;
    of
    MyClass::dwIndex = dwIndex;

    ::dwIndex = dwIndex; // wat moest hier nou eigenlijk? :?
}

[curry684]

Op donderdag 03 januari 2002 21:22 schreef OiSyN het volgende:
volgens mij kan dat helemaal niet, aangezien locale variabelen en parameters dezelfde scope hebben

Klopt, mijn fout... voordeel 1 van mijn aanpak overigens meteen aangetoond

dus even afgezien van dat wordt het

code:

MyClass (int dwIndex = 1)
{
    this->dwIndex = dwIndex;
    of
    MyClass::dwIndex = dwIndex;

    ::dwIndex = dwIndex; // wat moest hier nou eigenlijk? :?
}

Kinda says it all

[Verwijderd]

Hmmm.... hier erger ik me ook aan:

code:

for (int i=0;i<9;i++) doSomething();
for (int i=0;i<9;i++) doSomethingToo();

Gaat VC++ nl over klagen....

[Jrz]

Op donderdag 03 januari 2002 22:41 schreef vicz het volgende:
Hmmm.... hier erger ik me ook aan:

code:

for (int i=0;i<9;i++) doSomething();
for (int i=0;i<9;i++) doSomethingToo();

Gaat VC++ nl over klagen....

Niet zijken lul... gewoon lezen hoe je dat kan fixen in vc

[Verwijderd]

Op donderdag 03 januari 2002 20:58 schreef OiSyN de volgende meuk:

[ .. nieuwe code .. ]

Naar mijn naming conventions zijn heel anders, dus ik zal het nog een keer posten maar dan hoe ik zelf de variabelen en functies zou noemen:

[ .. oude code .. ]

*kneels down and worships OiSyN as ultimate code crafter

Kijk, dat is nou code, die je met plezier drie jaar later nog eens gaat debuggen i.t.t. tot wat Perl dingen die ik ooit ben tegengekomen en waaraan ik de meest verschrikkelijke nachtmerries heb overgehouden na nachtenlange programmeersessies

[Verwijderd]

Op donderdag 03 januari 2002 22:44 schreef Jrz het volgende:

[..]

Niet zijken lul... gewoon lezen hoe je dat kan fixen in vc

Goh... je hebt het wel moeilijk he... beetje vriendelijker mag ook wel...
Ik kan alleen een zogenaamde workaround vinden, geen fix.

[Bergen]

Op donderdag 03 januari 2002 22:44 schreef Jrz het volgende:

[..]

Niet zijken lul... gewoon lezen hoe je dat kan fixen in vc

Wat is er met jou aan de hand? Lekker vriendelijk vandaag zo te zien.. Het is gewoon irritant dat zulke regeltjes niet werken terwijl er in principe niets mis mee is.

[Verwijderd]

Op donderdag 03 januari 2002 22:41 schreef vicz het volgende:
Hmmm.... hier erger ik me ook aan:

code:

for (int i=0;i<9;i++) doSomething();
for (int i=0;i<9;i++) doSomethingToo();

Gaat VC++ nl over klagen....

Ik ken VC++ niet maar ik kan me goed voorstellen dat dit niet gepikt wordt; namelijk:

code:

for (int i=0;i<9;i++) ...

Hiermee is i als int geïnitialiseerd en gedefinieerd (ik mis deze constructies nog steeds in Delphi wat mijn grootste ergernis is).
Als je deze vervolgens weer gaat definiëren en dan ook nog weer een keer als precies hetzelfde type dan is het eigenlijk wel goed dat hij gaat klagen, imho.
Bovendien zou ik dit als volgt doen, al kan ik het natuurlijk helemaal fout hebben!

code:

for (int i=0;i<9;i++)
{
  DoSomething;
  DoSomethingToo;
};

En als het niet anders kan:

code:

  for (int i=0;i<9;i++) DoSomething;
  for (    i=0;i<9;i++) DoSomethingToo;

Ik ken VC++ helemaal niet goed, dus let maar niet teveel op mijn code aangezien die ongetwijfeld fout zal zijn.

[Verwijderd]

Op vrijdag 04 januari 2002 09:31 schreef hvdberg het volgende:

[..]

Als je deze vervolgens weer gaat definiëren en dan ook nog weer een keer als precies hetzelfde type dan is het eigenlijk wel goed dat hij gaat klagen, imho.

De variable zou binnen de "for" scoop moeten vallen en niet buiten de for loop.

[Verwijderd]

De variable zou binnen de "for" scoop moeten vallen en niet buiten de for loop.

'Zou' inderdaad. De oudere C++ compilers vinden dat de variabele buiten de scope valt (was toentertijd standaard) en is later veranderd naar binnen de 'for' scope.

[The End]

Op donderdag 03 januari 2002 20:58 veranderde OiSyN curry684's code:

[..]
[knip]

code:

if(p_IndentMode == e_ImNone)
  return;
// Check for generic indentation
else if(p_IndentMode == e_ImGeneric &&
      l_LineLength > 0 &&
      p_IndentSize > 0)
  {
  return PerformGenericIndent(p_IndentSize);
  }

[/knip]

Vinden jullie het niet irritant dat 'else if' zo staat? Ik kies altijd voor deze variant:

code:

if(p_IndentMode == e_ImNone)
  return;
// Check for generic indentation
else
{
  if(p_IndentMode == e_ImGeneric &&
      l_LineLength > 0 &&
      p_IndentSize > 0)
  {
     return PerformGenericIndent(p_IndentSize);
  }
}

Dan heb je nog net iets meer overzicht.

[drm]

vicz:
De variable zou binnen de "for" scoop moeten vallen en niet buiten de for loop.

Ben ik het mee eens. Dat was idd in de oudere compilers (zoals Turbo C++) ook een probleem.

curry684:
Klopt, mijn fout... voordeel 1 van mijn aanpak overigens meteen aangetoond
[..]

Kinda says it all

Tja, ach... Globale variabelen moet je toch enigszins zien te vermijden, imo.

Maar wat houdt dat Hungarian dan precies in? Dat je het type van een variabele in de naam verwerkt ofzo
lijkt me ook een beetje onzin...

[Verwijderd]

Op vrijdag 04 januari 2002 09:44 schreef vicz het volgende:

[..]

De variable zou binnen de "for" scoop moeten vallen en niet buiten de for loop.

Het kan voorkomen dat je de toch de variabele buiten de for-scope wilt behouden.
Bijvoorbeeld:

code:

  for (int i=0;i<obj->Length();i++) DoSomething;
  i *= 4;
  for (int j=i;j>0;j--) DoSomethingToo;

Ik ben het er helemaal mee eens dat het beter zou zijn als je de 'int i' buiten de for-scope zou zetten, dus:

code:

  int i;
  for (    i=0;i<obj->Length();i++) DoSomething;
  i *= 4;
  for (int j=i;j>0;j--) DoSomethingToo;

[Verwijderd]

Op vrijdag 04 januari 2002 10:56 schreef drm het volgende:
Maar wat houdt dat Hungarian dan precies in? Dat je het type van een variabele in de naam verwerkt ofzo

precies, bijv: strUsername, intMaxHeight etc etc

En dat is dus zeker geen onzin. Deze notatie stelt je in staat voor willekeurige lappen code veel sneller de werking in te zien, dan wanneer je per var eerst zelf het type moet uitzoeken.

Het levert alleen wat problemen als je typeless vars gebruikt

[leuk_he]

Op vrijdag 28 december 2001 20:10 schreef Otis het volgende:
';' vergeten in C/C++, waarbij de compiler dan over de zeik gaat doordat de statements volgend op waar die ';' had moeten staan niet meer kloppen (duh). Ipv dat de compiler zelf de ';' toevoegt (dus je code fixt).

Nog erger: de compiler geeft aan
; missing, inserted ; bofore xxxx
(b.v. in PLSQL)

En ondanks dat hij gelijk heeft en mijn fout heeft gevonden, en gecorrigeerd om verder te kunnen gaan MOET IK NOG STEEDS ZELF OOK DE CORRECTIE MAKEN. grrr. 8-(

[Verwijderd]

Op vrijdag 28 december 2001 19:53 schreef Breepee het volgende:
tis wel niet echt programmeren, maar ik ergeer me er wel kapot aan: [topic=363087/1] (1 na laatste post).

Is toch al opgelost

[Verwijderd]

heb er 2!

- Mensen die denken dat ze kunnen programmeren en het niet kunnen, maar heel de dag internet afstruinen voor scripts gemaakt door anderen.
- Mensen die omslachtig programmeren en alles commanten (bedoel dan meer webscripting) om te denken dat de pagina nog 10x ge-edit zou moeten worden.

[_JGC_]

Waar ik me aan erger?
De ins en outs van assembly onder Windows NT/2K/XP, dat is pas erg!

[.oisyn]

Op vrijdag 04 januari 2002 10:55 schreef The End het volgende:

[..]

Vinden jullie het niet irritant dat 'else if' zo staat? Ik kies altijd voor deze variant:

code:

if ()
{
}
else
{
    if ()
    {
    }
}

Dan heb je nog net iets meer overzicht.

nee, want als je een hele rij else if's hebt, dan wordt het met jouw methode steeds meer geindent, terwijl het eigenlijk op hetzelfde level is...
kijk:

code:

if (blaat)
{
}
else
{
    if (blaat2)
    {
    }
    else
    {
      if (blaat3)
      {
      }
      else
      {
         if (blaat4)
         {
         }
      }
    }
}

dan is dit veel mooier:

code:

if (blaat)
{
}
else if (blaat2)
{
}
else if (blaat3)
{
}
else if (blaat4)
{
}

kent C trouwens geen elseif? (aan elkaar dus) (zo ja: dan zou ik het nog niet gebruiken )

dat for probleem in MSVC++ kun je trouwens oplossen door dit in je code te zetten:

code:

#define for if (0) {} else for

[_JGC_]

code:

if () {
    code;
} else {
    if () {
      code;
    }
};

Switch & case wel es getest? Vind ik persoonlijk veel netter programmeren.

[Verwijderd]

Op vrijdag 04 januari 2002 10:55 schreef The End het volgende:
Vinden jullie het niet irritant dat 'else if' zo staat? Ik kies altijd voor deze variant:

code:

if(p_IndentMode == e_ImNone)
  return;
// Check for generic indentation
else
{
  if(p_IndentMode == e_ImGeneric &&
      l_LineLength > 0 &&
      p_IndentSize > 0)
  {
     return PerformGenericIndent(p_IndentSize);
  }
}

Dan heb je nog net iets meer overzicht.

Uhh... in dit geval doe ik dan liever dit:

code:

if(p_IndentMode == e_ImNone) return;
if(p_IndentMode == e_ImGeneric && l_LineLength > 0 && p_IndentSize > 0) {
    return PerformGenericIndent(p_IndentSize);
    }

[curry684]

Op vrijdag 04 januari 2002 10:55 schreef The End het volgende:
Vinden jullie het niet irritant dat 'else if' zo staat? Ik kies altijd voor deze variant:

(knip)

Dan heb je nog net iets meer overzicht.

Jij hebt zeker nog nooit een echt stevige nested if-else van tientallen regels in mekaar gedraaid als je denkt dat dat overzicht geeft

Zie bijvoorbeeld:

code:

if  (p_CommandString == "Logon")
  return PerformLogon();
else if (p_CommandString == "Authenticate")
  return PerformAuthenticate();
else if (p_CommandString == "Logoff")
  return PerformLogoff();
else if (p_CommandString == "Standby")
  return PerformStandby();
else if (p_CommandString == "Update")
  return PerformUpdate();
else if (p_CommandString == "Poll")
  return PerformPoll();
else
  throw EIllegalCommandString(p_CommandString);

Leef je uit in jouw vorm, u wordt gegarandeerd getikt.

[curry684]

Op vrijdag 04 januari 2002 11:07 schreef f0r.c3d het volgende:
precies, bijv: strUsername, intMaxHeight etc etc

En dat is dus zeker geen onzin. Deze notatie stelt je in staat voor willekeurige lappen code veel sneller de werking in te zien, dan wanneer je per var eerst zelf het type moet uitzoeken.

Je illustreert dus exact mijn punt tegen Hungarian hier ongewild. Als ik een willekeurige lap code voor mijn neus krijg weet ik nog steeds dat een Username een STRING is en geen INT, en dat een MaxHeight een INT is en geen BOOL. Logisch inzicht is toch volgens mij een vereiste voor een programmeur.

Daarentegen verdwaal je in die willekeurige lap code meteen als je niet waar die strUsername vandaan komt. Wordt die door de aanroepende functie meegegeven als parameter? Heeft de constructor die al gezet in de members? Of is het gewoon een lokale variabele voor de gein?

[curry684]

Op vrijdag 04 januari 2002 19:36 schreef _JGC_ het volgende:

code:

if () {
    code;
} else {
    if () {
      code;
    }
};

Switch & case wel es getest? Vind ik persoonlijk veel netter programmeren.

Switch werkt alleen op constantes.

[curry684]

Op vrijdag 04 januari 2002 20:47 schreef vicz het volgende:
[..]

Uhh... in dit geval doe ik dan liever dit:

code:

if(p_IndentMode == e_ImNone) return;
if(p_IndentMode == e_ImGeneric && l_LineLength > 0 && p_IndentSize > 0) {
    return PerformGenericIndent(p_IndentSize);
    }

Gatver... IF's die elkaar uitsluiten kunnen indien met 'else' geconstrueerd makkelijker geoptimalizeerd en uitgevoerd worden. Zal in dit specifieke geval weinig uitmaken maar in principe is iedere IF die teveel wordt uitgevoerd een performance-leak natuurlijk. En daar is ELSE nu net tegen bedoeld.

Overigens zie mijn post een stuk hierboven voor hoe het ook kan (gebruik ik zelf altijd daar ik ontiegelijk geil op mooi uitgelijnde en geindenteerde code )

[FendtVario]

als je een pracht stuk software hebt geschreven en het werkt alleen op de pc's die je thuis hebt en bij anderen gewoon niet en je kan de fout niet vinden.

[vinnux]

Wat dacht je van die ' waar je rekening mee moet houden !!!
In SQL statements.

[Hillie]

Op vrijdag 04 januari 2002 22:00 schreef curry684 het volgende:
Switch werkt alleen op constantes.

Precies. En dan ook nog, het gaat van dezelfde expressie uit bij iedere case. Ik ben nu bezig met een of andere CAD-tools voor VLSI opdracht voor school, waarbij ik een aantal else-if's heb, maar waarbij de conditionele expressie bij ieder geval van een aantal andere dingen afhangt. Case-switch werkt netter en fijner, maar het kan gewoon niet altijd.

Trouwens, bij die ingewikkelde else-if's is het wel handig om even goed te documenteren wat je precies doet.

[Verwijderd]

Op vrijdag 04 januari 2002 22:05 schreef curry684 het volgende:

[..]
Overigens zie mijn post een stuk hierboven voor hoe het ook kan (gebruik ik zelf altijd daar ik ontiegelijk geil op mooi uitgelijnde en geindenteerde code )

Ja... wat zijn we nou? Programmeurs of schoonheidsspecialisten?

[Verwijderd]

Op maandag 07 januari 2002 00:40 schreef vicz het volgende:
Ja... wat zijn we nou? Programmeurs of schoonheidsspecialisten?

Jij hebt nog nooit andermans code hoeven onderhouden zo te horen

[Klippy]

1 ding: ";"

[curry684]

Op maandag 07 januari 2002 00:40 schreef vicz het volgende:
Ja... wat zijn we nou? Programmeurs of schoonheidsspecialisten?

Allebei

Zoals Yarvieh al zegt: wacht maar totdat je met een paar man (of nog erger: tientallen mensen) op een project zit en je allemaal een verschillende rotzooierige codingstyle zonder commentaar hebt. You'd rather be dead...

[curry684]

Op maandag 07 januari 2002 00:54 schreef LiquidSilver het volgende:
1 ding: ";"

Lees jij de rest van het topic eens door... hier zijn al meerdere mensen mee gekomen en we hebben al lang beredeneerd dat je niet zonder die ; kan en alleen maar blij mag zijn dat ie in ieder geval consequent overal nodig is.

Zonde dat de errors soms wat onduidelijk zijn maar daar kijk je naar een tijdje ook zo doorheen (en als je erover nadenkt zijn ze wel degelijk logisch gevolg van elkaar).

[whoami]

Op maandag 07 januari 2002 10:24 schreef curry684 het volgende:

[..]

Allebei

Zoals Yarvieh al zegt: wacht maar totdat je met een paar man (of nog erger: tientallen mensen) op een project zit en je allemaal een verschillende rotzooierige codingstyle zonder commentaar hebt. You'd rather be dead...

Daarom hebben de meeste bedrijven een coding-standaard. Maar je moet je er wel aan houden, en dat wil in het begin nog wel eens falen.

[curry684]

Op maandag 07 januari 2002 10:34 schreef whoami het volgende:
Daarom hebben de meeste bedrijven een coding-standaard. Maar je moet je er wel aan houden, en dat wil in het begin nog wel eens falen.

Het ging mij er voornamelijk om dat het houden aan een heldere en duidelijke codingstandaard wel degelijk schoonheidsspecialistenwerk is soms En natuurlijk dat je het je binnen een team niet kunt veroorloven om 'sloppy' met de codingstyle om te springen.