Namen van variabelen en tabellen *

[g4wx3]

Bij het programmeren twijfel ik altijd over de naamgeving van variabelen, functies, classes en tabellen.
ik programeer in php, dus voorvoegsels zoals i, o, s, a zijn overbodig. Maar ik twijfel eraan om wel t voor mijn tabelnamen te zetten.

Jullie snappen het al, ik heb nooit iets geleerd van naamgeving, kunnen jullie me op weg helpen, want ik verlies hier ontzettend veel tijd mee. En hou zit het met hoofdletters, en underscore gebruik? ClassNamen zet ik in fullcaps, al de rest in lowercase, en underscores indien toepasselijk.

Zelf vind ik php op dat gebied trouwens ook nogal slordig - alleszinds niet 100% consequent - de meeste functies zijn met underscore, sommige echter niet.


Dus ik kom jullie vragen naar jullie methode en hopelijk zal ik dan in de toekomst minder problemen hebben.

[daniëlpunt]

Het is een persoonlijk iets. Tenzij je samen moet werken in een team, dan overleg je dat soort dingen.
Dus gewoon wat jij het prettigst vindt.

[Face_-_LeSS]

In php is zo'n voorvoegsel toch juist niet overbodig want php is lose-typed. Dus in een bepaalde variabele kan van alles zitten. Zo'n voorvoegsel maakt het juist duidelijker!

[Cyphax]

g4wx3 schreef op woensdag 03 december 2008 @ 12:14:
Bij het programmeren twijfel ik altijd over de naamgeving van variabelen, functies, classes en tabellen.
ik programeer in php, dus voorvoegsels zoals i, o, s, a zijn overbodig. Maar ik twijfel eraan om wel t voor mijn tabelnamen te zetten.

Het kan handig zijn om tabelnamen te prefixen als je ook views hebt. Alternatief is "view" in de naam verwerken. Ik prefix tabellen altijd met "tbl" eigenlijk. Dan kan daar geen verwarring over ontstaan.

Jullie snappen het al, ik heb nooit iets geleerd van naamgeving, kunnen jullie me op weg helpen, want ik verlies hier ontzettend veel tijd mee. En hou zit het met hoofdletters, en underscore gebruik? ClassNamen zet ik in fullcaps, al de rest in lowercase, en underscores indien toepasselijk.

Je moet eigenlijk zelf weten HOE je dit allemaal doet. De belangrijkste tip lijkt me: wees consistent. Als je camelcasing wilt gebruiken (zoals je nu doet met je klassenamen), doe het dan overal op dezelfde manier.

Als je een voorbeeld wilt hebben van conventies: http://msdn.microsoft.com/en-us/library/ms229045.aspx

Oh en maak voor jezelf een documentje waar je in zet hoe je naamgevingen doet.

Zelf vind ik php op dat gebied trouwens ook nogal slordig - alleszinds niet 100% consequent - de meeste functies zijn met underscore, sommige echter niet.

PHP is inderdaad een puinzooi op dat gebied, als je geen framework eromheen gebruikt.

Face_-_LeSS schreef op woensdag 03 december 2008 @ 12:20:
In php is zo'n voorvoegsel toch juist niet overbodig want php is lose-typed. Dus in een bepaalde variabele kan van alles zitten. Zo'n voorvoegsel maakt het juist duidelijker!

Bij zo'n loose-typed taal kan een variabele het ene moment een integer bevatten en het andere moment een string of een boolean. Daar zit je dan met je "iGetal".
Je kunt beter de naamgeving van je variabele gewoon in 1 keer goed doen. Die hongaarse notatie is lelijk

[ Voor 15% gewijzigd door Cyphax op 03-12-2008 12:24 ]

[YopY]

Face_-_LeSS schreef op woensdag 03 december 2008 @ 12:20:
In php is zo'n voorvoegsel toch juist niet overbodig want php is lose-typed. Dus in een bepaalde variabele kan van alles zitten. Zo'n voorvoegsel maakt het juist duidelijker!

