> Ja, is op zich wel handig om een compact script te schrijven. Maar ik
> vind dat dat het laatste is waar je naar moet kijken en desnoods
> bewaar je 3 verschillende versies van je script, eentje volledig,
> eentje met compacte variabele namen en nog een laatste die door de
> packer is gehaald. (misschien leuk ideetje? packer aanpassen om alle
> variabelen te laten krimpen want dat doet ie nu nog zeker niet :p) Het
> is gewoon zo belangrijk duidelijke code te schrijven die je makkelijk
> kan begrijpen.
> Betreft de naamgeving, ik stel dus een combinatie van CamelCase en
> underscores voor ;) om het verschil tussen functions en data weer te
> geven.
> En voorbeeld script was niet fout, alleen heb ik mijn haakje op een
> andere plaats staan dan je waarschijnlijk verwacht had ;) Het is
> namelijk op twee manieren te schrijven:
> (function() {})()
> of
> (function() {}())
> On 20 feb, 10:42, Lekensteyn <uwre...@gmail.com> wrote:
> > Ikzelf probeer juist een zo compact mogelijk script te maken.
> > Momenteel is dat nog handig omdat snellijst tuimte beperkt is, maar in
> > de toekomst kan dat veranderen door de javascript code in een apart
> > bestand te stoppen, en op een website te zetten.
> > Het gebruik van var en komma's is een goed idee, die heb ik meteen
> > toegevoegd.
> > Het gebruik van functie in variabelen is meteen twee tekens minder :p
> > Wat betreft de naamgeving van variabelen, dat is CamelCase (http://
> > nl.wikipedia.org/wiki/CamelCase).
> > Voor de volledige code (broncode of Greasemonkey / Userscript) is dat
> > misschien wel gewenst.
> > Maar een compacte versie, daar zijn minder tekens toch meer gewenst?
> > In jouw voorbeeldscript zat nog een fout, deze is gecorrigeerd:http://ttdev.pastebin.com/m68ded530
> > On 19 feb, 22:27, Zalastra <maarten.bons...@gmail.com> wrote:
> > > Dat lijkt mij sowieso nogal een must ;) Ik stel trouwens voor om dit
> > > richtlijnen te noemen ipv standaarden en dat er uitleg en code
> > > snippets bij komen te staan ter uitleg en verduidelijking voor degenen
> > > die nog niet zo bekend zijn met javascript. De reden dat ik denk dat
> > > richtlijnen beter zijn is omdat javascript een erg dynamische taal is
> > > waarin je op veel verschillende manieren kan programmeren.
> > > Suggesties voor andere richtlijnen:
> > > - Gebruik 1 var statement in een functie en zet deze in het begin
> > > neer. Dit is overzichtelijker omdat je duidelijk alle gedeclareerde
> > > variabelen in die scope bij elkaar hebt en er een duidelijke scheiding
> > > is tussen het declareren van de variabelen en de logica. Dit is
> > > bovendien ook hoe het intern in de javascript interpreter werkt. Je
> > > kan de verschillende variabelen met komma's scheiden en als je ze in
> > > het begin ook meteen wilt initialiseren kan dat ook.
> > > - Declareer functies op dezelfde manier als je andere variabelen
> > > declareert:
> > > var doSomething = function() { /* code */ };
> > > in plaats van:
> > > function doSomething() { /* code */ }
> > > De enige reden dat ik kan bedenken dat de tweede vorm bestaat is om de
> > > eventuele overstap van een andere programmeertaal makkelijker te
> > > maken. Het is echter zo dat variabelen geen vast type hebben, je kan
> > > prima opeens een string in de doSomething variabele stoppen. De tweede
> > > schrijfwijze suggereert anders (naar mijn mening) en raad ik daarom
> > > iig af. (ik weet het, in m'n farmscript staat het nog wel zo :p gaat
> > > veranderd worden ^^)
> > > - Alhoewel je dus wel van alles in elke variabele kan gooien is het
> > > vaak toch wel wenselijk functies en data te onderscheiden. En functies
> > > kan je dan nog weer opdelen in normale functies en constructor
> > > functies.
> > > * data variabelen (alles wat geen functie is in principe) schrijf je
> > > volledig in kleine letters en de woorden zijn gescheiden door een
> > > underscore _
> > > * 'normale' functies schrijf je de woorden aan elkaar en begint elk
> > > woord na het eerste met een hoofdletter
> > > * constructor functies schrijf je hetzelfde als normale functies
> > > alleen begint ook het eerste woord met een hoofdletter
> > > - Zorg ervoor dat je variabelen duidelijke namen geeft. Als je dan
> > > verder wilt werken aan script wat je een half jaar geleden gemaakt
> > > hebt kan je weer snel begrijpen hoe het precies in elkaar zit. Zorg
> > > ook voor commentaar in je code om dezelfde reden. En niet alleen voor
> > > jezelf is het handig, ook voor anderen die je eventueel helpen of
> > > gewoon op je script voortbouwen kunnen het dan ook makkelijk
> > > begrijpen. Ook spaties, en witregels zorgen voor een goede
> > > leesbaarheid van de code. Eventuele zorgen die je hebt over de grote
> > > van je script komen pas aan de orde als je je script af en werkend
> > > hebt. Die kan je in het packer script stoppen dat ervoor zorgt dat je
> > > code een heel stuk minder ruimte in beslag neemt.
> > > - Meer een tip dan een richtlijn, gebruik jslint.com geweldige analyse
> > > tool die je duid op fouten en/of eventuele problemen in je script. (ik
> > > zal em ff aan de hulpmiddelen pagina toevoegen)
> > > Deze richtlijnen nemend zou een script er zo ongeveer uit zien:http://ttdev.pastebin.com/f33e5956e
> > > On 19 feb, 08:49, Lekensteyn <uwre...@gmail.com> wrote:
> > > > Is iedereen akkoord met het bovenstaande?
> > > > "Het script moet 'niet vervuilend' zijn, d.w.z., het mag de globale
> > > > scope niet vervuilen met variabelen als 'x' (gebruik var keyword)"
