[Alg] Naamgeving

[Verwijderd]

Javascript werkt vaak nauw samen met HTML documenten. Denk hieraan als je in HTML een bepaald element een naam geeft, waarmee je het via een script wilt kunnen benaderen. Geef HTML elementen dus geen onverstandige namen als "submit", "parent" en "document". Ook zijn er in Javascript gereserveerde woorden die je in Javascript niet kunt gebruiken als namen van variabelen, functies, properties en methoden. Gebruik deze ook niet als namen voor HTML elementen, tenzij je precies weet wat je doet.

Eén reden voor deze restricties op naamgeving, is dat sommige browsers het toestaan om bijvoorbeeld HTML elementen direct bij hun naam aan te spreken. Doe dit nooit. Het is echter onmogelijk om die browsers te vertellen dat je helemaal niet wilt dat die HTML elementen een referentie naar een 'globaal' object met die naam krijgen. Daarom is het belangrijk om zelf nooit onverstandige namen te gebruiken.

Als je zelf ergens een naam aan geeft, of dat nu een HTML element is, of een Javascript variabele of functie, zorg dan dat de naam aan vrij algemene conventies voldoet. Namen van variabelen beginnen altijd met een letter of een underscore, eventueel gevolgd door één of meer letters, cijfers of underscores.

JavaScript:

// goed
   MyObject   
   someFunction   
   md5   
   CONSTANT_VALUE   
   some_other_var   
   _localVar   

// fout
   1stVar   
   my-function   
   class   

In Javascript is het ook toegestaan om het dollarteken te gebruiken in namen van variabelen. Dit is echter ongebruikelijk, en kun je beter ook niet doen als je bijvoorbeeld HTML pagina's met Javascript zou laten genereren door een PHP script. In CSS is het gebruik van een liggend streepje in de naam wél toegestaan.

Spreek HTML elementen altijd aan via de beschikbare arrays als forms, elements, links, anchors en options, of via DOM methoden. Dit is iets langer dan het direct gebruiken van de naam, maar het voorkomt problemen. Er is elke week wel een topic waarin de 'korte notatie' de oorzaak is van het probleem. PHP heeft bijvoorbeeld een specifieke wijze om waarden uit een HTML formulier in een array te krijgen. Hiertoe moeten de namen van de HTML formulier elementen eindigen met twee vierkante haakjes: []. Deze hebben echter ook een betekenis in Javascript. Het is toch mogelijk om deze haakjes te gebruiken in een naam, zie de voorbeelden hieronder:

JavaScript:

// goed
   document.forms['myForm'].elements['myTextField'].value = 'leeg';   
   parent.frames['menuFrame'].someFunction(13);   
   document.getElementById('example').style.display = 'none';   
   document.links['myLink' + a].href = 'http://www.tweakers.net';   
   document.forms[0].elements['myFiles[' + 1 + ']'].disabled = true;   

// fout
   myForm.myTextField.value = 'leeg';   
   parent.menuFrame.someFunction(13);   
   document.links.myLink+a.href = 'http://www.tweakers.net';   
   document.forms['myForm'].myTextField[].disabled = true;   

Ik wil wel even duidelijk maken dat niet alles wat afgeraden wordt ook verboden of onmogelijk is. Met de 'lange notatie' kun je heel vreemde namen gebruiken, het zal in de meeste gevallen nog werken ook! Maar dat wil natuurlijk niet zeggen dat het ook verstandig is. Gebruik alleen dergelijke namen als dat nodig is, én als je weet wat je doet.

Het kan ook helpen om je aan bepaalde naming conventions te houden. Nu mag je uiteraard je eigen manier bedenken, maar ook dan geldt: wees consequent! Zorg dat je zelf precies weet wat iets betekent. Een voorbeeld van hoe ik het zelf over het algemeen doe:

• Alle variabelen, properties, methoden, functies en instanties van objecten beginnen met een kleine letter. Als het een samengevoegde woorden zijn, dan krijgt ieder volgwoord een hoofdletter.
• Objects/Classes beginnen met een hoofdletter, verder gelijk aan bovenstaande regel.
• Constanten hebben alleen maar hoofdletters, bij samengevoegde woorden komt er een underscore als scheidingsteken tussen.

Dit topic is bedoeld als hulpmiddel, om bijvoorbeeld naar te verwijzen bij een bepaald probleem die te maken heeft met naamgeving. Uiteraard zijn aanvullingen en discussies van harte welkom.