Waarom zou je $iNogwat dan gebruiken als er ook een string, object, array, float of etc in kan zitten? Als je jezelf wilt limiteren om allen integers in variabelen die een 'i'-prefix hebben te zetten, kun je beter gewoon overschakelen naar een normale typed taal.

@topic, voor PHP zijn er door verschillende instanties wel naamgevingsregels opgesteld, misschien zou je daar eens naar kunnen zoeken.

[Verwijderd]

YopY schreef op woensdag 03 december 2008 @ 15:47:
[...]


Waarom zou je $iNogwat dan gebruiken als er ook een string, object, array, float of etc in kan zitten? Als je jezelf wilt limiteren om allen integers in variabelen die een 'i'-prefix hebben te zetten, kun je beter gewoon overschakelen naar een normale typed taal.

Dat is natuurlijk geen argument, C# of Java , ... is niet altijd voor handen en omdat je aan type juggling kan doen betekent dat niet dat je dat moet doen, het lijkt me alleen maar irritant eigenlijk. Overigens ben ik zelf ook geen voorstander van Hungrian oid.

Qua naamgeving, geef variabelen enzovoorts gewoon duidelijk beschrijvende namen, het heeft totaal geen zin om met arbitraire afkortingen te gaan werken, het schept uiteindelijk alleen maar onduidelijkheid en zeg nou zelf is
$aantalKamers niet net zo duidelijk, zo niet duidelijker, dan $iKamers?

Wat betreft tabelnamen, als ik een tabel met klanten zou hebben noem ik deze, wonder boven wonder, gewoon klanten of klant.

[Cartman!]

Gewoon 1 keer vastleggen hoe en wat je met naamgeving doet. Wij hebben als regel hier dat we camelcasen en prefixen bij variabelen (in PHP ja) en dat werkt echt goed, als iedereen zich daar ook strict aan houd kun je ook ervan uit gaan dat $intRoomCount het aantal kamers heeft. Alles een naam geven met duidelijke beschrijving en prefixen, kan niet missen. Overigens alles in het engels (incl. comments) om verwarring te voorkomen later (evt. buitenlandse collegas).

[Cyphax]

Verwijderd schreef op woensdag 03 december 2008 @ 15:57:
zeg nou zelf is
$aantalKamers niet net zo duidelijk, zo niet duidelijker, dan $iKamers?

Nee. $aantalKamers is zelfs duidelijker.
Aantal betekent niet alleen dat het een numerieke waarde gaat zijn maar ook wat dat nummer betekent.

[Verwijderd]

Cyphax schreef op woensdag 03 december 2008 @ 16:06:
[...]

Nee. $aantalKamers is zelfs duidelijker.
Aantal betekent niet alleen dat het een numerieke waarde gaat zijn maar ook wat dat nummer betekent.

Dat zeg ik toch

[BalusC]

Verwijderd schreef op woensdag 03 december 2008 @ 15:57:
Wat betreft tabelnamen, als ik een tabel met klanten zou hebben noem ik deze, wonder boven wonder, gewoon klanten of klant.

Toch ben ik benieuwd: wanneer meervoud en wanneer enkelvoud?

Ikzelf ben meer geneigd om de meervoudsvorm te gebruiken als tabelnaam.

[Verwijderd]

Ik gebruik persoonlijk enkelvoud, er zit records van het type klant in, grof gezegd.
Natuurlijk valt er voor meervoud ook wat te zeggen, want er zitten, waarschijnlijk, meerdere klanten in.

[Verwijderd]

Als je echt een precieze definitie wilt hebben kun je eens kijken naar hoe grote pakketten het doen. Zend Framework en veel andere frameworks en projecten hebben een 'style guide' waar mensen die zelf code willen schrijven voor het project zich aan kunnen houden.
Bijvoorbeeld Zend Framework heeft de volgende:
http://framework.zend.com...P+Coding+Standard+(draft)

