Archief - [C++] Eisen naam variabele

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

Curahee Q

Legacy Member
In mijn cursus informatica staat

De naam van een variabele moet steeds volgende eisen voldoen
  • Hij begint met een letter
  • Hij bevat uitsluitend hoof-en kleine letters, cijfers en het onderstreepteken '_'
  • Hij bevat geen blanco's

Ik snap alles en vind het ook logisch en weet dit eigenlijk al heel lang. Echter verder in de cursus bij het deel OOP hebben ze dan een constructor waarbij de parameter-variabelen met een '_' beginnen?

Code:
Student(string _naam, int _leeftijd) {
       naam = _naam;
       leeftijd = _leeftijd;
}

Volgens mij lapt hij daar toch regel nummer 1 aan zijn laars. Ook heb ik het gewoon uitgetest met een variabele (omdat ik dacht dat dit mss enkel bij parameters kon) en daar blijkt het ook te werken. Is dit gewoon een regel of is mijn compiler niet strict genoeg?

SharkyXTS

Legacy Member
Underscores zijn toegelaten in C++. Met die code is niks mis me dunkt. Ik hoop voor u trouwens dat je die regeltjes over de naamgeving van een variabele niet vanbuiten leert?

Curahee Q

Legacy Member
Ze zijn inderdaad toegelaten, maar regel 1 zegt dat ze moeten beginnen met een letter.

Leer ze ook ni vanbuiten, ze zijn zo logisch als iets en zoiets vragen ze toch ni. Maar het viel me gewoon op toen ik dit las.

Cycloon

Legacy Member
Ja idd, maar ze bedoelen waarschijnlijk eerder "mag niet met een cijfer beginnen".

Manjak

Legacy Member
Ik wist niet helemaal meer hoe het zat, daarom heb ik het even opgezocht. De reden dat je niet met een '_' mag beginnen is niet omdat het niet zou werken, maar om mogelijk conflict te vermijden.

Identifiers dat met een _ beginnen worden namelijk intern in de std gebruikt. Als je bijvoorbeeld kijkt naar http://www.sgi.com/tech/stl/string zie je dat alles daar begint met '_'

Zo staat er ergens intern in std:: string
Code:
 struct _Not_within_traits

Stel dat jij in je code het volgende doet:
Code:
 int _Not_within_traits;

Ga je errors krijgen, wat vreemd lijkt op het eerste zicht aangezien
Code:
int a;
geen problemen veroorzaakt..

Tyfius

Legacy Member
Manjak zei:
Ik wist niet helemaal meer hoe het zat, daarom heb ik het even opgezocht. De reden dat je niet met een '_' mag beginnen is niet omdat het niet zou werken, maar om mogelijk conflict te vermijden.

Identifiers dat met een _ beginnen worden namelijk intern in de std gebruikt. Als je bijvoorbeeld kijkt naar http://www.sgi.com/tech/stl/string zie je dat alles daar begint met '_'

Zo staat er ergens intern in std:: string
Code:
 struct _Not_within_traits

Stel dat jij in je code het volgende doet:
Code:
 int _Not_within_traits;

Ga je errors krijgen, wat vreemd lijkt op het eerste zicht aangezien
Code:
int a;
geen problemen veroorzaakt..
Code:
#include <iostream>
#include <string>

int main(void)
{
    int _Not_within_traits;

    _Not_within_traits = 1;

    std::cout << _Not_within_traits << std::endl;
}
Code:
jensen@atlantis:~/Desktop$ ./a.out 
1
Uw eerste regel van uwe cursus is in theorie fout, omdat een _ wel mag. Echter wordt er algemeen aangenomen om variabelen die met een _ beginnen voor te behouden voor std. Het is niet verboden en het kan geen kwaad maar het is nu historisch eenmaal zo gegroeid. Hetzelfde geld voor een dubbele _ en een hoofdletter. (__reserved, _reserved, Reserved)

In Java wordt er aangenomen dat functies met een kleine letter beginnen, en sommige frameworks gaan blijkbaar van die veronderstelling uit, maar in theorie mag je functie met een hoofdletter beginnen. Dat wordt echter ook overal afgeraden.

Manjak

Legacy Member
Hm, dat is nu al de 2e grote fout dat ik maak in korte tijd. Mijn excuses.

Zal, als ik nog is post, er is proberen wat langer over na te denken.

Thx voor de verbetering Tyfius.

Tyfius

Legacy Member
Manjak zei:
Hm, dat is nu al de 2e grote fout dat ik maak in korte tijd. Mijn excuses.

Zal, als ik nog is post, er is proberen wat langer over na te denken.

Thx voor de verbetering Tyfius.
Beter dat men denkt dat het niet werkt dan dat men het misbruikt. :)

Gurdt

Legacy Member
@TS: ik heb zulke regeltjes ook gekregen ooit, het is niet dat het allemaal niet zou mogen, maar het gaat hem erom dat er conventies zijn waar je je best aan houdt. Zo is het allemaal voor iedereen leesbaar enzovoort.

Een andere conventie is de naam van een member variabele te laten beginnen met 'm_' of '$'. Ik verkies eigenlijk dat laatste (zoals enkele proffen ook dus het is niet dat het niet mag ofzo) omdat dat vind ik het meest leesbaar is :)
(en ook omdat ik een azerty toetsenbord heb en die _ altijd zo debiel ver staat =D ik haat dat teken om de een of andere reden :') tja)

Tyfius

Legacy Member
Met die $ moet je toch opletten.
Code:
jensen@atlantis:~/Desktop$ g++ test.cpp -pedantic
test.cpp:5:6: warning: '$' in identifier or number
Als je dan een of andere lint tool aan je compilatie proces gaat hangen heb je het vlaggen.

Gurdt

Legacy Member
Tyfius zei:
Met die $ moet je toch opletten.
Code:
jensen@atlantis:~/Desktop$ g++ test.cpp -pedantic
test.cpp:5:6: warning: '$' in identifier or number
Als je dan een of andere lint tool aan je compilatie proces gaat hangen heb je het vlaggen.

Nooit van gehoord? Het is nu wel zo, dat dat enkel met Java wordt gebruikt, zou dat het verschil kunnen maken?
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan