Constanten

ALLES_IN_HOOFDLETTERS

Merendeel constanten trouwens. Wel fijn als alles z'n eigen namespace heeft.

if($foo->status == Model\Foo::STATUS_BAR) ...

(voorkomt ook dat je binnen de class altijd enorme prefixen nodig hebt - dan is het gewoon self::STATUS_BAR).

Zonder leestekens en andere context kun je zó al in een oogopslag zien wat iets is:

- FOO_BAR : constante
- foo_bar : variabele/parameter
- FooBar : klasse
- fooBar : functie/methode

Merk op dat het uiteindelijk je eigen keuze is.

Of je je constante FOO_BAR noemt of foo_bar of FooBar is aan jou ... tenzij je in een team werkt en andere afspraken hanteert.

Wel is het vaak zo dat voor constanten alleen hoofdletters worden gebruikt. Op die manier zie je direct dat het om een constante gaat. Dus als ik je zou mogen adviseren, zou ik zeggen gebruik alleen hoofdletters, maar als je zelf iets anders prettiger vindt werken dan mag dat ook, zolang je het maar consequent toepast.

Dan lijkt mij de aanpak van @Ward beter en breder geaccepteerd. Waarschijnlijk is dit ook een standaard of dit formaat zal in ieder geval vaak herkend (en mogelijk ook onbewust gehanteerd) worden.

Misschien is ook een betere of minstens zo interessante vraag wanneer je constanten zou moeten inzetten. Ik zou hier terughoudend in zijn, het is lang niet altijd nodig om een variabele met een constante waarde maar te bombarderen tot constante.

Een eigenschap van constanten is dat deze een universele scope hebben. Wanneer je dus (de waarde van) een variabele (die constant is) in meerdere scopes gebruikt, dan zou dit een argument kunnen zijn om hier een constante van te maken.

@Thomas

>> Dan lijkt mij de aanpak van @Ward beter en breder geaccepteerd.

Beter en breder geaccepteerd dan wat?

>> Misschien is ook een betere of minstens zo interessante vraag wanneer je constanten zou moeten inzetten.

En hier je eigen antwoord :)

>> Een eigenschap van constanten is dat deze een universele scope hebben.

Je kunt ze in een class gebruiken als class constants. Ze worden vaak gebruikt om default waardes in te stellen. En in globale zin kun je ze gebruiken om bijv. een DEVELOPMENT_MODE in te stellen of een APPLICATION_PATH. Maar in het algemeen gebruik je ze inderdaad zo weinig mogelijk.

Ozzie PHP op 29/08/2020 22:58:23

Beter en breder geaccepteerd dan wat?

Dan foo_bar of FooBar. Dat zorgt voor verwarring. Ontbreekt daar een $ of methode- of class-haken? Of wordt daar toch een constante bedoeld? Hoe dan ook, deze schrijfwijze zet je elke keer dat je die code ziet aan tot nadenken.

Als je bij ontwikkeling niet alert bent dan sluipen er mogelijk ook fouten doorheen door dit soort schrijfwijzen. Bij FOO_BAR is het meteen duidelijk en "zelfdocumenterend" door de vorm, het valt ook gewoon op vanwege de blokletters.

Je zou ook consequent een BrEeZaH-schrijfwijze kunnen hanteren, maar simpelweg iets consequent (op een onhandige manier) schrijven is nou niet bepaald een zelfrechtvaardigend argument.

edit

Ozzie PHP op 29/08/2020 22:58:23

Je kunt ze in een class gebruiken als class constants.

Die zijn toch ook overal beschikbaar? Het feit dat ze in een klasse staan gedefinieerd doet hier niets aan af?

>> ... is het meteen duidelijk en "zelfdocumenterend" door de vorm, het valt ook gewoon op vanwege de blokletters.

Klopt, ik gebruik het ook en ik raad het ook aan. Maar het is geen verplichting. Misschien wil iemand graag FoO_BaR gebruiken. Dat kan en werkt ook. Ik bedoel te zeggen dat het soms lijkt alsof sommige zaken 'regels' zijn, terwijl het in feite handigheden zijn. Ja, ik raad in dit geval ook aan om hoofdletters te gebruiken, maar het is geen verplichting. Het is niet zo dat je code ineens niet meer werkt of slechter wordt als je niet alles in hoofdletters schrijft.

>> Je zou ook consequent een BrEeZaH-schrijfwijze kunnen hanteren, maar simpelweg iets consequent (op een onhandige manier) schrijven is nou niet bepaald een zelfrechtvaardigend argument.

Hehe lol ... dan bevind je je op een vlak van wat onhandig is. Misschien vindt iemand BrEeZaH wel handig, leuk of grappig en kan dat voor hem/haar een reden zijn om het wel zo te doen. Het is net zo consequent als BREEZAH.

>> Die zijn toch ook overal beschikbaar? Het feit dat ze in een klasse staan gedefinieerd doet hier niets aan af?

Jawel, maar dan roep je ze aan in relatie tot een class. Universele constanten kun je altijd gewoon in het wilde weg overal aanroepen. Daarom wordt het ook afgeraden, omdat er niet een bepaalde context/scope is.

PSR-1: Basic Coding Standard:

• Class names MUST be declared in StudlyCaps.

• Class constants MUST be declared in all upper case with underscore separators.

• Method names MUST be declared in camelCase.

Het is maar een Recommendation, dus als je denkt dat je het beter weet, kun je ervan afwijken...

HOOFDLETTERS. Dan weet je meteen dat het een constante is.

Even andersom: het is altijd leuk als iedereen zich aan "een" standaard houdt, maar in de praktijk blijkt iedereen vaak een "eigen" (bedrijfs-) standaard te hebben ("als je denkt dat je het beter weet, kun je ervan afwijken...") (of zie bijv. ook de WordPress en Joomla coding standards). Het kan dus ook geen kwaad om een beetje "flexibel" te zijn in hoe code aan je "gepresenteerd" wordt, en ook hoe je code schrijft (code voor de ene klant moet in een andere "dialect" dan voor de ander; je moet dus vrij eenvoudig "om kunnen schakelen").