Overigens je opmerking over de inconsistentie van PHP, dit is idd erg storend, maar ik heb er minder last van (en minder mee te maken) sinds ik Zend Framework gebruik voor mijn projecten, misschien een tip .

[Jaap-Jan]

BalusC schreef op woensdag 03 december 2008 @ 16:14:
[...]

Toch ben ik benieuwd: wanneer meervoud en wanneer enkelvoud?

Ikzelf ben meer geneigd om de meervoudsvorm te gebruiken als tabelnaam.

Ik was geneigd om dat ook te doen, maar ik had bij ODA geleerd dat het good practice is om enkelvoud te doen. Op zich ook wel logisch, als je kijkt hoe je query er uit ziet:

SQL:

select Klant.naam ...

of

SQL:

select Klanten.naam ...

Je wilt van elke klant de naam hebben en niet van meerdere klanten, want die hebben hoogstwaarschijnlijk verschillende namen. Ik geef toe, het is geen sterk argument, maar sindsdien doe ik het wel op die manier.

Voor 'identifiers' (en soms ook de codestijl) gebruik ik het systeem wat het meest gebruikelijk is voor dat platform.

Voor Java betekent dat CamelCasing voor classes, HOOFDLETTERS (en underscores) voor constanten, en ook camelCasing voor variabelen (eerste letter niet met hoofdletters) en de gebruikelijke stijl voor packagenamen.

Voor PHP en C++ zou ik dezelfde stijl gebruiken (afgezien van variabelennamen, die ik met underscores zou doen), want de stijl van Java gewoon duidelijk.

Voor C# en Python zou ik de naamgeving overnemen die gebruikelijk is voor die talen. Python gebruikt korte functienamen en variabelennamen. Hoe C# eruit ziet ga ik maar niet helemaal uitleggen.