[ Voor 13% gewijzigd door Verwijderd op 24-04-2003 21:38 ]

[oh,when?]

Verwijderd schreef op 24 April 2003 @ 20:32:
In Javascript is het ook toegestaan om het dollarteken te gebruiken in namen van variabelen. Dit is echter ongebruikelijk, en kun je beter ook niet doen als je bijvoorbeeld HTML pagina's met Javascript zou laten genereren door een PHP script. In CSS is het gebruik van een liggend streepje in de naam wél toegestaan.

[..]

Uiteraard zijn aanvullingen en discussies van harte welkom.

mooie post. Graag wil ik toch even inhaken op het volgende:

Het gebruik van dollartekens in Javascript om zogenaamde private/public methods en vars te emuleren is helemaal niet zo ongebruikelijk en stiekem al best wel ingeburgerd. Het probleem met het laten genereren van dit teken via PHP vind ik dan een beetje raar, het blijft tenslotte een ASCII teken. Dat PHP dit nu toevallig ook als variable gebruikt, maakt niet uit.

In CSS is een liggend streepje juist NIET toegestaan, in de CSS1 specificaties is aangegeven dat een underscore in een naam ge'escaped moet worden met een forward slash! In CSS2 is dit niet veranderd en alleen in een later toegevoegde errata zijn ze hier op teruggekomen. Desalniettemin willen browsers een liggend streepje in class en ID namen vaak nogal raar interpreteren.

Bovenstaande was me ook niet opgevallen totdat ik een paar weken geleden tegen een hardnekkig probleem aan ben gelopen waar dit dus de oorzaak van was.

Gewoon ter aanvulling, nice work Cheatah.

[Clay]

idd erg handig

Wat ook een practisch weetje is;
properties van objecten kan je altijd aanspreken als (op string index) array waarde van het moederobject. alert() is een functie van het window, maar dus ook een property die aan te roepen is als:

JavaScript:

window['alert']('fiets!');

Raar voorbeeld misschien, maar het geeft denk ik des te duidelijker aan wat het inhoudt

[LauPro]

Ik ben zelf van mening dat je de eindgebruiker niet met dingen moet opzadelen waar zij niks aan hebben. Dus de naamgeving is niet belangrijk voor de eindgebruiker, maar wél belangrijk tijdens het programmeren en voor je eventuele collega's. En imo moet je namen dus ook niet lange gaan maken dan nodig. Als het een script betreft dat niet terug te vinden is in een url dan zou ik dat proberen te optimaliseren dmv het gebruik van var1, var2 etc of nog beter v1, v2 etc. Dit is uitsluitend bedoeld voor pagina's die gepubliceerd worden nogmaals.

Waar ik het zelf overigens niet in kan vinden is om met 'sommige browsers' meer dan 90% te bedoelen.

[Clay]

Als het goed is heeft de eindgebruiker inderdaad niets te maken met code, sterker nog, met een beetje mazzel krijgt hij/zij het nooit te zien, dus van opzadelen is denk geen sprake. Om dan met die gebruiker in het oog de conventie van je code te bepalen vind ik een vreemde denkwijze.

En als de gebruiker de code ziet zal die hem meestal niet snappen of het interesseert hem of haar niet. Dus of je dan je variabele "v1" noemt, of "beamMeUpScotty" maakt dan ook niet uit. Te lang is inderdaad fout, maar een duidelijke naamgeving kan eigenlijk altijd met een paar korte termen aan elkaar.

[oh,when?]

LauPro schreef op 24 April 2003 @ 21:17 een onnodig verhaal over eindgebruikers:.

waar zie jij de link naar de eindgebruiker? volgens mij gaat het hier over de ontwikkelaars en is het een topic voor tips over naming conventies tijdens het ontwikkelen...je verhaal komt een beetje uit de lucht gegrepen?

[crisp]

Clay schreef op 24 April 2003 @ 20:54:
idd erg handig

Wat ook een practisch weetje is;
properties van objecten kan je altijd aanspreken als (op string index) array waarde van het moederobject. alert() is een functie van het window, maar dus ook een property die aan te roepen is als:
[...]

een extreem goed voorbeeld daarvan is het stukje wat ik vanmiddag hier postte:

JavaScript:

var ar_boe = new Array();

check_ar('boe');

check_ar('bla');

function check_ar(name) {

  alert(typeof(window['ar_'+name]));

}

Puur de wetenschap dat global variabelen op te vragen zijn als property van het window object maakten dat ik hier geen 10 seconden over heb hoeven nadenken