Voor class members (variabelen) gebruik ik geen aparte notatie, al zie ik wel mensen die die prefixen met een underscore of m_ (aanbeveling van MS voor C#). Zelf vind ik dat niet prettig en attendeert mijn IDE mij er wel op als een class member wordt verborgen door een lokale variabele. Ook hungarian notation voor welke taal dan ook vind ik persoonlijk niet fijn.

[Cyphax]

Jaap-Jan schreef op woensdag 03 december 2008 @ 18:48:

SQL:

select Klant.naam ...

of

SQL:

select Klanten.naam ...

Je wilt van elke klant de naam hebben en niet van meerdere klanten, want die hebben hoogstwaarschijnlijk verschillende namen.

Je selecteert echter wel meerdere klanten, waarschijnlijk. Als je met Klant.naam een rij bedoelt is enkelvoud logischer, als je de kolom naam bedoelt gaat het in de meeste gevallen om meerdere klanten. 't Is maar net wat je zelf het liefst hebt...

Ik geef toe, het is geen sterk argument, maar sindsdien doe ik het wel op die manier.

En daar gaat het om.
Ik hou zelf trouwens bij tabelnamen ook zoveel mogelijk enkelvoud aan en ook om dezelfde reden zelfs.

[MSalters]

Sowieso is het Customer(s) en geen Klant(en). Ik heb een keer het ongeluk gehad om aan code te werken waar het commentaar in het Frans was. Dat is al erg genoeg, ook al waren de variabelen wel netjes in het Engels. Dat werkt dus ook de andere kant op; geen Fransman kan iets met jouw code op deze manier.

[Cyphax]

Aan de andere kant heb ik van een collega namen van tabellen en variabelen gezien die mij deden wensen dat ie maar Nederlands had gebruikt.

[g4wx3]

Als je een tabel hebt met usernames en passwords, hoe noem je die dan, account/account/s user/users?

Ik noem hem nu account_index, die vanwege het feit dat er nog meer gebruikersgegevens zijn in andere tabellen, en dit de hoofd index is. Maar ook omdat ik alles ivm accounts laat beheren door een module 'account', ik heb de beslissing genomen om de tabelnamen te laten prefixen door de modulenaam

Ook heb ik een module winkel 'store'. Daar horen ook wat tabel namen bij. Nu gebruik ik de volgende structuur
store_index - bevat groepen en producten
store_nodes - (vroeger genaamd store_pedigree) bevat een hyrachie om subgroupen en producten bij bepaalde, of verschillnde groepen te zetten
store_products beschrijving van producten
store_groups (vroeger categories) beschrijving van producten

Ik overweeg nu ook nog afbeelding paths op te nemen in store_index, ofwel moet ik een nieuwe module schrijven, en het meteen degelijke aanpakken, photobook of iets dergelijk? Dan krijg ik tabelnamen als photobook_index

[BCC]

Ik houd tegenwoordig overal de Ruby on Rails standaard aan. Simpel en duidelijk. En alles in het Engels.
Zie http://itsignals.cascadia.com.au/?p=7 en http://www.softiesonrails...by-101-naming-conventions

Vooral de enkelvoud/meervoud standaardisatie is een zegen.

[ Voor 47% gewijzigd door BCC op 03-12-2008 21:51 ]

[compufreak88]

Cyphax schreef op woensdag 03 december 2008 @ 12:21:
[..]
Die hongaarse notatie is lelijk

Als je het op die manier doet wel, maar als je het op de juiste manier doet niet. Komt er op neer dat je niet het type variabele er neer zet, maar meer een soort eenheid.

Een voorbeeld dat werd aangehaald is sId en usId. Beiden postwaarden, maar de ene Save (escaped), en de andere UnSave(nog niks mee gedaan). Dan heeft het ineens een grote meerwaarde.

[Jaap-Jan]

MSalters schreef op woensdag 03 december 2008 @ 20:01:
Sowieso is het Customer(s) en geen Klant(en). Ik heb een keer het ongeluk gehad om aan code te werken waar het commentaar in het Frans was. Dat is al erg genoeg, ook al waren de variabelen wel netjes in het Engels. Dat werkt dus ook de andere kant op; geen Fransman kan iets met jouw code op deze manier.

Mijn vorige voorbeeld zou ook geen productiecode van mij zijn, hoor. Ik doe ook alles in het Engels.

[Remus]

BalusC schreef op woensdag 03 december 2008 @ 16:14:
[...]

Toch ben ik benieuwd: wanneer meervoud en wanneer enkelvoud?

Ikzelf ben meer geneigd om de meervoudsvorm te gebruiken als tabelnaam.

Bij mijn weten wordt in de literatuur over het algemeen de enkelvoudsvorm aangeraden. Een tabel bevat een of meerdere relaties (of records) die een entiteit vormen (bijvoorbeeld klant), vergelijk het maar met klassen: je hebt een klasse Klant en meerdere instanties van de klasse Klant (net als dat je dus een tabel Klant hebt met daarin meerdere records van de entiteit Klant).

[BCC]

Ruby on Rails doet ook tabellen in meervoud. Mijn tabel heet users en elke regel bevat een user. Vind ik persoonlijk erg logisch. Je vergelijking met klassen snijdt volgens mij dus ook geen hout. Een item in de Users tabel is namelijk de data voor een User model. Het is een instantie van de User klasse met behulp van 1 regel data uit de Users tabel.

[ Voor 48% gewijzigd door BCC op 09-12-2008 19:16 ]

[Verwijderd]

Of het geen hout snijdt is net zo subjectief aan je eigen voorkeur als het wel of niet gebruiken van enkelvoud.
1 regel data uit de users tabel = 1 user. Het is maar net wat je zelf fijn vindt werken.

[Remus]

BCC schreef op dinsdag 09 december 2008 @ 19:02:
Ruby on Rails doet ook tabellen in meervoud. Mijn tabel heet users en elke regel bevat een user. Vind ik persoonlijk erg logisch. Je vergelijking met klassen snijdt volgens mij dus ook geen hout. Een item in de Users tabel is namelijk de data voor een User model. Het is een instantie van de User klasse met behulp van 1 regel data uit de Users tabel.

Tja, het is misschien zoals Sintax hieronder zegt gevoelsmatig. Gevoelsmatig ben ik het niet met je eens, maar ook vanuit de relationele theorie, ER-modelling en dergelijke wordt de enkelvoudsvorm aangehangen. Daarnaast snijdt mijn vergelijking met klassen wel degelijk hout: Zowel een tabelschema als een klasse geven een entiteit type weer, en dus is een enkelvoudsvorm op zijn plaats om dat type te benoemen. Individuele tupels/rijen of objecten geven een invulling aan dat entiteit type.

Het verschil tussen onze opvatting is terug te brengen tot dit: ik bepaal de naam aan het entiteit type die door een individuele tupel of rij gerepresenteerd kan worden : dus enkelvoud, jij aan het feit dat een tabel meerdere tupels of rijen van dat entiteit type kan bevatten en benoemt het als verzameling : dus meervoud.

[Verwijderd]

Hoe je je variabelen noemt vind ik meer iets naar je eigen stijl.. Wat doet het ertoe als je alles nu met $i, $y, $p, ... gaat noemen. Oké het is onoverzichtelijk maar dat is jou probleem.

Ikzelf doe het meer zo, bij gewone variabelen gebruik ik bv. $naam, bij een database naam gebruik ik $dbNaam, bij een $_post naam gebruik ik dan weer, $postNaam.. Enzodoor.

Het is gewoon je eigen stijl wat, mijn tip voor jou is gebruik iets waar je later nog alles gemakkelijk kunt herkennen zodat je niet telkens hoeft terug te kijken in je code.

[BCC]

Verwijderd schreef op dinsdag 09 december 2008 @ 21:47:
Oké het is onoverzichtelijk maar dat is jou probleem.

Tja, totdat je met 2 of meer man aan een project werkt. Of het project een support tijd van meer dan 5 jaar heeft. Of een combinatie daarvan.

[ Voor 17% gewijzigd door BCC op 09-12-2008 21:59 ]

[Verwijderd]

BCC schreef op dinsdag 09 december 2008 @ 21:59:
[...]

Tja, totdat je met 2 of meer man aan een project werkt. Of het project een support tijd van meer dan 5 jaar heeft. Of een combinatie daarvan.

Ja, precies, en zelfs als je je eigen code na een paar maanden doorleest heb je spijt dat je niet gewoon voor 'numberOfPimps', 'DeliveryAddress' hebt gekozen. Het is een kleine moeite en je hebt er zoveel profijt van, zelfd gedurende je ontwikkeltraject. Ik zie niet in waarom je jezelf dwars zou moeten zitten met onduidelijk geschreven code

[kenneth]

En iedere zelfrespecterende IDE heeft auto-aanvulling, IntelliSense, enz ...

Houd namen zo kort mogelijk, maar maak ze zo lang als nodig. Je leest code veel vaker dan dat je het schrijft

[Verwijderd]

BCC schreef op dinsdag 09 december 2008 @ 21:59:
[...]

Tja, totdat je met 2 of meer man aan een project werkt. Of het project een support tijd van meer dan 5 jaar heeft. Of een combinatie daarvan.

Daarom dat het nou je eigen probleem is als je onoverzichtelijk werkt.. Als de mensen waarmee je dan samen werkt klagen tegen jou dan ben jij de pineut..

Dat is ook de reden dat ik erbij zet dat het onoverzichtelijk is en dat het je eigen probleem dan is.. Daarom raad ik het ook af.