oh,when? schreef op 24 April 2003 @ 20:46:
[...]
mooie post. Graag wil ik toch even inhaken op het volgende:

Het gebruik van dollartekens in Javascript om zogenaamde private/public methods en vars te emuleren is helemaal niet zo ongebruikelijk en stiekem al best wel ingeburgerd. Het probleem met het laten genereren van dit teken via PHP vind ik dan een beetje raar, het blijft tenslotte een ASCII teken. Dat PHP dit nu toevallig ook als variable gebruikt, maakt niet uit.
[...]

Een goed gebruik van single en double quotes in PHP voorkomt al een hoop ellende. Ik hou variabelen altijd buiten strings, en gebruik enkele quotes voor de strings zelf. Het echo-en van een dollarteken is dan ook geen enkel probleem:

PHP:

echo 'var $eenString = '.$eenString.';';

Cheatah:

Een goed stuk waarin je inderdaad een aantal pitfalls voor beginnende scripters goed uiteenzet. Ik denk dat het voor veel mensen een hoop duidelijk maakt

[ Voor 6% gewijzigd door crisp op 24-04-2003 22:13 ]

[Verwijderd]

Gebruik var:

var a =
var b =
var c =

Is overigens voor je collega's ook erg handig. Die weten naderhand tussen de bomen het bos niet meer te vinden in je code

[GrimaceODespair]

Misschien nog iets over notatie. Smaken verschillen, dat is duidelijk, maar ik zal even uitleggen waarom ik erop in ga.

Hongaarse notatie
Ik kom uit een C++ achtergrond, en daarin tiert de (wel eens verguisde) Hongaarse notatie welig. De variabelenaam wordt dan geprefixt met een type-afkorting, zoals in:

C++:

int nMyNumber = 0;
string strMyString = "";
int MyFunction() {};

mixedCase / camelCase
Ik heb mij echter nooit ergens zo in verdiept als in C++, waardoor ik bij het schrijven van PHP, Java, JavaScript of ActionScript eigenlijk niet goed in de gaten heb gehouden wat het meest gangbaar is qua notatie. Nu ja, bij Java en JavaScript vermoed ik dat het eigenlijk de hierboven beschreven methode is (naam blijkt dus camelCase te zijn, tnx Crisp ):

Java:

int myNumber = 0;
String myString = "";
int myFunction() {};

JavaScript:

var myNumber = 0;
var myString = "";
int myFunction() {}

Underscores
Voor PHP wordt ipv de hoofdletter een underscore als scheidingsteken gebruikt:

PHP:

$my_number = 0;
$my_string = "";
function my_function() {};

ActionScript
Om nu te voorkomen dat dit naar P&W geschopt wordt , zal ik dan nu maar to the point komen. Ik hield vroeger de Java-notatie aan voor mijn Flash ActionScripts. Toen kwam echter MX met zijn code completion, en die ging uit van nog een andere notatie:

Flash ActionScript:

var my_number = 0; // geen suffix gedefinieerd voor integers
var my_string_str = "";
function my_function() {} // geen suffix gedefinieerd voor functies

Het suffix wordt door de Flash IDE gebruikt als herkenningspatroon voor het variabeletype. Dat is op zich eigenlijk een beetje krom, maar soms toch wel een handige oplossing om in een weakly typed language aan (gesimuleerde) code completion te doen.

Waar ik eigenlijk naar toe wilde
Nu vroeg ik mij dus af of deze notatie onder AS-ers echt gangbaar is, want standaard kan je hem volgens mij bezwaarlijk noemen. Daarbij komt nog dat, als je graag IDE's tweakt, je de ASCodeHints.xml van Flash kan ombouwen om Hongaarse notatie te herkennen.

[ Voor 4% gewijzigd door GrimaceODespair op 25-04-2003 01:11 ]

[crisp]

GrimaceODespair schreef op 25 April 2003 @ 00:48:
Mixed case
[...]

Dat heet volgens mij CamelCased, een notatievorm die ik zelf ook vaak gebruik. Al naar gelang mijn bui neig ik echter ook wel eens naar underscore notatie.
Hungarian vind ik persoonlijk lelijk (puur gevoelsmatig); ik weet meestal zelf wel of een var int of string is (en in een weaktyped language kan een var het ene moment het ene zijn, en het andere moment het andere hoewel ik dat vat onder sloppy coding), maar ik zie hier wel voordelen in als je devved in teamverband (iets wat ik dus niet graag doe trouwens).

[GrimaceODespair]

crisp schreef op 25 april 2003 @ 00:56:
Hungarian vind ik persoonlijk lelijk (puur gevoelsmatig)

Laat dat gevoelsmatig maar weg. Google geeft je gelijk.

[drm]

Wat naamgeving betreft gebeuren er vaak rare dingen in de hoofden van programmeurs en scripters Zo ook in de mijne...

Ik heb laatst besloten om alleen class-members camelCased te schrijven, en alle 'globale' of 'gewone' functies en globale/lokale variabelen met underscores naam_te_geven. Heel achterlijk, slaat nergens op, maar zolang je het consequent volhoudt is het toch altijd beter te lezen voor de ander.

oh,when? > Wat Cheatah bedoelde met liggend streepje was niet de underscore maar de hyphen, of dash (kortom: het-"min"-teken of koppelteken ) welke ik persoonlijk in CSS juist erg mooi vind, en welke dus wel gewoon werkt itt de underscore

Escapen met een forward slash is overigens nieuw voor mij in CSS Na even testen bleek mijn vermoeden bevestigd, en ga ik er vanuit dat jij ook de backslash bedoelde

[Verwijderd]

op zich maakt het niet zo heel veel uit wat je doet, zolang je maar conventies maakt die voor je medeprogrammeurs duidelijk zijn. In databases is het ook gebruikelijk om hoofdtabellen een prefix M_ te geven, en kruistabellen een L_ bijvoorbeeld. Of hier verder regeltjes voor zijn, geen idee, maar op mijn werk hebben we besloten tabelnamen geprefixed en met een hoofdletter te schrijven: M_EenTabel en velden daarin startend met de tabelnaam en camelCased: eenTabelVeld1, eenTabelVeld2 etc

objecten binnen js start ik met een T en een hoofdletter: TClassName (overgehouden uit een delphi achtergrond), variabelen camelCased: eenVar. Omdat ik werk aan een UI waarbij mensen (een selectie van) properties van objecten getoont moeten krijgen, heb ik geroepen dat properties beginnend met een underscore "private" zijn en dus niet getoont worden ("_privateVar"; "publicVar")

in dit kader vroeg ik me af wat oh when bedoelt met het emuleren van private en public vars in js (met dat dollarteken, is dat een beetje wat ik hier doe? dan ga ik effe m'n underscores vervangen door dollars )

en verder wat variabelen betreft uit de wiskunde komt het "gevoel" dat x,y,z erg variabel zijn, a,b,c erg constant, i,j,k,l etc tellertjes en meer van dat soort dingen (griekse letters voor hoeken bv)

liefst gebruik ik beschrijvende namen voor variabelen, doch niet te lang. Korte namen als i,j enzo gebruik ik alleen voor tellertjes, n,m voor kortgebruikte integers en s,t voor kort gebruikte strings (die bijna nooit voorkomen, maar bijvoorbeeld in een een of andere string replace functie)

[Clay]

in dit kader vroeg ik me af wat oh when bedoelt met het emuleren van private en public vars in js (met dat dollarteken, is dat een beetje wat ik hier doe? dan ga ik effe m'n underscores vervangen door dollars )

Ik heb laatst ook ff zitten stoeien met private public en static in js, en heb het er ook ff met oh,when? over gehad. Het "probleem" van ecma is dat je niet direct zoals in java een classe variabele private of public can declareren.

JavaScript:

function Ding() {
   this.type = 'ding';
}

var ding = new Ding();

ding.type is nu public. Ik zou het overal vandaan kunnen opvragen, aanpassen en/of weghalen als ik zou willen, en dat geldt ook bijvoorbeeld voor functies die met this.functieNaam of prototyping zijn gekoppeld. Maar door van een scope 'truuk' (eigenlijk geen truuk, maar het principe is niet al te bekend) gebruik te maken kan je een object wel "read only" properties geven die dus niet aan te passen zijn:

JavaScript:

function Ding() {
   var readOnly = {
      dinges:'fiets',
      naam:'harry'
   }

   this.getProperty = function(name) {
      // deze funcie kent bovenstaande readOnly var!
      return readOnly[name];
   }
}

var ding = new Ding();
alert(ding.getProperty('dinges'));

private en public bestaat dus wel, maar meer indirect. die getProperty function heet dan "privileged", omdat die toegang heeft tot de "private" (eigenlijk gewoon local) var binnen Ding.

$ tekens en _'s gebruik ik zelf eigenlijk nooit, behalve _'s voor constanten. Het enige waar ik $ tekens wel voor gebruik is het aanpassen van fundamentele object eigenschappen van script zelf, bijvoorbeeld als Function.apply niet bestaat. Dan moet ik properties aan Function koppelen, en met een $ ben je er iig zeker van dat je dan geen enkele andere property in de weg zit.

[ Voor 13% gewijzigd door Clay op 25-04-2003 09:23 ]

[GrimaceODespair]

Clay schreef op 25 april 2003 @ 09:20:
[...]

JavaScript:

function Ding() {
   var readOnly = {
      dinges:'fiets',
      naam:'harry'
   }

   this.getProperty = function(name) {
      // deze funcie kent bovenstaande readOnly var!
      return readOnly[name];
   }
}

var ding = new Ding();
alert(ding.getProperty('dinges'));

private en public bestaat dus wel, maar meer indirect. die getProperty function heet dan "privileged", omdat die toegang heeft tot de "private" (eigenlijk gewoon local) var binnen Ding.

De programmeur in mij zegt dat ie dit maar een irritant lapmiddel vindt. Het aanspreken van variabelen wordt op deze manier omslachtiger en geeft meer overhead, zowel in code als in CPU power (hoewel dat laatste natuurlijk maar minimaal hoeft te zijn). Je gebruikt nu een functie (getProperty) om die variabele uit te lezen, maar dan kan je dus net zo goed accessor methodes gebruiken.

Waarom wil je immers getProperty gebruiken? Om private en public variabelen te simuleren. Maar in het geval van getProperty moet je dus alsnog zelf weten welke variabelen public en welke private zijn. Het enige voordeel is dat je niet per ongeluk een private variabele kan overschrijven, maar either way: je script loopt fout, of je'm nu overschrijft of niet.

En omdat je dus toch moet weten welke variabelen private en public zijn, kan je dus evengoed met accessor methodes werken (gemakkelijker en minder overhead) en zorgen dat je softwaremodel goed zit.

[Verwijderd]

Clay schreef op 25 April 2003 @ 09:20:
[...]
leuk trucje

Da's een aardig trucje, had ik laatst ook mee lopen stoeien nav jullie topique daarover, maar dit is niet echt wat ik bedoelde en volgens mij ook niet waar oh when? het over heeft. Ik vroeg me meer af of dat trucje wat ik toepaste (eigenlijk dus de eigenschap of een variabele gepubliceerd wordt aangeven met de naam van de variabelen) vaker gebruikt wordt en zo ja of er conventies voor zijn.

Eigenlijk zijn get geen private vars maar zijn ze niet published.

(http://www.rikkertkoppes.com/neptune/objtest.htm da's wat ik ermee wou bereiken, een extra eigenschap meegeven aan variabelen dus)

[Clay]

GrimaceODespair
De programmeur in mij zegt dat ie dit maar een irritant lapmiddel vindt. Het aanspreken van variabelen wordt op deze manier omslachtiger en geeft meer overhead, zowel in code als in CPU power (hoewel dat laatste natuurlijk maar minimaal hoeft te zijn). Je gebruikt nu een functie (getProperty) om die variabele uit te lezen, maar dan kan je dus net zo goed accessor methodes gebruiken.

Nee erg mooi is het niet Ik gebruik het ook niet actief, maar het is een voorbeeld van hoe de scope in js/as je toestaat dit soort "private" variabelen te maken.

Waarom wil je immers getProperty gebruiken? Om private en public variabelen te simuleren. Maar in het geval van getProperty moet je dus alsnog zelf weten welke variabelen public en welke private zijn. Het enige voordeel is dat je niet per ongeluk een private variabele kan overschrijven, maar either way: je script loopt fout, of je'm nu overschrijft of niet.

Volgens mij moet je in je code altijd zelf weten (of je code laten weten) welke variabelen private of public zijn en waarvandaan je ze aanroept. Het voordeel wat je noemt is dan ook juist de reden waarom je dit ooit (zo of in een andere vorm) zou willen toepassen. Om te voorkomen dat je per ongluk (maar zeker zo belangrijk: met opzet) variabelen overschrijft. Denk bijvoorbeeld aan games & cheaten.

[2]

GrimaceODespair schreef op 25 april 2003 @ 00:48:
Voor PHP wordt ipv de hoofdletter een underscore als scheidingsteken gebruikt:

Je stelt het als een absolute waarheid hier, maar in PHP kun je net zo goed camelcase gebruiken hoor, wordt ook vaak genoeg gedaan.

[RSP]

Naamgeving hou ik altijd wel overzichtelijk en consequent. daarnaast mag ook wel aandacht gegeven worden aan de letterlijke naamgeving, dit gaat meer over de conventies van de namen... ik bedoel stel we hebben functie checkformulier. dan is het belangrijk dat het wordt geschreven als checkFormulier of CheckFormulier (liever de eerste) maar wat sommige mensen ook presteren is ckhform of chkForm nou valt het bij deze naam nog wel te overzien maar soms is het echt zoeken naar de werkelijkenaam.

btw, naamgeving komt ook naar voren bij versie beheer. wat vinden jullie?

Project versie X.zip
project_versie_x.zip
asdf.zip (het boeit je dus niet)
Project - datum - versie.zip
Project_datum_versie.zip

natuurlijk zijn hier ook veel meer varianten op te bedenken maar ik zou wel graag horen wat jullie hiervoor gebruiken

[Bosmonster]

2 schreef op 25 April 2003 @ 15:31:
[...]
Je stelt het als een absolute waarheid hier, maar in PHP kun je net zo goed camelcase gebruiken hoor, wordt ook vaak genoeg gedaan.

Nadeel hierbij is dat alle standaard PHP-functies wel de underscore gebruiken en je dan 2 stijlen door elkaar moet combineren, wat nogal een zooitje wordt.

[2]

Bosmonster schreef op 25 April 2003 @ 15:42:Nadeel hierbij is dat alle standaard PHP-functies wel de underscore gebruiken en je dan 2 stijlen door elkaar moet combineren, wat nogal een zooitje wordt.

Goed punt. Maar het màg wel.

[disjfa]

HTML:

document.links...

gebruik ik zelf liever niet ik behoud graag de uniformheid van de coden en als ik dan een link aan wil spreken gebruik ik liever

HTML:

document.getElementByTagNames("a")

of k roep m aan via t id wat ik m meegeef

dat houd t imho weer wat overzichtelijker en dat was mijn mededeling van vandaag

[Verwijderd]

Overigens heb je ook nog de volgende naamgeving:

code:

FunctionWithoutACoolName ( iInputVariable, out oOutputVariable );

Het gaat hier dus om de i van input en o van output; wordt vaak gebruikt bij
COM interface e.d.

[oh,when?]

RSP schreef op 25 April 2003 @ 15:38:
btw, naamgeving komt ook naar voren bij versie beheer. wat vinden jullie?

[...]

natuurlijk zijn hier ook veel meer varianten op te bedenken maar ik zou wel graag horen wat jullie hiervoor gebruiken

gewoon... CVS, maak gewoon verschillende branches aan, en per delivery maak je een release aan...makkelijk zat.

Beetje gek om versiebeheer via filenames te gaan doen...

[drm]

Bosmonster:
Nadeel hierbij is dat alle standaard PHP-functies wel de underscore gebruiken en je dan 2 stijlen door elkaar moet combineren, wat nogal een zooitje wordt.

Dat is overigens ook een reden dat ik vaak member-functions camelCased schrijf en globale functies met_underscores

[Annie]

Bosmonster schreef op 25 april 2003 @ 15:42:
[...]


Nadeel hierbij is dat alle standaard PHP-functies wel de underscore gebruiken en je dan 2 stijlen door elkaar moet combineren, wat nogal een zooitje wordt.

Haha, alsof de devvers van PHP zich aan naamconventies houden (ze zullen ze ongetwijfeld hebben, maar houden aan blijkt wat moeilijker in de praktijk).

Overigens ben je er dan wel meteen zeker van dat je niet "in de knoei" komt met reeds bestaande functienamen.

[drm]

Annie:
Haha, alsof de devvers van PHP zich aan naamconventies houden (ze zullen ze ongetwijfeld hebben, maar houden aan blijkt wat moeilijker in de praktijk).

Hej!

Of bedoel je juist degene die PHP ontwikkelen? Een van de raarste vind ik nog steeds 2 functies: opendir() en fopen()

Overigens ben je er dan wel meteen zeker van dat je niet "in de knoei" komt met reeds bestaande functienamen.

Da's waar

Overigens bedacht ik me nog dat je in camelcased benamingen afkortingen eigenlijk als "woorden" moet zien:

Fout:

code:

HTMLElement

goed:

code:

HtmlElement

leest, maar tikt ook vooral, veel fijner
[/offtopic]